Subject: [quicwg/base-drafts] Consistent presenting Connection ID in packet or frame (#1336)

From: Quoc-Viet Nguyen <[email-masked]>
Date: Thu, 03 May 2018 16:00:07 -0700

Currently, there are 4 ways a Connection ID (CID) is presented in a packet or frame:

1. Using DCIL and SCIL (both 4-bit) in Long Header to encode its length.
2. No CID length in Short Header.
3. Fixed size CID in Stateless Reset packet.
4. Using a 8-bit field in NEW_CONNECTION_ID Frame for its length.

I am wondering if it is possible to unify the way a CID is presented like Stream ID. I understand that CID is version-independent but what I am concerned the most is CID in Short Header:

> Endpoints using a connection-ID based load balancer could agree with the load balancer on a fixed or minimum length and on an encoding for connection IDs. This fixed portion could encode an explicit length, which allows the entire connection ID to vary in length and still be used by the load balancer.

I'm trying to implement a QUIC proxy and I don't know how to do with that since I don't control backend applications. Can we specify a Connection ID encoding in the specification, or at least in the first version?

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 03 May 2018 19:04:50 -0700

Practically speaking, the short header and stateless reset are the same thing.

The encodings for packet headers are special, but we have none of the constraints that drive the need for a special encoding when sending NEW_CONNECTION_ID.

Do you have a suggestion?

-- 
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/1336#issuecomment-386488493

---

From: Quoc-Viet Nguyen <[email-masked]>
Date: Thu, 03 May 2018 22:07:31 -0700

I prefer always using 8-bit for the length of CID as we're already using Variable-Length Encoding.
(I think that is how it's described in https://github.com/quicwg/base-drafts/issues/1101)

Before opening this issue, I tried to find and understand all comments regarding symmetric CID & number vs opaque value. And I believe always having CID length will make it easier for a load-balancer implementation (parsing CID) or migration from 64-bit unsigned integer (using first 8-bit of the number). I might be wrong here but I think it's a valid reason to still interpret CID as a number since number lookup is easily done in some programming languages.

-- 
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/1336#issuecomment-386506694

---

From: Patrick McManus <[email-masked]>
Date: Fri, 04 May 2018 05:14:31 -0700

tangentially, no CID-len for short packets caused a problem for @larseggert who wanted to disambiguate between 0-len and non-0 len CID on the same 4 tuple. I believe in the omit-cid era he would omit them on the first connection from a 4 tuple and start using them after that.

plausibly the compromise for that is bringing back a shorter amount of signaling for a variable length encoding.. either making the min cid len 1 byte instead of 4, or even (less desirably imo) bringing the omit cid bit back.

-- 
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/1336#issuecomment-386582905

---

From: ianswett <[email-masked]>
Date: Fri, 04 May 2018 05:29:43 -0700

Differentiating between 0-len and non 0-len CIDs is a problem, but I'm not sure it's an important use case.  0-len CIDs are very much designed for cases when you expect the 4-tuple to identify the connection.  Non-0 are for all other cases.  Those cases seem quite distinct, so I don't see a need to support both on the same 4-tuple at once.

If you're using a load balancer, you should almost certainly be using a non-0 length CID.  And you can choose to encode the length in that CID however you'd like, since the CID is receiver chosen.

@mcmanus  Bringing back the bit is sad, and making the min length 1 byte would require some substantial changes to the invariants, which I'd really rather not do.

-- 
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/1336#issuecomment-386586397

---

From: Lars Eggert <[email-masked]>
Date: Fri, 04 May 2018 05:40:28 -0700

Regarding "when you expect the 4-tuple to identify the connection" - what do you do if you have omitted the CID for a connection, but that expectation ends up being wrong?

Not being able to accept additional connections on a 4-tuple (with non-omitted CIDs) IMO severely limits the possibility to use omitted CIDs, to the point where we might as well ditch them completely.

-- 
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/1336#issuecomment-386588885

---

From: ianswett <[email-masked]>
Date: Fri, 04 May 2018 05:47:02 -0700

If a client uses an ephemeral port to connect to a peer, the client would have to choose to re-use that port to create a new QUIC connection.  I don't see why it wouldn't know whether that was possible when it created the connection?

I expect most client code will not use the same port for multiple QUIC connections, but if they support that(ie: maybe server to server connections?), then they should't use 0-len CIDs.

Do you have a use case in mind where typically you don't need a CID and then suddenly you do?

-- 
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/1336#issuecomment-386590536

---

From: Lars Eggert <[email-masked]>
Date: Fri, 04 May 2018 07:24:02 -0700

Think of a server w/o load balancers, and clients behind CGNs. The server might want to not use CIDs, and the clients may not know they should.

-- 
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/1336#issuecomment-386617603

---

From: ianswett <[email-masked]>
Date: Fri, 04 May 2018 07:29:44 -0700

Not using a connection ID on the server side in that case seems pretty brittle.  The QUIC design includes CIDs partially for NAT rebinds, so the server would be implicitly deciding it didn't care about NAT rebinds.  If it decided it'd rather reset connections than deal with NAT rebinds, that's certainly a choice it can make.

-- 
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/1336#issuecomment-386619380

---

From: Lars Eggert <[email-masked]>
Date: Fri, 04 May 2018 17:41:16 +0000 (UTC)

OK, so which are the cases where we think that zero-length CIDs are actually useful?

-- 
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/1336#issuecomment-386674811

---

From: MikkelFJ <[email-masked]>
Date: Fri, 04 May 2018 17:44:29 +0000 (UTC)

> OK, so which are the cases where we think that zero-length CIDs are actually useful?

Average http clients using ipv6?

-- 
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/1336#issuecomment-386675713

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 04 May 2018 17:56:21 +0000 (UTC)

Client CID can be set to zero-length if a client allocates a new ephemeral port for every new connection.

It is just that it is less useful for endpoints using one IP:port for multiple connections (which includes servers).

-- 
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/1336#issuecomment-386684623

---

From: MikkelFJ <[email-masked]>
Date: Sat, 05 May 2018 10:06:57 +0000 (UTC)

I was thinking a bit about using a single port also for the client case:

In this case the number connections is likely small, but a CID cannot be zero length. Using a full byte to encode CID length is a bit much if you only need to distinguish between 8 different CIDs.

At the same time, if CID's are tied to key rotation, 0 length CID's won't work but a single bit CID would work similar to a key phase, iff CID's can be reused in this case.

If the minimal CID length, including length prefix, is a single byte, there isn't much space left for longer, but it can be handled:

Two bits code for length. 00, 01, 02, 03

00: keyphase, zero length CID, but a single keyphase bit.
01: 6 bit bit CID
02: 14 bit CID
03:  CID length is encoded in the following 6 bits.

-- 
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/1336#issuecomment-386794629

---

From: Lars Eggert <[email-masked]>
Date: Sun, 06 May 2018 10:54:46 +0000 (UTC)

What if the client is behind a CGN that does port slicing?

-- 
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/1336#issuecomment-386870689

---

From: ianswett <[email-masked]>
Date: Sun, 06 May 2018 14:05:12 +0000 (UTC)

I can't find any good reference on port slicing, but presumably that's using one external port for multiple 4-tuples flowing through it?

If so, then the CGN still needs to only direct traffic intended for the client to the client.

-- 
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/1336#issuecomment-386881726