19:01:54 #startmeeting network health team meeting, 10 february 2020 19:01:54 Meeting started Mon Feb 10 19:01:54 2020 UTC. The chair is gaba. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:54 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:02:05 the pad is here: https://pad.riseup.net/p/tor-networkhealth-2020.1-keep 19:02:30 you could add your status in line 33 of the pad if you have any for this week 19:02:41 and please add anything to the agenda you may need 19:05:10 (hello world, i am around in case needed. catching up on things. i think i might have a funder phone call in 25 minutes.) 19:05:37 o/ 19:05:43 first item in the agenda is the roadmap for Q1 19:06:18 we added a few tickets to the list and geko created the ones that we need. You can see that we are using the keyword network-health-roadmap-2020Q1 in trac 19:07:09 we will review this roadmap at the end of April 19:07:37 the second item is also an annoucement of the gsoc projects that pili is sending 19:08:57 and the 3rd item in the list is about metrics queries for GoodBadISPs. RotationMatrix: is that your topic? 19:09:41 yes 19:10:15 what is that you want to discuss? 19:10:24 working on improvements for GoodBadISPs. Wondering which would be good queries to use. 19:10:31 rotationmatrix is working on this https://dip.torproject.org/torproject/web/community/issues/72#note_483 19:10:50 thanks ggus! was just about to grab that. 19:11:15 great! this may be something to bring to Thurday's meeeting from the metrics team 19:12:02 adding it to the agenda for Thursday: https://pad.riseup.net/p/tor-metricsteam-2020.1-keep 19:12:17 perfect 19:12:37 In principle this would be some kind of mapping from ISPs to stats that Metrics holds about relays using those ISPs? 19:12:55 E.g. count? bandwidth? exit or not? age? 19:13:15 And turned into some kind of score to help people work out where to host their own? 19:13:23 we want to improve the GoodBad ISPs page using the information about good isps from metrics. so we need to think how using metrics info we could determine if an ASN is good: number of relays? network diversity (OS?)? bandwidth? 19:13:31 There is already a suggestion from irl in that ticket 19:13:49 dennis_jackson: yep 19:15:00 dennis_jackson: we have too many relays in 5 ASNs 19:15:13 planning on linking all ASNs to relay searches per irl's suggestion. debating whether to use a normal search or aggregate. 19:15:49 Ah, I didn't know it was so unbalanced, that's interesting. 19:15:49 examples: 19:15:52 https://metrics.torproject.org/rs.html#search/country:at 19:15:54 https://community.torproject.org/relay/technical-considerations/ (see AS/location diversity) 19:15:58 https://metrics.torproject.org/rs.html#aggregate/all/country:at 19:16:04 other idea: link back to these metrics from inside atlas, so when people see a relay, they know immediately that it's in an overrepresented place 19:16:52 (as opposed to having to think of the idea on their own and go find the metrics diversity graphs themselves) 19:17:05 atlas is the new metrics.tpo? or we still have another thing called atlas? 19:17:15 yes. "relay-search" i think is its new name. 19:17:28 atlas.torproject.org sends you to https://metrics.torproject.org/rs.html 19:17:35 not to be confused with relay search, an unrelated previous thing that did something else 19:18:20 it would be nice to have the good bad isps page in a more machine-friendly format 19:18:43 this data is crying out to be mashed up but a wiki page isn't great for doing that with 19:19:02 (not only that, but the wiki doesn't let most people edit the page, because it has too many links in it so you are a spammer) 19:19:04 irl: i was thinking to keep the goodbadisp page in wiki, since the community can collaborate more freely, which also means outdated info... 19:19:43 ggus: arma seems to disagree that it helps you collaborate more freely 19:20:18 but machine readable doesn't need to mean not on the wiki, for example the metrics timeline is a wiki page but we are strict with the formatting of the table and have scripts for parsing it 19:20:20 well, you need to solve a captcha or deal with PRs and GitHub. 19:20:38 https://trac.torproject.org/projects/tor/wiki/doc/MetricsTimeline 19:21:12 machine readable is also going to help with having a better framework for comparing isps, identifying common pathologies, etc 19:21:23 right now it's all pretty free text and open 19:21:39 Oh man, that timeline is incredibly useful and I had no idea it existed 19:22:02 (thanks irl) 19:22:17 we include data from the timeline underneath metrics graphs, we could include good bad isps data on relay search if it were equally accessible to us 19:24:10 irl: do you think it makes sense to continue discussion in the ticket or in the meeting with karsten? 19:24:49 good bad isps is a network health topic, metrics will consume the data if it is presented in a consumable form 19:24:59 if there are questions about how to make it consumable, please ask on the metrics-team@ list 19:25:21 ok. sounds fair 19:25:58 rotationmatrix: are you ok sending a mail to metrics-team@ ? 19:26:01 about the queries 19:26:06 sure I can do that 19:26:09 thanks! 19:26:15 awesome, thanks for your work on this! 19:26:22 i'm going to end the meeting now if there is nothing else 19:26:25 np! :) 19:26:37 #endmeeting