16:59:10 <ahf> #startmeeting Network team meeting, 13th June 2022
16:59:10 <MeetBot> Meeting started Mon Jun 13 16:59:10 2022 UTC.  The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:59:10 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:59:18 <dgoulet> o/
16:59:23 <nickm> ack! meeting time!
16:59:24 <nickm> hi !
16:59:27 <ahf> hello hello hello, our pad is at https://pad.riseup.net/p/tor-netteam-2022.1-keep
16:59:31 <juga> o/
16:59:53 <ahf> how are folks doing with their respective boards: https://gitlab.torproject.org/groups/tpo/core/-/boards ?
17:00:16 <Diziet> o/
17:00:45 <nickm> running out of Q2 arti stuff that is assigned to me. :)
17:00:49 <dgoulet> still legit
17:01:13 <nickm> (I'll grab more)
17:01:16 <jnewsome> o/ partly here
17:01:44 <ahf> very nice
17:01:55 <ahf> dgoulet: anything on releases?
17:02:07 <dgoulet> nope, not at the moment
17:02:09 <Diziet> I'm mostly arti#353 atm
17:02:25 <Diziet> (sorry to interrupt by being late, fetching the ticket #...)
17:02:58 <Diziet> Err, I mean arti#82 even.
17:03:03 <Diziet> No wait.
17:03:05 * Diziet shuts up
17:03:27 <Diziet> 62
17:03:30 <ahf> we don't have anything incoming for other teams, other than the cpu overload reporting issue
17:03:37 <ahf> but i don't think that is urgent
17:04:01 <ahf> no reminders
17:04:04 <ahf> no discussion items
17:04:09 <ahf> mikeperry: you wanna do s61?
17:04:27 <mikeperry> ok
17:04:55 <mikeperry> so I think first I will report on the DoS and load balancing
17:05:04 <mikeperry> First, observe the DoS appears to be still ongoing, up to June 11tth: https://metrics.torproject.org/hidserv-rend-relayed-cells.html?start=2022-06-01&end=2022-06-13
17:05:14 <mikeperry> Second, observe that bwauth votes became more sane, with the upgrade to 1.5.2: https://metrics.torproject.org/totalcw.html?start=2022-06-01&end=2022-06-13
17:05:29 <mikeperry> Third, observe that at that point of upgrade, the op7 onionperf throughput began to rise again: https://metrics.torproject.org/onionperf-throughput.html?start=2022-06-01&end=2022-06-13&server=public
17:05:52 <mikeperry> so the sbws upgrade to 1.5.2 has improved the situation under DoS
17:06:00 <eta> (hey, sorry I'm late)
17:06:00 <mikeperry> this is great
17:06:39 <ahf> nice
17:06:42 <ahf> very nice
17:07:13 <mikeperry> juga: are you still digging into the comparisons? is that tedious? I am trying to decide what is the most valuable next step here
17:07:39 <juga> mikeperry: yes, a bit, cause so far the data takes long to load and calculate ratios
17:07:48 <juga> i was trying to make it faster today
17:07:59 <mikeperry> I feel like this might be sufficient evidence to declare the sbws congestion control upgrade a success; we may want to move to comparing beteen the upgraded bwauths
17:08:01 <juga> s/load/parse/
17:08:17 <juga> ok, i can do that
17:08:45 <mikeperry> and seeing how sbws votes correspond to overloaded relays
17:09:21 <juga> hmm, with the cdf relay stream bandwidth or other graph?
17:09:34 <GeKo> seems like the ddos actually having crossed its peak
17:09:47 <GeKo> assuming clients are involved
17:09:52 <GeKo> see e.g: https://metrics.torproject.org/userstats-relay-country.html?graph=userstats-relay-country&country=fi
17:09:59 <GeKo> and the same for de
17:11:03 <GeKo> and ro
17:11:22 <mikeperry> interesting. the onion service rend cells is still high tho
17:11:43 <GeKo> yeah, i am a bit unsure here what's going on
17:12:51 <mikeperry> yeah, I am scratching my head as to what is most important to look at right now
17:13:38 <mikeperry> GeKo: are you able to do https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/38 without hiro, based on acutes work?
17:14:42 <mikeperry> hiro will likely need to help me with looking at https://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/40043 and https://gitlab.torproject.org/jnewsome/sponsor-61-sims/-/issues/17
17:14:58 <GeKo> mikeperry: yeah
17:15:11 <GeKo> i asked taking this off of hiro's plate
17:15:14 <hiro> @mikeperry I told GeKo that I would do that because the outliers you mention that are those we need on https://gitlab.torproject.org/jnewsome/sponsor-61-sims/-/issues/17
17:15:25 <GeKo> yeah
17:15:37 <hiro> s/that/there
17:15:47 <mikeperry> for #17, I am most concerned about the Fast and Guard cutoff testing there
17:15:59 <mikeperry> I will need to look for cutoffs for that this week
17:16:52 <mikeperry> the outlier analysis I see as something to check out overload reporting vs onionperf vs sbws.. ie just analysis at this point to see how much things agree
17:17:19 <hiro> ok
17:17:21 <mikeperry> and to see if our overload relays happen to be at a certain capacity threshhold
17:17:32 <GeKo> i did the outlier analysis previously, so that should be possible
17:17:46 <mikeperry> ie: it could inform the fast+guard cutoff stuff, but the filtering itself will be just cutoffs I think
17:17:48 <hiro> ok then I'll leave it to GeKo
17:18:02 <GeKo> don't want to steal tickets from you :)
17:18:21 <GeKo> i am fine either way
17:18:27 <hiro> nono please go ahead
17:18:37 <GeKo> kk
17:18:38 <mikeperry> I know it is annoying to have to go back and forth a bunch between tickets also :)
17:18:48 <hiro> I just thought it was an intermediate step for https://gitlab.torproject.org/jnewsome/sponsor-61-sims/-/issues/17
17:18:52 <GeKo> it's fine
17:19:05 <mikeperry> and I will need hiro to help verify that the CBT filtering is working for https://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/40043, and to help with Fast+Guard filtering analysis
17:19:22 <GeKo> yeah, makes sense
17:20:31 <hiro> sounds good
17:20:33 <mikeperry> jnewsome: if you are here, are there any usable updates on https://gitlab.torproject.org/jnewsome/sponsor-61-sims/-/issues/16? if not, is ok. I can just continue to use non-flooding for now
17:22:49 <mikeperry> hiro: For https://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/40043, some instructions on how to graph that for me, and more details on the weird Guard exception you hit that you mentioned in PM, on the ticket would be good. I am concerned about the CBT oddness
17:23:00 <mikeperry> that may involve some back and forth and chitchatting
17:23:35 <mikeperry> it should have made some difference.. it may be some artifact or bug or mis-measurement in onionperf that made it not different
17:23:37 <hiro> yep I just updated the other ticket: https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/37#note_2812322
17:24:17 <mikeperry> in particular, I am also wondering if circuit build time is included in onionperf's "time to first byte", or if that is just the stream time
17:24:32 <hiro> yep
17:24:42 <hiro> build time is included
17:25:14 <mikeperry> ahh.. that may explain it. there will be a latency penalty if they have to rebuild a circuit because of timeout
17:25:31 <mikeperry> I will follow up on that #37 with more questions tho
17:25:37 <hiro> ok sounds good
17:27:19 <ahf> anything else?
17:27:26 <mikeperry> hiro: it sounds like you have the infos you need for https://gitlab.torproject.org/jnewsome/sponsor-61-sims/-/issues/16?
17:27:34 <mikeperry> err damnit
17:27:39 <mikeperry> for https://gitlab.torproject.org/jnewsome/sponsor-61-sims/-/issues/17
17:28:03 <hiro> yep I need to know which percentiles you want to filter out
17:28:18 <hiro> otherwise I think I am good
17:29:02 <mikeperry> ok. it may be a bandwidth cutoff or percentile. and there will be different cutoffs for Guard vs Fast. I will have to look at the code in Tor for each again
17:29:13 <hiro> ok thanks
17:30:04 <mikeperry> ok. I think that is it for now
17:30:17 <mikeperry> any other questions here?
17:30:32 <GeKo> i am good
17:30:36 * ahf good
17:30:38 <Diziet> Not from me
17:31:52 <ahf> shall we call it?
17:32:52 <mikeperry> fine with me
17:32:58 <ahf> let's
17:33:04 <ahf> thanks all! o/
17:33:06 <ahf> #endmeeting