17:01:15 <nickm> #startmeeting network team, 10 May 2021 17:01:15 <MeetBot> Meeting started Mon May 10 17:01:15 2021 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:15 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 17:01:21 <asn> o/ 17:01:22 <dgoulet> o/ 17:01:24 <nickm> hi all! who's here for the meeting today? 17:01:32 <gaba> hi all! 17:01:33 <jnewsome> o/ 17:01:36 <asn> hellooo 17:01:49 <nickm> woo, so many folks! 17:02:25 <nickm> we don't have ahf right now, so I'll press on forward. Please follow along with the meeting pad at https://pad.riseup.net/p/tor-netteam-2021.1-keep and make sure I don't miss things. 17:02:36 <nickm> first off we look at the kanban 17:02:52 <nickm> https://gitlab.torproject.org/groups/tpo/core/-/boards 17:03:01 <nickm> anything not looking good there? 17:03:19 <asn> good for me 17:03:26 <dgoulet> yes 17:03:44 <nickm> great 17:03:53 <nickm> next we get to harder stuff: 045 and 046. 17:03:56 <nickm> Let's start with 045 17:04:39 <nickm> I see 3 things there assigned to me, 2 to dgoulet, 2 to ahf, 1 to mikeperry, 1 to guinness 17:05:30 <nickm> we should probably plan to fix or workaround all of these issues, since 045 is LTS 17:05:44 <nickm> are we on track to get these done before long? 17:06:15 <dgoulet> I hope so! 17:07:33 <nickm> I'm afraid I'm a bit baffled looking for a workaround or a fix on the second part of tor#40355 -- but that's not so bad since it's a compatibility issue with different versoins of msys stuff 17:08:09 <dgoulet> I guess some edge cases can't be always resolved... 17:08:15 <dgoulet> fine by me 17:08:33 <nickm> guinness hasn't shown progress on tor#40175 since taking the issue. maybe we should reassign? 17:08:47 <nickm> the "desired fix" here is to log a warning with the origin of the supposed bomb 17:08:56 <nickm> I can do that? 17:09:28 <dgoulet> it might be one of those bugs that is very hard to pin though so maybe moving it out of the milestone could be ok 17:09:45 <nickm> yeah 17:09:50 <nickm> anything else need to change? 17:10:14 <nickm> If not: On to 046! 17:10:28 <dgoulet> can't speak for the others but one of my ticket should be easy to resolve, the other one maybe less so, unclear yet but we'll see 17:10:37 <nickm> We have 2 unassigned tickets here, 3 owned by me, and 1 by ahf 17:11:01 <nickm> tor#40375 and tor#40379 aren't assigned 17:11:13 <dgoulet> nickm: maybe #40379 is OK considering your comment... :S ? 17:11:40 <nickm> ok, I'll suggest closing it 17:14:14 <nickm> I'll assign 40375 to myself long enough to write a diagnostic patch for roger to use 17:14:28 <dgoulet> ack 17:15:20 <nickm> ok, any announcements or discussion items this week? 17:15:32 <dgoulet> I don't have anything personally 17:15:35 <asn> neither do i 17:16:03 <nickm> nor I :) 17:16:15 <nickm> okay, time for S61 stuff, if mikeperry is here? 17:16:21 <mikeperry> yep 17:16:50 <mikeperry> next week we'll be re-running rob's perf experiment. geko posted to tor-relays 17:17:31 <nickm> for context: what will we learn? 17:17:37 <mikeperry> I need to dig into the congestion control negotiaation to have a list of exactly what needs to be negotiated still: https://gitlab.torproject.org/tpo/core/tor/-/issues/40377#note_2735134 17:17:56 <nickm> oh, i thought that was on me? 17:18:22 <mikeperry> nickm: well I can have a list of stuff that needs to be negotiated. not all of it has to. 17:18:28 <nickm> ah, got it 17:19:27 <mikeperry> wrt rob's experiment, we hope to learn some things about sbws vs torflow, and see if relays become overloaded with the same DNS timeout issue again, and also we have some better tools now to dig into specific bad perf that may result, and see if stuff gets better in othr cases 17:20:09 <mikeperry> basically the plan is to do this periodically and eventually use the overload lines and analysis to make the network faster, with these descriptor values 17:20:25 <mikeperry> rob has a machine to help us do this periodically over the next 6 months 17:21:12 <GeKo> i wonder whether the results of the first experiment are somewhere available 17:21:18 <mikeperry> this lays the groundwork for flashflow eventually (still not planned or funded; but this will find other bugs that may be in the way), as well as hopefully allow us to better utilize the network 17:21:32 <GeKo> regardless we should make sure they are for the second and subseqeuent runs 17:21:39 <mikeperry> we have a bunch of graphs and analysis from the last one at https://gitlab.torproject.org/tpo/metrics/analysis/-/issues/33076 17:21:51 <mikeperry> the stuff acute did in https://gitlab.torproject.org/tpo/network-health/team/-/issues/44 will also help 17:22:15 <GeKo> okay, that's good 17:22:17 <asn> yeah i also have some acute onionperf emails on my backlog that i havent got to them yet 17:22:47 <mikeperry> asn: I handled those, I believe. but worth a look over 17:23:24 <asn> there is onionperf#40024 17:23:29 <asn> that hasn't been handled yet i think 17:24:10 <mikeperry> yeah there is a metricsweb ticket I think that is about graphing stuff properly on metrics.tpo 17:24:26 <mikeperry> I think the output fro onionperf is sane, but metricsweb does not ignore stuff from before CBT yet 17:25:29 <mikeperry> https://gitlab.torproject.org/tpo/metrics/website/-/issues/40005 17:27:20 <mikeperry> I think that covers it unless there's more questions 17:27:54 <mikeperry> I am also still wrapping up the server thread and helping with vg-lite, so I will be a little delayed on that consensus param list, nick 17:28:07 <mikeperry> but hopefully the list itself is not so much a blocker 17:28:14 <nickm> no worries 17:28:38 <nickm> and if that wraps it up and there's nothing else, it's time to #endmeeting... 17:28:47 <nickm> going once... 17:28:50 <nickm> going twice... 17:28:58 <nickm> #endmeeting