Sequence for Connection IDs, RETIRE #1829
Conversation
MikeBishop
added
design
| @@ -1249,8 +1252,11 @@ using the NEW_CONNECTION_ID frame ({{frame-new-connection-id}}). | |||
| ### Issuing Connection IDs | |||
|
|
|||
| The initial connection ID issued by an endpoint is the Source Connection ID | |||
| during the handshake. Subsequent connection IDs are communicated to the peer | |||
| using NEW_CONNECTION_ID frames ({{frame-new-connection-id}}). | |||
| during the handshake. The sequence number of the initial connection ID is 0. If | |||
There was a problem hiding this comment.
Q: Is it really necessary to allocate IDs to connection IDs during the handshake? To me, it makes more sense to only allocate IDs to those that are post-handshake.
There was a problem hiding this comment.
That would result in complications with non-unique 5-tuples if I understand you correctly.
There was a problem hiding this comment.
I was thinking that the handshake connection IDs exist, but they don't need an identifier?
There was a problem hiding this comment.
Ah, the id of the id, that is different.
There was a problem hiding this comment.
We can avoid that if the entire CID is sent in the RETIRE_CID frame. That would mean, instead, that issuers need to stop using the contained CID for the current connection iff they are and absorb duplicates by silently consuming RETIRE messages for CIDs which aren't associated with the connection.
By having the sequence number in the RETIRE_CID frame, we make it shorter (one varint) and enable using the same deduplicating code as the consumer of NEW_CID messages.
There was a problem hiding this comment.
I like the use of seq num here. It does serve the dedup purpose, and is easier on implementations as well.
There was a problem hiding this comment.
So these are given numbers so they can be retired? If so, that makes sense.
draft-ietf-quic-transport.md
Outdated
| the preferred_address transport parameter is sent, the sequence number of the | ||
| supplied connection ID is 1. Subsequent connection IDs are communicated to the | ||
| peer using NEW_CONNECTION_ID frames ({{frame-new-connection-id}}), and the | ||
| sequence number on each newly-issued connection ID MUST increase by 1. |
There was a problem hiding this comment.
I think this should say something about CIDs on Retry (that they don't really count).
* Add sequence number to NCID frame * Sequence for Connection IDs, RETIRE (#1829) * Connection ID changes * Discuss pre-handshake CIDs * not contains
Suggestions for your PR, as discussed.