Re: [quicwg/base-drafts] Limit RCID state (#3547)

[martinduke <[e-mail]>]

I'm reluctant to blow away the whole PR with brand new text, so in this comment I will propose four entirely new paragraphs that IMO says what needs to be said. Either the current PR, Martin's revision, or this proposal could serve as the basis of the eventual change:

If a peer sends large numbers of NEW_CONNECTION_ID frames that increase Retire
Prior To, and/or acks of packets that contain RETIRE_CONNECTION_ID are lost, the
state required at the RETIRE_CONNECTION_ID sender can grow without regard to its
active_connection_id_limit. Therefore, endpoints SHOULD take steps to bound the
state associated with needed RETIRE_CONNECTION_ID frames while ensuring that it
eventually transmits all required RETIRE_CONNECTION_ID frames.

For example, it might limit voluntarily retirement of sequence numbers if it has
not received enough acknowledgments of packets containing previous retirements.
It might also restrict the RETIRE_CONNECTION_ID frames in flight to a single
packet in order to simplify tracking of what is in flight, what needs retransmission,
and what has been acknowledged.

An endpoint MAY treat having too many connection IDs to retire as a connection
error of type CONNECTION_ID_LIMIT_ERROR. The threshold for this error SHOULD
be at least twice the endpoint's advertised active_connection_id_limit.

Endpoints SHOULD NOT issue updates of the Retire Prior To field prior to
receiving all of the RETIRE_CONNECTION_ID frames for the previous update to
Retire Prior To.

****

If people much prefer this or MT's revision, I'll update the PR accordingly.

-- 
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/3547#issuecomment-610667224