16:59:10 <ahf> #startmeeting Network team meeting, 11th July 2022
16:59:10 <MeetBot> Meeting started Mon Jul 11 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:17 <nickm> hi ahf ! hi everybody!
16:59:19 <ahf> hello everyone
16:59:23 <GeKo> hi
16:59:25 <Diziet> o/
16:59:58 <eta> o/
17:00:17 <ahf> let's dive into it
17:01:04 <ahf> https://pad.riseup.net/p/tor-netteam-2022.1-keep is our pad
17:01:24 <ahf> really nice work with the roadmapping on thursday folks, that was much appriciated!
17:01:32 <juga> hi
17:01:43 <ahf> https://gitlab.torproject.org/groups/tpo/core/-/boards <- how are folks doing with their boards?
17:02:21 <nickm> doing okay. Taking a break from my error-wrangling to work through other smaller stuff.
17:02:59 <ahf> nice
17:03:56 <ahf> i don't see anything in the board i need to talk with everybody about
17:04:01 <Diziet> Trying to actually do channel padding.  Making progress.  Most of the faffsome bits seem done.
17:04:14 <ahf> mike and i and gaba will go over it today in our 2 1:1's
17:05:38 <ahf> ok!
17:05:41 <ahf> no release updates from david
17:05:49 * eta is making slow progress on congestion control
17:06:20 <ahf> very nice, eta and Diziet - it is nice you are diving into some of the newer protocol things in tor 8)
17:06:31 <ahf> don't see anything incoming from other teams
17:07:07 <Diziet> eta: I won't get to arti!525 until tomorrow, hope that's OK.
17:07:16 <ahf> Diziet has a discussion item on tor-spec!76 and tor-spec!77 and tor-spec#120
17:07:22 <Diziet> Yeah.
17:07:31 <Diziet> I just wanted to check if it's OK if I implement what I put in those MRs.
17:07:31 <eta> Diziet: yeah, should be fine; my next step is probably to look at an actual tor-vegas impl anyhow
17:07:39 <Diziet> We can debate the spec text at our leisure :-)
17:08:18 <Diziet> I mean, particularly, !77
17:08:31 <ahf> torspec!76 torspec!77 torspec#120
17:08:33 <ahf> there it was
17:08:41 <Diziet> Ah sorry
17:08:55 <ahf> no worries, i also remember it as tor-spec
17:09:22 <ahf> okay, i see most things there have interactions - are you blocked on something here?
17:10:03 <Diziet> Mostly I just wanted to check thatt https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/77#note_2819770 meant "yes, implement that"...
17:10:16 <ahf> mikeperry: ^^
17:11:57 <mikeperry> yeah I saw that. as I said, we want some better concept of bounds checking here, I think. but if we just want to implement something, doing whatever C does and specifying it works for me right now
17:12:28 <Diziet> C Tor doesn't do this because AIUI it doesn't disable padding in dormant mode or doesn't reenable it when coming out of dormant mode, or something ?
17:13:49 <Diziet> If the answer to my question is "it is complicated" then fine but we should actually make some time to figure it out :-).
17:14:13 <mikeperry> yes, as I said, we have time to look at padding under a pending contract. time is being made
17:14:28 <ahf> are you comfortable diving into the C code to look at how it behaves today, Diziet?
17:15:09 <Diziet> Sure, but if the spec text is to be believed it won't tell me how it reenables padding because it doesn't.
17:15:38 <ahf> right, that answer probably needs to be investigated with experiments :-p
17:15:44 <Diziet> (The spec text and the C Tor code agree that the behaviour of my proposed negotiation cell is the behaviour I want.)
17:15:45 <mikeperry> dormant mode keeps our connections open but refuses to send on them? is that the idea?
17:16:29 <ahf> it tries to minimize the time we wake up from our main loop function (epoll, etc.)
17:16:30 <Diziet> mikeperry: IDK what C Tor dormant mode is.  Arti dormant mode mostly disables periodic directory updatting and things.
17:16:38 <Diziet> It doesn't actually prevent you using connections.
17:16:44 <ahf> the number of times*
17:17:14 <Diziet> I think dormant mode ought to disable channel padding too.
17:17:38 <Diziet> (in both directions) (assuming that it isn't supposed to close down all the channels)
17:17:43 <mikeperry> but not other circuit activity?
17:18:12 <ahf> if we have circuit activity, i don't see why we cannot have padding activity too there
17:18:24 <nickm> Um
17:18:27 <Diziet> Well, I think our assumption is that if someone uses the Arti API to tell us to be dormant, they won't then tell us to actually do things.  But you make a good point that perhaps we should reject them or something.
17:18:53 <nickm> Remember the original motivations of dormant mode:
17:19:13 <nickm> 1) we want to make it possible to run a tor client on a mobile device without it eating the battery when it's not in use
17:19:53 <nickm> 2) we wanted to make it possible to ship a tor client that's turned on my default, but which won't actually bother the network until somebody tries to use it
17:20:38 <nickm> Currently arti's dormant mode is only the "backend level" support: it turns timers off and on, but it doesn't (IIRC) do anything to connections.  But it will have to, if we want to allow 1.
17:21:01 <nickm> I don't think we need dormant mode for 2 in arti: we can use our bootstrap-on-first-use code.
17:21:49 <Diziet> For (1), during dormancy, we ought to be neither sending nor receiving channel padding.
17:22:05 <ahf> right. what do you think though here specifically on the padding? i can understand we don't want to do padding when we are dormant, but when there is activity from the user the padding machines can continue to run?
17:22:09 <nickm> right.  There is a case to be made that there should be a "going dormant" state in which channel padding is still sent or received for a while.
17:22:13 <nickm> But that can be a separate thing
17:22:15 <Diziet> That means either that we have no (circuit) channels, or we some but we have disabled padding on them.
17:22:24 <nickm> ahf: there are no padding machines for channel padding
17:22:38 <ahf> ah
17:23:18 <Diziet> In the latter case (of my analysis ^) we need a way to turn the padding on again.
17:23:52 <Diziet> In the former case we need some thing to close the channels (perhaps, after a delay designed to help with netflow or something)
17:24:28 <Diziet> Also Arti supports (partially, right now) reconfiguration.  You might configure it to send reduced padding and then reconfigure it to send normal padding.
17:24:43 <Diziet> In the latter case all the channels will need a negotiation cell sent to set the padding back to the default.
17:25:11 <nickm> In this case maybe the C question isn't so much "what do C clients do" but "do C relays indeed support getting padding_renegotiate a few times on the same channel"
17:25:43 <Diziet> nickm: I haven't UTSL for that question but AIUI the answer is "yes".  I could go check.
17:26:01 <nickm> I think it should be "yes".
17:27:03 <Diziet> But in fact I don't think it really matters _for what I want to write in Arti_ so long as the C relays don't do something totally stupid (like crash or what have you) in these cases.
17:27:16 <Diziet> IOW if they *don't* handle this case properly it's simply a bug.
17:27:30 <nickm> ack
17:27:31 <ahf> ya
17:27:37 <ahf> i don't think they crash lol
17:28:03 <Diziet> But the question in torspec!77 is whether to explicitly say that sending PADDING_NEGOTIATE START low=0 high=0 is the way to request "default padding as if no PADDING_NEGOTIATE had been sent on this channel"
17:28:36 <nickm> if it happens to work, we may as well document it.  I'm +1 in that case.
17:28:37 <ahf> yeah
17:28:55 <Diziet> We have (AIUI) established that C Tor handles it correctly, and other parts of the spec imply that it will DTRT.
17:29:28 <mikeperry> sending CHANNELPADDING_COMMAND_STOP will disable padding; sending 0 will cause consensus param values to be used
17:29:41 <Diziet> The question is what the spec tells a possible sender to send.  Right now (without !77) it's not clear but the text suggests that one would send timer values from the consensus, rather than zeroes.
17:29:53 <mikeperry> my read of the code is that it can handle multiple of these requests at any time
17:29:59 <Diziet> mikeperry: Cool.
17:30:29 <ahf> cool. sounds like there can be made some progress here with a bit of testing that needs to be done at some point between our C relays and arti. as mike said we have some upcoming grants out where the is some time to dive deeper into some of the padding work
17:30:46 <ahf> mikeperry: you wanna continue into the s61 landscape?
17:31:13 <Diziet> mikeperry: So are you OK with me writing code in Arti that implements what I propose in !77
17:31:21 <Diziet> (I don't think more testing is needed.)
17:31:41 <Diziet> (Since I think we know the answers to all the questions other than ones about hypothetical future protocol evolution.)
17:31:46 <ahf> yeah
17:32:35 <mikeperry> Diziet: yes sending 0 is a fine signal to mean "use your consensus please"
17:32:42 <Diziet> Cool, thanks.
17:32:45 <mikeperry> I believe I said this on the MR
17:33:10 <Diziet> Your comment suggested that the protocol might want to change to make this not recommended...
17:33:34 <Diziet> IOW really I think you should either merge !77 or close it and tell me what to do instead...
17:33:47 <mikeperry> no I meant we need better bounds checks because you had another ticket about bounds checks. but 0 is fine to specify as use consensus
17:34:44 <Diziet> OK, so you'll merge !77 ?
17:35:13 <Diziet> https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/77/diffs      the text which I am proposing to add recommends to do the thing that I am writing
17:35:27 <mikeperry> I can't merge to torspec. I can look at the diff again and click approve later
17:35:35 <Diziet> OK cool.
17:36:46 <ahf> ok!
17:37:07 <Diziet> mikeperry: Thanks and sorry to be difficult.
17:37:12 <ahf> i can merge it when mike has taken a look, can just reassign it to me when it gets an approval. if iam out, david and nick can also merge
17:37:20 <ahf> should we do the s61 part? we only have 20 min left
17:38:16 <mikeperry> ok. I can go over the major pieces
17:38:48 <ahf> 👍
17:38:56 <mikeperry> I checked to see if 1-hop dirconns were causing any additional queuing in shadow at guards by disabling CC for them. it looks like the answer is no
17:39:21 <mikeperry> which means that the remaining thing to look at is Guard+Fast cutoffs
17:39:58 <mikeperry> hiro is lowering the guard rotation period on our 'a' onionperf instances, so we can get more Guard datapoints for this analysis: https://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/40050
17:40:30 <hiro> Yeah I did that this afternoon
17:40:44 <mikeperry> awesome, thanks!
17:40:56 <ahf> nice
17:41:25 <mikeperry> GeKo: the more frequent guard rotation may help https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/38, but you may still need to look at multiple days to get enough Guard datapoints
17:41:54 <GeKo> yeah
17:41:59 <GeKo> i plan to do that this week
17:42:04 <mikeperry> for the next step in the actual cutoff analysis, we want to be able to also use multiple days, with the onionperf filters
17:42:21 <mikeperry> basically https://gitlab.torproject.org/jnewsome/sponsor-61-sims/-/issues/17 in combination with https://gitlab.torproject.org/tpo/core/tor/-/issues/40160
17:42:41 <mikeperry> hiro: those two are you, also
17:43:48 <mikeperry> jnewsome: on the shadow side for this analysis, I made https://gitlab.torproject.org/jnewsome/sponsor-61-sims/-/issues/18, if you want to bounce that off rob
17:44:08 * jnewsome looking
17:44:38 <jnewsome> ah interesting
17:45:17 <mikeperry> jnewsome: how is the link-sharing thing looking? we might also want to consider that for this too.. I am not sure. I guess it depends on how much it helps :)
17:45:45 <jnewsome> unfortunately still blocked on a tgen bug https://github.com/shadow/tgen/issues/35
17:46:04 <jnewsome> it's not directly related to link sharing; just something that has started happening with the latest version of tornettools and shadow
17:46:25 <jnewsome> the link sharing is built into the latest tornettools, which needs a newer shadow, which has the bug
17:46:40 <mikeperry> aha, ok
17:46:56 <mikeperry> well we still want to look at live data first anyway, so no pressure
17:47:02 <jnewsome> ok, cool
17:47:41 <jnewsome> yeah i've tried unsuccessfully to reproduce in smaller sims. now trying to add extra logging to try debugging in the big sim, but keep using all of our storage :/
17:47:57 <mikeperry> ugh
17:50:29 <mikeperry> juga,geko: re https://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40130, are bwauths responding wrt post? I saw bastet wanted some complicated auth thing
17:50:59 <mikeperry> this might be a situation where dkg figures it out and provides some guidance? or do we need micah to help there?
17:51:00 <juga> mikeperry: atm it seems only gabelmoo
17:51:21 <mikeperry> I suppose gabelmoo might be enough just to test an implementation
17:51:25 <juga> mikeperry: do you actually have a conf that works?
17:51:26 <GeKo> i think it's in dkg's court
17:51:33 <juga> yes, re. dkg
17:51:35 <mikeperry> while we wrangle the rest of them
17:51:41 <GeKo> yeah re: gabelmoo being enough to test an implementation
17:52:03 <juga> yes, i'm also implementing the server in python for the tests
17:52:09 <GeKo> i guess i should start pinging sina harder again :/
17:52:10 <juga> (the post method)
17:52:27 <mikeperry> ok great. so we're not blocked there. awesome
17:52:50 <juga> mikeperry: i was wondering if we'l like to enforce a name for www-form field or a name for the filename, i guess it's not needed?
17:52:57 <juga> or a url path
17:53:06 <juga> s/we'l/we'd/
17:53:24 <mikeperry> hrmm yeah, that might help assuage bastet. though I am not sure what the concern is since the GET urls are already public yeah?
17:53:42 <juga> also, i don't think we need http sessions and HEAD requests, right?
17:53:48 <juga> the GET urls are not public
17:53:56 <mikeperry> it feels like some case where someone who has more experience with httpds could point to some best practices. thats why I mentioned micah
17:53:58 <juga> though might not be difficult to get them
17:54:09 <juga> mikeperry: ah, ic
17:54:48 <mikeperry> but yeah for now, making it be a specific form and specific url seems good, and in-line with how the GET works anyway
17:55:04 <juga> ok, sounds good
17:55:13 <juga> and i can ping dkg and/or micah
17:55:52 <mikeperry> anything else in network health? I guess we had a brief overload spike that went away?
17:56:01 <GeKo> yeah
17:56:12 <ahf> david reported high memory usage on his relay the other day
17:56:24 <GeKo> and nifty's 0.4.6.8 relays are back :/
17:56:47 <GeKo> so the exit graph goes up again...
17:57:01 <GeKo> in case someone is wondering :)
17:57:06 <ahf> /o\
17:57:09 <mikeperry> they are gonna ride that to EOL arent they
17:57:14 <GeKo> that said. i've been working on the s61 report
17:57:30 <GeKo> a first pass for o4 is done and i am almost done with a first pass for o2
17:57:41 <GeKo> juga: you could add things if you wanted which i missed
17:57:51 <GeKo> i plan to have those parts ready tomorrow
17:57:53 <juga> GeKo: ok, i'll have a look this week
17:57:54 <ahf> i have a meeting in 1 min, can we continue the s61 part without the bots in here?
17:57:54 <mikeperry> thanks. it is still on my todo pile. I can handle O1 and O3 and the intro summary
17:58:05 <GeKo> nice
17:58:13 <mikeperry> ahf: yeah I think we are wrapping up anyway
17:58:16 <GeKo> i'll be out for 3 weeks starting next week
17:58:19 <GeKo> fwiw
17:58:25 <ahf> also this will be the second last team meeting in a while where i am around before my vacation. if people need something for me, or want me to do something for them, etc. then this week is last chance
17:58:28 <GeKo> vacation and such
17:58:37 <ahf> i back around 15th of august
17:58:42 <GeKo> same
17:58:45 <GeKo> kind of :)
17:58:51 <ahf> with half the brain capacity as before given that i am going to two festivals
17:58:56 <ahf> so expect a dumber, but more relaxed alex
17:59:00 <mikeperry> nice
17:59:21 <ahf> i'll close the meeting. thanks all o/
17:59:23 <ahf> #endmeeting