Subject: [quicwg/base-drafts] Connection ID Sequence Number and Server's Preferred Address (#1483)

From: Mike Bishop <[email-masked]>
Date: Tue, 26 Jun 2018 16:24:20 -0700

Follow-on issue from #1465.  The existing text (restored but not changed by the PR) defines the CID selected during the handshake to be Sequence -1, and the CIDs issued via NCID frame to begin at zero.

However, the CID issued by the server as part of the Server's Preferred Address doesn't have a suggested sequence number.  If we follow a similar convention and assign it an implicit negative number (e.g. handshake becomes -2, SPA gets -1), that introduces another quirk:  With the existing language, the server will answer with a new connection ID (say, 0) which will immediately force the client into a connection ID rotation anyway.

Possible solutions include:
- Not including a CID with the SPA parameter; client needs to wait for (and server needs to send) a NCID frame before the probe/transition has happened.
- Server includes a sequence number in the SPA parameter and treats it like any other sequence number it has issued (but then why should the client be required to use that particular CID?)
- SPA is implicitly sequence number zero, and server can use the client's sequence number zero in response

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

---

From: janaiyengar <[email-masked]>
Date: Wed, 27 Jun 2018 11:38:15 -0700

Do you remember why we needed a CID in the SPA? I can't seem to come up with a good reason for it.

-- 
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/1483#issuecomment-400787252

---

From: Mike Bishop <[email-masked]>
Date: Wed, 27 Jun 2018 12:40:16 -0700

So the client has a CID to probe with as soon as it finishes the handshake.  Otherwise, the client has to delay until it receives a NEW_CONNECTION_ID frame. Hopefully that will be in the server's first 1-RTT packet, but it's still an additional wait the client has to introduce.  (Or the client probes without changing CID, which is probably okay for a public web server but might not be universally.)

-- 
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/1483#issuecomment-400804736

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Jun 2018 14:49:58 -0700

Also, routing to the new address may be contingent on the corresponding connection ID.

-- 
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/1483#issuecomment-400840386