16:59:15 #startmeeting Network team meeting, 7 March 2022 16:59:15 Meeting started Mon Mar 7 16:59:15 2022 UTC. The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:59:15 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:59:17 hello hello 16:59:20 whoa hi! 16:59:21 Afternoon 16:59:34 o/ 16:59:41 o/ 16:59:41 hello hello 16:59:52 pad is at https://pad.riseup.net/p/tor-netteam-2022.1-keep 17:00:59 giving folks a few to join in 17:01:04 o/ 17:01:10 o/ 17:01:32 how are folks doing with their respective boards on https://gitlab.torproject.org/groups/tpo/core/-/boards ? 17:01:59 i have 2 huge items and am tryint to move ahead with them :) 17:02:22 i am super stuck by grant crap, but i think i will recover once we are done with this week... 17:02:24 I have 4 tickets which are all somehow aspects of the same thing... 17:02:28 nice 17:02:47 good 17:03:37 can't see anything fishy 17:03:47 dgoulet: anything on releases? 17:03:48 eta: Can you move what you're working to into "doing"? 17:04:07 still working on 047 tickets that need to be in before stable but no ETA for next one 17:04:38 nickm: done 17:04:43 ty! 17:04:45 * eta has arti!90 and not much else 17:04:46 ok i do see something bad 17:04:47 hm 17:04:49 uh, arti#90 17:04:55 * ahf moves tor#40395 out of doing 17:05:41 ok, now i think is all OK 17:05:49 dgoulet: perfect 17:06:17 dgoulet: i'll let you do the wiki entry update for CoreTorRelease when you have an idea about stable estimate 17:06:26 for sure 17:06:36 https://gitlab.torproject.org/tpo/core/tor/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Backport 17:06:43 looks like our backport situation is alright 17:07:06 maybe once we are out of the 0.4.7 stable period we can take a look at these and make the plan for them? 17:08:33 ok, thanks to nickm there has actually been made progress to a tpo/core/team ticket this period! 17:08:50 core/team#19 is in a much better place now 17:08:56 ahhh 17:08:57 but i think it still doesn't do all the stuff we wanted 17:09:05 so lets keep it open for now 17:09:12 sounds good 17:09:21 otherwise i don't think any of us had time for any of these things 17:10:07 i only see one new ticket from other teams which is something jnewsome found during shadow experiments with onion services with timeouts 17:10:12 looks like there is activity on that one still 17:10:28 we have no reminders, no announcements 17:10:57 mikeperry: yo, so since we didn't do s61 A/V meeting today, should we keep the sync here ? 17:11:02 yeah 17:11:10 (remember all the s61 meeting is next monday at 15 utc in the usual bbb) 17:11:18 mikeperry: excellent, you can take over now then 17:11:34 yep, I moved the meeting since several s61 ppls are out today 17:12:11 so last week, jnewsome added the ability to simulte mixed networks, with a percentage of Exit bandwidth running 0.4.6 17:12:33 we ran a sim with 50% Exit bandwidth on 0.4.6, and 50% with congestion control enabled 17:13:06 so negotiation was exercised, and we got to see how congestion control should behave at that level of exit upgrade 17:13:40 the results are surprisingly promising.. the old 0.4.6 traffic did not choke out the congestion control circuits, which was one major concern with the upgrade 17:13:45 so that is great news 17:13:53 very nice 17:14:08 I ran two more sims with 75% 0.4.6 and 90% 0.4.6 over the weekend. I am still downloading those results to look at them 17:14:26 quite epic indeed 17:14:43 that was your big concern after the patch was merged right? so this is really good news in general 17:15:26 yeah. there was a chance that we would need to wait for a lot of Exits to upgrade before turning it on at all, or there might be no benefit (or worse, degredation) 17:15:36 nice 17:16:06 but at the 50% point, there is still an improvement in perf with congestion control, and no instances that I can see of circuits being choked out by the old alg 17:16:25 sweet 17:17:30 I need to record these results and update the sim plan, but this was a very good result. it should move up our timeline a bit wrt turning the thing on 17:18:20 nice 17:18:24 I also did a patch for sbws for the CIRC_BW fields: https://gitlab.torproject.org/tpo/core/tor/-/issues/40568 17:18:50 it looks like juga was able to test that with our network-health exit 17:18:58 yes 17:19:32 juga: those fields are the client's view of congestion control. so they will only update during upload activity 17:19:46 upload, not download? 17:20:15 I had a minor brain fail juggling all of these things for the alpha and forgot to mention that in the spec patch 17:20:26 :) 17:21:07 yeah.. if it is a huge problem for sbws to upload instead of download, then hrmm.. I will have to think about what to do 17:21:18 ok 17:21:36 right now there's no easy way to see the congestion control state of an exit from the client (which is the download direction -- the exit is controlling it) 17:22:47 there is also the question as to if upload is a good enough measurement for sbws.. in theory it *should* be exactly the same as a download.. but in practice maybe there's implementation quirks that make it different :/ 17:23:38 if you think it's worth trying upload, we can try it 17:25:02 the advantage of upload is also we can get hints if any of the bw auths do not have enough bandwidth to measure circs.. in that case, they will cause Exits to start sending XOFF 17:25:07 which we can watch for in the logs 17:25:15 so maybe upload is the way to go 17:25:29 ic, i can try it in a branch 17:25:29 just makes me a little nervous that it is different than what we have always been doing, ofc 17:26:37 maybe I should also add an XOFF field to STREAM_BW.. sbws listens to that yeah? 17:26:45 anyway we should chat after this meeting 17:26:54 ok, let's chat later 17:27:52 :-) 17:28:40 dgoulet is still working on the overlod patch, I take it? there was the additional piece of making sure the descriptor updated if overload continued.. so we get fresh timestamps indicating fresh overload 17:28:52 right, should be one very soon 17:29:34 GeKo: anything for network-health? 17:29:43 just two small things 17:30:03 we have one exit on 0.4.7 with CC enabled that we can test with.. do we know if torralf or others have updated to it yet? 17:30:18 i started creating a laundry list of things to check when we want to analyze some performance issues 17:30:24 e.g. due to ddos 17:30:43 i put that on the wiki 17:30:53 so we don't always start from scratch 17:30:56 https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Tor-network-health-work#investigating-network-performance-issues 17:31:08 if things are missing, let's add them there 17:31:35 the other thing i that i organized our net health analysis work into a separate project 17:31:57 it collects all analysis issues related to netw ork health in a central place 17:32:06 https://gitlab.torproject.org/tpo/network-health/analysis 17:32:09 ah, yeah. wrt ddos there were some analysis tickets we had to find relays that were consistently showing up in slow paths in onionperf 17:32:21 so in case you are wondering where issue X you filed might have landed 17:32:49 yeah, something like that would be useful 17:33:19 if there are tickets missing in that analysis project feel free to add them 17:33:25 that's all from me 17:33:47 ok I can try to dig thru my history to find what I am talking about. I'll chat with you and juga after this 17:34:18 sounds good 17:34:23 i am afk for a bit, though 17:34:27 but sure 17:35:34 anything else we need to dive into? 17:35:41 I will likely also be somewhat distracted by grant things this week, with ahf. so most likely I'll just be doing followups on things, and organizing the sim plan this week. maaaybe I'll have time to start unit tests, since our params are looking solid 17:36:20 that's it for s61 I think 17:36:30 yeah, crossing fingers we will return to more normal days later this week 17:36:37 mikeperry: awesome 17:36:46 anybody who have anything else we need to chat about for this meeting? 17:37:02 * dgoulet is good 17:37:26 * GeKo too 17:37:51 let's call it then 17:37:54 thanks all for joining! 17:37:56 #endmeeting