Subject: [quicwg/base-drafts] Client connection IDs are broken (#2844)

From: David Schinazi <[email-masked]>
Date: Tue, 25 Jun 2019 12:31:24 -0700

QUIC supports client connection IDs (CIDs) in order to allow a client to multiplex multiple QUIC connections on the same local IP and port. However, the current spec doesn't allow that to work, as pointed out by @kazuho on #2834 : if a server decides to use zero-length CIDs, then the client cannot establish multiple connections to that server from the same local port. For this to work, the client would need to know out-of-band that the server will not use zero-length CIDs, and that's not viable.

Therefore we have two protocol features that are at odds with one another:
(1) server can share port and use zero-length CIDs (which prohibits migration)
(2) client can share port and use non-zero-length CIDs

We can't have both (1) and (2) because the client wanting to do (2) doesn't know if the server will do (1) or not. If that happens, long headers will be demultiplexed properly because they contain the client's CID, but short headers from client to server do not and therefore cannot be demultiplexed.

@huitema and I have a use-case for (2) which is a QUIC proxy that only uses one port for outbound connections and relies on client CIDs for demultiplexing. I don't see a use for (1).

For client connection IDs to be useful in QUIC, I think we should ban zero-length connection IDs when you're multiplexing multiple connections on a local IP + port.

The current spec states:

> A zero-length connection ID MAY be used when the connection ID is not needed for routing and the address/port tuple of packets is sufficient to identify a connection.

We may want to change it to something like:

> A zero-length connection ID MAY be used when the connection ID is not needed for routing and the destination address/port tuple of incoming packets is sufficient to identify a connection.

-- 
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/2844

---

From: ianswett <[email-masked]>
Date: Tue, 25 Jun 2019 12:44:10 -0700

I think your suggested text is preferable.  That is how I think of using connection IDs, and it still allows 0 byte CIDs for P2P cases.

-- 
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/2844#issuecomment-505594070

---

From: Christian Huitema <[email-masked]>
Date: Tue, 25 Jun 2019 12:48:37 -0700

On 6/25/2019 12:31 PM, David Schinazi wrote:

> QUIC supports client connection IDs (CIDs) in order to allow a client
> to multiplex multiple QUIC connections on the same local IP and port.
> However, the current spec doesn't allow that to work, as pointed out
> by @kazuho <https://github.com/kazuho> on #2834
> <https://github.com/quicwg/base-drafts/issues/2834> : if a server
> decides to use zero-length CIDs, then the client cannot establish
> multiple connections to that server from the same local port. For this
> to work, the client would need to know out-of-band that the server
> will not use zero-length CIDs, and that's not viable.
>
> We can't have both (1) and (2) because the client wanting to do (2)
> doesn't know if the server will do (1) or not. If that happens, long
> headers will be demultiplexed properly because they contain the
> client's CID, but short headers from client to server do not and
> therefore cannot be demultiplexed.
>
> @huitema <https://github.com/huitema> and I have a use-case for (2)
> which is a QUIC proxy that only uses one port for outbound connections
> and relies on client CIDs for demultiplexing. I don't see a use for (1).
>

Sure, but that use case comes with a deployment requirement. QUIC nodes
using the proxy service MUST use a CID of equal or larger length than
required by the proxy. This is a requirement on incoming packets, and
the CID on incoming packets is chosen by the intended recipient of these
packets, in our case the nodes behind the proxy. It is not a requirement
of outgoing packets -- the proxy will just send the packets formatted by
the client to the address and port that the clients specifies. It will
work even if Azure servers are using zero length CID. Theses servers
won't work behind a proxy, but they will reachable through the proxy.

-- Christian Huitema

-- 
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/2844#issuecomment-505595723

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 25 Jun 2019 14:47:33 -0700

@DavidSchinazi Thank you for opening the issue. I agree that this is a design issue that needs to be fixed.

> We can't have both (1) and (2) because the client wanting to do (2) doesn't know if the server will do (1) or not.
> (snip)

Agreed.

IIRC, the introduction of client CID was a deliberate action to allow multiple QUIC connections be coalesced on a 5-tuple. I think the reason (1) exists is simply because we did not notice that there is a conflict. Based on that, I think we should adjust (1) to allow (2) to happen.

Allowing a client use one (or few) UDP packets to handle many QUIC connections has benefits. It helps code reuse (because servers are designed to use one port for many connections) and also has performance benefits (because you can use one system call to read / write packets belonging to many connections).

-- 
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/2844#issuecomment-505635297

---

From: David Schinazi <[email-masked]>
Date: Tue, 25 Jun 2019 18:10:21 -0700

@huitema I think you may have misunderstood what I meant. If the web server uses zero-length CIDs on port 443, then it will not be able to demultiplex incoming short packets from multiple connections that transit through the proxy. So we cannot build that kind of proxy if servers like this exist.

-- 
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/2844#issuecomment-505677656

---

From: Christian Huitema <[email-masked]>
Date: Tue, 25 Jun 2019 20:20:07 -0700

@DavidSchinazi Got it, OK. Server should not assume that client connections would always come from different 5 tuples, because in the case of proxies they will not. For example, two clients coming through the same proxy will appear to come from the same IP and port.

This is not a problem for clients, because clients can decide whether or not to send several outgoing connections through the same port.

-- 
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/2844#issuecomment-505701424

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Jun 2019 20:23:56 -0700

I think that the one word fix is fine.  It needs to be about things that the recipient controls.  I would be reluctant to say more though.  This isn't that important a point.

Note that clients are prevented from reusing a source port if the server chooses a zero-length connection ID, but I think that's fine.

-- 
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/2844#issuecomment-505702129

---

From: David Schinazi <[email-masked]>
Date: Wed, 26 Jun 2019 14:28:10 -0700

@martinthomson the issue is that, at the moment it creates the connection, a client has no way of knowing that a server will multiplex and use zero-length CIDs. Therefore just giving servers the possibility of multiplexing and using zero-length CIDs completely negates the value of client connection IDs.

-- 
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/2844#issuecomment-506051933

---

From: Martin Thomson <[email-masked]>
Date: Wed, 26 Jun 2019 18:05:58 -0700

Isn't that something the client can know before it creates the *second* connection?

-- 
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/2844#issuecomment-506098582

---

From: Christian Huitema <[email-masked]>
Date: Wed, 26 Jun 2019 19:03:34 -0700

The problem is not the leaf client, it is the proxy. The logical implementation of the proxy is to have just one UDP port. Conceivably, the proxy could manage a pool of ports and try to guarantee that a given 5 tuple corresponds to exactly one client-server connection. But that's significantly more complex than having just one port and relying on the CID.

-- 
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/2844#issuecomment-506108881