16:58:32 #startmeeting network team meeting, 22nd February 2021 16:58:32 Meeting started Mon Feb 22 16:58:32 2021 UTC. The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:58:32 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:58:32 ok ok ok 16:58:43 hi 16:58:44 we have our pad at https://pad.riseup.net/p/tor-netteam-2021.1-keep 16:58:47 hello everybody 16:59:28 how are people doing with their roadmaps? 16:59:35 https://gitlab.torproject.org/groups/tpo/core/-/boards 16:59:45 hihi! 16:59:49 hello hello! 17:00:07 I have to say that https://gitlab.torproject.org/groups/tpo/core/-/boards is a board I basically NEVER look at :) 17:00:10 mikeperry: o/ should i close #40157 or put it on the icebox or something like that? 17:00:17 I do look at my dgoulet board though :) 17:00:19 mikeperry: now that the first (and maybe last) round of CBT measurements has been done? 17:00:28 dgoulet: which one do you look at? 17:00:36 right, but i am not gonna link at every person's board here :-P 17:00:39 dgoulet: yes same here. i've been assuming it's being looked by the "management" and that's why i maintain it. 17:00:48 i open that one up and does a query for author = ahf 17:00:48 I look at https://gitlab.torproject.org/groups/tpo/core/-/boards?scope=all&utf8=%E2%9C%93&state=opened&assignee_username=nickm 17:00:59 err, ikke author, assignee, yeah 17:01:01 asn: yeah hrm.. we need to check tthe onionperf stuff that ana does changes guards properly, but probably best to break that one off of this analysis ticket since that experiment's analysis is done 17:01:21 https://gitlab.torproject.org/groups/tpo/core/-/boards?scope=all&utf8=%E2%9C%93&state=opened&assignee_username=dgoulet 17:01:23 that is mine ^ 17:01:24 asn: as long as you use your own with the right labels this one should reflect reality 17:01:46 right, that is the same just with some added constraints to the search :-P 17:01:48 asn: so I think we close it and make sure we note to check the proper onionperf behavior on those tickets 17:01:53 sounds like we are all looking at the same thing lol 17:02:12 ok! sounds like people are good 17:02:25 i am not gonna ask how review assignment is going, but is the bot doing an OK job? 17:02:35 if yes, then i will remove this point on the agenda list 17:02:45 it is yes 17:02:51 yes, that bot is _great_ 17:03:00 if someone is not happy with the ticket that the bot has given them, please let me know and i will switch things up. 17:03:04 yaml goes in, random assignment goes out 17:03:31 asn: cool! 17:03:50 I have a private ticket whose patches need review. The private ticket is tor#40304 ; please follow the links from there and don't discuss it too much in public. :) 17:04:00 It is for TROVE-2021-001, a DoS issue. 17:04:23 ok! 17:04:27 sounds like a todo for all of us 17:04:33 * asn added todo 17:04:38 man i love these private gitlab tickets 17:05:16 the permission system in gitlab is driving me a bit crazy i think, i am so tired of it, but i guess that was the price of integrating everything lol 17:05:57 ok 17:05:58 yes... im afraid of missin gup all the time 17:06:17 are we OK with 0.4.5 status page? i don't think we have moved things over to 0.4.6 yet? maybe that is a task for the thursday meeting 17:06:49 I think dgoulet moved a lot of stuff out of 045 17:07:07 I moved few tickets from 045-stable to 045-post-stable 17:07:14 045-stable should NOT have anything now :) 17:07:16 yeah, still in 0.4.5 but the other 0.4.5 17:07:43 it should actually be a closed milestone (if we have not done it yet) 17:07:51 +1 17:08:21 yeah I can close it, no Open issues in that milestone 17:08:23 045-stable, yeah? 17:08:25 good idea 17:08:35 voila 17:08:49 do we want to revise this agenda item to be about 0.4.6 from now on? 17:09:04 we always have a bit of a weird overlap windows this 17:09:06 with this* 17:09:08 let's have a "look at both" step. 17:09:12 ack 17:09:48 I also changed the 045-post-stable milestone due date to the 045 EOL date in 2023 lol 17:10:00 so at least our milestone align with lifetime 17:10:40 i am gonna remove the list of individual person links from the pad 17:10:46 i am not maintaining those anyways and nobody seems to have complained 17:11:22 ok 17:11:24 https://gitlab.torproject.org/dashboard/issues?scope=all&utf8=%E2%9C%93&state=opened&milestone_title=Tor%3A%200.4.5.x-post-stable and https://gitlab.torproject.org/dashboard/issues?scope=all&utf8=%E2%9C%93&state=opened&milestone_title=Tor%3A%200.4.6.x-freeze 17:11:34 anything we need to talk about there? 17:11:53 * asn looks 17:12:26 there are a couple of 045 bugs I fixed after the stable that would benefit from releasing a new stable let say "not in a month time" tbh 17:12:42 there are already duplicates on Gitlab and tor-relays@ about those 17:13:31 yeah 17:13:51 i guess we also want the dirauth ticket from roger that you looked at too out in a 0.4.5? 17:14:00 yup 17:14:12 there are a good series of things we need in next stable sooner than later imo 17:14:30 I'm fine doing new stables in ~2 weeks if you think it wise? 17:14:40 very much so 17:14:52 ok 17:15:11 looking at the 045 post-stable, I took tor#40296 on me. if someone has another ticket that they want to offload, feel free to drop it on me. 17:15:12 are _all_ items there must-do-in-next-2-weeks? 17:15:24 If not maybe we should move them to 0.4.6 and mark as backport? 17:15:32 (move the not-must ones) 17:15:40 no I doubt it 17:15:57 this is maybe one thing where a 0.4.5.7 milestone would be beneficial :) 17:17:52 isn't the set of tickets for this tiny enough for us to not need that? 17:18:06 well it might grow... 17:18:19 this is all about being able to identify them and putting a due date on them 17:18:43 hm, let's create a 0.4.6.7 milestone then 17:18:44 I no care how we do it... just less temporary label is better imo, but no strong opinion 17:19:09 at least a ticket attached to a milestone, it is very easy to know when it got in 17:19:34 let's go for that 17:19:42 do you want to create it? sounds like you have the overview right now on these issues 17:19:57 I do know several so I can get on that 17:20:10 and will put due date in 2 weeks so March 8th 17:20:15 awesome \o/ 17:20:16 thank you 17:21:14 ok! this means we are done with items for this meeting. i see no discussion items. remember to add anything if you want to discuss something on thursday 17:21:25 and remember to sign up for the arti hackathon if you haven't already said the 4th is ok for you 8) 17:21:30 mikeperry: you wanna run the s61 part? 17:22:23 ahf: sure 17:22:44 I am a little slow today, but updates are going in the pad 17:23:12 main things to highlight was promising progress in discussions with NRL re floodflow. rob is getting resources to re-run that speedtest experiment 17:23:29 from which ideas came out to update https://gitlab.torproject.org/tpo/core/tor/-/issues/40222 17:23:37 nice 17:24:08 once he gets machines, I will bring in GeKo and ana for how to plan and schedule such experiments 17:24:46 and monitor for issues (particularly https://gitlab.torproject.org/tpo/metrics/analysis/-/issues/33076) 17:24:56 acute ^ 17:25:19 gaba: thanks 17:25:21 sounds good 17:26:01 I am also emailing mptcp researchers about sheduling algs. got one of the authors of BLEST involved. she is helping clarify things and make sure we specify correctly for tor 17:26:16 updates to the proposal based on their input are still going into my remote 17:26:30 https://gitlab.torproject.org/mikeperry/torspec/-/blob/ticket40202_01/proposals/329-traffic-splitting.txt 17:26:56 juga is also in discussions with some folks about auditing sbws/stem 17:26:59 very nice 17:27:12 juga: do you have more updates there? 17:27:25 i think they are not at the meeting today 17:27:31 ah ok 17:27:37 but i heard it went well and there are some follow-ups they are working on 17:29:04 ok 17:29:18 I think those are the major things to highlight. any questions/discussion? 17:29:41 <-- has none 17:30:04 * ahf good 17:31:00 ok! does this mean that the last network team monday meeting of february 2021 is over? 17:31:08 asn/dgoulet: did my additions to https://bugs.torproject.org/tpo/core/tor/40222 make sense? 17:31:50 all ok w m! 17:31:58 * asn reads 17:32:12 mikeperry: i havent had time to work on prop#328 today. i will look into it tomorrow 17:32:20 ok 17:32:32 mikeperry: sounds legit, not sure what "excessive controlport messages" would be though 17:32:44 * asn read it now, and it seems reasonable 17:33:13 yeah, idk how long the queue grows normally, vs when nyx or tor is not able to keep up 17:33:28 i see 17:33:37 not sure how to extract this queue details right now from little-t-tor 17:33:40 but i can look into it 17:33:50 it is a good guess for the experriment tho. control port load is one thing shadow does not simulate, and shadow could not reproduce the issue 17:34:00 which makes that and DNS good guesses 17:34:11 since shadow does not do DNS either 17:34:21 and we know DNS has historically had overload problems 17:35:04 GeKo: you may be familiar with that from arthur's work on it. so if you have more ideas, please feel free to add 17:35:25 arthuredelstein: ^ 17:35:49 I think that is all for now 17:36:49 * dgoulet is good 17:37:21 mikeperry: we've chatted a bit about this before, but LMK if we should talk more about whether/how we could model DNS performance/overload in shadow 17:38:23 jnewsome: I think you may need to set up some kind of mock DNS server in shadow 2.0 to really ensure we have the full scope of DNS covered.. there are too many unknowns still about what the problem is/could be in the future 17:38:57 so I think actual DNS answers from a real DNS-speaking server may be required.. idk 17:39:42 unbound have a very nice api interface too where you can flush cache and control prefetching and all that jazz 17:39:43 at this point, the hope is to find the problem in live, when we reproduce 17:39:49 i have some experience with that if we need to do something there 17:39:52 and then we can make sure that shadow 2.0 can also reprtoduce it 17:40:17 that's feasible, but not clear even that would necessarily be enough. do you need to model particular DNS servers getting overloaded, and is it cpu-overload, ... etc. if we really want to to try modeling this in shadow we should talk more 17:40:25 probably too detailed for this meeting though 17:40:55 yeah. we do not know enough. hopefully if we see it again, we will learn more, and then can discuss shadow changes to make sure it could see such issues in the future 17:42:58 ok. otherwise, good here :) 17:43:39 * ahf gonna tell the bot to stop logging 17:43:41 #stopmeeting 17:43:46 #endmeeting