16:59:05 #startmeeting Network team meeting, 2023-04-03 16:59:05 Meeting started Mon Apr 3 16:59:05 2023 UTC. The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:59:05 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:59:08 o/ 16:59:09 hello hello welcome 16:59:11 o/ 16:59:15 * jnewsome is here, warily eyeing nickm's pouncing stance 16:59:16 * nickm pounces, catlike, and misses completely: hihi! 16:59:22 our pad is at https://pad.riseup.net/p/tor-netteam-2023.1-keep 16:59:52 hello 17:00:06 okay, so today is technically a "first of the month meeting", which means the s61 part is split into another meeting at 18 UTC (iirc) 17:00:56 going to start with announcements 17:01:04 no s61 bbb today actually 17:01:06 i see this one from a week ago but i think my life fuckery caused us to not have a meeting here? 17:01:07 so it will be here 17:01:11 mikeperry: ah! so we do it here? 17:01:12 ok good 17:01:19 nickm added the following: 17:01:20 * [nickm 2023-03-27] Arti conversation to help orient around onion services, discussion around changing the next meeting (but only that one) to be earlier: 1500UTC seems to work with folks 17:01:28 did we already talk about this or is it something we aught to talk about now? 17:01:55 That was about last week's Arti meeting I think 17:02:06 Which we did indeed do at an unusual time 17:02:10 ahhhh! 17:02:12 it was where it was moved 17:02:14 perfectly fine 17:02:17 good good, i am moving along 17:02:36 gaba and i just did a smaller pass on the board at https://gitlab.torproject.org/groups/tpo/core/-/boards 17:02:42 mostly moving some stuff into ~Q2 17:03:02 and a few smaller things that hadn't been touch in a while was closed or demoted 17:03:12 but all the stuff folks have in ~Doing and ~Next should be fine 17:03:27 does people have anything with their boards here they want to talk about? 17:04:26 Not really. I keep generating yak MRs but gabi and nickm seem to be disposing of them efficiently. 17:04:48 <3 17:04:49 very nice 17:05:06 i think dgoulet wont have anything to add here with releases - goal is to roll 0.4.8 alpha's in may at some point 17:05:25 we can skip the triage-bot things until then 17:05:31 nothing incoming from other teams 17:05:44 mikeperry: okay, you wanna talk about s61 here then? 17:05:52 ok! 17:06:06 (conflux conflux conflux conflux conflux conflux) 17:06:10 so the main thing is the conflux mr is up: https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/704 17:06:15 \o/ 17:06:18 very exciting 17:06:18 nice 17:06:40 :o 17:07:06 as per ahf's mail, anyone can look at that, but yeah please try to focus on big issues and spec stuff, since we want to toss C-Tor client into the fire soonish anyhow 17:07:27 XD 17:07:32 mikeperry: i'd like you to comment on my current plans wrt review on that so you can aim me better 17:07:42 is now the right time or should i wait till later in this meeting 17:07:44 ? 17:07:48 we want to get this in before dgoulet leaves for vacation, but you can also continue to look at it for spec things or serious issues after that 17:08:00 mikeperry: How exciting. 17:08:43 I mean yeah we can discuss review a bit, see if who is planning on doing it, and when 17:09:20 who is interested in looking at it, I guess might be a good start? 17:09:42 ok. I'm planning to do a really careful review of the spec, looking for #1 security issues #2 forward compatibility issues and #3 ambiguities that will bug us when we go to clone this in Arti 17:09:52 my plan was to do a somewhat fast pass on the spec and dive a bit more carefully into the C code 17:10:00 mikeperry: So FTAOD are comments based purely on reading the spec prop #329 welcome or would I be too late for that ? 17:10:12 and also give it a spin on Windows 17:10:47 it is a bit late for massive protocol changes, but yeah spec clarity and stuff like that is good 17:10:54 at that point, I don't think I'm going to have time to read all of the C code carefully before dgoulet leaves; I'm hoping that mikeperry and dgoulet can suggest which commits/files/functions/aspects of the code want the most attention 17:10:56 Looks like spec comments are going to be welcome. Although I guess mikeperry may have a different view when it becomes evident how picky I can be... 17:11:24 I'll try not to spot any fundamental design issues then :-). 17:11:29 Diziet: IME it helps a lot if you clarify which nitpicks are nitpicks and which offer to break the universe 17:11:42 (end-of-query) 17:11:58 Right, also which are textual clarifications and which are things where I am proposing to change the behaviour. 17:12:55 the important thing this week is likely to discover any catastrophes and then we can do nitpicks afterwards as we also stabilize in april/may for 0.4.8 alpha. isn't that correct, mikeperry? 17:12:57 (Do my plans sound reasonable) 17:13:34 ahf: yeah. this is not the last MR on it. but we do want the protover live on main, because some relay operators run main and we would like info about any logspam 17:13:49 dgoulet and I already found some of that logspam in the case where nobody ran conflux 17:13:51 *nods* 17:14:43 nickm: yeah it sounds reasonable 17:15:09 mikeperry: cool! do you/dgoulet have ideas where I should look in the code now, or should I wait a few hours? ;) 17:15:16 we will have to play it by ear as to what is simple to change and what will need to be deferred, etc 17:15:22 yes absolutely 17:15:24 mbeth, gabi: feel free to also dive your heads into this area if you want to -- having more people who understands these things is going to be good once we get further down the road with arti too 8) 17:15:36 cool, i'll dig into it today 17:15:41 ack 17:16:06 I will not claim to have blocking issues. If I think I do, I'll let you and dgoulet decide if they are. 17:16:37 nickm: the fixups we have are very minor. they will be on the mr soon. the code is not going to change majorly 17:16:40 Please let me know any other ways I can structure my review to optimize your wellbeing 17:16:53 nickm: the starting point for conflux is really the conflux* files in src/core/or/ ... especially the .c and _pool.c 17:16:57 ok 17:17:02 nickm: from there, you get all ramifications into the maze 17:17:19 dgoulet: is there some kind of a minotaur in the middle, and should I bring string? 17:17:19 I will have to think about specific commits. but you can use your instincts there too. they are all functionally organized 17:17:21 nickm: there is also trunnel def. for all 3 new cells 17:17:33 4* 17:17:45 nickm: it is big and powerful, all I can say :P 17:19:17 so that was fairly painless... so far ;) 17:19:48 ok. other random s61 things are the ratio experiments for the PT bwuaths, re juga and geko (who may not be here, and that is fine) 17:20:17 mikeperry: GeKo changed today the threshold to 0.5, i still need to look at the data from last week 17:20:21 and geko asked about the last piece of tuning for congestion control in : https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/49#note_2892657 17:20:24 too which I replied 17:22:06 juga: ok, sounds good. there's no huge rush on that, but having it this month means we can mention it in this report 17:22:40 if not, I don't think it is a huge deal either, from my read of the situation, but I have only second hand info on how the extension for the audit went down 17:22:57 mikeperry: ok 17:25:06 ok. I think that covers it for stuff in progress. any other questions, comments, etc? 17:25:06 anything else for today? 17:25:08 (one last q to make sure. The spec to review is prop329 as amended by torspec!123 and the code to review is tor!704. Right?) 17:25:09 Uhm, which one of [tpo/core/debian/tor, tpo/core/tor] did you mean? 17:25:23 tpo/core/tor!704 is what I meant, you silly bot. 17:26:04 nickm: yes that is correct. there is an MR for the spec, as mentioned in the code MR 17:26:22 So the spec I should be reading is the one in !123, ok. 17:26:42 for sanity I recommend just reading https://gitlab.torproject.org/mikeperry/torspec/-/blob/conflux_mr/proposals/329-traffic-splitting.txt in full rather than trying to grok the diff 17:26:49 Right. 17:27:16 I guess for textual changes I should make MR(s) and if there are substantive things file a ticket ? 17:27:37 eh just comment on the spec MR. could add suggestions and stuff 17:27:46 OK, fine :-) 17:27:52 let's try to avoid a huge ticket or MR spawn, if we can 17:28:00 not playing mao here, or whatever ;) 17:28:01 Sure, whatever works for you 17:28:19 Us arti folks seem to like the mr and ticket spawn... 17:28:28 Happy to do it your way :-) 17:28:38 lol 17:28:39 yeah we actively avoided that for this dev. had a pad and zipper merge 17:29:20 the pad still has post-merge stuff on it, includeing some potential tickets 17:29:27 will get to that later 17:29:38 speaking of merge details.. once conflux goes in, will gitlab's MR system be okay if i rebase and then push an update, or should I do a new MR, or something else? 17:29:58 (for the pending PoW MR) 17:29:59 mbeth: it's hard to know - it can do some automatic stuff, but it is not super bright 17:30:07 mbeth: if you are talkin about PoW, personally, you could squash + rebase and force push the MR, I would be fine with that 17:30:22 ok i'll plan to do that, seems easiest if gitlab won't blow up 17:30:22 mbeth: as I want to go over it all again 17:30:25 IMO: try it the easy way, and if it fails say "oops" and do the harder thing :) 17:30:30 probably easier 17:31:52 okay, nothing else folks? 17:32:16 * dgoulet is good 17:32:24 thanks all for joining, and happy hacking during the week! and nice work by the conflux gang! 17:32:27 Oh this weekend is Easter. 17:32:31 #endmeeting