Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Consolidate connection ID negotiation section with prior text #1888

Merged
merged 3 commits into from Oct 23, 2018
Merged

Consolidate connection ID negotiation section with prior text #1888

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
6bbfbdf
Consolidate connection ID negotiation section with prior text
martinthomson Oct 19, 2018
e56b38a
Reword based on feedback
martinthomson Oct 21, 2018
d20f5b5
My ideas for corrections, taking feedback into account
martinthomson Oct 23, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
45 changes: 21 additions & 24 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -907,6 +907,7 @@ different IP or port at either endpoint as
described in {{migration}}. Finally, a connection may be terminated by either
endpoint, as described in {{termination}}.


## Connection ID {#connection-id}

Each connection possesses a set of connection identifiers, or connection IDs,
Expand All @@ -926,6 +927,23 @@ them with other connection IDs for the same connection. As a trivial example,
this means the same connection ID MUST NOT be issued more than once on the same
connection.

Packets with long headers include Source Connection ID and Destination
Connection ID fields. These fields are used to set the connection IDs for new
connections, see {{negotiating-connection-ids}} for details.

Packets with short headers ({{short-header}}) only include the Destination
Connection ID and omit the explicit length. The length of the Destination
Connection ID field is expected to be known to endpoints. Endpoints using a
load balancer that routes based on connection ID could agree with the load
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Run on sentence ("that ... that"). I prefer the earlier construction: "Endpoints using a connection-ID based load balancer could agree with the load balancer on a fixed or minimum length and on an encoding for connection IDs."

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It has all the problems already highlighted, plus the precedence of the "or" and "and" toward the end is unclear. I've tweaked again.

balancer on a fixed length for connection IDs, or agree on an encoding scheme.
A fixed portion could encode an explicit length, which allows the entire
connection ID to vary in length and still be used by the load balancer.

A Version Negotiation ({{packet-version}}) packet echoes the connection IDs
selected by the client, both to ensure correct routing toward the client and to
allow the client to validate that the packet is in response to an Initial
packet.

A zero-length connection ID MAY be used when the connection ID is not needed for
routing and the address/port tuple of packets is sufficient to identify a
connection. An endpoint whose peer has selected a zero-length connection ID MUST
Expand All @@ -938,7 +956,7 @@ packets sent to the endpoint. These connection IDs are supplied by the endpoint
using the NEW_CONNECTION_ID frame ({{frame-new-connection-id}}).


### Issuing Connection IDs
### Issuing Connection IDs {#issue-cid}

Each Connection ID has an associated sequence number to assist in deduplicating
messages. The initial connection ID issued by an endpoint is sent in the Source
Expand Down Expand Up @@ -1440,8 +1458,6 @@ Handshake[0]: CRYPTO[FIN], ACK[0]

## Negotiating Connection IDs {#negotiating-connection-ids}

<!-- TODO: Check if this section belongs here or in Connection IDs above. -->

A connection ID is used to ensure consistent routing of packets, as described in
{{connection-id}}. The long header contains two connection IDs: the Destination
Connection ID is chosen by the recipient of the packet and is used to provide
Expand Down Expand Up @@ -1486,27 +1502,8 @@ include a different Source Connection ID, they MUST be discarded. This avoids
problems that might arise from stateless processing of multiple Initial packets
producing different connection IDs.

Packets with short headers ({{short-header}}) only include the Destination
Connection ID and omit the explicit length. The length of the Destination
Connection ID field is expected to be known to endpoints.

Endpoints using a connection-ID based load balancer could agree with the load
balancer on a fixed or minimum length and on an encoding for connection IDs.
This fixed portion could encode an explicit length, which allows the entire
connection ID to vary in length and still be used by the load balancer.

The very first packet sent by a client includes a random value for Destination
Connection ID. The same value MUST be used for all 0-RTT packets sent on that
connection ({{packet-protected}}). This randomized value is used to determine
the packet protection keys for Initial packets (see Section 5.2 of
{{QUIC-TLS}}).

A Version Negotiation ({{packet-version}}) packet MUST use both connection IDs
selected by the client, swapped to ensure correct routing toward the client.

The connection ID can change over the lifetime of a connection, especially in
response to connection migration ({{migration}}). NEW_CONNECTION_ID frames
({{frame-new-connection-id}}) are used to provide new connection ID values.
response to connection migration ({{migration}}), see {{issue-cid}} for details.


## Transport Parameters {#transport-parameters}
Expand Down Expand Up @@ -4380,7 +4377,7 @@ Length:
Sequence Number:

: The sequence number assigned to the connection ID by the sender. See
{{issuing-connection-ids}}.
{{issue-cid}}.

Connection ID:

Expand Down