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