16:59:27 <ahf> #startmeeting Network team meeting, 28 February 2022
16:59:27 <MeetBot> Meeting started Mon Feb 28 16:59:27 2022 UTC.  The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:59:27 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:59:29 <ahf> hello hello
16:59:36 <nickm> hi ahf !
16:59:39 <ahf> our pad is at https://pad.riseup.net/p/tor-netteam-2022.1-keep
16:59:56 <Diziet> Afternoon
17:00:01 <eta> o/
17:00:12 <jnewsome> o/
17:00:15 <ahf> last meeting in february. remember that means looking into harvest soon is a good idea and it also means next week we have the s61 sync since it'll be first monday of the week
17:00:16 <nickm> [fwiw I have been having riseup pad problems today, so before you write anything major there, you might want to make a local copy]
17:00:35 <ahf> yeah, please keep backup of your pad activity today.. i have just had to write the same line 5 times
17:01:11 <ahf> how are you all doing with your boards: https://gitlab.torproject.org/groups/tpo/core/-/boards ?
17:01:50 <juga> o/
17:01:57 <nickm> fine over here!
17:02:00 * eta has an empty board; will pull stuff from the top of the backlog
17:02:14 <nickm> we'll likely do some more arti task pulling at our meeting tomorrow
17:02:24 <GeKo> o/
17:02:31 <Diziet> I have about 3 things for arti 0.1.0....
17:03:05 <ahf> cool
17:03:19 <ahf> i cannot spot anything off on the board state
17:04:29 <ahf> missing david rigt now, so gonna skip the release point for now. we made C tor release last week with the CC work in it \o/
17:04:54 <ahf> very nice work by everybody who was in that. i bet your weekend was extra excellent after that \o/
17:04:56 <ahf> hey dgoulet
17:05:01 <ahf> was just at the tor release point
17:05:04 <ahf> i wrote:
17:05:10 <ahf> missing david rigt now, so gonna skip the release point for now. we made C tor release last week with the CC work in it \o/
17:05:11 <dgoulet> o/
17:05:17 <ahf> i don't know if you wanna add something there
17:05:27 <dgoulet> that is it :)
17:05:29 <dgoulet> nice alpha
17:06:30 <ahf> excellent, let's see what kind of bugs that comes in from some more user-testing
17:06:35 <ahf> ok!
17:07:13 <ahf> don't see anything new coming in from other teams that isn't handled
17:07:30 <ahf> looks like mikeperry is working with juga/geko on CIRC_BW
17:07:53 <juga> yes
17:08:17 <mikeperry> yeah, that's https://gitlab.torproject.org/tpo/core/tor/-/issues/40568
17:08:32 <ahf> on thursday we will be talking a bit about scoping of some of the upcoming arti tickets, where some knowledge between c-tor and arti gang will be needed to be shared :-)
17:08:48 <ahf> remember tomorrow at 17 UTC we have the internal arti sync up where we will be looking at the arti ticket list
17:08:49 <ahf> ok!
17:09:00 <ahf> i think it's s61 time, mikeperry
17:09:11 <mikeperry> ok!
17:09:38 <mikeperry> so yeah, 0.4.7.4 has full negotiation support, disabled by default
17:10:07 <mikeperry> if we have any exits running it, we can ask them to force it on if we want
17:10:18 <mikeperry> and then it will turn on for any clients that use them that also force it on
17:10:27 <ahf> NHT has an exit, but i don't know if they are doing something exciting already on it
17:10:29 <mikeperry> same for onions
17:10:41 <dgoulet> oh I should enable it on ours!
17:11:07 <dgoulet> mikeperry: you have a "recommended patch" somewhere to do such thing?
17:11:33 <mikeperry> torrc __AlwaysCongestionControl 1
17:11:38 <dgoulet> ack
17:11:41 <mikeperry> must be done on both sides
17:12:15 <mikeperry> it might be slow, depending on competition with old clients at bottleneck relays
17:12:44 <mikeperry> I also ran some onion service sims using jnewsome's onion service work
17:13:06 <mikeperry> I think I am satisfied with the results. I dont actually think we need to do anything major there, which is nice
17:13:29 <ahf> would be nice ot have this on the onion version of debian package's repo
17:13:38 <ahf> so i don't have to spend 3 hours waiting for debian testing to update XD
17:13:41 <mikeperry> I also ran some sims increasing the client scale in shadow. I am still waiting on full results there
17:14:27 <mikeperry> jnewsome,hiro: how are the utilization graphs coming?
17:14:50 <hiro> I think I'd like to do some test with more data if that's possible
17:14:59 <hiro> like running the MR branch with a sim
17:15:17 <jnewsome> hiro: sgtm, we have the runner capacity
17:15:33 <mikeperry> nice, ok
17:15:34 <hiro> ok, mikeperry what presets should I run?
17:15:45 <hiro> so that the test makes sense?
17:16:31 <mikeperry> hiro: negotiation-0474-onions or negotiation-main are good starting points
17:16:40 <mikeperry> the onion one also has the onion serice activity and graphs
17:16:53 <hiro> ok
17:18:03 <mikeperry> jnewsome: if you are able to do https://gitlab.torproject.org/jnewsome/sponsor-61-sims/-/issues/3 this week, that would be good before you leave. I think that is the next most important thing we need to look at, after we have utilization CDFs
17:18:41 <jnewsome> mikeperry: ok, yeah i should be able to do that
17:19:57 <mikeperry> https://gitlab.torproject.org/jnewsome/sponsor-61-sims/-/issues/11 may also be related and similar. it is less important, but might be easy to pick up on the way
17:20:22 <mikeperry> idk that might be some tricky consensus parsing tho, to get it realistic
17:20:49 <mikeperry> so I would focus on the exit %
17:21:25 <mikeperry> juga: I should have a circbw patch for you this week. maybe today, if not, on weds/thursday
17:21:30 <mikeperry> (I am off tomorrow)
17:21:38 <jnewsome> hmm, ok. i'll see about that too. i suppose we'll want to split the perf clients too and their data?
17:21:55 <mikeperry> jnewsome: no, I don't think that is necessary
17:22:11 <juga> mikeperry: ack
17:22:25 <jnewsome> ok, cool, that keeps things simple
17:22:26 <mikeperry> what we are trying to see is if the old clients and exits impact congestion control if they don't upgrade
17:22:53 <mikeperry> jnewsome: so exit % gets us most of that. maaaaybe background markov client percent too, but if that is complicated, it is not necessary
17:23:21 <mikeperry> since they will not use congestion control when they pick a non-CC exit
17:23:56 <mikeperry> and the exit % number is the key one we will watch for when to flip the switch
17:24:41 <mikeperry> jnewsome: anyhow nice work with the onion service support btw. that all looks good afaict
17:25:09 <jnewsome> mikeperry: ok cool
17:25:18 <mikeperry> GeKo,juga: anything else from network-health and sbws land?
17:25:29 <juga> mikeperry: not from my side
17:25:38 <GeKo> we got green light from tpa for our non-exit relays
17:25:43 <jnewsome> i suppose we should dig into that weird onionservice timeout issue at some point
17:25:51 <mikeperry> for the next alpha, we will hopefully have https://gitlab.torproject.org/tpo/core/tor/-/issues/40560
17:25:55 <GeKo> so we can get a better understanding on the non-exit overload we still see
17:25:57 <mikeperry> dgoulet: will you have cycles for that?
17:26:13 <GeKo> yeah, that could be a thing
17:26:26 <GeKo> dgoulet: have you set up those relays yet?
17:26:41 <GeKo> and if not could you do that and document things in our wiki this week?
17:27:12 <mikeperry> jnewsome: yeah, I mean that bug has probably been there for 20 years, heh. it can wait until we stablize 0.4.7.
17:27:21 <dgoulet> mikeperry: yes, we must
17:27:35 <dgoulet> GeKo: I have not yet
17:28:15 <GeKo> okay, so if you could get to that this week that would be nice
17:28:26 <dgoulet> I'll do my best
17:28:27 <ahf> jnewsome: how bad does the issue look in shadow?
17:28:31 <GeKo> thanks
17:28:35 <ahf> and do we have a ticket for it?
17:29:01 <GeKo> there is not much else to note from my side (apart from the usual boilerplate work)
17:29:08 <jnewsome> ahf:  https://gitlab.torproject.org/tpo/core/tor/-/issues/40570
17:29:11 <GeKo> so all is good from my side
17:29:11 <mikeperry> ahf: https://gitlab.torproject.org/tpo/core/tor/-/issues/40570#note_2780074
17:29:41 <mikeperry> that comments has a graph
17:29:54 <mikeperry> basically onion services sometimes wait for a minute before retrying stuff
17:29:58 <jnewsome> ahf: it ultimately results in a lot of transfer timeouts while building onionservice circuits in Shadow
17:30:08 <ahf> excellent
17:30:33 <jnewsome> hopefully it's not as bad in the real network; i'd sure think we'd have noticed
17:30:54 <jnewsome> but conversely if it's not as bad in the real network then we have to wonder if we're not modelling something accurately in shadow
17:30:58 <mikeperry> but again, it has likely always been there. I was eyeing it in https://gitlab.torproject.org/tpo/core/tor/-/issues/40169
17:31:17 <ahf> hm, interesting
17:31:29 <dgoulet> yeah ...
17:31:36 <dgoulet> this is that "circuit expire" function likely
17:31:39 <dgoulet> and it is a crazy one
17:31:40 <mikeperry> I didn't see that exact case.. but I suspected such weirdness was possible
17:33:32 <ahf> ok
17:33:38 <ahf> anything else today?
17:33:42 <mikeperry> ok.. I think the main other thing on my mind is https://gitlab.torproject.org/tpo/core/tor/-/issues/40545, but I did not see that impacting performance in shadow. it seems less important than the overload line thing
17:34:17 <mikeperry> I think that is it on my radar
17:34:30 <mikeperry> any other questions, comments, concerns?
17:35:13 <jnewsome> nothing here
17:35:46 * dgoulet is s61 good
17:35:54 <GeKo> me too
17:35:58 * ahf good
17:36:21 <mikeperry> kk awesome
17:36:28 <ahf> let's call it then
17:36:28 <mikeperry> great work everyone
17:36:29 <eta> . o O ( I'm not just good, I'm s61 good! )
17:36:36 <Diziet> *rotfl*
17:36:43 <ahf> eta: it's when you have been in tor for long enough then you become one with the sponsors
17:36:48 <eta> what a terrible fate
17:36:50 <ahf> XD
17:36:59 <ahf> thanks all for joining, let's talk in #tor-dev
17:37:05 <ahf> #endmeeting