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

[Kazuho Oku <[e-mail]>]

> One detailed point is that it seems best to me to combine these two frames into one. If you're asking for new CIDs, you're probably retiring some anyway.

I agree. In my view, the logic could be as simple as follows:
* during the handshake, the endpoints negotiate the maximum number spare CIDs to be used for the given connection
* the endpoints will try to provide the negotiated amount of spare CIDs to the peers (i.e., after handshake an endpoint sends `max_spare-1` CIDs to peers, then send additional ones as it notices a CID getting retired)
* a CID that both peers know that it is has been used will be retired by an expiration timer
* a CID that an endpoint has used but that peer might not have seen will be explicitly retired by a RETIRE_CONNECTION_ID
* we could have CONNECTION_ID_BLOCKED frame

Instead of using a timer, we could always explicitly signal the retirement using the RETIRE_CONNECTION_ID frame.

As you can see, the design is analogous to how we handle streams. It caps the maximum amount of CIDs that the endpoints need to remember.

-- 
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#issuecomment-406333457