16:59:10 #startmeeting Network team meeting, 11th July 2022 16:59:10 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:59:17 hi ahf ! hi everybody! 16:59:19 hello everyone 16:59:23 hi 16:59:25 o/ 16:59:58 o/ 17:00:17 let's dive into it 17:01:04 https://pad.riseup.net/p/tor-netteam-2022.1-keep is our pad 17:01:24 really nice work with the roadmapping on thursday folks, that was much appriciated! 17:01:32 hi 17:01:43 https://gitlab.torproject.org/groups/tpo/core/-/boards <- how are folks doing with their boards? 17:02:21 doing okay. Taking a break from my error-wrangling to work through other smaller stuff. 17:02:59 nice 17:03:56 i don't see anything in the board i need to talk with everybody about 17:04:01 Trying to actually do channel padding. Making progress. Most of the faffsome bits seem done. 17:04:14 mike and i and gaba will go over it today in our 2 1:1's 17:05:38 ok! 17:05:41 no release updates from david 17:05:49 * eta is making slow progress on congestion control 17:06:20 very nice, eta and Diziet - it is nice you are diving into some of the newer protocol things in tor 8) 17:06:31 don't see anything incoming from other teams 17:07:07 eta: I won't get to arti!525 until tomorrow, hope that's OK. 17:07:16 Diziet has a discussion item on tor-spec!76 and tor-spec!77 and tor-spec#120 17:07:22 Yeah. 17:07:31 I just wanted to check if it's OK if I implement what I put in those MRs. 17:07:31 Diziet: yeah, should be fine; my next step is probably to look at an actual tor-vegas impl anyhow 17:07:39 We can debate the spec text at our leisure :-) 17:08:18 I mean, particularly, !77 17:08:31 torspec!76 torspec!77 torspec#120 17:08:33 there it was 17:08:41 Ah sorry 17:08:55 no worries, i also remember it as tor-spec 17:09:22 okay, i see most things there have interactions - are you blocked on something here? 17:10:03 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 mikeperry: ^^ 17:11:57 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 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 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 yes, as I said, we have time to look at padding under a pending contract. time is being made 17:14:28 are you comfortable diving into the C code to look at how it behaves today, Diziet? 17:15:09 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 right, that answer probably needs to be investigated with experiments :-p 17:15:44 (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 dormant mode keeps our connections open but refuses to send on them? is that the idea? 17:16:29 it tries to minimize the time we wake up from our main loop function (epoll, etc.) 17:16:30 mikeperry: IDK what C Tor dormant mode is. Arti dormant mode mostly disables periodic directory updatting and things. 17:16:38 It doesn't actually prevent you using connections. 17:16:44 the number of times* 17:17:14 I think dormant mode ought to disable channel padding too. 17:17:38 (in both directions) (assuming that it isn't supposed to close down all the channels) 17:17:43 but not other circuit activity? 17:18:12 if we have circuit activity, i don't see why we cannot have padding activity too there 17:18:24 Um 17:18:27 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 Remember the original motivations of dormant mode: 17:19:13 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 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 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 I don't think we need dormant mode for 2 in arti: we can use our bootstrap-on-first-use code. 17:21:49 For (1), during dormancy, we ought to be neither sending nor receiving channel padding. 17:22:05 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 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 But that can be a separate thing 17:22:15 That means either that we have no (circuit) channels, or we some but we have disabled padding on them. 17:22:24 ahf: there are no padding machines for channel padding 17:22:38 ah 17:23:18 In the latter case (of my analysis ^) we need a way to turn the padding on again. 17:23:52 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 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 In the latter case all the channels will need a negotiation cell sent to set the padding back to the default. 17:25:11 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 nickm: I haven't UTSL for that question but AIUI the answer is "yes". I could go check. 17:26:01 I think it should be "yes". 17:27:03 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 IOW if they *don't* handle this case properly it's simply a bug. 17:27:30 ack 17:27:31 ya 17:27:37 i don't think they crash lol 17:28:03 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 if it happens to work, we may as well document it. I'm +1 in that case. 17:28:37 yeah 17:28:55 We have (AIUI) established that C Tor handles it correctly, and other parts of the spec imply that it will DTRT. 17:29:28 sending CHANNELPADDING_COMMAND_STOP will disable padding; sending 0 will cause consensus param values to be used 17:29:41 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 my read of the code is that it can handle multiple of these requests at any time 17:29:59 mikeperry: Cool. 17:30:29 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 mikeperry: you wanna continue into the s61 landscape? 17:31:13 mikeperry: So are you OK with me writing code in Arti that implements what I propose in !77 17:31:21 (I don't think more testing is needed.) 17:31:41 (Since I think we know the answers to all the questions other than ones about hypothetical future protocol evolution.) 17:31:46 yeah 17:32:35 Diziet: yes sending 0 is a fine signal to mean "use your consensus please" 17:32:42 Cool, thanks. 17:32:45 I believe I said this on the MR 17:33:10 Your comment suggested that the protocol might want to change to make this not recommended... 17:33:34 IOW really I think you should either merge !77 or close it and tell me what to do instead... 17:33:47 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 OK, so you'll merge !77 ? 17:35:13 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 I can't merge to torspec. I can look at the diff again and click approve later 17:35:35 OK cool. 17:36:46 ok! 17:37:07 mikeperry: Thanks and sorry to be difficult. 17:37:12 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 should we do the s61 part? we only have 20 min left 17:38:16 ok. I can go over the major pieces 17:38:48 👍 17:38:56 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 which means that the remaining thing to look at is Guard+Fast cutoffs 17:39:58 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 Yeah I did that this afternoon 17:40:44 awesome, thanks! 17:40:56 nice 17:41:25 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 yeah 17:41:59 i plan to do that this week 17:42:04 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 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 hiro: those two are you, also 17:43:48 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 ah interesting 17:45:17 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 unfortunately still blocked on a tgen bug https://github.com/shadow/tgen/issues/35 17:46:04 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 the link sharing is built into the latest tornettools, which needs a newer shadow, which has the bug 17:46:40 aha, ok 17:46:56 well we still want to look at live data first anyway, so no pressure 17:47:02 ok, cool 17:47:41 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 ugh 17:50:29 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 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 mikeperry: atm it seems only gabelmoo 17:51:21 I suppose gabelmoo might be enough just to test an implementation 17:51:25 mikeperry: do you actually have a conf that works? 17:51:26 i think it's in dkg's court 17:51:33 yes, re. dkg 17:51:35 while we wrangle the rest of them 17:51:41 yeah re: gabelmoo being enough to test an implementation 17:52:03 yes, i'm also implementing the server in python for the tests 17:52:09 i guess i should start pinging sina harder again :/ 17:52:10 (the post method) 17:52:27 ok great. so we're not blocked there. awesome 17:52:50 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 or a url path 17:53:06 s/we'l/we'd/ 17:53:24 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 also, i don't think we need http sessions and HEAD requests, right? 17:53:48 the GET urls are not public 17:53:56 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 though might not be difficult to get them 17:54:09 mikeperry: ah, ic 17:54:48 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 ok, sounds good 17:55:13 and i can ping dkg and/or micah 17:55:52 anything else in network health? I guess we had a brief overload spike that went away? 17:56:01 yeah 17:56:12 david reported high memory usage on his relay the other day 17:56:24 and nifty's 0.4.6.8 relays are back :/ 17:56:47 so the exit graph goes up again... 17:57:01 in case someone is wondering :) 17:57:06 /o\ 17:57:09 they are gonna ride that to EOL arent they 17:57:14 that said. i've been working on the s61 report 17:57:30 a first pass for o4 is done and i am almost done with a first pass for o2 17:57:41 juga: you could add things if you wanted which i missed 17:57:51 i plan to have those parts ready tomorrow 17:57:53 GeKo: ok, i'll have a look this week 17:57:54 i have a meeting in 1 min, can we continue the s61 part without the bots in here? 17:57:54 thanks. it is still on my todo pile. I can handle O1 and O3 and the intro summary 17:58:05 nice 17:58:13 ahf: yeah I think we are wrapping up anyway 17:58:16 i'll be out for 3 weeks starting next week 17:58:19 fwiw 17:58:25 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 vacation and such 17:58:37 i back around 15th of august 17:58:42 same 17:58:45 kind of :) 17:58:51 with half the brain capacity as before given that i am going to two festivals 17:58:56 so expect a dumber, but more relaxed alex 17:59:00 nice 17:59:21 i'll close the meeting. thanks all o/ 17:59:23 #endmeeting