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