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

[Nick Banks <[e-mail]>]

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

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