16:59:15 <nickm> #startmeeting network team meeting, 22 mar 2021
16:59:15 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:59:21 <dgoulet> o/
16:59:30 <mikeperry> o/
16:59:37 <GeKo> hi
16:59:47 <nickm> https://pad.riseup.net/p/tor-netteam-2021.1-keep is the pad
17:01:13 <nickm> 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 <asn> yep it's good
17:03:14 <nickm> 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 <dgoulet> I'm good
17:03:35 <nickm> ack
17:04:03 <nickm> next is our milestone URLs
17:04:32 <nickm> hm.  I see 12 open items in 0.4.5.x-post-stable, some with no assignee
17:04:38 <nickm> 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 <nickm> I'll assign the seccompp one to me
17:05:06 * asn looking
17:05:22 <asn> hmm
17:05:32 <asn> should i take one from ahf to offload him?
17:05:44 <asn> or i can look at the netbsd or sunos stuff...
17:05:50 <nickm> asn: I bet he wouldn't mind, if you see one that makes sense for you to do...
17:06:14 <asn> i guess i will take the sunos/netbsd stuff first and see if i can tackle them at all
17:06:19 <asn> if i fail, i will take from ahf's plate
17:06:20 <nickm> ok, awesome
17:06:33 <nickm> 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 <asn> ack
17:07:06 <nickm> Next milestone for us to look at is 0.4.6.x-freeze
17:07:24 <nickm> technically speaking this milestone should probably stopp existing.
17:07:45 <nickm> rather, it should get closed, since 046x is frozen
17:07:54 <dgoulet> yup
17:08:57 <nickm> 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 <nickm> I'll do the unassigned ones there
17:10:02 * asn looking
17:12:41 <asn> i'm removing tor#40209 as well. seems like a feature that never made iti n.
17:13:04 <dgoulet> I've moved some of them out of 046 freeze
17:13:09 <nickm> ok, only 3 left in 046-freeze
17:13:14 <asn> same for tor#33617
17:13:25 <asn> ok two remaining
17:13:33 <nickm> I'll do ahf's
17:14:13 <nickm> there!
17:15:02 <nickm> ok, now the important 046 milestone is 046-stable
17:15:22 <nickm> 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 <dgoulet> there one left
17:16:46 <asn> i took it
17:16:56 <nickm> awesome!
17:17:12 <nickm> remember to call them Backlog or whatever so we don't lose them on the kanban
17:18:20 <nickm> ok, time for reminders and discussion items
17:18:23 <nickm> I think
17:18:35 <nickm> next week is DST in some places
17:18:44 <nickm> so that will confuse everybody who wasn't already confused
17:18:53 <nickm> next week is also hack week, so no regular meeting
17:19:13 <nickm> and I don't see any new discussion topics...
17:19:26 <nickm> doees anybody have any topics?
17:20:10 <asn> not me
17:20:21 * dgoulet is good
17:20:28 <nickm> nice!
17:20:33 <nickm> so we move on to s61 updates?
17:21:25 <asn> let's
17:21:25 <mikeperry> updates are in the pad.
17:21:32 <mikeperry> arg lagging
17:21:59 <nickm> anything you want to highlight?  If not I think we can call the meeting done
17:22:24 <mikeperry> main highlight is I put XXX's and then some updates from the netteam review of conflux
17:23:27 <mikeperry> I am also still talking with TCP researchers re when we should stop reading on edge connections for BLEST
17:24:00 <mikeperry> commits are in my gitlab remote
17:24:44 <nickm> nice nice
17:25:04 <nickm> okay.  So if that's all, then let's call the meeting done and move back to #tor-dev for now
17:25:07 <nickm> thanks everybody!
17:25:08 <GeKo> 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 <mikeperry> 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 <GeKo> mike was there which was good
17:25:48 <GeKo> but i think it would have been beneifical if juga and i would have been there, too
17:26:05 <GeKo> for the sbws and network-health monitoring part
17:26:31 <GeKo> *beneficial
17:26:51 <mikeperry> yeah, I think the effect on sbws will be non-trivial
17:27:14 <GeKo> (well, that decision is done but there will be next decisions which are similarily affecting more than the network-team)
17:27:20 <mikeperry> 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 <nickm> Rust has a rule that says "no private rationales" for design decisions
17:28:34 <nickm> Maybe we should adopt something similar
17:28:58 * nickm tries to find a link
17:29:20 <asn> 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 <asn> in the mailing list, i don't see any issues being raised about the information being in extra-info  descriptors
17:29:52 <nickm> 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 <mikeperry> 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 <nickm> ah, it's "no new rationale" https://aturon.github.io/tech/2018/05/25/listening-part-1/
17:31:14 <nickm> mikeperry: the way I remember it, we did discuss it at the meeting, and followed up there.
17:31:59 <nickm> 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 <nickm> Possibly it would have been better to defer, based on the other arguments on the ticket
17:32:22 <nickm> (that is, that nobody knows how to actually use this data)
17:32:36 <GeKo> asn: i agree, that we mostly talked about putting that into extra-info descs
17:33:01 <nickm> wait hang on.
17:33:01 <GeKo> and i don't want to say that was at the end the wrong decision
17:33:03 <mikeperry> 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 <asn> ehm i lost the proposal ticket where the extrainfo concerns are raised, can someone link it again   plz
17:35:00 <mikeperry> https://gitlab.torproject.org/tpo/core/tor/-/issues/40158#note_2718220
17:35:09 <mikeperry> https://gitlab.torproject.org/tpo/core/tor/-/issues/40158#note_2718248
17:35:34 <GeKo> 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 <nickm> 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 <asn> i agree
17:36:14 <GeKo> nickm: that's fine, if all parties affected be part of that decision
17:36:20 <asn> i agree we should have had this conversation with you people as well
17:36:26 <asn> i'm not sure why this conversation happened so late in the process
17:36:53 <GeKo> asn: that's cool. those things happen
17:37:04 <GeKo> something to keep in mind for next time :)
17:37:06 <asn> 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 <dgoulet> 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 <dgoulet> 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 <asn> perhaps network health team should attend network team meetings?
17:38:37 <asn> it was not even that we arranged for a prop328 discussion to happen IIRC
17:38:40 <GeKo> we do right now :)
17:38:41 <asn> it just occured naturally
17:38:45 <nickm> 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 <dgoulet> true
17:39:50 <asn> i think geko is more worried about the decision process -- and not the actual position of the lines
17:39:53 <asn> iiuc
17:40:17 <mikeperry> well, it is still not clear how much analysis we need to do on the sbws side, still
17:40:38 <nickm> mikeperry: respectfully, nothing has changed since thursday
17:40:52 <nickm> or has it?
17:41:43 <GeKo> 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 <nickm> GeKo: let me know what you think about that document I liked and wither it would help
17:42:31 <nickm> 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 <GeKo> will do after i've read it after the meeting
17:42:51 <nickm> when there is a requested-for-X feature coming up right before deadline
17:42:57 <nickm> thanks!
17:43:19 <mikeperry> my takeaway from thursdy was that we needed to do analysis to show the cost of sbws using extra-info
17:43:45 <mikeperry> in terms of dirauth bandwidth, memory, CPU, eng effort, etc on sbws
17:44:06 <GeKo> nickm: waiting another 4 months is not always the right alternative
17:44:49 <GeKo> 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 <nickm> 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 <nickm> 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 <nickm> *up on
17:46:47 <nickm> I can totally try to improve communications here in the future, and I do like "no new rationales" as a princilppe
17:46:52 <nickm> *sp
17:47:49 <nickm> 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 <nickm> 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 <GeKo> we should plan to make those choices earlier then next time so that the stakeholders can participate
17:49:14 <nickm> But that's okay
17:49:22 <GeKo> yeah, i am sorry for that
17:49:31 <nickm> Sometimes we need to bend process in the interests of good decisions being made...
17:49:39 <GeKo> but i hope we can learn something for the future here
17:50:05 <nickm> I hope so too.
17:50:10 <nickm> Do we have anything else for this meeting.
17:50:12 <nickm> ?
17:51:03 <asn> not from me
17:51:10 <nickm> okay.  Thanks for you time everybody!
17:51:16 <asn> cheers all
17:51:20 <nickm> peace everybody!
17:51:24 <nickm> #endmeeting