Subject: [quicwg/base-drafts] Add sequence number to NCID frame (#1821)

From: janaiyengar <[email-masked]>
Date: Tue, 02 Oct 2018 09:18:18 -0700

Closes #1799.

I've left this out of RETIRE_CONNECTION_ID because there's no seq num assigned to the CIDs used during the handshake.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/1821

-- Commit Summary --

  * Add sequence number to NCID frame

-- File Changes --

    M draft-ietf-quic-transport.md (22)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1821.patch
https://github.com/quicwg/base-drafts/pull/1821.diff

-- 
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/pull/1821

---

From: Marten Seemann <[email-masked]>
Date: Tue, 02 Oct 2018 09:33:17 -0700

marten-seemann approved this pull request.

-- 
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/pull/1821#pullrequestreview-160812944

---

From: ianswett <[email-masked]>
Date: Tue, 02 Oct 2018 10:02:17 -0700

ianswett commented on this pull request.

> @@ -3285,8 +3292,10 @@ zero-length Destination Connection ID MUST treat receipt of a NEW_CONNECTION_ID
 frame as a connection error of type PROTOCOL_VIOLATION.
 
 Transmission errors, timeouts and retransmissions might cause the same
-NEW_CONNECTION_ID frame to be received multiple times. Receipt of the same
-frame multiple times MUST NOT be treated as a connection error.
+NEW_CONNECTION_ID frame to be received multiple times.  Receipt of the same
+frame multiple times MUST NOT be treated as a connection error.  A receiver can
+use the sequence number supplied in the NEW_CONNECTION_ID frame to identify new
+connection IDs from old ones.

Q: What happens if the CID sequence number increases by a large amount(ie: 1000)?  If the same sequence number arrives with a different connection ID, is the receiver supposed to close the connection, ignore the second one?

-- 
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/pull/1821#pullrequestreview-160825068

---

From: Mike Bishop <[email-masked]>
Date: Tue, 02 Oct 2018 11:01:04 -0700

MikeBishop requested changes on this pull request.

We either need a requirement that each CID be unique for the lifetime of a connection (potentially difficult to guarantee unless you're encrypting a payload with a counter inside), or we need sequence numbers in RETIRE as well.  Otherwise, it's possible for a delayed RETIRE to retire the wrong instance of a duplicate.  (My inclination is actually "both," but at a minimum we need one or the other.)

I recognize the problem of missing sequence numbers, but it's easy enough to say that the CID from the handshake is CID 0 and the sequence number from the SPA is CID 1 if present.  At that point, everything has a sequence number and we could save some bytes on RETIRE.

For the first, I think we need to require the sender to always increase by one.  That way, the receiver could assume they're in flight.  That's one argument for putting the sequence number on RETIRE, since you could preemptively retire CIDs that are in-flight but not yet received.  Otherwise, you wind up with gaps which the issuer could choose to fill at any time, and the recipient has to keep track of the sparse set of retired/available IDs.

For the second, I don't think it would be unreasonable to abort the connection if it still remembers what CID was with that sequence number, but we shouldn't require that behavior because it might have been forgotten.  Just drop based on the sequence number if it's a repeat.

-- 
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/pull/1821#pullrequestreview-160848192

---

From: Mike Bishop <[email-masked]>
Date: Tue, 02 Oct 2018 11:05:28 -0700

Also, this PR can remove the recommendation to remember CIDs for 3xRTO after you retire them (section 6.1.2).  The point of that recommendation was to dedupe retransmissions; we can use the sequence number for that now.

-- 
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/pull/1821#issuecomment-426373722

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 02 Oct 2018 22:07:06 +0000 (UTC)

kazuho commented on this pull request.

> I think we need to require the sender to always increase by one.

On the flip-side, does it require the sender to have a window of CIDs (i.e. the maximum number of CIDs in-flight)?

I ask this because unless we have such maximum, it is impossible for the receiver to enforce the rule.
If we have an enforcement, then the receiver could use a simple data structure (like holding the most-recent N CIDs where the recency is identified by the sequence number). But otherwise, the receivers need to be aware that the sender can try to consume large amount of state by sending a huge gap...

-- 
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/pull/1821#discussion_r222127836

---

From: janaiyengar <[email-masked]>
Date: Wed, 03 Oct 2018 21:01:28 +0000 (UTC)

@janaiyengar pushed 1 commit.

391641e  Sequence for Connection IDs, RETIRE (#1829)

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1821/files/4c4024aef219bb2d3ed2db80e8188ead19923ca2..391641ed60351d5685d5121b261059862dfd8e63

---

From: janaiyengar <[email-masked]>
Date: Wed, 03 Oct 2018 14:57:39 -0700

Merged #1821 into master.

-- 
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/pull/1821#event-1883166490