16:58:25 #startmeeting Network team meeting, 30 January 2023 16:58:25 Meeting started Mon Jan 30 16:58:25 2023 UTC. The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:58:25 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:58:29 hello hello, welcome! 16:58:32 hiya 16:58:35 our pad is at https://pad.riseup.net/p/tor-netteam-2023.1-keep 16:58:54 o/ 16:58:54 giving folks a few minutes to join 16:59:38 o/ 16:59:46 o/ 17:00:07 okay 17:00:31 we are sort of done with the arti estimations, which is very nice. C tor we should probably look into roadmap stuff next week when i am back from brussels 17:00:43 then we can probably get a nicer overview on the board 17:00:47 how are folks doing here: https://gitlab.torproject.org/groups/tpo/core/-/boards ? 17:00:54 hi 17:01:02 * nickm is here , and on distracted programmer mode :) 17:01:16 the only thing i am unsure about is who should have https://gitlab.torproject.org/tpo/core/tor/-/issues/40661 assigned to them? 17:01:23 it's in ~Doing, but with nobody assigned 17:01:58 GeKo / dgoulet: ^^ 17:02:49 iirc, this is a patch in C-tor and a dirauth conf change 17:03:14 so the net team one should be mine and then I suspect GeKo should have a ticket about this in the health team to not lose track? 17:03:14 which part of it are we at? :p 17:03:21 ah 17:03:25 yeah, so it may be split 17:04:02 i thought we'd do a blog post first 17:04:20 oh yeah that part... 17:04:24 and wondered whether dgoulet would do that one given that he was involved in that proposal 17:04:32 *that#s where we are currently at :) 17:04:50 so i can assign it to dgoulet and maybe move it into ~Next forn ow? 17:05:05 then we can do the spliting idea 17:05:08 I like everyone optimism on this :) 17:05:09 ok 17:05:14 *splitting 17:05:20 it's not something we have to do right now, no? 17:05:26 we'll make it!1! 17:05:30 i am fine with whatever here - we can just move it out of ~Doing 17:05:35 that is all i care for right now 17:05:39 then we can triage it at a later point 17:05:48 i think we could get the blog post out sooner than later 17:06:01 doesn't have to be a long one anyway 17:06:03 *could* or *should* ? ;p 17:06:14 should 17:06:19 :) 17:06:26 i have it put it in ~Next for now with nobody assigned 17:06:34 then we can talk about i t when we look at C tor stuff in the near'ish future 17:06:54 i think that was all in the board stuff 17:07:03 dgoulet: anything on releases we need to talk about? 17:07:15 nothing on release side for now. 035 EOL in 15 days ;) 17:07:21 (woo) 17:07:25 0.4.5! 17:07:31 yes sorry! 17:07:34 we should almost have aparty just for that 17:07:38 (also woo) 17:07:46 yeah, 0.3.5 was a long one too /o\ 17:07:48 awesome dgoulet 17:08:02 3 is nearly equal to 4 17:08:30 yeah! i think 0.3.5 was more painful than 0.4.5 was iirc 17:08:36 okay, nothing incoming from other teams 17:09:13 we had a relay ops meeting this saturday. i think the only major request other than some stuff that we already have tickets for is a dashboard for grafana, but i saw dgoulet and GeKo talk about that in #tor-dev earlier, so i think that is being talked about 17:09:24 we have an announcement from nickm: 17:09:25 Nick has dentist appt Thurs 2 Feb, 1400-1500. Might be late for Thursday meeting, if we have it. 17:09:58 i think it's very likely we wont have a thursday meeting this week since i am traveling those days, but if y'all need to talk about anything, you can always just take the thursday room and chat 17:10:11 okay, on discussion items: 17:10:11 qq: when is the FFI/RPC meeting? :) -nickm 17:10:21 will come an email later today, just giving folks a few more hours to answer 17:10:30 [nickm, 26 jan] Should we propose some ideas for GSoc? Possibilities: 17:10:31 build something neat with arti, propose API/doc improvements. 17:10:37 Maybe I should mention there is some risk I randomly decide to cycle to Wentworth (next on my alphabetical villages) if I get too stir crazy, which would mean I would vanish very early some day. But I doubt that will affect anyone's planning. 17:10:52 Diziet: ah, nice 17:11:09 do we have anything else we want to consider for gsoc? i don't think we have capacity for doing anything gsoc's on C tor 17:11:20 I thought about it but didn't come up with anything, sorry. 17:11:37 So, I'd be happy to be one of two co-mentors on that proposed project if anybody wants to be the other. But I ought not be sole mentor. 17:11:50 would the arti team be interested in moving on with the API examples project? 17:11:55 ah, nice nickm 17:12:05 I am very happy to co-mentor 17:12:13 very nice 17:12:24 do you two want to follow up with gaba than on the thread about this yourself? 17:12:28 nickm: We should chat outside the meeting about proposal doc etc 17:12:35 👍 17:13:00 Diziet: works for me 17:13:04 awesome 17:13:29 i don't think we have anything else for today, so we can move to the last s61 irc meeting for january - next week is the BBB s61 meeting since it'll be first monday of the month 17:13:33 thanks all non-s61 folks for joining! 17:13:37 mikeperry: wanna take over? 17:13:43 o/ 17:13:45 o/ 17:13:51 ok sure 17:13:58 thanks nickm <3 17:14:01 lol 17:14:06 epic pad confusion 17:14:16 so first up I have been doing the sims for https://gitlab.torproject.org/tpo/core/tor/-/issues/40585 17:14:30 I have a set of param values to use when exits upgrade 17:14:46 noted on the ticket 17:15:25 I also did a couple sims for jim. turns out rob fixed an issue with tgen that was causing higher than normal error rates in the sim. but that did not get rid of all of the errors seen in onion services 17:15:48 err sorry, the parmam ticket is https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/49 17:16:22 mispaste. the first ticket I used to record dgoulet's idea about some kind of persistence counter for overload-general 17:16:32 which I think we table for S112 17:17:23 juga: you successfully unblocked on the PT load balancing after fixing that parsing issue? 17:17:43 mikeperry: yes, more or less 17:18:05 hopefully the other errors go away running the scanner from a faster machine with more bandwidth 17:18:56 ok 17:19:54 so then for the conflux update: I implemented stream blocking and unblocking, takeing multiple circuits into consideration. I added helper functions for that and layer_hint checking for streams to conflux_pool.c 17:20:27 I also implemented some rate limiting for circuit switching, so we don't switch too often (since that will be expensive until prop#340) 17:21:36 in the process of doing this I added some TODO-329-STREAM markers for where we will have to share pointers of the stream list and half-closed streams, during linking conflux circuits 17:22:02 exciting with the conflux work 17:22:28 dgoulet: so far the git-absorb workflow is working for m; the commit structure is pretty decent, though at some point we'll want to change commit order for ease of reviewing 17:22:39 excellent 17:22:55 I need to squash my conflux_next branch for those changes I mentioned 17:23:35 after that I want to stare at the algs again, with this new rate limiting and stream blocking support 17:23:47 and update the proposal 17:24:10 but otherwise I am pretty close to done with the core algs and operation 17:24:19 nice 17:26:12 big time nice 17:26:51 I could possibly do the circuit purpose stuff next, since I've done that before. it will be a little involved.. 17:27:29 I still generally think that a new purpose will be safer wrt making sure these things are not used elsewhere, but maybe there is another way 17:27:43 like only using a special purpose until they are linked or sth 17:29:11 anyway, dgoulet I will let you know when I am about to squash that branch. can update your branch as well then, and perhaps we can sync in bbb 17:29:21 the next s61 monthly sync is next monday at 18utc 17:29:35 yup 17:29:38 nice 17:30:18 I think that is all unless there are questions 17:30:45 not from my side 17:31:09 * juga is good 17:31:13 * ahf good too 17:31:45 ok all good then 17:31:58 thanks all o/ 17:32:00 #endmeeting