Subject: [quicwg/base-drafts] Negative Connection ID Sequence Number (#1484)

From: Mike Bishop <[email-masked]>
Date: Tue, 26 Jun 2018 16:26:15 -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.

@nibanks objects to having negative sequence numbers.  We could, of course, make the handshake-negotiated CID be number zero, but then NCID with a sequence of zero would either be invalid or pointless.

Arguments for/against, or alternative solutions?

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

---

From: Nick Banks <[email-masked]>
Date: Tue, 26 Jun 2018 23:38:00 +0000 (UTC)

It's going to be painful to have a variable in memory that can represent both a variable length integer (UINT64) and a negative number. There is no precedent for it already. I'd **really** like to only use positive numbers.

-- 
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/1484#issuecomment-400496168

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Jun 2018 16:43:18 -0700

Conveniently, varints can use int64_t because they only use the lower 62 bits.  Also, uint64_t(0)-1 underflows reliably to UINT64_MAX if you want to keep your variables unsigned.

However, I think that the -1 recommendation is wrong, particularly in light of the changes to Retry and the server's preferred address transport parameter.  We should rephrase and avoid making any recommendation about how to handle these.

Those same things makes me very reluctant to recommend starting at 1 or 2, but if we don't require a contiguous sequence of connection IDs, then maybe some implementations can skip a few without consequence.  We probably shouldn't require contiguous sequence numbers anyway because of the potential for some endpoints to consume values that aren't seen and then they might decide not to provision their peer with matching connection IDs.  The frame isn't that small, after all.

-- 
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/1484#issuecomment-400497080

---

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

The text currently says they SHOULD be contiguous.  The advantage to contiguity is that you can speculatively issue batches and assume with some accuracy that the sequence numbers you pick will match the sequence numbers your peer picks.

Loosening that to simply ordered seems touchy, since one since effectively becomes dominant in picking which sequence numbers will actually become useful. (Only the intersection of the sequence numbers chosen by each peer can be stably used.)

-- 
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/1484#issuecomment-400539712

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Jun 2018 21:51:30 -0700

Yeah, I think that we'd want to retain the "SHOULD", but we might expand this to mention that gaps are generally only OK in the case where the corresponding sequence number was used on a dead path (or because you don't want to count backwards from zero to account for the handshake and server preferred address).

-- 
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/1484#issuecomment-400541961

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 27 Jun 2018 17:26:04 -0700

My preference goes to numbering each Connection ID *the endpoint provides* contiguously, starting from zero.

To be precise:
* SCID of the Initial packet is "zero"
* CID of SPA is "one", if exists
* CID being exchanged using NEW_CONNECTION_ID frames will start from "one" (if a CID is not provided by the endpoint using SPA), or "two" (if SPA was used)

I believe that the definition is clear, and that it is also easy to implement.

An implementation is required to have a structure that drops duplicate NEW_CONNECTION_ID frames. Having non-negative sequence numbers for SCID of the Initial packet and CID in SPA is only a matter of how we setup the structure.

-- 
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/1484#issuecomment-400871736

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Jun 2018 18:57:24 -0700

After realizing that you need to consume a sequence number if you intend to implement the preferred address, I think that this is the best approach.

At that point, we might as well concede that there will be a gap at the start in a lot of cases.  What @kazuho proposes here seems OK.  I don't think that the Initial packet needs a slot reserved, but the difference between one unused value and two isn't worth worrying about.

This does nothing for connection IDs provided with Retry, but the handling of Retry is reactive and can probably overwrite the zero index as it goes.

-- 
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/1484#issuecomment-400886188

---

From: MikkelFJ <[email-masked]>
Date: Thu, 28 Jun 2018 11:44:49 -0700

Just a comment from the sideline - I'm not really keep track of NEW CID atm, but I'm worried that a peer can force feed new CID's so the state for an idle connection grows large. Any protection / guidance on this? Ideally a passive QUIC connection should only need to store a few ID's and counters.

-- 
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/1484#issuecomment-401134683

---

From: Mike Bishop <[email-masked]>
Date: Thu, 28 Jun 2018 20:54:07 +0000 (UTC)

I had been playing with adding a RETIRE_CONNECTION_ID frame for that purpose.  As I start digging into when you can forget an old CID, you run into situations where the peers don't agree, such as #1495.

-- 
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/1484#issuecomment-401170074