Re: [quicwg/base-drafts] active_connection_id_limit interacts poorly with Retire Prior To (#3193)

[Mike Bishop <[e-mail]>]

Another potential pitfall of "MUST NOT":  Assume you've filled the peer's quota, but now need to revoke all prior CIDs and start a new generation.  You have to send at least one NCID to carry the RPT and give the client something in the new generation of CIDs.  Depending on the client's implementation, the limit might be exceeded during the processing of the frame.

This can be addressed if the client takes actions in this order:
- Retire all unretired CIDs <= RPT, queuing the RCID frames for transmission
- Add the new CID to the connection
- Send the queued RCID frames using the new CID

During this transition, though, there are zero active CIDs on the connection.  A more savvy implementation might retire _all but one_ of the old CIDs (so data flow never gets stalled), install the new CID, then retire the last old one.  Of course, that gets trickier in a multipath world; you have to make sure that the one you keep is okay for the currently-active path.

What the client can't do is add the new CID first, check the limit, then process any retirements; in that order, the limit gets breached.

-- 
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/3193#issuecomment-551234463