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

[Kazuho Oku <[e-mail]>]

I think the model that @erickinnear's has described is accurate.

At the same time, it seems alarming to me  that we have failed to incorporate that model into the text.

Specifically, as @marten-seemann points out, we have the following text:
> Upon receipt, the peer MUST retire the corresponding connection IDs and send corresponding RETIRE_CONNECTION_ID frames.

and FWIW also:
> Connection IDs that are issued and not retired are considered active; any active connection ID can be used.

that both assume that all connections IDs are expected to be retired. But as @erickinnear points out, when the issuer provides more than what `active_connection_id_limit` recommends, those connection IDs are not expected to be retired.

I'd like to point out that the way we control the active CIDs sticks out from other "crediting schemes". For all other crediting schemes (i.e. MAX_DATA, MAX_STREAMS, MAX_STREAM_DATA), there is a hard limit. It is a protocol violation when the sender exceeds the allowed maximum. It is only for this active_connection_id_limit - RETIRE_CONNECTION_ID pair that we do not enforce the sender adhering the limit.

Considering these aspects, and the fact that implementors are complaining about the complexity caused by "SHOULD NOT," I think it's worth considering changing the "SHOULD NOT" of "an endpoint SHOULD NOT provide more connection IDs than the peer’s limit" to "MUST NOT."

The counterargument might be that it's an additional complexity; but I doubt if it's that important, compared to the importance of resolving the confusion that we have now.

As @erickinnear have stated, the issuer is excepted to stick to providing *N* active CIDs, where N is a constant throughout the lifetime of a connection. No other approach works. So the *complexity* that is to be added by changing the "SHOULD NOT" to "MUST NOT" is that the issuer would be required to set N to no greater than the value of "active_connection_id_limit" provided by the peer.

I think we can pay that cost for buying a consistent design (that avoids the confusion).

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