16:58:33 #startmeeting network team meeting november 17 2020 16:58:33 Meeting started Tue Nov 17 16:58:33 2020 UTC. The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:58:33 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:58:37 hello network-team 16:58:39 yello 16:58:40 hi ahf! 16:58:42 hi 16:58:46 our pad is at https://pad.riseup.net/p/tor-netteam-2020.1-keep 16:58:56 for folks here for s61, that is the last part, so we will get to that after a bit of time 8) 16:59:15 no announcements this week 16:59:28 how are folks doing with their boards? 16:59:41 doing ok 16:59:55 yeah making much progress, pretty good 16:59:57 * ahf not, but hope to recover that this week 17:01:14 how are we doing with 0.4.5 ? 17:01:40 I've got one assigned ticket left for 045 stable. I'd like us all to try to burn through our remaining 045 stuff... 17:02:09 also there are some new tickets that we haven't triaged or anything; maybe on Thursday we should go through the last week or two of tickets and see if any of them need to go into 045? 17:02:45 Also we have three unassigned tickets in 045 17:03:22 * dgoulet takes tor#40142 17:03:58 hm 17:04:04 i can take tor#40185 17:04:18 ok, i'll take the other one 17:04:28 BOOM 17:04:30 very nice 17:05:27 i see no new tickets from other teams to us 17:05:48 we have the first of two discussion items: 17:05:50 [17 Nov] Flashflow: what are our next steps now that pastly has posted a MR? (tor!210) 17:06:04 i have been assigned the MR and was planning on going over it in this week and leave initial feedback there 17:06:19 but everybody else is of course welcome to join in there 17:06:25 it's 47 commits 17:06:51 hm. maybe you and/or pastly should walk is through it once you've formed a first impression? Or you can decide as you go? 17:06:53 so it will without doubt need more eyes than my two 17:06:54 woa... that is +3.8k linws 17:06:54 fun 17:07:04 yeah, it's big 17:07:10 ahf: i guess the tor things need to get hashed out first before we start to look at the sbws? 17:07:20 or should we try to parallelize that 17:07:21 ? 17:07:31 GeKo: i think so too, yeah. i also need to keep an eye on the spec changes here in this review 17:07:39 tor changes might change the sbws side 17:07:48 yeah 17:07:49 we had some questions about how flashflow was doing auth 17:07:53 for measurers 17:07:58 not sure which way that went in this impl 17:08:52 i have set my friday off to this and i am not sure how much else i will get done that day with trying to figure this out. this wont be a one week cycle review for sure 17:09:16 there is some high level things that david also pointed out like no tests for now 17:09:24 so it surely wont be a "let's land this" review 17:10:00 there's also a discussion item for "how to handle new issues" -- we're tackling that on wednesday... 17:10:10 mikeperry: i am gonna track these hours in my notes as s61 work 17:10:11 and one from nov 16 aking about templates for gitlab? 17:10:20 yes 17:10:28 we are not done with discussion items :-) 17:10:51 good catch with the 16/11 one though 17:10:58 oh flashflow probably wants a version of "happy families" for relays to say they are on the same machine 17:11:08 I have not read "happy families" yet 17:11:18 that was up in the meeting with matt and aaron 17:11:20 but it is another thing flashflow is very likely to need 17:11:50 yeah 17:12:10 ok 17:12:20 [17 Nov] We should go through recently opened issues and figure how/when to handle. 17:13:06 is this one of those things that will take us 5-10 min on a thursday bbb session? 17:13:09 I nominate this thursday's meeting for that, unless we have something else? 17:13:14 yes! 17:13:16 i am +1 on that 17:13:27 the "ticket list" tasks are so much easier over bbb 17:13:42 +1 17:14:17 ok! 17:14:26 (Nov 16th) - do we use templates for issues in Core? please add any comment to the ticket -> https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/47 17:14:46 this is quite interesting. we have these templates we can prefill (including commands to gitlab with /assign etc.) that we can add to tickets 17:15:01 i added that mostly to call attention to see if people have any opinion on adding issue templates to the projects in core group 17:15:03 so people get a dropdown saying "Feature" or "Bug" or whatever and we have some info they can pre-fill 17:15:03 yeah that would be great 17:15:11 I have no strong preference -- I'm okay either way. 17:15:11 but we need to figure out what to add there 17:15:16 We can try it and see how it goes? 17:15:17 things like "run tor --version" and paste the output 17:15:33 i added some proposals to the ticket in the pad 17:15:37 and I suppose it can auto assign if certain labels ? 17:15:43 we can have more specifics for the tor project 17:15:46 dgoulet: yes 17:15:51 superb 17:16:04 hm, it can't do if statements i think 17:16:15 or maybe it can :o 17:16:19 gaba is more uptodate here 17:16:33 if people are ok i can add them to the projects and then we go from there 17:16:38 +1 17:16:43 +1 17:16:51 ok 17:17:08 okay 17:17:14 i don't see anything else in bold 17:17:26 so we are at the point where this meeting warps into the s61 status meeting 17:17:50 mikeperry: do you wanna start here? 17:18:31 ok I put the per-objective progress updates on the pad 17:18:37 under my update 17:18:49 I may have missed some things esp wrt geko's network health 17:19:24 how is that format? do we need more info? do we want me to go thru things or is async ok for this? 17:19:34 we decide the format 17:19:41 i am fine with async 17:20:38 async OK with me 17:20:41 anything else? asn and I are working well on CBT+onionperf but it is tricky 17:20:50 two things I'm hoping to see as followup from the current CBT work and similar stuff: 17:20:55 I owe dgoulet some edits on the overload proposal. will get to that this week I hope 17:20:57 mikeperry: we are set on the sbws roadmap, right? Do we need anything there? 17:21:04 (and i did not spend too much time in O4 but was working on the sbws side mostly) 17:21:12 https://gitlab.torproject.org/groups/tpo/-/boards?scope=all&utf8=%E2%9C%93&label_name[]=Sponsor%2061&milestone_title=sbws%3A%201.1.x-final <-- that will be the sbws roadmap related to s61 17:21:14 congestion control still back burner for now; other stuff is more important as it is blocking progress on multiple other things 17:21:15 a pass where you go over the spec and make sure that it explicitly excludes the bugs that you fixed, in a way that would be obvious. 17:21:40 a writeup of what exactly turned out to be up, from a "in retrospect" pov 17:21:44 mikeperry: if you want to deleguate congestion control stuff to me in the meantime of the overload proposal, feel free 17:21:47 gaba: at a high level it is good. we will want to manage specific tickets in the planning meeting 17:21:50 (those may already be in your plans) 17:21:55 ok 17:22:58 nickm: I am doing the spec updates. I have a draft branch with current things but we're still tweaking Xm estimation 17:23:04 neat 17:23:10 excellent 17:23:50 I saw that you were doing spec updates for behavior that had to change, but I just wanted to make sure that clarification was also in the pipeline. Sounds like it is 17:23:54 GeKo: with the arrival of FF and some backlog on my other netteam tickets, i wont be getting around to finish my tcp reachability scanner and convert it to have prometheus output this week :-/ 17:23:54 asn and I can do a tor-dev post with our onionperf findings 17:24:28 it's cool 17:24:31 nickm: yeah I clarified much of the confusion and omissions in the spec, or at least tried to 17:24:36 great 17:24:55 fixed the "we" thing, reorganized, added more detail, etc 17:26:56 nice 17:27:10 dgoulet: wrt congestion control, it is not urgent. I have things in mind to that should be clarified wrt experiments. I can do that, no worries 17:27:16 ack 17:28:05 dgoulet: if you want to revive your conflux proposal tho and adapt it to use congestion control info, that would be great tho 17:28:24 mikeperry: ah that could be an idea yeah! 17:28:44 nickm also wanted side channel analysis section there. you don't have to write it, but at least put a place holder so we remember 17:30:04 dgoulet: for conflux, don't worry about resumption or windows required for that. just focus on the unreliable version for now. small reorder window needed for that but hopefully not as large as what would be required if a circuit path failed.. I hope 17:30:20 ok! 17:30:41 dgoulet: and keep in mind nick's proposal for stacked relay commands/extra fields.. we need a sequence number 17:30:50 I forget that prop number... 17:31:08 325-packed-relay-cells.md 17:31:51 yah. I think that is what we would use for adding sequence numbers? 17:32:24 can't recall but I'll keep that in mind 17:33:34 anything else we have to look at today? 17:33:36 (resumption for conflux would be awesome but it is not clear relays can support that much memory for such windows... if you find a way feel free to mention it tho) 17:34:03 mikeperry: I have my ideas, we'll see how realistic it can become 17:34:08 * dgoulet is good ahf 17:34:13 ahf: i guess next steps for the sbws - torflow issue? 17:34:31 we could patch sbws to figure out whether mikeperry is right 17:34:47 while making sense of the bwauthealth data 17:34:56 it is already emitting an unmeasured relays csv right? 17:35:04 thought I saw those in the dashboard juga made 17:35:11 yup 17:35:16 comparing that to ahf's scanner results for the appropriate time should be easy 17:35:17 with unmeasured relays 17:35:32 mikeperry: yep 17:35:34 roger's 0.2.9 point might also be relevant, idk 17:35:46 yeah, i think taking the set of nodes i published from my test and compare it with the set we have elsewhere might be next steps there? 17:35:49 probably a few reasons for this problem 17:36:57 ahf: yah. make sure to use the appropriate times from juga's dashboard vs your scan 17:36:58 ahf: we might need a new test run of your script, but apart from that, yes 17:37:05 yep 17:37:07 juga had results going back thru october I think 17:37:16 right 17:37:33 mikeperry: i think most of those files were buggy 17:37:34 and some were unusable due to bugs 17:37:38 yeah 17:37:38 yup 17:37:44 ah 17:37:50 but once that is solved 17:37:56 a new test run with ahf's script 17:38:00 hopefully last 2 ones and consecutives are fine 17:38:08 might be fastest to move forward 17:38:36 i get a slightly different set each time i run my script 17:38:41 that part i found interesting 17:39:06 i think the set it usually different with the tool i've been using too 17:39:57 juga: just fyi the flashflow merge is lower priority on your side for now; let tor-core look at it first. not sure if you saw that 17:40:05 ok 17:40:17 making sbws work to replace torflow, and then improving it. both those are higher priority rn 17:40:28 yup 17:42:11 ok 17:42:16 nothing else? 17:42:56 not from me 17:43:02 one arti thing: 17:43:18 if anybody wants to look at code that I am not going to change for a while,, review it, suggest improvements,, just ask. 17:43:38 how do we know what code wont change in a while? :o 17:43:44 ask me :) 17:43:46 ah! 17:43:56 sounds good. i had my first build and look at the code friday 17:43:58 very exciting 17:44:12 cool, i will end the meeting then 17:44:13 thanks all! 17:44:14 o/ 17:44:16 #endmeeting