From 6bbfbdfff1303446ab251e038bcb8720ec99e408 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 19 Oct 2018 14:18:51 +1100 Subject: [PATCH 1/3] Consolidate connection ID negotiation section with prior text The text here was mostly good, and I believe that this is a good place for that text. However, some of the text was expository in nature, and I moved that up to the connection ID definition section. There is some new stuff in there, mostly just to point forward to the negotiation section. --- draft-ietf-quic-transport.md | 44 ++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 24 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 1cb2d8e37c..c8da2d695e 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -926,6 +926,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 at least two connection IDs, which are used to +establish the connection IDs that are used for the connection when established, +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 +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. + +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 @@ -938,7 +955,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 @@ -1440,8 +1457,6 @@ Handshake[0]: CRYPTO[FIN], ACK[0] ## Negotiating Connection IDs {#negotiating-connection-ids} - - 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 @@ -1486,27 +1501,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} @@ -4380,7 +4376,7 @@ Length: Sequence Number: : The sequence number assigned to the connection ID by the sender. See - {{issuing-connection-ids}}. + {{issue-cid}}. Connection ID: From e56b38a33a1bc4a6c75f9631b40ab857235a64ab Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 22 Oct 2018 09:42:10 +1100 Subject: [PATCH 2/3] Reword based on feedback --- draft-ietf-quic-transport.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index c8da2d695e..d8edbed045 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -927,16 +927,16 @@ this means the same connection ID MUST NOT be issued more than once on the same connection. Packets with long headers include at least two connection IDs, which are used to -establish the connection IDs that are used for the connection when established, +determine the connection IDs that are used for the connection when established, 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 -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. +Connection ID field is expected to be known to endpoints. Endpoints that use a +load balancer that routes based on connection ID 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. A Version Negotiation ({{packet-version}}) packet echoes the connection IDs selected by the client, both to ensure correct routing toward the client and to From d20f5b542ed3374310df3d824453dfb2484e1816 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 23 Oct 2018 16:11:05 +1100 Subject: [PATCH 3/3] My ideas for corrections, taking feedback into account --- draft-ietf-quic-transport.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index d8edbed045..6f53c9973d 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -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, @@ -926,16 +927,16 @@ 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 at least two connection IDs, which are used to -determine the connection IDs that are used for the connection when established, -see {{negotiating-connection-ids}} for details. +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 that use a +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 -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 +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