16:59:15 #startmeeting network team meeting, 22 mar 2021 16:59:15 Meeting started Mon Mar 22 16:59:15 2021 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:59:15 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:59:21 o/ 16:59:30 o/ 16:59:37 hi 16:59:47 https://pad.riseup.net/p/tor-netteam-2021.1-keep is the pad 17:01:13 we have no ahf today -- so let's start with the kanban -- everybody on track for their work there? 17:01:43 * asn looking 17:03:13 yep it's good 17:03:14 I think I'm doing okay though some of the items there are going to bounce in and out of "doing" for a while 17:03:22 I'm good 17:03:35 ack 17:04:03 next is our milestone URLs 17:04:32 hm. I see 12 open items in 0.4.5.x-post-stable, some with no assignee 17:04:38 https://gitlab.torproject.org/dashboard/issues?scope=all&utf8=%E2%9C%93&state=opened&milestone_title=Tor%3A%200.4.5.x-post-stable 17:05:00 I'll assign the seccompp one to me 17:05:06 * asn looking 17:05:22 hmm 17:05:32 should i take one from ahf to offload him? 17:05:44 or i can look at the netbsd or sunos stuff... 17:05:50 asn: I bet he wouldn't mind, if you see one that makes sense for you to do... 17:06:14 i guess i will take the sunos/netbsd stuff first and see if i can tackle them at all 17:06:19 if i fail, i will take from ahf's plate 17:06:20 ok, awesome 17:06:33 the netbsd/sunos ones look like glob-related failures. That code is new in 045; let me know if you want to try to figure it out together :) 17:06:41 ack 17:07:06 Next milestone for us to look at is 0.4.6.x-freeze 17:07:24 technically speaking this milestone should probably stopp existing. 17:07:45 rather, it should get closed, since 046x is frozen 17:07:54 yup 17:08:57 Let's take a minute to look over all the tickets in 046x-freeze that are assigned to us, and either move them to 046x-stable, or remove the milestone 17:09:59 I'll do the unassigned ones there 17:10:02 * asn looking 17:12:41 i'm removing tor#40209 as well. seems like a feature that never made iti n. 17:13:04 I've moved some of them out of 046 freeze 17:13:09 ok, only 3 left in 046-freeze 17:13:14 same for tor#33617 17:13:25 ok two remaining 17:13:33 I'll do ahf's 17:14:13 there! 17:15:02 ok, now the important 046 milestone is 046-stable 17:15:22 we do have a few unassigned tickets there at https://gitlab.torproject.org/dashboard/issues?scope=all&utf8=%E2%9C%93&state=opened&milestone_title=Tor%3A%200.4.6.x-stable 17:15:38 * nickm edits the pad 17:16:01 * dgoulet takes some 17:16:41 there one left 17:16:46 i took it 17:16:56 awesome! 17:17:12 remember to call them Backlog or whatever so we don't lose them on the kanban 17:18:20 ok, time for reminders and discussion items 17:18:23 I think 17:18:35 next week is DST in some places 17:18:44 so that will confuse everybody who wasn't already confused 17:18:53 next week is also hack week, so no regular meeting 17:19:13 and I don't see any new discussion topics... 17:19:26 doees anybody have any topics? 17:20:10 not me 17:20:21 * dgoulet is good 17:20:28 nice! 17:20:33 so we move on to s61 updates? 17:21:25 let's 17:21:25 updates are in the pad. 17:21:32 arg lagging 17:21:59 anything you want to highlight? If not I think we can call the meeting done 17:22:24 main highlight is I put XXX's and then some updates from the netteam review of conflux 17:23:27 I am also still talking with TCP researchers re when we should stop reading on edge connections for BLEST 17:24:00 commits are in my gitlab remote 17:24:44 nice nice 17:25:04 okay. So if that's all, then let's call the meeting done and move back to #tor-dev for now 17:25:07 thanks everybody! 17:25:08 it would be nice if all the stakeholders could be at the meeting next time when discussing the decision to put the overload indicators into the extrainfo descriptors 17:25:19 I am also unsure that the gap sequence number thing actually prevents the need to switch legs in the event of 2^16-1, but it is possible I do not fully understand it still 17:25:23 mike was there which was good 17:25:48 but i think it would have been beneifical if juga and i would have been there, too 17:26:05 for the sbws and network-health monitoring part 17:26:31 *beneficial 17:26:51 yeah, I think the effect on sbws will be non-trivial 17:27:14 (well, that decision is done but there will be next decisions which are similarily affecting more than the network-team) 17:27:20 we're gathering stuff to look at in test scripts in https://gitlab.torproject.org/tpo/network-health/helper-scripts/-/issues/8 17:28:23 Rust has a rule that says "no private rationales" for design decisions 17:28:34 Maybe we should adopt something similar 17:28:58 * nickm tries to find a link 17:29:20 the way i see it, is that prop#328 was always about extrainfo descriptors. so it's not like a meeting changed that. 17:29:48 in the mailing list, i don't see any issues being raised about the information being in extra-info descriptors 17:29:52 As we read the ticket, the best arguments were in favor of "merge as is" or "don't merge at all for now" 17:30:35 there was discussion on the proposal ticket about this, but it did not get followed up on (re extrainfo ascpect of the proposal) 17:30:51 ah, it's "no new rationale" https://aturon.github.io/tech/2018/05/25/listening-part-1/ 17:31:14 mikeperry: the way I remember it, we did discuss it at the meeting, and followed up there. 17:31:59 GeKo: feature freeze for 046 was scheduled on monday. So we did need to decide pretty promptly. Would it have been better to merge this as-is, or defer it to 047? 17:32:12 Possibly it would have been better to defer, based on the other arguments on the ticket 17:32:22 (that is, that nobody knows how to actually use this data) 17:32:36 asn: i agree, that we mostly talked about putting that into extra-info descs 17:33:01 wait hang on. 17:33:01 and i don't want to say that was at the end the wrong decision 17:33:03 I was fine with the decision to merge so we can get early testing. but it is still not clear how much analysis is neccessary to decide to switch it to descs later. the ticket I linked mentions seversl things that are factors 17:34:05 ehm i lost the proposal ticket where the extrainfo concerns are raised, can someone link it again plz 17:35:00 https://gitlab.torproject.org/tpo/core/tor/-/issues/40158#note_2718220 17:35:09 https://gitlab.torproject.org/tpo/core/tor/-/issues/40158#note_2718248 17:35:34 asn: it just seems to me, in particular based on the discussion that juga, mike, and i had once mike came back from the meeting it might have been beneficial for juga and me being part of those discussions in the first place 17:36:01 GeKo: to be clear, would you have rather deferred the merge until we could get your feedback, if doing so meant deferring to 047? 17:36:02 i agree 17:36:14 nickm: that's fine, if all parties affected be part of that decision 17:36:20 i agree we should have had this conversation with you people as well 17:36:26 i'm not sure why this conversation happened so late in the process 17:36:53 asn: that's cool. those things happen 17:37:04 something to keep in mind for next time :) 17:37:06 i've been developing prop328 the past month, and the question about extrainfo vs general descruiptors, was not raised to me, apart from that very last moment right before the freeze 17:37:12 it is difficult for us to assess when to bring someone or not in a proposal discussion when we are at implementation stage and when that proposal has been sitting on tor-dev@ since November 17:37:42 thus I do understand the problems that are here and that is mainly why we decided that it was OK for us to put it in the server desc later on if need be in the 046 series 17:38:29 perhaps network health team should attend network team meetings? 17:38:37 it was not even that we arranged for a prop328 discussion to happen IIRC 17:38:40 we do right now :) 17:38:41 it just occured naturally 17:38:45 If we really need to move this, moving it will take less energy than the discussions we have had on it so far plus the discussions about the discussions. 17:39:44 true 17:39:50 i think geko is more worried about the decision process -- and not the actual position of the lines 17:39:53 iiuc 17:40:17 well, it is still not clear how much analysis we need to do on the sbws side, still 17:40:38 mikeperry: respectfully, nothing has changed since thursday 17:40:52 or has it? 17:41:43 asn: yes, the decision process was my main concern here, about the other part i am not sure yet but i suspect we can cope with that 17:41:48 GeKo: let me know what you think about that document I liked and wither it would help 17:42:31 GeKo: I'd also like your thoughts about, on features like this, whether "wait another 4 months for the feature that X wants" is always the right alternative over "implement it now in a way we believe will work for X" 17:42:49 will do after i've read it after the meeting 17:42:51 when there is a requested-for-X feature coming up right before deadline 17:42:57 thanks! 17:43:19 my takeaway from thursdy was that we needed to do analysis to show the cost of sbws using extra-info 17:43:45 in terms of dirauth bandwidth, memory, CPU, eng effort, etc on sbws 17:44:06 nickm: waiting another 4 months is not always the right alternative 17:44:49 i don't even think it would have been or be the right alternative for the feature at hand if that is what you were hinting at 17:45:42 Okay. So we acted on Thursday on the belief that it would be better to merge this as-is now than to miss the feature freeze. 17:46:18 Please understand that this is not the only ticket that we had to talk about coming u pon the freeze, and that nearly all of of them had stakeholders outside the network team 17:46:22 *up on 17:46:47 I can totally try to improve communications here in the future, and I do like "no new rationales" as a princilppe 17:46:52 *sp 17:47:49 But in the end we do need to make some choices without circling back with all the stakeholders, on the theory that the stakeholders will be better off _not_ waiting till the next release cycle 17:48:49 We have now spent more time talking about this than we have about all other issues at today's meeting put together. 17:49:14 we should plan to make those choices earlier then next time so that the stakeholders can participate 17:49:14 But that's okay 17:49:22 yeah, i am sorry for that 17:49:31 Sometimes we need to bend process in the interests of good decisions being made... 17:49:39 but i hope we can learn something for the future here 17:50:05 I hope so too. 17:50:10 Do we have anything else for this meeting. 17:50:12 ? 17:51:03 not from me 17:51:10 okay. Thanks for you time everybody! 17:51:16 cheers all 17:51:20 peace everybody! 17:51:24 #endmeeting