16:58:20 #startmeeting network team meeting december 14 2020 16:58:20 Meeting started Mon Dec 14 16:58:20 2020 UTC. The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:58:20 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:58:23 hello hello, welcome 16:58:25 hi 16:58:30 hi! 16:58:33 our pad is at https://pad.riseup.net/p/tor-netteam-2020.1-keep 16:59:12 let's see who else will join today 16:59:19 hi! 16:59:30 hi there 16:59:42 hello 16:59:58 o/ 17:00:26 o/ 17:00:26 we have no new announcements this week. i've sent out an invite to a january arti hackathon to tor-internal@ that y'all should look at if you want to join 8) 17:01:23 we have four unassigned code reviews, and a lot of unreviewed reviews in the backlog. many of them are mine and i will prioritize those today and tomorrow 17:01:37 asn, dgoulet: you will shuffle the 4 others around? 17:01:40 sure 17:01:45 awesome 17:01:53 ugh, i am out of order 17:02:01 how is everybody doing with their boards? 17:02:57 doing pretty good! 17:03:11 i need to make sure all my needs_review and merge-reasy stuff is all inthe correct state 17:03:34 nice 17:04:11 * ahf hopes to decide on an end for s91 this week so i can wrap that up, succesful or not 17:04:31 okay, how are folks doing with 045? 17:04:40 just put my last ticket into needs_review... 17:04:50 able to help others if need be 17:05:09 * ahf is on tor#32666 for that and then tor#40185 this week 17:05:34 I think I have couple outstanding but things under control mostly 17:05:55 nice 17:06:23 okay, we have two items to discuss today 17:06:33 [14 Dec] Should we skip next week's meeting, since it's a short week? -nickm 17:06:40 i think that is a good idea. i was just thinking a bit about the same 17:06:45 +1 17:06:48 +1 17:06:58 mikeperry: up to you though if we want to do s61 things next week, but then there wont be the network-team content before 17:07:15 oh I will be off that monday 17:07:29 mentioned it in the planning meeting; still need to add it to the afk cal, sorry 17:08:01 ah, then let's also all of the network-team meeting on monday 17:08:07 ... 17:08:14 ah, then let's drop all of the network-team meeting on monday 17:08:37 next team meeting will then be january 11 :-) 17:08:59 okay, next item is: 17:09:03 [14 Dec] IPv6 bandwidth stats: what is the status? 17:09:11 who added that? and want to run the discussion? 17:10:03 sounds like it might have been gaba? 17:10:16 ah so on Friday, I setup a relay on IPv6 17:10:28 and we wanted to confirm what option is turning on IPv6 stats for real :P 17:10:51 so the "ipv6-conn-bi-direct" is indeed set by "ConnDirectionStatistics 1" 17:10:56 and the rest by "ExtraInfo..." 17:10:56 yay! 17:10:59 yes, it was me 17:11:07 so, there's 1 relay reporting these stats now? 17:11:09 let me check... 17:11:23 is it akka and ukka you did it with? 17:11:27 "ukko" 17:11:33 err, yes, ukko 17:11:34 awesome 17:11:42 gaba: you need it for some reporting? 17:11:45 yes 17:11:52 it was not clear if the reporting was happening 17:12:04 karsten: for some reasons I don't see my extra info here on the relay so I'm guessing collector should have it ? :) 17:13:08 what's the nickname? 17:13:27 12:13 <+dgoulet> "ukko" 17:13:37 hmm, no, I don't see it. 17:13:50 fantastic... 17:14:09 ah, capital U. 17:14:18 ya 17:14:23 303509AB910EF207B7438C27435C4A2FD579F1B1 17:15:01 still no ipv6-conn-bi-direct line.. 17:15:08 :/ 17:15:12 ipv6-conn-bi-direct 2020-12-14 15:48:53 (86400 s) 1315458,171654,68320,370614 17:15:12 anything on disk? 17:15:15 I see it locally ^ 17:15:33 interesting! 17:15:34 are we neglecting to put it in the extrainfo doc? are we running out of space? 17:15:50 the first sounds plausible. 17:15:54 that is the line in stats/conn-stats 17:16:01 anyway I think we can figure that out off meeting? 17:16:06 yes. 17:16:16 gaba: is that OK with you? sounds like dgoulet and karsten will follow up on it 17:16:19 good starting point though! 17:16:56 taking this offline is fine with me. 17:17:18 ok 17:17:19 yes, it is ok 17:17:24 excellent 17:17:24 okay 17:17:30 but i would love it if t his can be figured it out before we go afk 17:17:37 i think it's s61 time then 17:17:40 we fill in a bug if there is a bug and i fix the report 17:17:41 mikeperry: you want to run this 17:17:55 Sure 17:18:17 for objective 1, we're still digging into cbt. I have spec updates for asn's review, and some fixes, but need to write a unit test still 17:18:51 and asn is wrapping up the experiments with that branch, which I still need to look over 17:19:39 for o2, juga is investigating relay responsiveness, persistent state duration discrepancy between torflow and sbws, and measurement priority 17:20:14 for o3, congestion control proposal merged; conflux proposal still needs work and analysis to minimize reorder queue, and for traffic analysis/side channels 17:20:51 for o4. dgoulet and my overload proposal posted to tor-dev; good feedback 17:21:08 and geko is finding more badexits and bad relays 17:21:14 nice 17:21:36 GeKo: is also working in o2 with me :) 17:21:58 juga: did you figure out what needed to happen with some of the tickets? any question to send here? 17:21:58 ah yes, thanks for that 17:22:19 we made good progess last week on that 17:22:30 gaba: yes, i think we're good 17:23:23 (dgoulet: I think I found the bug. looks like load_stats_file reads until the "conn-bi-direct" part of the "ipv6-conn-bi-direct" line, cuts off everything before that, and reports the rest.) 17:23:27 ahf: have you begun looking at flashflow on the core-tor side? should I look over anything specific rn? 17:24:05 i have, i was going to dump all the small nits to it, but i will probably ask for some help with the next steps this week 17:24:09 also the sbws side of things 17:24:20 err, the python side of things 17:24:30 karsten: ok let me know about it on #tor-dev when you can 17:24:56 ahf: is pastly committed to fix things up? 17:25:01 even next year? 17:25:43 GeKo: i don't think so, i think he will leave in january to another group at their office 17:25:51 should we have a minimum requirement for test coverage for when a request like this happen? 17:26:02 but it's a lot of things that needs to be done i think, but the overall lines looks OK. there are no tests though 17:26:03 can he at least add tests before leaving? 17:26:21 gaba: yeah, that is one of the things that has to change 17:26:33 ahf: that was my impression. so we need to figure out who will pick that up and push things over the finish line? 17:26:45 we also need to decide if this is what we want 17:26:52 one thing is the code itself, but also if we want flashflow at all 17:26:59 like if it's a priority 17:27:05 right 17:27:06 mikeperry also have the floodflow code now 17:27:08 good call, gaba. tests are a good chunk of work that can be done by then 17:27:19 the declared results are impressive; if they measure up IRL we might want to do flashflow IRL. 17:27:36 IMO it could be a good part of S61 to push flashflow or any successor of it over the finish line 17:27:45 including deciding which thing to do :) 17:27:53 i think it is a part of s61 :-) 17:28:00 I have the same opinion as nickm. it's also not just perf, but measurement security. 17:28:10 but I suspect we will find lots of edges need cleaning up 17:28:45 for live deployment 17:29:14 let me write a note right away this to hear about tests of this 17:29:31 i wanted to do that friday but then the privchat thing went on and i never returned to work after that 17:29:53 I think we'll have to plan to put substantial effort into this in 2021 if we're going to get it merged, one way or another. Is that also your judgment, ahf? 17:30:16 these lrough edges include needing to integrate it with sbws; it does not eliminate tor replace sbws; it merely reduces how much sbws should have to change relay measured weights 17:30:42 nickm: i think so, yes 17:30:58 i think it will bel ike when KIST got in where dgoulet spend a lot of focused time on that 17:31:09 i don't remember how big kist was upon arrival though 17:31:40 and it's not just tor code that needs changes this time :) 17:31:46 yep 17:32:34 mikeperry: we do not have budget so much for 2021 on s61 to incorporte flashflow... 17:32:43 what is your plan there? 17:32:58 gaba: yes that is my concern as well.. sbws is more important to get right, first 17:33:09 yes 17:33:13 it is not looking good if we have to do a lot of work for flashflow too 17:34:42 especially also since FF will take some focus away from the other things with sbws that is needed :o 17:35:03 a stopgap in terms of functionality is to continue to find bugs reproducing flashflood, and deal with measurement security (relays lying) via network health scanning 17:35:14 and then we can look for another funder for flashflow merge 17:35:40 and deployment (which will also take signficantly longer due to he need for relays to upgrade before we can turn it on) 17:36:06 yeah, flashflood can be deployed on the network without upgrading any parts of the network? 17:36:14 yes 17:36:56 in fact, congestion control fixes to sbws should have very similar effects as flashflood 17:37:35 if we use short paths with controlled exits, or single-onions with short paths 17:38:35 this will get us the ability to driver relay descriptors up to their full capacity during measurement.. and then we only have to deal with lying potential (which flashflow solves very elligantly, but we can still scan/monitor for) 17:39:01 at any rate, we should see what we can get done before pastly leaves 17:39:11 unit tets and initial code review seems good there 17:39:34 ahf: lmk as soon as your initial review is posted. I will take a look then 17:39:38 i asked for testing info on the ticket 17:39:42 ya 17:40:28 mikeperry: will do 17:40:40 mikeperry: your last day this year will be friday this week? 17:40:49 yah 17:41:16 let me reshuffle my week plan then a bit and dump it all in some structured way tomorrow 17:41:27 thanks 17:42:22 do we have more for today? 17:43:00 I think that's it for s61 17:43:04 not from me 17:43:20 woh, let's end the last network team meeting of 2020! 17:43:23 thanks all! 17:43:26 #endmeeting