Subject: Re: [quicwg/base-drafts] Equivalence of preferred_address and NEW_CONNECTION_ID (#3560)

From: ianswett <[email-masked]>
Date: Wed, 01 Apr 2020 07:43:45 -0700

I'll note that prohibiting a 0 length CID doesn't actually ensure the server's IP isn't unique, though it does remove an incentive to make it unique.

I'd like to leave the option to switch to a zero-length CID later in the connection, and I think I'd be fine with 4 if we allowed that.

An easy example is a large upload.  I mostly don't care about the CID, but if I'm uploading a 10GB file, maybe saving some bytes matters.  Also, if you're constantly filling the pipe, NAT rebinds are extremely unlikely.

Another example is an environment like a datacenter where there are no NATs and routes are very stable, unless a peer intentionally changes it, so the 5-tuple is sufficient.  In that case, the ideal operating condition is to typically use a 0 byte CID and switch to a non-0 length anytime a peer changes IP or port.  Changing port has some clear benefits in some cases, so it's in no way a threoretical use case.  @nibanks may have thoughts on this range of use case as well.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3560#issuecomment-607291331

---

From: Nick Banks <[email-masked]>
Date: Wed, 01 Apr 2020 07:58:29 -0700

In our implementation, we plan to do all routing based purely on the CID. IMO, the couple of byte overhead in a 1500 MTU (at least; in datacenter) packet isn't going to make much difference, so it's just simpler to have a common CID routing scheme.

That being said, I personally am not against allowing for others to do something different. I've never understood why we make any restrictions on changing between 0-length and non-0-length CIDs at all. IMO, the complexity is that it can change length at all, not that it's zero or not.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3560#issuecomment-607299756

---

From: Martin Thomson <[email-masked]>
Date: Wed, 01 Apr 2020 16:30:47 -0700

@ianswett we already prohibit changing from non-zero-length to zero-length using NEW_CONNECTION_ID.  I don't want to relitigate that.  I want to concentrate on this specific issue.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3560#issuecomment-607539563

---

From: ianswett <[email-masked]>
Date: Wed, 01 Apr 2020 18:40:08 -0700

If we're not going to re-litigate that, then I'd suggest we continue allowing a 0-length CID for the preferred address case.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3560#issuecomment-607572595

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 01 Apr 2020 19:13:49 -0700

@ianswett While I would not argue strongly against continue allowing that, I would appreciate it if you could clarify why allowing a zero-byte CID would be useful.

As pointed out in https://github.com/quicwg/base-drafts/issues/3560#issuecomment-607028938, when you provide a zero-byte CID in SPA, you need to be prepared for receiving a short header packet using zero-length CID from any IP address, and be capable of associating that to an existing connection. This is because the client (or the network) might change the client's address tuple when it sends packets to the preferred address.

I would anticipate that you wouldn't want to do that in your file upload case (or in any deployment that might accept multiple connections concurrently).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3560#issuecomment-607581460

---

From: ianswett <[email-masked]>
Date: Thu, 02 Apr 2020 11:25:59 -0700

@kazuho If I know 5-tuples are stable, then using a zero-length CID is always fine, just like it's typically fine in the server to client direction.  But in that case, hopefully I can avoid needing to use SPA, making the decision on this issue moot.

After thinking about this more, we're probably better off with option 4 for the sake of consistency and if we want to allow 0-length CIDs in more case, I can write an extension for how that would work, since I don't think it's only a matter of relaxing some constraints.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3560#issuecomment-608027612

---

From: Martin Thomson <[email-masked]>
Date: Tue, 07 Apr 2020 00:10:52 -0700

Thanks all.  I think that we reached the same conclusion in the end, via different paths.

The proposed fix here is firmly design chairs.  A bugfix only, but still worth careful review.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3560#issuecomment-610216596

---

From: David Schinazi <[email-masked]>
Date: Wed, 08 Apr 2020 17:23:31 -0700

Apologies for getting to this late, but I'm not sure I agree that we should disallow this. Here's a use-case that I think makes sense: the client wants to upload a very large file to the server over HTTP/3 and it has a small MTU, making it particularly sensitive to per-packet overheads. Let's also assume that we are in the future and the server supports IPv6 and has its own /64 (shocking!). In this scenario, a good way to reduce per-packet overhead is to operate the server on a given address, and then switch each client to their own unique server IP using preferred address, and then use zero-length CIDs. I've always found this use-case a good use of preferred address, and I would rather we didn't ban it without a good reason (and making the design cleaner doesn't necessarily count as a good reason at this stage in the process).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3560#issuecomment-611260430

---

From: Martin Thomson <[email-masked]>
Date: Wed, 08 Apr 2020 17:43:13 -0700

That is an example we discussed.  As Kazuho noted, that doesn't work as we have already agreed that any connection ID (in this case, a zero-length one) can be used prior to handshake completion.

That's why we ended up on 4.  As Ian noted, this isn't ideal, but this is an area that is ripe for extensions that might allow this sort of thing.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3560#issuecomment-611265745

---

From: David Schinazi <[email-masked]>
Date: Wed, 08 Apr 2020 17:53:16 -0700

I don't understand what you meant by the following:
> we have already agreed that any connection ID (in this case, a zero-length one) can be used prior to handshake completion.

Can you clarify? I was under the impression that the client switches to the preferred address **after** the handshake is done.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3560#issuecomment-611268251

---

From: Martin Thomson <[email-masked]>
Date: Wed, 08 Apr 2020 18:01:50 -0700

Yes, you can't migrate (act on the address information) before the handshake is confirmed.  However, the connection ID is not special; it can be treated just like any other connection ID you learn, so you can act on the connection ID information before you confirm the handshake.

So that means that a server that opts to include a zero-length connection ID in the preferred_address might receive a packet with the zero-length connection ID at the old address.  That might not work out.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3560#issuecomment-611270314

---

From: David Schinazi <[email-masked]>
Date: Wed, 08 Apr 2020 19:30:16 -0700

What's the point of including a connection ID (and stateless reset token) in the `preferred_address` transport parameter if that CID isn't tied to the preferred address in any way? At that point might as well remove that CID entirely and rely on NEW_CONNECTION_ID frames. My understanding was that the reason for there being a CID in the `preferred_address` TP was specifically to make that CID special. Would it make sense to just say that this CID MUST NOT be used when sending to the handshake server IP?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3560#issuecomment-611293114

---

From: Martin Thomson <[email-masked]>
Date: Wed, 08 Apr 2020 19:56:59 -0700

the reason for having a connection ID in the transport parameter is only so that the client has a connection ID to use for the new path

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3560#issuecomment-611299925

---

From: ianswett <[email-masked]>
Date: Thu, 09 Apr 2020 08:32:46 -0700

@DavidSchinazi I agree with your intuition, but I think we discussed this in Zurich and ended up concluding the preferred_address CIDs weren't special.  This was in issue #3348 and also came up in #3353 (which I realize hasn't gone out for a consensus call yet, that PR seems stalled?).

In the upload example, the server needs to know that the client is going to send a lot of data, which it might know via SNI, or it might not.  I tend to think the more annoying restriction is that you can't change from a non-0 length CID to a 0-length one and vice versa.  By supplying a 0-length CID later in the connection along with other CIDs, the client could choose whether it wanted to use a 0-length CID at any time.

Thinking out loud, an easier solution may be a TP like 'accept_empty_connection_id' that indicates at anytime, the peer can switch to a 0-length CID if it wants.  It could either think the 5-tuple is stable or its happy re-establishing the path with a non 0-length CID after a NAT rebind.  In this world, the Connection ID is more of a path re-establishment token.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3560#issuecomment-611593332

---

From: David Schinazi <[email-masked]>
Date: Thu, 09 Apr 2020 10:24:19 -0700

Thanks for the details @ianswett and @martinthomson. I get a sense I might be trying to re-litigate  past consensus without providing new information, so I'll back down. I do think that the ghost of hypothetical linkability has caused us to make some very odd design choices, but this isn't new to this issue/PR. In the end, this is the kind of feature that can be enabled by extensions so I can live with us further restricting the base spec for consistency.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3560#issuecomment-611649970