16:00:57 #startmeeting network-health 16:00:57 Meeting started Mon Apr 19 16:00:57 2021 UTC. The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:57 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:01:02 hello everyone! 16:01:06 hello! 16:01:11 o/ 16:01:18 we have a new week, and thus a new network-health meeting 16:01:29 hi! 16:01:31 our pad is at http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/tor-nethealthteam-2021.1-keep 16:01:44 gaba: you around, too? 16:03:02 o/ 16:03:38 hi gus! 16:04:53 okay, let's get started 16:05:11 i've one item i thought about talking a bit 16:05:36 i've finally found time to start updating our team wiki 16:05:55 the landing page is in shape: 16:05:56 https://gitlab.torproject.org/tpo/network-health/team/-/wikis/home 16:06:07 and there i put some priorities for 2021 16:06:20 let me know if things should get added there 16:06:35 or if we want to set (slightly different prios) 16:06:38 yes 16:06:39 hi! 16:06:44 o/ 16:07:14 this week i'll work on the bad-relays criteria page 16:07:29 i need to clean this more up and focus on the criteria and how we apply them 16:07:34 that is nice 16:07:46 ggus: it would be nice if we could chat a bit about that topic at some point 16:07:59 because there is a community page, too, about bad-relays 16:08:04 I guess there should be 6 areas that network health focuses on, because Metrics is missing 16:08:24 GeKo: yes, sure. i didn't have time to read the latest wiki page 16:08:26 ah no, it's number 3, just using different words that didn't immediately recognise 16:08:32 but i'm happy to update the community portal one 16:08:32 yeah 16:08:42 irl: let me know if you have better words 16:08:47 or just change the wiki :) 16:09:10 ggus: the latest wiki page is a slightly cleaned-up version from the old trac one i believe 16:09:36 i have some ideas about splitting up the content for the team wiki page and the community portal 16:09:36 yeah i'll write up some text that covers what I think the metrics team did before, and see how much of it can fit in there 16:09:43 irl: we were thinking of integrating metrics as a goal for this year 16:09:49 ggus: we could maybe chat about that tomorrow 16:09:52 ? 16:09:52 we can have new goals metrics related for next year 16:10:26 GeKo: yes, wfm 16:10:43 yes, i think for 2021 its mainly integrating metrics into network-health and figuring out a good workflow 16:10:56 maybe making progress on high-level metrics goals 16:11:03 yes 16:11:07 ggus: great. i'll ping you 16:11:41 yeah i don't want to add new goals, just cover the things that already exist and should keep existing 16:13:19 okay 16:13:39 hm, i had another item which the pad ate 16:13:58 i wonder where we want to put issues related to the dir-auths 16:14:38 tpo/core/tor#40368 comes to mind 16:14:55 dgoulet: there is a dir-auth project in tpo/core 16:15:03 would that be a good place? 16:15:13 or should we have that somewhere in network-health land? 16:15:34 i am not sure what that dir-auth project is for, actually 16:15:35 yeah I think so, that DirAuth project I think was created originally for the tools in dirauth conf and anything that we need to do on the dirauth side like add a new parameters and what not 16:15:42 so moving that to health seems good to me 16:15:53 since core/ doesn't really use it nor notice it :P 16:16:05 yeah 16:16:26 okay, i'll move it later then and probably write a mail to sina 16:16:54 okay, anything we should discuss related to anyone's updates? 16:18:28 then let's move on to the discussion part 16:18:46 dgoulet: i guess we need to further postpone the libressl thing? 16:19:06 (that is you helping nick to help) 16:19:11 yeah... that one is hard 16:19:20 i know :( 16:20:10 so be it 16:20:15 dennis_jackson: you are up 16:20:33 I'm a little concerned about the v2 switch-off, from a network-health perspective. 16:21:00 Am I right in understanding that when the new stable hits in July, relays will no longer handle v2 requests from clients? 16:21:23 Or is the new stable only disabling v2 on the client and on the hs's client? 16:21:46 the former 16:22:03 every v2 requests won't work _except_ rendezvous 16:22:18 So if a substantial amount of traffic is still on v2, it will become concentrated on the relays which are slower to upgrade? 16:22:33 correct 16:22:53 that is why we plan to also release stable (for other versions) a bit after to also stop v2 16:23:58 So this has been thought of and we anticipate a gradual switchover? 16:24:08 If so, cool. I didn't find a ticket which is why I wanted to raise it 16:25:04 yeah there might be a situation where many services converge to few intro points/HSDir but at least rendezvous where the bigger load happens will still work for all relays 16:25:36 but yeah, it might be rough 16:25:59 is there anything we can help with form the network-health side? 16:26:02 any reason that we didn't have a consensus parameter to just turn off v2 services one day? 16:26:28 no reason I recall 16:27:12 GeKo: dunno, yet, I haven't thought this through about what health team can do but overload line might start to pop more during that time? I'm not sure tbh since load on intro/hsdir is really not that much but maybe 16:27:41 yeah 16:28:02 might be just a bumpy ride and we need to bite the bullet... 16:28:20 Worst case, we get some fun data to look at. 16:28:29 (but also some sad users and relay operators) 16:28:30 :) 16:28:31 yeah it might be bumpy 16:28:33 :( 16:28:35 in different ways... 16:29:08 but that is what it is, network won't crash, I mean v2 traffic is still a tiny portion of what we are seeing and we'll roll out releases removing v2 16:29:31 and worst case it crashes our Pi4 relay which personally I wouldn,t mind lol :P .... but yeah, 2021 will be interesting 16:29:43 dgoulet: anything related to metrics that we should pay attention to wrt to v2? 16:29:43 dennis_jackson: i liked the experimental analysis pipeline you put up in tpo/metrics/statistics#40002 16:29:51 thanks for doing that 16:29:52 having v3 traffic 16:29:56 would be important 16:30:03 very exciting and seems a cool way forward 16:30:04 in different graph (line) 16:30:09 keep poking at it :) 16:30:09 yeah go dennis_jackson !! 16:30:15 +1 16:30:20 thanks / np! :-) 16:30:34 as network will move to 0.4.6 (and historically more than half upgrade in less than 2 months) 16:30:34 It's pretty hacky, but I think using that pipeline / style would alleviate a lot of pressure on the metrics team / person 16:30:50 if v2 traffic stays the same, we need to definitely check if relay overloading becomes a thing 16:31:33 the likely big catalyst also for "something exciting" will be when TB ship without v2 stable :) 16:31:36 anyway 16:32:17 dennis_jackson: yep 16:32:24 dgoulet: cause the few remaining relays would get all the v2? 16:32:48 dennis_jackson: i think the plan is moving (slowly) towards that 16:33:19 yanmaani: that is definitely one problem, but also most clients unable to reach v2 might bring unhappy people, rants, relay operators not upgrading, etc... 16:34:03 I worry would have would be if it drives v2 users to switch to another browser or client config 16:34:29 e.g. Brave, older Tor Browser 16:34:40 won,t help much if the network doesn't allow you though hehe 16:35:11 Well if you were a bad person, you'd find it easier to scoop all the v2 traffic I guess, but that's pretty speculative 16:35:20 yes... 16:35:22 definitely 16:35:32 okay, do we have anything else to discuss today? 16:35:43 nothing from me 16:35:52 i'm good. 16:35:53 that is mostly why we will release all maintained version to cut it off so we dn't have relay that can hang around for many years supporting v2 16:35:56 * dgoulet is good 16:36:04 nothing from me 16:36:08 fine 16:36:15 * ggus reading about dennis_jackson experimental analysis pipeline 16:36:20 * gaba too 16:37:01 k, thanks everyone. have a nice week 16:37:05 cool! feel free to ping me if you have questions 16:37:05 #endmeeting