16:59:37 #startmeeting Network team meeting, 7th September 2021 16:59:37 Meeting started Tue Sep 7 16:59:37 2021 UTC. The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:59:37 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:59:46 hello hello, welcome, our pad is at: https://pad.riseup.net/p/tor-netteam-2021.1-keep 16:59:51 greetings 17:00:15 let's give folks a little bit to join in 17:00:21 o/ 17:00:46 hihi 17:01:06 let's get going 17:01:12 o/ 17:01:36 o/ 17:01:48 i don't see anything new to our release status lists 17:02:05 but i think dgoulet and i need to put our heads together and talk a bit about what we learned from the last release series? 17:02:34 we did that part 17:02:40 I think we need to do part 2 :) 17:02:43 activate() 17:02:44 ya 17:02:57 i think the things we want to talk a bit about was changelog being the big one, no? 17:03:27 can we take that during this week maybe ? i want to prioritize sponsor stuff first this week before i dive into anything else 17:03:45 sure np 17:04:20 ok, i don't see this meeting as a "first meeting of the month" so skipping a few items 17:04:32 otherwise i'm gonna be so confused next week with the s61 sync earlier 17:04:43 ugh, i skipped an item! 17:04:49 how is everybody's boards looking? 17:05:23 not sure; I'm still getting back to mine :/ 17:05:30 hehe, is fine on day #1 after vacation XD 17:05:33 no rush 17:06:11 dgoulet, mikeperry: Is there a ticket for specifically the part of the s61 work I'm doing? 17:07:08 not to my knowledge but the main flow control branch is under early review and so I would think that is at least the starting point for hooking ntorv3 in there... mikeperry would know 17:07:16 nickm: there is one for all of the negotiation logic, but the main thing that would be most helpful that you can do there is just hook up the protover and stub the calls to the new ntorv3 17:07:36 what is the ticket id? I'll start a subticket for the part I'm doing. 17:07:51 (I would like to have something assigned to me here so I can track it better) 17:07:52 if dgoulet can handle the equivalent for hs descs and the hs intro extension fields, then I can do the more complicated logic and use of the fields 17:07:55 https://gitlab.torproject.org/tpo/core/tor/-/issues/40444 17:07:59 thanks, mikeperry ! 17:08:08 mikeperry: yes HS stuff is on my side, spec + code 17:09:28 if either/both of you prefer to break off your pieces into your own tickets, you (or me) can do that 17:09:45 but I am fine just taking a branch for each of you and working on it from there 17:10:27 very good 17:11:14 there is no discussion items. on the thursday meeting, we need to talk a bit about team goals and objectives for us to prepare for all hands next week 17:11:25 i'll talk a bit about what i have noted down and then we can do some feedback on it 17:11:32 otherwise i think we can move to the s61 part of the meeting 17:12:21 What is the all-hands next week for? 17:12:45 it's the thing where team leads talk about OKR's for their teams 17:13:17 ah! 17:13:26 the next round after matt, duncan, and cecylia started 17:13:33 ye 17:13:40 mikeperry: wanna run the s61 part? 17:13:50 ok 17:14:44 I have not made a ton of progresss; still distracted, but much less so. I saw dgoulet's prelim review of flow control. thanks! I will make fixups this week 17:14:52 \o/ 17:16:09 dgoulet: the other checklist items on https://gitlab.torproject.org/tpo/core/tor/-/issues/40450 for you are slightly higher prio than the negotion stuff. do you have a preference for how we coordinate on those things? 17:16:30 I can do fixups and squash, and you can take it for a bit, or discuss them first, or ? 17:16:53 mikeperry: hmmm my prio list here was 1) Flow control review, 2) Ratelimit edge conn, 3) HS Specs for congestion control 17:16:56 mikeperry: should I reconsider? 17:17:17 yeah that sounds about right, though I would like to spotcheck with your knowledge of the oomkiller abnd kist queues too 17:17:26 to decide if we want to tweak or parameterize those 17:17:28 mikeperry: ok! lets meet up then when you are there? 17:17:38 shadow sim might hit those, idk 17:17:39 I left a comment about KIST in the review 17:17:43 and we can definitely discuss that 17:17:59 maybe my understanding there is off so voice would be desirable 17:18:23 ok yeah I have stable internet now so BBB is possible 17:18:51 anytime 17:19:30 jnewsome,hiro: how is the shadow sim data and baseline sime size scaling shaping up? 17:20:03 i'm generating the right tgen and onionperf logs now 17:20:18 i've enabled guards, but there's still a client scaling factor, so the results may be wonky 17:21:04 I have to work on the baseline part and the metrics you requested. hopefully this week will finish it 17:21:11 i'm working on getting rid of that (by scaling up the # of clients), but currently running into an unknown failure. semi-blocked on storage issues in the CI for debugging e.g. https://gitlab.torproject.org/tpo/tpa/team/-/issues/40375 17:22:54 speaking of which I should clarify on that issue that it's (kind of) blocking for me now. I can maybe work around by logging less in the meantime but it's a fiddly slow feedback loop 17:23:20 yeah, bleh 17:24:02 ahf: do you have enough gitlab knowledge to help improve that, or offer guidance? 17:24:09 or hiro, idk 17:24:12 hm 17:24:43 idk if space is actually scare or if this is just another conservative limit 17:24:50 i don't think i can set settings there 17:24:53 it's just the default i think 17:25:18 yeah I don't get the pushback for increasing the 4 MB console limit, especially since they can do it jsut for the shadow runner 17:26:16 yeah, i think that value should just be bumped to something larger than 4 MB's for sure. i don't even know what a webconsole is here, but i assume it's some kind of shell via the runner 17:26:42 yeah - that'd let me interactively debug while it's still running 17:27:04 but if the job fails and doesn't save logs i'd still be stuck 17:27:06 ah, it's on the runner's settings, then i cannot do anything magical :-/ 17:27:11 i think i can only touch the gitlab config itself 17:28:15 let's see what the sysadmins says, they have also had long weekend and just returned today 17:29:14 also see tpa/gitlab#95 17:29:23 I think there's some good discussion there about dpace issues 17:29:27 space 17:29:30 not sure if it's relevant 17:29:51 i think that is for artifacts, which can be GC'ed - i don't think log output gets GC'ed in the same way 17:30:41 ah ok 17:31:07 yeah, I could definitely see hesitating to increase this much if there's not some GC in place 17:32:02 ya, but just doubling it or 4x should be OK at least i think :-S but don't know how the space situation looks for GL 17:33:16 anyway we'll see. i'm not 100% stuck; just need to log less to the console and try again 17:33:50 cool! 17:34:22 ok 17:34:34 GeKo: gaba asked me if we still need to keep https://gitlab.torproject.org/tpo/network-health/metrics/analysis/-/issues/33077 open 17:34:55 hrm 17:34:56 GeKo: you and juga are comparing results a diff way, right? so those graphs not necessarily needed? 17:35:00 mikeperry: here's a run with guards enabled, but client scaling still in place, if you care to sanity-check results. https://gitlab.torproject.org/jnewsome/sponsor-61-sims/-/jobs/35340/artifacts/browse/jobs/ 17:35:22 jnewsome: thanks. is this still a 1% sim? 17:35:31 yup 17:35:44 mikeperry: right 17:35:56 we *could* do something like that 17:36:10 but it is not really necessary i think 17:36:13 ok 17:36:16 so, closing is fine 17:37:18 i wonder where the code for that is, though 17:37:22 might be handy 17:37:27 at some point 17:37:52 but i can dig for that later 17:38:28 so I the last item I'm aware of is that juga still needs a decision on what to do about pinned exits vs onions for https://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40022. I think we are now leaning towards onions, since both approaches require hacks, and maybe onions less so 17:39:11 but other things are currently higher priority than getting that done (which is fine for now) 17:39:15 I think the exit approach would require less hacking, but I'll defer to whoever is doing the hacking 17:39:46 who is it? :) 17:40:19 well if it ends up being onions, probably dgoulet. dgoulet also not happy with .exit, so he is in theory motivated ;) 17:40:34 but maybe there is a way to do exits without .exit 17:40:41 onion side np... the .exit notation is very MEH for me 17:40:42 I have not had a chance to put more brain into it though 17:40:51 as in with the past of that thing :P 17:40:53 Did you try mapaddress + .exit ? 17:41:13 That should work. 17:42:27 ah is that part of arma2's hack already? looks like it may be 17:42:41 so that .exit can only be used if we're doing an addrmap from the control port? 17:43:03 i think .exit is alread supported on addrmap from controlport, no hack needed 17:44:57 ok 17:45:05 are we at the end? :-) 17:46:19 maybeeeee 17:46:53 one can never know if the meeting is truly at its end 8) 17:47:00 does anybody have more we need to chat about? 17:47:19 sorry I lost internet again 17:47:23 * jnewsome is good 17:47:27 maybe not so stable after all 17:47:27 mikeperry: ah 17:47:44 anyway I am good I think 17:47:47 excellent 17:48:00 i am good, to 17:48:02 o 17:48:14 thanks everybody o/ next meeting is on monday, and remember we do the first-of-the-month meetings on next monday, which means a long network team meeting AND we have the s61 bbb sync earlier 17:48:24 update your calendars if needed 8) 17:48:25 thx o/ 17:48:27 #endmeeting