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

[Marten Seemann <[e-mail]>]

Dropping connection IDs worked out fine before we introduced the Retire Prior To field. We added that field in #2769, which was merged in July (about half a year after our discussion in Tokyo and the claryfing PRs).

> If/when the peer sends RetirePriorTo and requests that you retire them, you retire the ones you haven't yet retired and still know about.

That's not what the spec says (but maybe what the spec intends to say?). If this was the only issue, we could probably easily resolve this by changing the wording to something like "MUST retire the corresponding connection IDs that it still remembers" or so.

> Generally, that means that you get a replacement for those, so now you still have active_connection_id_limit CIDs. 

That might or might not happen. It all depends on the peer's assumption of what you did: Does it assume that you dropped connection IDs (if so, which ones?)? Does it assume that you actually enforced the limit that you announced in the TP by dropping all CIDs in excess of it?
The situation gets even worse when you assume that  a RETIRE_CONNECTION_ID frame was in flight just when the endpoint provided the new CIDs. In this situation, there's no race-condition-free view of how many CIDs the peer was actually storing, so it's not possible to know how many of the new CIDs were actually stored and how many of them might have been dropped.

-- 
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-550232159