Clarify zero-length CIDs and active_connection_id_limit TP #3426
Conversation
draft-ietf-quic-transport.md
Outdated
| parameter MUST NOT be sent. | ||
| transport parameter is absent, a default of 2 is assumed. When the client | ||
| is using a zero-length connection ID, the server MUST NOT send the | ||
| active_connection_id_limit parameter. |
There was a problem hiding this comment.
I would say here that the server MAY omit the parameter. Sending a fixed set of transport parameters is a good practice.
There was a problem hiding this comment.
I was trying to keep this an editorial PR - saying that the server MAY omit the parameter changes normative language, which I thought would make it design.
There was a problem hiding this comment.
The MUST NOT is gone, leaving an implicit MAY.
draft-ietf-quic-transport.md
Outdated
| @@ -4697,11 +4697,11 @@ active_connection_id_limit (0x000e): | |||
| to store. This value includes the connection ID received during the handshake, | |||
| that received in the preferred_address transport parameter, and those received | |||
| in NEW_CONNECTION_ID frames. | |||
| Unless a zero-length connection ID is being used, the value of the | |||
| Unless the peer is using a zero-length connection ID, the value of the | |||
There was a problem hiding this comment.
I would instead prefer to say that the value is assumed to be zero if the peer requests that a zero length CID be used.
There was a problem hiding this comment.
Rather than "assumed to be zero," just say that value of the TP is not used in that case.
There was a problem hiding this comment.
I've changed this to say that the TP is ignored if an endpoint is using a zero-len CID.
draft-ietf-quic-transport.md
Outdated
| than 2. If this transport parameter is absent, a default of 2 is assumed. | ||
| If an endpoint uses a zero-length connection ID, the | ||
| active_connection_id_limit value received from its peer is ignored and | ||
| not used. |
There was a problem hiding this comment.
| not used. | |
| not used, as NEW_CONNECTION_ID frames can't be sent by a peer that opts for | |
| a zero-length connection ID. |
There was a problem hiding this comment.
I slightly tweaked the suggested change: s/peer/endpoint/ and s/can't/cannot/.
This is @martinthomson's suggestion from the PR with a slight tweak.
Co-Authored-By: ianswett <ianswett@users.noreply.github.com>
draft-ietf-quic-transport.md
Outdated
| transport parameter is absent, a default of 2 is assumed. | ||
| When a zero-length connection ID is being used, the active_connection_id_limit | ||
| parameter MUST NOT be sent. | ||
| The value of the active_connection_id_limit parameter MUST NOT be less |
There was a problem hiding this comment.
How about "MUST be at least 2"?
martinthomson
added
-transport
editorial
Co-Authored-By: Jana Iyengar <jri.ietf@gmail.com>
|
Purely editorial nit: This text has a lot of line breaks that won't render as such in the output. If you want to have separate paragraphs in the definition, you need a new |
draft-ietf-quic-transport.md
Outdated
| An endpoint that receives a value less than 2 MUST close the connection | ||
| with an error of type TRANSPORT_PARAMETER_ERROR. | ||
| If this transport parameter is absent, a default of 2 is assumed. If an | ||
| endpoint uses a zero-length connection ID, the active_connection_id_limit |
There was a problem hiding this comment.
"uses" here seems confusing
If an endpoint issues a zero-length connection-id, the active_connection_id_limit value it says is ignored, as...
There was a problem hiding this comment.
Here's the situation I'm trying to explain:
Suppose the client (C) uses 0-length CIDs. Since C uses 0-length CIDs, it will never send a NEW_CONNECTION_ID frame. The server (S) can still send an active_connection_id_limit transport param, but C will ignore it because it is irrelevant.
If an endpoint issues a zero-length connection-id, the active_connection_id_limit value it says is ignored, as...
My interpretation of this is that it says if a client (for example) C uses the 0-length CID, the active_connection_id_limit sent by C should be ignored. I believe this is incorrect, as C's active_connection_id_limit is regarding how many NEW_CONNECTION_IDs S can send to C.
There was a problem hiding this comment.
My problem here is the text "uses", which is non-specific. A issues a CID and B sends packets with it. So they both use it.
You're right that my text above is backwards, which seems like an argument in favor of "this is confusing text". How about:
"If an endpoint issues a zero-length connection ID, it will never send NEW_CONNECTION_ID and therefore ignores any active_connection_id limits values it receives"
There was a problem hiding this comment.
I've changed "uses" to "issues" and tightened up the language.
Fixes #3427.