16:59:23 #startmeeting Network team meeting, 28th March 2022 16:59:23 Meeting started Mon Mar 28 16:59:23 2022 UTC. The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:59:23 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:59:25 yo yo 16:59:31 o/ 16:59:37 first day of me being very confused about summer time since it changed in the weekend 16:59:42 o/ 16:59:48 yello 16:59:48 hi! 16:59:53 pad is at https://pad.riseup.net/p/tor-netteam-2022.1-keep 17:00:06 o/ 17:00:10 o/ 17:00:14 giving folks a few to join 17:00:52 hihi 17:01:42 how are you all doing with your boards: https://gitlab.torproject.org/groups/tpo/core/-/boards ? 17:01:54 o/ 17:02:23 no trouble; kinda blocked on a few things, but not blocked on a few others 17:03:31 does that mean that you are blocked on less-than-a-few-others or ? :o 17:03:47 like we need to coordinate some unblocking or is that already happening? XD 17:04:31 it's happening; I just have to do a lot of context switching 17:05:20 oki, let me know if i can help there with some coordination 17:05:24 ok i don't spot anything off here 17:05:40 nickm: Sorry about my contribution (delay on 433) 17:05:43 dgoulet: you have Good News Everyone on release stuff 8) 17:06:12 0.4.7.5-alpha was released on friday! so far so good 17:06:20 very nice 17:06:20 and we hope it is the last alpha before the road to stable! 17:06:27 Diziet: s'ok, it'll be fine 17:06:33 that is about it... as for ETAs on that stable, unclear but I suspect "faster than usual" 17:06:46 pretty much it 17:07:41 very good 17:08:15 i don't see anything incoming from other teams. we have the DoS discussion that is still ongoing on the private ticket, which is good, but otherwise nothing seems like it needs our attention here and now 17:08:49 no announcements or anything. this is the last meeting in march, so next week we have the s61 standalone meeting 17:08:54 mikeperry: you wanna talk s61 now? 17:09:02 ok yeah 17:09:45 so I updated the sim plan with all the stuff that has been one for the alpha, the stuff to do pre-stable, and the stuff post-stable 17:09:49 https://gitlab.torproject.org/mikeperry/tor/-/blob/cc_shadow_experiments_v2/SHADOW_EXPERIMENTS.txt#L1183 17:10:25 the last thing for the stable that I want to check is large downloads, to make sure that throughput remains the same long-term 17:10:37 hiro is working on that in https://gitlab.torproject.org/jnewsome/sponsor-61-sims/-/issues/15 17:11:40 I relocated the utilization CDF graphs for post-stable, since the large-download test was more important, and after other sim runs, we only need the utilization stuff to check our calibration with the lvie network 17:11:52 and to support further tuning post-congestion control 17:12:22 GeKo: this is partly why I dropped your question about the analysis graphs; I am thinking we can discuss that next week 17:13:10 it is looking to be fairly involved to parse and extract all that data, and the large-download test is much simpler and more immediately useful 17:13:25 okay, sounds good 17:13:49 juga: I did some commenting on the sbws congestion control MR and ticket, as you saw. it is looking good so far 17:14:20 mikeperry: ok, i didn't work much on that last week 17:14:40 (just cause other stuff) 17:14:48 yeah np 17:15:24 I think we're in good shape tho 17:15:35 ok 17:15:51 this week I hope to finally write those unit tests for flow control and the CC alg test vectors, heh 17:16:23 there is a small risk that the large-bandwidth result might require some tweaking, but hopefully not 17:17:07 does anyone have any questions? I don't have much else 17:17:18 * juga is good 17:17:30 just a quick note 17:17:33 the meeting will be Apr 4th, 15utc 17:17:53 i've been crunching overload data we accumulated over the months, see: https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/24 17:17:57 and https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/27 17:18:08 i think things are not looking unresaonable 17:18:30 in particular with the ntor onionskin fix being the likely culprit for the things we saw in analysis#27 17:18:36 oh are we gonna backport the ntor onionskin fix to 0.4.6? 17:18:57 i do think given all of that we should use the 18h window for nethealth purposes 17:19:02 and on relay-search 17:19:12 it gives us less noise and better data overall 17:19:23 and is thus less confusing to relay operators 17:19:41 if that sounds good then i can file tickets and we can get that going 17:19:52 this might be a ticket for hiro for the relaysearch portal? hiro did the first version of that? 17:20:00 yes 17:20:12 and i need to adapt the overload monitoring tools 17:20:34 other than that i am good 17:21:04 dgoulet: for the backport above? 17:21:33 I'm not entirely sure... 046 is EOL "soon" so unclear if this would worth the work. Maybe if this just comes up all the time on our 046 relays? 17:22:17 we can cut down the noise with the 18h overload window in our netork health tools 17:22:41 so, not too urgent from that side 17:23:36 ack 17:23:43 maybe flag it for backporting and then we can evaluate if we need to roll a release anyway? 17:23:48 dgoulet: fwiw, even if the large-bandwidth test shows a bad result, that would be a change that won't impact anything until cc_alg=2 is set 17:23:48 the change wasn't huge iirc 17:24:07 ahf: +1 17:24:12 so in theory we can already start planning rc and stable fairly quickly, just to get it out and start the switch from 046 17:24:48 mikeperry: yeah that is basically what I was hoping for 17:26:06 ah, you want to roll people over to 0.4.7 here as part of this 17:26:23 yeah... 17:26:44 well, perhaps instead of bothering with backports, yeah. and to open the merge window for 048 stuff 17:27:46 FWIW, if we do not change our support policy, the EOL date for 046 will need to change: 17:28:05 yes, that is gonna be a bit grim (048 merge window) 17:28:05 our policy has been that we support releases for 9 months, or until 3 months after the next release is stable, whichever is later 17:28:13 ah 17:28:16 yeah 3 months after stable is what I had in mind 17:28:19 great 17:28:35 that would argue for a backport of the ntor overload thing maybe? idk 17:29:03 plausible 17:29:43 we should have good overload stats going at the point of cc_alg=2 17:29:53 to make sure that it's not making things worse 17:30:17 so if 046 is still in the picture, we should backport the overload thing before cc_alg=2 17:30:54 ok 17:31:02 anyway we have a bit of time to think about that and let it bake in 047 17:32:18 I think that's all for s61 then? 17:32:33 nice 17:32:41 <-- is still good 17:32:51 anything else we need to talk about whilst we are all here? 17:33:08 if i am off by a bit in meetings this week, please prod me. it takes me a few days to switch over 17:34:17 My timezone tip again: if using muggle-style calendaring tools rather than Unix-TZ-style ones, set the "location" of your meetings to Reykjavik. 17:34:53 Iceland use UTC all year round. That avoids the thing where the muggle tools say "UTC" but mean "London time" 17:35:06 i have my google calendar copies of our meetings set to UTC so my phone is mostly right, but sometimes i don't listen to my phone's *beep* 10 min before a meeting 17:35:22 but yes, good point with iceland 17:35:38 ok folks, i am gonna call it for now. see you all at all the other meetings during the week and on thurday for our sync 17:35:39 o/ 17:35:40 #endmeeting