active_connection_id_limit is unknown for 0-RTT

[marten-seemann]

This value is not remembered for 0-RTT. A client therefore cannot send NCID frames in 0-RTT without risking to violate the server’s limit.

[MikeBishop]

The alternative would be to add it to the list of things to remember, but yes, we should fix it.

[marten-seemann]

@MikeBishop That would mean that the server needs to remember / save in the session ticket, and can’t reduce in the resumed connection. My understand was that we only remember those values that are absolutely necessary to make 0-RTT make sense, i.e. flow control and stream number limits.

[larseggert]

Discussed in ZRH. @marten-seemann to write up a PR for his preferred option.

[MikeBishop]

Post-discussion and having re-read, I believe the current text covers this for NEW_CONNECTION_ID:

• The client has already issued one CID to the server during the handshake, which might be zero-length
• Sending NEW_CONNECTION_ID is forbidden if you are using zero-length CIDs; receipt of one is a protocol violation
• The default and minimum value of active_connection_id applies until the server's value is received, which is two if the client is using non-zero-length CIDs
• Exceeding the limit is a protocol violation

So the client can send no more than one NEW_CONNECTION_ID frame in 0-RTT, or it's a protocol violation. If it sends exactly one, that never exceeds the server's limit, provided that it has a non-zero-length Source Connection ID.

It also covers it for RETIRE_CONNECTION_ID:

• The client has exactly one CID for the server during 0-RTT
• It is a protocol violation for RETIRE_CONNECTION_ID to retire the CID used by the containing packet

[MikeBishop]

Over supper, @marten-seemann wanted to know why a client would include a new connection ID in its 0-RTT packets. The answer is that the client's handshake CID has no associated SRT. If the client wants the ability to send stateless resets, it might very well put NCID(N=1, RPT=1) in its 0-RTT flight. The server will retire the handshake connection ID in 0.5-RTT and begin using the CID with an associated token.

[larseggert]

Discussed in ZRH. Proposed resolution is written up in #3425.

[ianswett]

The meeting notes record that there was a 12 to 1 vote for saving the value instead of using the default of 2.
https://github.com/quicwg/wg-materials/blob/master/interim-20-02/minutes.md#3423-active_connection_id_limit-is-unknown-for-0-rtt-1

I believe I was convinced by the argument that a server could just always use the default and never change it, so it doesn't really matter for servers.