16:58:17 <ahf> #startmeeting Network team meeting, 13 February 2023
16:58:17 <MeetBot> Meeting started Mon Feb 13 16:58:17 2023 UTC.  The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:58:17 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:58:20 <ahf> hello hello o/
16:58:24 <ahf> our pad is at https://pad.riseup.net/p/tor-netteam-2023.1-keep
16:58:33 <Emil[m]> o/
16:58:35 <dgoulet> o/
16:58:37 <gabi> hello!
16:58:40 <Diziet> o/
16:58:43 <ahf> today is our combo-meeting with both netteam meeting, then directly followed by s61 sync with mike!
16:58:58 <ahf> just giving folks a few to join
16:59:52 <mbeth> o/
16:59:54 <GeKo> o/
17:00:24 <ahf> okay, let's get going. we have no announcements, no discussion items
17:00:34 <jnewsome> o/
17:00:37 <ahf> how are folks doing with their boards: https://gitlab.torproject.org/groups/tpo/core/-/boards ?
17:00:38 <mikeperry> o/
17:00:44 <hiro> o/
17:01:08 <ahf> o/
17:01:10 <Diziet> My board seems OK to me.  There are tickets.  I even mostly know what they are and can work on them, so hooray.
17:01:32 <ahf> i don't see anything off with the boards either
17:01:35 <ahf> Diziet: very nice :D
17:01:48 <mbeth> i don't think i actually have any tickets assigned right now, i can take 40570 if nobody else wants it
17:02:31 <ahf> mbeth: maybe coordinate with david and mikeperry on that? i only see that mike moved it to ~Next the other day
17:02:38 <mbeth> k
17:02:43 <ahf> but i mean you are pretty deep in the DoS one 8)
17:02:50 <mbeth> :)
17:03:07 <gabi> I'm doing 40717 (which is linked with 40570) - let's coordinate on what needs to be done if you pick it up
17:03:14 <mikeperry> yeah, perhaps we discuss that stuff on thursday?
17:03:40 <mbeth> gabi: ok cool, i'm in no rush since i've got plenty else to look at
17:03:48 <nickm> hihi!
17:03:49 <ahf> sounds good - let's follow up on thursday then
17:03:51 <mikeperry> mbeth seems to be gravitating to dos things and gabi seems to be starting on 40570 was my take
17:03:51 <nickm> sorry im late
17:04:00 <ahf> dgoulet: anything noteworth on tor releases here?
17:04:03 <ahf> nickm: no worries!
17:04:24 <dgoulet> nothing on release side
17:04:31 <dgoulet> 2 days until 045 EOL ... but that is it
17:04:42 <dgoulet> we don't even have pending 045 fixes from the latest release so ..
17:04:51 <ahf> ... we should declare an international week of celebration when that goes end of life
17:05:10 <ahf> how much money on some massive bug discovered in the next 48 hours?
17:05:11 * nickm .oO{ viking funeral? }
17:05:19 <ahf> nickm: XD
17:06:10 <ahf> i don't see anything new from other teams that are unhandled
17:06:36 <ahf> okay, i guess that means people who aren't doing s61 things can return to their normal lives and mikeperry takes over the rest of the sync to talk about where we are on s61 things
17:07:26 <mikeperry> ok so dgoulet and I got conflux fully workign on d2d4 on Friday. we still need to flush out more bugs and then do some refactoring and cleanup
17:07:42 <GeKo> \o/
17:07:42 <mikeperry> but it is pretty close to shadow sim time. maybe another week
17:08:11 <mikeperry> jnewsome: we have not gotten notice about the sim runner moving yet, right?
17:08:26 <mikeperry> if we do, we should be sure to reserve 1 cloud runner for that period
17:08:27 <jnewsome> mikeperry: right
17:08:44 <mikeperry> but otherwise what we have is sfine for the first sims
17:09:15 <ahf> sweet
17:09:36 <mikeperry> hiro: I had missed your question re the other instances on https://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/40056#note_2871975
17:09:59 <jnewsome> mikeperry: maybe we should reserve some cloud runners either way for the extra capacity  (+ backup?)
17:10:01 <mikeperry> noticed that on saturday. we need the set I mentioned here: https://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/40056#note_2866988
17:10:10 <mikeperry> even tho that means changing the us and nl to 'a' instances
17:10:22 <mikeperry> we dont need op-hk7
17:10:33 <hiro> yep I am just working on that now
17:10:49 <mikeperry> ok great
17:10:56 <hiro> archiving old instances and setting up the new ones
17:11:46 <mikeperry> this will be useful for the next stages of https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/49
17:13:17 <mikeperry> juga: how are things with the PT load balancing? I also was too deep in confluxing to track that this past week. any new issues?
17:13:58 <GeKo> i wonder whether juga is around...
17:14:08 <juga> mikeperry: going good, meskio is going to parse the ratio
17:14:16 <juga> in rdsys
17:14:27 <juga> i already changed the api to pass the ratio
17:14:32 <GeKo> aha, they are :)
17:14:43 <juga> we also have already an issue for tpa to deploy onbasca
17:14:43 <mikeperry> jnewsome: I think so long as anarcat gives us a week notice, we can hold off on new runners until that notice
17:15:24 <jnewsome> mikeperry: ok
17:15:31 <juga> rdsys will just combine the result from bridgestrap and onbasca for now
17:15:40 <mikeperry> juga: ok great. so we are gonna do the approach that is in parallel to bridgestrap after all then?
17:15:48 <juga> yes
17:15:52 <mikeperry> ok
17:16:07 <juga> if it wouldn't work, we can still use bridgestrap answer in onbasca
17:16:49 * juga finished talking
17:17:20 <mikeperry> ok. I am fine with either approach, so long as we have visibility into what rdsys decides about the ratio and how many bridges that actually means are being marked slow, and if that set is stable or variable because of the dos, etc
17:17:41 <juga> alright
17:17:57 <mikeperry> I could see the rdsys decision approach leading to a black box situation where it just randomly decides to ignore or use the ratio and we don't know what is going on.. so we should just make sure to avoid that failure mode
17:18:25 <juga> mikeperry: for now i guess logs in rdsys will help?
17:19:18 <mikeperry> juga: yeah. and keeping an eye on the set of bridges that are below the ratio generally
17:19:28 <juga> ack
17:19:45 <mikeperry> we can start with a low ratio so that only a few bridges should be excluded
17:20:11 <juga> ok, i guess you'll tell the dirauths which ratio to set :)
17:20:14 <mikeperry> and if that set is not stable, we can try increasing the number of measurements, or possibly adding filtering
17:20:54 <juga> ah!, should we take 28 days of bridge measuarements as we do with sbws?
17:21:17 <juga> filtering you mean filtering slow streams?, that's already included in the main branch
17:21:50 <mikeperry> yeah, though re 28 days, that also feels like it should be a parameter
17:22:09 <mikeperry> I guess it depends on how fast we can measure all bridges/relays
17:22:29 <juga> mikeperry: ok, will check if it's already a parameter (the days)
17:23:00 <mikeperry> if a full set of measurements can be done in either case faster than 28 days, then that should be lower
17:23:15 <mikeperry> and I could see the time periods being different for relays vs bridges.. so maybe different params
17:23:26 <juga> ic, yes
17:26:33 <mikeperry> ok... I think that is it for the sync then?
17:26:43 * GeKo is good
17:26:49 <mikeperry> dgoulet: I will have a couple hours after this meeting to chat more if you want
17:26:49 * juga is good too
17:27:08 * ahf very good
17:27:14 <ahf> very excited about the conflux stuff!
17:27:17 <dgoulet> mikeperry: ack
17:27:35 * ahf calls the meeting
17:27:37 <ahf> #endmeeting