22:59:02 <ahf> #startmeeting s55 meeting
22:59:02 <MeetBot> Meeting started Wed Apr 29 22:59:02 2020 UTC.  The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:59:02 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
22:59:30 <nickm> hi!
22:59:41 <teor> hi
22:59:52 <nickm> evening/moring!
23:00:01 <nickm> *morning
23:00:14 <ahf> where do we want to start? a status on where you are teor?
23:01:12 <gaba> hi
23:01:37 <teor> Yeah, I can also go through the status email I sent a few days ago. But let's not talk about outreachy or sponsor negotiations in a public channel.
23:02:00 <teor> So I had a few major tasks over the last week:
23:02:15 <teor> * Tell ahf, nickm, and dgoulet which tickets they can start on
23:02:17 <ahf> agreed @ outreachy/sponsor things
23:02:25 <teor> * Make a list of essential tickets
23:02:39 <teor> * Update the torspec proposals
23:03:10 <teor> (Sorry, just checking notes)
23:03:43 <teor> * Work out what I can do in my remaining time
23:03:54 <ahf> yep
23:03:57 <teor> * Analyse some specific technical issues
23:04:01 <teor> (I'm done)
23:04:41 <teor> So I sent an email out to your all covering those things.
23:04:51 <nickm> yup, got it.  It looked reasonable.
23:05:13 <ahf> yep. we went over bits of it with david too yesterday
23:05:14 <teor> I think the proposal updates will be ongoing. But most changes are in the proposals now.
23:05:47 <teor> I have finished the relay side of IPv6 extends (#33817 and parents)
23:06:13 <ahf> sweet
23:06:15 <nickm> sounds good.  I started looking at your changes to 33817 based on my review earlier today, and so far they look fine.  I think that one will probably be good to merge
23:06:17 <teor> And next I want to start sending IPv6 extends from clients (#33222), so we can do integration testing on that code.
23:07:01 <teor> Just trying to find my next tasks...
23:07:12 <nickm> ok. before we actually merge the client part do we need to add the protover support?
23:08:16 <teor> nickm: I think it's safe to send IPv6 extend requests to relays that don't support them. But I'll find out in the next day or two.
23:08:21 <nickm> ok
23:08:28 <nickm> this is from relays, for self-test purposes, yeah?
23:08:32 <teor> They should just ignore the IPv6, and use IPv4.
23:08:47 <teor> Yes, only relays will send IPv6 for now.
23:08:51 <nickm> ack
23:09:43 <teor> And I think only for self-test circuits. We could send IPv6 for all relay circuits, but we can do that later if we want to.
23:10:05 <nickm> so in summary from what dgoulet and I talked about yesterday: we're going to try to ramp up with dgoulet on O1.2 starting with code movement and refactoring for the existing address detection logic
23:10:30 <nickm> and I'm going to try to ramp up on O1.1 with code review on your stuff and with addr/real_addr fixing and other test/refactoring you've requested
23:10:45 <teor> Great! I haven't touched the 1.1 address detection code, so there won't be any merge conflicts.
23:10:49 <nickm> (I'm hesitating to do more right now on O1.1 because I think it could get in your way)
23:11:04 <nickm> "1.1" address detection code?
23:11:17 <teor> Oops, sorry, 1.2
23:11:29 <nickm> ah ok
23:11:30 <teor> Lots of details in my head right now :-)
23:11:45 <nickm> no worries; just wanted to make sure you didn't know about an extra address detection thing I wasn't aware of :)
23:11:49 <teor> I think we'll be fine both working on O1.1. It will be easier if we keep a short review-merge cycle.
23:12:25 <ahf> teor: you don't see any conflicts with people in parallel working on both O2.1 and O1.1 right?
23:12:31 <nickm> 1.2
23:12:33 <nickm> not 2.1
23:12:48 <teor> They're completely different parts of the code, so I don't think there will be many impacts.
23:12:52 <ahf> err, yes
23:12:53 <nickm> for #33817, I need to take a closer look at #cd7e2fc; the other changes look like they should address my comments
23:13:07 <ahf> teor: great
23:13:30 <teor> There might be a bit of crossover with the real_addr refactor, and when we replace the current IPv6 address functions with the new ones.
23:13:35 <teor> But those should be simple mass replacements.
23:14:17 <teor> Do you have any questions for me right now about O1.1 or O1.2 ?
23:14:45 <ahf> not so far, nope
23:14:50 <teor> We can always set up an IRC meeting to go over code or technical questions. I'm usually on email and signal every day. (Sometimes I lose my IRC backlog.)
23:14:55 <nickm> for O1.1 -- is it really this simple?  It seems like this is going to be comparatively straightforward from this point.
23:15:46 <teor> So there's a bit of tricky coding at the end of #33222, to make these checks happen:
23:15:56 <teor> 1. Check for create cells on inbound ORPort connections
23:16:05 <teor> 2. Check for created cells from testing circuits on outbound OR connections
23:16:36 <teor> And some work to do extra diagnostics, and preserve the legacy checks as a diagnostic
23:16:52 <nickm> do you think that 1/2 are a reasonable fit for our pubsub logic?
23:17:20 <teor> I think so, as long as it's performant
23:17:46 <nickm> it should be.  we wouldn't want to use it for every byte or every relay cell, but for every create or created it's cool
23:18:51 <teor> Ok, that seems fine then.
23:19:11 <nickm> other question -- do you happen to know _why_ we overwrite conn.addr?   Or did you ask me that?
23:19:19 <nickm> (and if you did ask me, did I know at the time?)
23:19:44 <teor> There is a nice comment from arma explaining that. It's for logging.
23:20:44 <teor> https://github.com/torproject/tor/blob/7517e1b5d31aada1f594c2594737a231d9d8e116/src/core/or/channeltls.c#L738
23:20:57 <teor> Oops sorry not that one.
23:21:48 <nickm> found it
23:21:55 <nickm> ok, so arma thinks it's just for logging
23:22:05 <nickm> if that's the case this isn't too bad to fix
23:22:14 <nickm> the hard part is auditing to see that nothing relies on getting a match
23:22:18 <teor> It's not though, it's also for reverse proxied addresses
23:22:18 <ahf> hm, interesting
23:22:20 <teor> https://github.com/torproject/tor/blob/7517e1b5d31aada1f594c2594737a231d9d8e116/src/core/or/channeltls.c#L1339
23:22:47 <teor> So yes, tricky
23:23:14 <nickm> yowch
23:23:38 <nickm> ok, well that will probably eat my coding time for a couple of days at least. :)
23:23:59 <teor> Yeah, sorry about that. But it's a source of endless confusion every time I try to use it.
23:24:17 <nickm> no worries; I dislike it too
23:24:50 <nickm> oh, one last question. for prop#312, did you have an abstraction in mind for "unifying" the various ways to detect an address?
23:25:06 <nickm> if not I'll try to come up with one with dgoulet after he's done some refactoring
23:25:53 <nickm> other than that I'm out of topics for now
23:25:55 <teor> I think a priority list is a good abstraction
23:26:58 <teor> Where each item contains a source and an address. And the sources are sorted in priority order.
23:27:46 <teor> It's also possible that we just want one address per family and source. In that case, a map from source would be better. And we could have one map for IPv4 and IPv6.
23:27:49 <nickm> hm. and where the code that sets each item gets launched as needed?  or sets the item "in the background" as it finds it?
23:27:59 <nickm> i think that makes sense too
23:28:21 <teor> There is a table in the proposal that lists how each source is currently discovered
23:28:32 <nickm> yes
23:28:53 <nickm> the effect of that table was to convince me that there is not much consistency right now
23:29:05 <teor> We need to be able to record discovered addresses that are triggered by other events. pubsub would be good here.
23:29:40 <nickm> hm. sounds plausible.
23:29:47 <teor> I think most other addresses can be an async query, or a regularly scheduled task.
23:30:02 <nickm> that seems about right
23:30:39 <teor> If we want to expire addresses, we should also have a last discovered timestamp. But I don't think that's necessary in the first implementation.
23:30:50 <nickm> agreed
23:31:09 <nickm> just treating this stuff uniformly would make it easier to add a timestamp if/when we think it's necessary
23:31:32 <teor> Yes, I think a well-defined pubsub interface would really help you here.
23:31:48 <nickm> i'll give it a try
23:32:02 <teor> It would also make it easy to switch in NETINFO for directory headers. If we decide to want to do that.
23:32:07 <nickm> dgoulet: I'm marking this for you so you can have a look at it :)
23:32:36 <ahf> he is not in here, but i'll prod him with the log tomorrow
23:32:40 <nickm> yup
23:32:44 <nickm> ok, that's it for me for today.  Anything else for now?
23:32:53 <nickm> I'll continue to be online at my usual times
23:32:58 <ahf> should we continue with these statuses each wednesday at 23 utc?
23:33:07 <nickm> seems like a good idea for now
23:33:11 <nickm> if it is okay with teor
23:33:15 <ahf> i agree if it's cool with teor
23:33:17 <teor> Um yeah hang on their are other topics :-)
23:33:21 <ahf> yep
23:33:24 <teor> I can do this time regularly
23:33:27 <gaba> one question from me. I'm wondering why you are suggesting to remove #33264
23:33:33 <gaba> and the other tickets in item .3
23:33:56 <teor> gaba: Can we not talk about sponsor negotiations in a public channel :-)
23:34:07 <gaba> i'm not talking about sponsor negotiations
23:34:09 <teor> Or do you think it's ok?
23:34:26 <gaba> i'm talking about if those tickets are not necessary in this project or not
23:35:27 <gaba> You could reply in the mail if you do not feel comfortable talking about it here
23:35:36 <teor> As part of the proposal, we promised the sponsor we would deliver this objective:
23:35:37 <teor> O1.5 - Measure the number of connections, and consumed bandwidth, using IPv4 and IPv6
23:35:56 <gaba> yes
23:36:44 <teor> So unless we re-negotiate the scope with the sponsor, we have to keep #33264.
23:37:04 <teor> But I don't know if it will be particularly useful.
23:37:09 <gaba> yes. It seems to me that we can keep doing what we said we were going to do.
23:37:53 <teor> I don't know how we're tracking for time on this project.
23:38:15 <gaba> we can ask for an extension if we need to
23:38:15 <teor> I was asked what tasks I though were essential, so I suggested some less useful tasks that we could cut.
23:38:38 <gaba> ok
23:38:39 <teor> Let me clarify: I don't know how we're tracking for effort against budget on this project.
23:39:02 <gaba> ok. I thought maybe there was other reason that I did not know about on why to cut them
23:39:05 <gaba> thanks
23:39:33 <teor> Those tasks are not particularly useful, and I suggest that we'd be better to deliver more useful things.
23:40:11 <gaba> but nothing changed from when we created the proposal that make you say that, right?
23:41:09 <gaba> we are going to have a new roadmap session in a couple of weeks and can adjust things if needed. So far I'm writing all this suggestions down.
23:42:09 <nickm> i think it makes sense to divide tasks into more and less essential
23:42:39 <teor> I'm not sure if we're working with the same context here.
23:42:44 <teor> Since we wrote the proposal, I analysed the design tradeoffs in detail. I wrote detailed proposals describing these designs.
23:43:04 <teor> Then I recently did an analysis of the most useful tasks for the project objectives.
23:43:21 <teor> gaba, can you explain what kind of changes you're thinking of?
23:43:27 <gaba> this is why i'm asking you if there was anything else to consider (other than budget and time tracking and capacity)
23:43:30 <ahf> i think it is smart to prioritize it with the new situation we are in
23:43:52 <nickm> gaba: they are saying: utility.
23:44:07 <nickm> that's the something else to consider: how useful the item is.
23:44:36 <teor> gaba: I revised the effort estimates on those tickets, and I don't think they're worth the amount of effort they might take.
23:44:45 <teor> (Not as much as other tickets.)
23:46:08 <teor> I would like to continue this conversation privately.
23:46:37 <gaba> ok
23:46:38 <nickm> (i need to go in 15 minutes; are there more non-private topics to talk about?)
23:47:36 <teor> Yes. I really wanted to talk about testing. And I want to go through the list of other tickets I suggested that we cut.
23:47:44 <teor> But we don
23:47:53 <teor> But we don't have to cover those topics right now.
23:48:06 <ahf> i think the last part is useful, i think testing can maybe wait?
23:48:19 <ahf> the last part might be useful to david also tomorrow
23:48:31 <teor> Yeah sure. I can try to get back in that headspace.
23:48:41 * ahf nods
23:49:30 <teor> So let's talk about #33224, because that's the earliest optional task
23:49:47 <nickm> (for the tickets to possibly cut --whichever ones we don't get to tonight -- would it make sense to have that conversation on the email thread?  It seems like teor's reasoning there is pretty detailed)
23:50:13 <ahf> nickm: yeah
23:50:20 <ahf> teor: yep
23:50:21 <nickm> the amount of work for adding a network parameter is slight at most
23:50:33 <teor> Yeah, I think that's a good idea. There are lots of tickets though. So we'll have to keep the thread tight.
23:51:05 <nickm> ok.  let's maybe start a new thread based on the text under "Details of possible scope changes".
23:51:13 <teor> Or we could have the conversation on the tickets. And keep the email thread for the 3 tickets that I didn't want to discuss in public.
23:51:44 <ahf> ok
23:52:28 <teor> So for #33224, I recommend that we spend the time we need to implement it.
23:52:39 <nickm> right, it doesn't look hard
23:52:47 <teor> If we don't, and the IPv6 reachability self-tests have a bug, then 30% of relays will go down.
23:52:58 <ahf> yeah, it is a good idea to have an option folks can disable
23:53:03 <nickm> consensus parameters are easy to add
23:53:04 <ahf> and worst case we can let tor-relays@ know
23:53:23 <teor> So here's another question: we're going to change the IPv4 reachability code as well.
23:53:32 <nickm> (though tbh this would also argue for _not_ doing the "disable the whole relay if one port is down" logic)
23:53:54 * gaba needs to go. ttyl o/
23:53:55 <teor> We've had clear feedback from directory authority operators and relay operators that that's what they want.
23:54:12 <teor> They want a very clear signal that their relay is misconfigured.
23:54:47 <ahf> gaba: o/
23:55:04 <teor> This question keeps coming up every 6 months or so. Maybe we can document this design somewhere?
23:55:16 <nickm> teor: whom should I talk with to undertand that?
23:55:55 <nickm> I worry that they only want it because they experience the pain of the current behavior, not the pain of the desired behavior
23:55:57 <teor> Sebastian was the person who I last spoke to
23:56:10 <nickm> ok, I'll ask him.
23:56:22 <teor> But it's been pretty clear on the tor-relays list as well.
23:56:38 <nickm> ok
23:56:42 <teor> We last had this conversation when we modified the directory authority IPv6 reachability code.
23:56:52 <teor> It might be in the mailing list archives?
23:57:03 <nickm> i'll look. has anybody complained about the new authority behavior?
23:57:09 <nickm> if not that's a reasonably strong argument
23:57:37 <teor> No, it works really well. Relay operators get good feedback when their IPv6 ORPorts are unreachable.
23:57:46 <nickm> ok
23:57:56 <teor> The biggest complaint is the lack of relay IPv6 self-tests.
23:57:58 <nickm> (I need to go in 60 seconds. thanks for explaining this to me over and over)
23:58:23 <nickm> ahf: who should write the first round of thoughts on the email thread?
23:58:25 <ahf> teor: when both the discovery of the host's own address and the self-test is there, do we have a ticket for information the operator that they might be able to enable v6?
23:58:50 <teor> nickm: how about I put a recommendation on each of the public tickets, and then give a recommendation for each of the private tickets?
23:59:04 <teor> ahf: I'm not sure what you mean?
23:59:08 <nickm> ok
23:59:08 <ahf> nickm: i'll prod david tomorrow to look at the backlog tomorrow, and then the 3 of us can talk when we are all online tomorrow? or what do you mean here?
23:59:11 <arma2> (what's the comment by arma? now i want to look at it to see if i still agree with it. :)
23:59:37 <ahf> teor: one of the things that pops up as relay operator meetings is that relay operators aren't aware that ipv6 isn't automagically enabled on their relay
23:59:39 <nickm> (sorry, I need to get offline now.  I'll check backlog later on, but this is a hard stop for me.  Thanks everybody!)
23:59:46 <ahf> nickm: later o/
23:59:48 <teor> Thanks nickm!
00:00:01 <teor> arma2: sorry, I don't have a link
00:00:05 <ahf> arma2: it was about why we change the addr field on connections to the canonical addr i think
00:00:38 <teor> If you can link it in #33898 that would be useful
00:01:13 <teor> ahf: we'll talk about the IPv6 changes in the release notes, and also on tor-relays as part of the testing tickets
00:01:31 <teor> #33230 #33253
00:01:45 <ahf> great
00:01:54 <teor> Do you think we should do anything else?
00:02:02 <teor> There should also be man page updates :-)
00:02:20 <ahf> no, i think that is fine. i was wondering if it would make sense to notify the user in the tor log if we detect a valid non-local v6 address, but no v6 configuration for the relay
00:02:32 <ahf> s/user/relay operator/
00:03:30 <teor> So in #33246 we'll automatically open an IPv6 ORPort, and publish it if the reachability self-tests work
00:03:56 <teor> It should work just like IPv4, as far as the operator is concerned?
00:03:59 <ahf> perfect, i think that is fine
00:03:59 <ahf> yeah
00:04:01 <ahf> it is
00:04:01 <arma2> ah, here we are, the one with
00:04:04 <arma2> /* XXXX <arma> i believe the reason we did this, originally, is because
00:04:12 <teor> Yes, that one
00:05:25 <teor> https://github.com/torproject/tor/blob/7f9eaec538b7d01e0d1b130dc4cf2ec634252d46/src/core/or/connection_or.c#L920
00:06:30 <ahf> oh, old comment there
00:07:22 <teor> ahf: I think we're good for now?
00:07:36 <teor> I'll send that email, and then we can catch up as people have questions?
00:07:37 <ahf> huh, we copy it, free it, then copy it again?
00:07:49 <teor> Yeah, old code, too
00:07:55 <ahf> ook
00:08:02 <ahf> teor: i think we are good. i'll prod david tomorrow
00:08:09 <ahf> thank you, teor
00:08:17 <ahf> arma2: and nice to see you join here 8)
00:08:22 <ahf> #endmeeting