Re: [quicwg/base-drafts] Required state for retaining unacked RETIRE_CONNECTION_ID frames is unbound (#3509)

[Kazuho Oku <[e-mail]>]

@martinthomson 
> I think that the idea is to reduce the set of RCID frames needed to a range of sequence numbers. You only have to remember the few exceptions for sequence numbers that are in use, sequence numbers for which you have outstanding frames, and a range of sequence numbers that require retirement.
> 
> As long as your discretionary use is sequential, this is bounded state.

Yes, this is one method of limiting the state that is being used for retaining sequence numbers that need to be sent. And it works even when discretionary use is not sequential, as the number of "exceptions" (i.e. gaps) is bounded by max_connection_id_limit. The other assumption of using this method is that you would somehow bound the state that is used to track RCID frames being inflight. There are various ways of accomplishing that, e.g., have a limit on the number of RCID frames sent at once, track bunch of inflight RCID frames as one meta-frame.

And it is correct that the outcome would be a "lag" in this method.

The downside of this method is that it might be a disruptive change to existing implementations. It is essentially equivalent to what #3553 proposes, with the exception being that tracking RCID frames are difficult (as you track to send many).

For existing implementations, it would be easier to adopt a "leaky" method, i.e.:

* let endpoints have a counter counting on the number of sequence numbers that are retired but are yet to be acknowledged
* when a CID is being retired, if the value of the counter is below a certain threshold (i.e. 2 * max_connection_id_limit), the counter is incremented, and a RCID frame carrying the sequence number of that CID is added to the outstanding queue. If the counter was not below the threshold, no RCID frame will be sent (leak!)
* when an RCID frame is deemed lost, it will be resubmitted into the outstanding queue
* when an RCID frame is acknowledged before deemed lost, the counter is decremented
* when an RCID frame is late-acked, we do nothing

Assuming that the solution we prefer is the least-disruptive approach, I think we need to  recommend the latter. If we have distaste in the latter and prefer the former, I think we'd better switch to #3553, as it more cleanly reflects the design of the former.

-- 
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/3509#issuecomment-607541624