Re: [quicwg/base-drafts] Timer interval for retire the connection IDs (#3215)

[Mike Bishop <[e-mail]>]

It's tied up in why you would retire CIDs.  Various conditions mean that a CID issuer's infrastructure might no longer be able to honor old CIDs (i.e. recognize them as valid and get them to the correct recipient).  However, you usually either know that's coming or can extend the period with some temporary extra state.

The CID issuer will stop accepting the CIDs in question 3 PTO after sending the frame requesting retirement.  That 3-PTO period covers transit time to the peer, any time the peer decides to wait before it stops using the old CIDs, the return transit time for any packets that were already in flight before the peer stopped, and any extra time those packets might have been delayed.  If packets arrive late, they will not be processed and will generate stateless resets.  Those shouldn't be connection-fatal; if the peer has dropped the CIDs and corresponding tokens correctly, then they won't recognize the stateless resets as matching the current connection and will drop *them*.  But you've caused packet "loss" in excess of what happened on the network if you let it get to that point.

This is advice that the peer not wait more than 1 PTO, to make it likely that the issuer is not still receiving packets with old CIDs after the 3-PTO timer has expired.  It's an arbitrary period, no doubt, but it's a better arbitrary period than anything else we've come up with.  Alternative suggestions welcome.

-- 
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/3215#issuecomment-552607316