Subject: [quicwg/base-drafts] CID Lifetime Management (#1496)

From: Mike Bishop <[email-masked]>
Date: Thu, 28 Jun 2018 14:46:50 -0700

Fixes #1495 by adding an explicit `RETIRE_CONNECTION_ID` frame.

Fixes #1464 by adding an explicit `REQUEST_CONNECTION_ID` frame.

(A previous version also changed `NEW_CONNECTION_ID` to contain a series of CIDs, but that's entirely separable if we decide we want that.)
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * CID lifetime frames
  * Include in table
  * SRT, too

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1496.patch
https://github.com/quicwg/base-drafts/pull/1496.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/1496

---

From: Nick Banks <[email-masked]>
Date: Thu, 28 Jun 2018 19:50:52 -0700

nibanks commented on this pull request.

> + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                         Sequence (i)                        ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+~~~
+
+The fields in the RETIRE_CONNECTION_ID frame are as follows:
+
+Sequence:
+: Sequence number of the oldest connection ID issued by the sender which the
+  sender will still recognize as associated with the current connection. The
+  sequence number is formatted as a variable-length integer.
+
+Upon receipt of a RETIRE_CONNECTION_ID frame, an endpoint MUST consider
+connection IDs older than the specified sequence number as unusable and MUST NOT
+consider the associated stateless reset tokens to be valid. If an older

I don't think older CIDs should be considered unusable. I can imagine a use for this to retire a CID that you used to try to probe a path that didn't work. In that case, you might still be using the older CID for your main path, and you just want to throw away the new 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/1496#pullrequestreview-133083900

---

From: Mike Bishop <[email-masked]>
Date: Fri, 29 Jun 2018 08:56:19 -0700

MikeBishop commented on this pull request.

Perhaps, but then you'd need to individually retire old CIDs one at a time.  I'm envisioning this as more of a sliding window -- an implementation is moving the end of the window.  Is there a reason you wouldn't just roll forward to another CID when you send this frame, in that situation?

-- 
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/1496#discussion_r199205706

---

From: Nick Banks <[email-masked]>
Date: Fri, 29 Jun 2018 08:59:04 -0700

We should be dealing is so few numbers of simultaneous CIDs that it should be just fine to be explicit. I think a sliding window puts to much of a restriction that you are constantly moving the primary path to these new CIDs. I must prefer being explicit, per 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/pull/1496#discussion_r199206490

---

From: Mike Bishop <[email-masked]>
Date: Fri, 29 Jun 2018 10:20:37 -0700

I'm inclined to think that if you're dealing in small numbers of CIDs, it's fine to just remember all of them.  If you reach the point where you need to abandon old CIDs because you have too many outstanding, then we're already in a scenario where you're using a lot of them.

-- 
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/1496#discussion_r199226914

---

From: Nick Banks <[email-masked]>
Date: Fri, 29 Jun 2018 10:27:24 -0700

While, we haven't implemented migration yet in WinQuic, the following is the design we'd have been considering:

- Have a hard coded limit on the number of CIDs to give to the peer, X (probably 3 or 4)
- Have a hard coded limit on the number of valid paths to maintain, Y (probably 2 or 3)
- Whenever we need to give a new CID out, if we are at our limit, we throw away the oldest, non-primary path, CID in our cache. If that CID was for a validated path, throw the path away.
- Trickier logic is around new paths being created. Not quite worked through the details on that one.

But bottom line, with this design, we don't expect to age out more than one at a time. And additionally, the peer could indicate they have to throw a CID away because they tried and failed to use it for a new path validation.

-- 
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/1496#discussion_r199228603

---

From: Mike Bishop <[email-masked]>
Date: Fri, 29 Jun 2018 15:06:13 -0700

I'm surprised at throwing the path away.  I'd think there are separate criteria to throw away a path, independent of needing new CIDs.  Still, I can see where a reasonable implementation might get into a state where it's always discarding a single CID at a time and perhaps wanting to discard CIDs non-contiguously.

Perhaps this is a question to discuss on-list, rather than in a PR comment?

-- 
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/1496#discussion_r199291098

---

From: Nick Banks <[email-masked]>
Date: Fri, 29 Jun 2018 15:09:13 -0700

I agree that we can follow up on the migration logic separate from this discussion. For this PR though, I don't think we should use a window style for CIDs. I think it restricts implementations from doing other things.

-- 
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/1496#discussion_r199291549