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

[Marten Seemann <[e-mail]>]

The `active_connection_id_limit` parameters communicates the maximum number of connection IDs sent in NEW_CONNECTION_ID frames that an endpoint is willing to store. This value is only advisory though, there's nothing stopping an implementation from storing more CIDs than this limit, and the peer is allowed to send more CIDs than this limit:
> An endpoint SHOULD NOT provide more connection IDs than the peer’s limit.

We don't specify any behavior in the case the peer provides more CIDs than this limit, but since retiring a CID asks the peer to provide a new CID, it seems like the reasonable thing to do would be to silently drop the CID on the floor:
> Sending a RETIRE_CONNECTION_ID frame indicates that the connection ID will not be used again and requests that the peer replace it with a new connection ID using a NEW_CONNECTION_ID frame.

This means that a peer cannot fulfill its duty of retiring those discarded connection IDs when receiving a NEW_CONNECTION_ID frame with Retire Prior To set:
>  Upon receipt, the peer MUST retire the corresponding connection IDs and send corresponding RETIRE_CONNECTION_ID frames.

This, however, is not guaranteed, either. A peer might decide to send a RETIRE_CONNECTION_ID frame for a sequence number that it already forgot.

Furthermore, depending on how implementations decide with all these uncertainties, one could end up in a situation where an endpoint only has a single active CID available, but its peer assumes that it is still keeping track of `active_connection_id_limit` CIDs and thus won't provide any new CIDs. In this situation, the endpoint won't be able to initiate or respond to a connection migration any more, leading to a failure of the connection.

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