From 913370291aa863a847126f7df9f9ab3df7024196 Mon Sep 17 00:00:00 2001 From: ianswett Date: Mon, 8 Jul 2019 21:57:22 -0400 Subject: [PATCH 01/17] Editorial fix for #2479 --- draft-ietf-quic-transport.md | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index da43810b38..4e3b98cc99 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3503,16 +3503,13 @@ Version: DCID Len: -: The byte following the version contains the lengths of the two connection ID - fields that follow it. These lengths are encoded as two 4-bit unsigned - integers. The Destination Connection ID Length (DCIL) field occupies the 4 - high bits of the byte and the Source Connection ID Length (SCIL) field - occupies the 4 low bits of the byte. An encoded length of 0 indicates that - the connection ID is also 0 bytes in length. Non-zero encoded lengths are - increased by 3 to get the full length of the connection ID, producing a length - between 4 and 18 bytes inclusive. For example, a byte with the value 0x50 - describes an 8-byte Destination Connection ID and a zero-length Source - Connection ID. +: The byte following the version contains the length in bytes of the Destination + Connection ID field that follows it. This length is encoded as an 8-bit + unsigned integer. In QUIC version 1, this value MUST NOT exceed 20 bytes. + Endpoints that receive a version 1 long header with a value larger than + 20 MUST drop the packet. Servers SHOULD be able to read longer connection IDs + from other QUIC versions in order to properly form a version negotiation + packet. Destination Connection ID: From b9f6425786a4a347ec926bac02c4b1631e15cdb9 Mon Sep 17 00:00:00 2001 From: ianswett Date: Mon, 8 Jul 2019 22:07:55 -0400 Subject: [PATCH 02/17] Update draft-ietf-quic-invariants.md Fixing invariants as well --- draft-ietf-quic-invariants.md | 27 ++++++++++++--------------- 1 file changed, 12 insertions(+), 15 deletions(-) diff --git a/draft-ietf-quic-invariants.md b/draft-ietf-quic-invariants.md index d7bd020573..58a1a896ee 100644 --- a/draft-ietf-quic-invariants.md +++ b/draft-ietf-quic-invariants.md @@ -161,21 +161,18 @@ All other bits in that byte are version specific. The next four bytes include a 32-bit Version field (see {{version}}). -The next byte contains the length in bytes of the two Connection IDs (see -{{connection-id}}) that follow. Each length is encoded as a 4-bit unsigned -integer. The length of the Destination Connection ID (DCIL) occupies the high -bits of the byte and the length of the Source Connection ID (SCIL) occupies the -low bits of the byte. An encoded length of 0 indicates that the connection ID -is also 0 bytes in length. Non-zero encoded lengths are increased by 3 to get -the full length of the connection ID; the final value is therefore either 0 or -between 4 and 18 bytes in length (inclusive). For example, a byte with the -value 0xe0 describes a 17 byte Destination Connection ID and a zero byte Source -Connection ID. - -The connection ID lengths are followed by two connection IDs. The connection -ID associated with the recipient of the packet (the Destination Connection ID) -is followed by the connection ID associated with the sender of the packet (the -Source Connection ID). +The byte contains the length in bytes of the Destination Connection ID (see +{{connection-id}}) field that follows it. This length is encoded as an 8-bit +unsigned integer. The Destination Connection ID field follows the DCI Len +and is between 0 and 255 bytes in length. + +The byte following the Source Connection ID contains the length in bytes +of the Source Connection ID field that follows it. This length is encoded as +a 8-bit unsigned integer. The Source Connection ID field follows the SCID Len +and is between 0 and 255 bytes in length. + +{{negotiating-connection-ids}} describes the use of the source and destination +connection ID fields in more detail. The remainder of the packet contains version-specific content. From 5601eb00ee1d8b88d10e1a5e9f75c9899d602abf Mon Sep 17 00:00:00 2001 From: ianswett Date: Mon, 8 Jul 2019 22:18:02 -0400 Subject: [PATCH 03/17] Update draft-ietf-quic-invariants.md Co-Authored-By: Martin Thomson --- draft-ietf-quic-invariants.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-invariants.md b/draft-ietf-quic-invariants.md index 58a1a896ee..80d213c452 100644 --- a/draft-ietf-quic-invariants.md +++ b/draft-ietf-quic-invariants.md @@ -163,7 +163,7 @@ The next four bytes include a 32-bit Version field (see {{version}}). The byte contains the length in bytes of the Destination Connection ID (see {{connection-id}}) field that follows it. This length is encoded as an 8-bit -unsigned integer. The Destination Connection ID field follows the DCI Len +unsigned integer. The Destination Connection ID field follows the DCID Len and is between 0 and 255 bytes in length. The byte following the Source Connection ID contains the length in bytes From a8a705e0da6e8009c4b9a902ad0228b0f7b3c181 Mon Sep 17 00:00:00 2001 From: ianswett Date: Mon, 8 Jul 2019 22:18:11 -0400 Subject: [PATCH 04/17] Update draft-ietf-quic-invariants.md Co-Authored-By: Martin Thomson --- draft-ietf-quic-invariants.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-invariants.md b/draft-ietf-quic-invariants.md index 80d213c452..537b88cf24 100644 --- a/draft-ietf-quic-invariants.md +++ b/draft-ietf-quic-invariants.md @@ -164,7 +164,7 @@ The next four bytes include a 32-bit Version field (see {{version}}). The byte contains the length in bytes of the Destination Connection ID (see {{connection-id}}) field that follows it. This length is encoded as an 8-bit unsigned integer. The Destination Connection ID field follows the DCID Len -and is between 0 and 255 bytes in length. +field and is between 0 and 255 bytes in length. The byte following the Source Connection ID contains the length in bytes of the Source Connection ID field that follows it. This length is encoded as From 49e721ae5aa2b3d5c1474cfc8c771721ed12b5fd Mon Sep 17 00:00:00 2001 From: ianswett Date: Mon, 8 Jul 2019 22:18:18 -0400 Subject: [PATCH 05/17] Update draft-ietf-quic-invariants.md Co-Authored-By: Martin Thomson --- draft-ietf-quic-invariants.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-invariants.md b/draft-ietf-quic-invariants.md index 537b88cf24..c5167ae7db 100644 --- a/draft-ietf-quic-invariants.md +++ b/draft-ietf-quic-invariants.md @@ -169,7 +169,7 @@ field and is between 0 and 255 bytes in length. The byte following the Source Connection ID contains the length in bytes of the Source Connection ID field that follows it. This length is encoded as a 8-bit unsigned integer. The Source Connection ID field follows the SCID Len -and is between 0 and 255 bytes in length. +field and is between 0 and 255 bytes in length. {{negotiating-connection-ids}} describes the use of the source and destination connection ID fields in more detail. From 553106c6343f699ea9dabe23df5e1cb06b6795a8 Mon Sep 17 00:00:00 2001 From: ianswett Date: Mon, 8 Jul 2019 22:18:32 -0400 Subject: [PATCH 06/17] Update draft-ietf-quic-transport.md Co-Authored-By: Martin Thomson --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 4e3b98cc99..67262d6118 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3505,7 +3505,7 @@ DCID Len: : The byte following the version contains the length in bytes of the Destination Connection ID field that follows it. This length is encoded as an 8-bit - unsigned integer. In QUIC version 1, this value MUST NOT exceed 20 bytes. + unsigned integer. In QUIC version 1, this value MUST NOT exceed 20. Endpoints that receive a version 1 long header with a value larger than 20 MUST drop the packet. Servers SHOULD be able to read longer connection IDs from other QUIC versions in order to properly form a version negotiation From 4f3e69d0f1a126e7c420a1d5d01efca60f498276 Mon Sep 17 00:00:00 2001 From: ianswett Date: Mon, 8 Jul 2019 22:38:43 -0400 Subject: [PATCH 07/17] Update draft-ietf-quic-invariants.md --- draft-ietf-quic-invariants.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/draft-ietf-quic-invariants.md b/draft-ietf-quic-invariants.md index c5167ae7db..2b94b6eec4 100644 --- a/draft-ietf-quic-invariants.md +++ b/draft-ietf-quic-invariants.md @@ -171,9 +171,6 @@ of the Source Connection ID field that follows it. This length is encoded as a 8-bit unsigned integer. The Source Connection ID field follows the SCID Len field and is between 0 and 255 bytes in length. -{{negotiating-connection-ids}} describes the use of the source and destination -connection ID fields in more detail. - The remainder of the packet contains version-specific content. From b205028bd6b3ee9419725022c96d8a6f72bd5d91 Mon Sep 17 00:00:00 2001 From: martinduke Date: Tue, 9 Jul 2019 07:52:49 -0700 Subject: [PATCH 08/17] fixed typo --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index da43810b38..d5fc38aaf5 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -244,7 +244,7 @@ x (*) ...: # Streams {#streams} Streams in QUIC provide a lightweight, ordered byte-stream abstraction to an -application. Streams can be unidirectional or bidirecational. An alternative +application. Streams can be unidirectional or bidirectional. An alternative view of QUIC unidirectional streams is a "message" abstraction of practically unlimited length. From 4926cf4edf332380b83e48b1a7ee717dfe891f5f Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 10 Jul 2019 08:45:11 +1000 Subject: [PATCH 09/17] Byte lengths are next Co-Authored-By: Jana Iyengar --- draft-ietf-quic-invariants.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-invariants.md b/draft-ietf-quic-invariants.md index 2b94b6eec4..1153c9298c 100644 --- a/draft-ietf-quic-invariants.md +++ b/draft-ietf-quic-invariants.md @@ -161,12 +161,12 @@ All other bits in that byte are version specific. The next four bytes include a 32-bit Version field (see {{version}}). -The byte contains the length in bytes of the Destination Connection ID (see +The next byte contains the length in bytes of the Destination Connection ID (see {{connection-id}}) field that follows it. This length is encoded as an 8-bit unsigned integer. The Destination Connection ID field follows the DCID Len field and is between 0 and 255 bytes in length. -The byte following the Source Connection ID contains the length in bytes +The next byte contains the length in bytes of the Source Connection ID field that follows it. This length is encoded as a 8-bit unsigned integer. The Source Connection ID field follows the SCID Len field and is between 0 and 255 bytes in length. From 212169ad443ebd496c4b0452fefd1223d5c9c13d Mon Sep 17 00:00:00 2001 From: Dmitri Tikhonov Date: Thu, 11 Jul 2019 19:32:36 -0400 Subject: [PATCH 10/17] qpack: fix reference to blocked-streams section --- draft-ietf-quic-qpack.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-qpack.md b/draft-ietf-quic-qpack.md index 81587ffdc9..daa77f930b 100644 --- a/draft-ietf-quic-qpack.md +++ b/draft-ietf-quic-qpack.md @@ -321,7 +321,7 @@ decoder has started reading from the stream. When processing header blocks, the decoder expects the Required Insert Count to -exactly match the value defined in {{blocked-streams}. If it encounters a +exactly match the value defined in {{blocked-streams}}. If it encounters a smaller value than expected, it MUST treat this as a connection error of type HTTP_QPACK_DECOMPRESSION_FAILED (see {{invalid-references}}). If it encounters a larger value than expected, it MAY treat this as a connection error of type From cb6828672ebbb3288be99155ae151ed243723421 Mon Sep 17 00:00:00 2001 From: ianswett Date: Mon, 15 Jul 2019 23:00:02 -0400 Subject: [PATCH 11/17] Merge Crypto timeout and PTO (#2806) * Update draft-ietf-quic-recovery.md * Update draft-ietf-quic-recovery.md * Update draft-ietf-quic-recovery.md * Update draft-ietf-quic-recovery.md Co-Authored-By: Matt Olson * Update draft-ietf-quic-recovery.md Co-Authored-By: Matt Olson * Update draft-ietf-quic-recovery.md * Remove crypto timer from the pseudocode * Update draft-ietf-quic-recovery.md * Update draft-ietf-quic-recovery.md * Update draft-ietf-quic-recovery.md * Update draft-ietf-quic-recovery.md * Update draft-ietf-quic-recovery.md * Update draft-ietf-quic-recovery.md Co-Authored-By: Martin Thomson * Update draft-ietf-quic-recovery.md Fix pseudocode indent * Update draft-ietf-quic-recovery.md * Changed to MUST * Update draft-ietf-quic-recovery.md * Update draft-ietf-quic-recovery.md * Update draft-ietf-quic-recovery.md * Update draft-ietf-quic-recovery.md * Update draft-ietf-quic-recovery.md * Update draft-ietf-quic-recovery.md * Ryan's suggestion --- draft-ietf-quic-recovery.md | 187 +++++++++++++----------------------- 1 file changed, 68 insertions(+), 119 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index faad864b77..c4b885293d 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -165,7 +165,7 @@ of frames contained in a packet affect recovery and congestion control logic: * Long header packets that contain CRYPTO frames are critical to the performance of the QUIC handshake and use shorter timers for - acknowledgement and retransmission. + acknowledgement. * Packets that contain only ACK frames do not count toward congestion control limits and are not considered in-flight. @@ -512,76 +512,14 @@ thresholds reduce reordering resilience and increase spurious retransmissions, and larger thresholds increase loss detection delay. -## Crypto Retransmission Timeout - -Data in CRYPTO frames is critical to QUIC transport and crypto negotiation, so a -more aggressive timeout is used to retransmit it. - -The initial crypto retransmission timeout SHOULD be set to twice the initial -RTT. - -At the beginning, there are no prior RTT samples within a connection. Resumed -connections over the same network SHOULD use the previous connection's final -smoothed RTT value as the resumed connection's initial RTT. If no previous RTT -is available, or if the network changes, the initial RTT SHOULD be set to 500ms, -resulting in a 1 second initial handshake timeout as recommended in -{{?RFC6298}}. - -A connection MAY use the delay between sending a PATH_CHALLENGE and receiving -a PATH_RESPONSE to seed initial_rtt for a new path, but the delay SHOULD NOT -be considered an RTT sample. - -When a crypto packet is sent, the sender MUST set a timer for twice the smoothed -RTT. This timer MUST be updated when a new crypto packet is sent and when -an acknowledgement is received which computes a new RTT sample. Upon timeout, -the sender MUST retransmit all unacknowledged CRYPTO data if possible. The -sender MUST NOT declare in-flight crypto packets as lost when the crypto timer -expires. - -On each consecutive expiration of the crypto timer without receiving an -acknowledgement for a new packet, the sender MUST double the crypto -retransmission timeout and set a timer for this period. - -Until the server has validated the client's address on the path, the amount of -data it can send is limited, as specified in Section 8.1 of {{QUIC-TRANSPORT}}. -If not all unacknowledged CRYPTO data can be sent, then all unacknowledged -CRYPTO data sent in Initial packets should be retransmitted. If no data can be -sent, then no alarm should be armed until data has been received from the -client. - -Because the server could be blocked until more packets are received, the client -MUST ensure that the crypto retransmission timer is set if there is -unacknowledged crypto data or if the client does not yet have 1-RTT keys. -If the crypto retransmission timer expires before the client has 1-RTT keys, -it is possible that the client may not have any crypto data to retransmit. -However, the client MUST send a new packet, containing only PADDING frames if -necessary, to allow the server to continue sending data. If Handshake keys -are available to the client, it MUST send a Handshake packet, and otherwise -it MUST send an Initial packet in a UDP datagram of at least 1200 bytes. - -Because packets only containing PADDING do not elicit an acknowledgement, -they may never be acknowledged, but they are removed from bytes in flight -when the client gets Handshake keys and the Initial keys are discarded. - -The crypto retransmission timer is not set if the time threshold -{{time-threshold}} loss detection timer is set. The time threshold loss -detection timer is expected to both expire earlier than the crypto -retransmission timeout and be less likely to spuriously retransmit data. -The Initial and Handshake packet number spaces will typically contain a small -number of packets, so losses are less likely to be detected using -packet-threshold loss detection. - -When the crypto retransmission timer is active, the probe timer ({{pto}}) -is not active. - - ## Probe Timeout {#pto} -A Probe Timeout (PTO) triggers a probe packet when ack-eliciting data is in -flight but an acknowledgement is not received within the expected period of -time. A PTO enables a connection to recover from loss of tail packets or acks. -The PTO algorithm used in QUIC implements the reliability functions of Tail Loss -Probe {{?TLP=I-D.dukkipati-tcpm-tcp-loss-probe}} {{?RACK}}, RTO {{?RFC5681}} and +A Probe Timeout (PTO) triggers sending one or two probe packets when +ack-eliciting packets are not acknowledged within the expected period of +time or the handshake has not been completed. A PTO enables a connection to +recover from loss of tail packets or acks. The PTO algorithm used in QUIC +implements the reliability functions of Tail Loss Probe +{{?TLP=I-D.dukkipati-tcpm-tcp-loss-probe}} {{?RACK}}, RTO {{?RFC5681}} and F-RTO algorithms for TCP {{?RFC5682}}, and the timeout computation is based on TCP's retransmission timeout period {{?RFC6298}}. @@ -606,16 +544,56 @@ delay sending an acknowledgement. The PTO value MUST be set to at least kGranularity, to avoid the timer expiring immediately. -When a PTO timer expires, the sender probes the network as described in the next -section. The PTO period MUST be set to twice its current value. This exponential -reduction in the sender's rate is important because the PTOs might be caused by -loss of packets or acknowledgements due to severe congestion. +When a PTO timer expires, the PTO period MUST be set to twice its current +value. This exponential reduction in the sender's rate is important because +the PTOs might be caused by loss of packets or acknowledgements due to severe +congestion. The life of a connection that is experiencing consecutive PTOs is +limited by the endpoint's idle timeout. A sender computes its PTO timer every time an ack-eliciting packet is sent. A sender might choose to optimize this by setting the timer fewer times if it knows that more ack-eliciting packets will be sent within a short period of time. +The probe timer is not set if the time threshold {{time-threshold}} loss +detection timer is set. The time threshold loss detection timer is expected +to both expire earlier than the PTO and be less likely to spuriously retransmit +data. + +## Handshakes and New Paths + +The initial probe timeout for a new connection or new path SHOULD be +set to twice the initial RTT. Resumed connections over the same network +SHOULD use the previous connection's final smoothed RTT value as the resumed +connection's initial RTT. If no previous RTT is available, the initial RTT +SHOULD be set to 500ms, resulting in a 1 second initial timeout as recommended +in {{?RFC6298}}. + +A connection MAY use the delay between sending a PATH_CHALLENGE and receiving +a PATH_RESPONSE to seed initial_rtt for a new path, but the delay SHOULD NOT +be considered an RTT sample. + +Until the server has validated the client's address on the path, the amount of +data it can send is limited, as specified in Section 8.1 of {{QUIC-TRANSPORT}}. +Data at Initial encryption MUST be retransmitted before Handshake data and +data at Handshake encryption MUST be retransmitted before any ApplicationData +data. If no data can be sent, then the PTO alarm MUST NOT be armed until +data has been received from the client. + +Because the server could be blocked until more packets are received, the client +MUST ensure that the retransmission timer is set if the client does not yet +have 1-RTT keys. If the probe timer expires before the client has 1-RTT keys, +it is possible that the client may not have any crypto data to retransmit. +However, the client MUST send a new packet, containing only PADDING frames if +necessary, to allow the server to continue sending data. If Handshake keys +are available to the client, it MUST send a Handshake packet, and otherwise +it MUST send an Initial packet in a UDP datagram of at least 1200 bytes. + +Because Initial packets containing only PADDING do not elicit an +acknowledgement, they may never be acknowledged, but they are removed from +bytes in flight when the client gets Handshake keys and the Initial keys are +discarded. + ### Sending Probe Packets When a PTO timer expires, a sender MUST send at least one ack-eliciting packet @@ -956,12 +934,6 @@ in_flight: : A boolean that indicates whether the packet counts towards bytes in flight. -is_crypto_packet: -: A boolean that indicates whether the packet contains - cryptographic handshake messages critical to the completion of the QUIC - handshake. In this version of QUIC, this includes any packet with the long - header that includes a CRYPTO frame. - sent_bytes: : The number of bytes sent in the packet, not including UDP or IP overhead, but including QUIC framing overhead. @@ -1013,19 +985,12 @@ are described in this section. loss_detection_timer: : Multi-modal timer used for loss detection. -crypto_count: -: The number of times all unacknowledged CRYPTO data has been - retransmitted without receiving an ack. - pto_count: : The number of times a PTO has been sent without receiving an ack. time_of_last_sent_ack_eliciting_packet: : The time the most recent ack-eliciting packet was sent. -time_of_last_sent_crypto_packet: -: The time the most recent crypto packet was sent. - largest_acked_packet\[kPacketNumberSpace]: : The largest packet number acknowledged in the packet number space so far. @@ -1065,7 +1030,6 @@ follows: ~~~ loss_detection_timer.reset() - crypto_count = 0 pto_count = 0 latest_rtt = 0 smoothed_rtt = 0 @@ -1073,7 +1037,6 @@ follows: min_rtt = 0 max_ack_delay = 0 time_of_last_sent_ack_eliciting_packet = 0 - time_of_last_sent_crypto_packet = 0 for pn_space in [ Initial, Handshake, ApplicationData ]: largest_acked_packet[pn_space] = infinite loss_time[pn_space] = 0 @@ -1089,7 +1052,7 @@ Pseudocode for OnPacketSent follows: ~~~ OnPacketSent(packet_number, pn_space, ack_eliciting, - in_flight, is_crypto_packet, sent_bytes): + in_flight, sent_bytes): sent_packets[pn_space][packet_number].packet_number = packet_number sent_packets[pn_space][packet_number].time_sent = now @@ -1097,8 +1060,6 @@ Pseudocode for OnPacketSent follows: ack_eliciting sent_packets[pn_space][packet_number].in_flight = in_flight if (in_flight): - if (is_crypto_packet): - time_of_last_sent_crypto_packet = now if (ack_eliciting): time_of_last_sent_ack_eliciting_packet = now OnPacketSentCC(sent_bytes) @@ -1146,7 +1107,6 @@ OnAckReceived(ack, pn_space): DetectLostPackets(pn_space) - crypto_count = 0 pto_count = 0 SetLossDetectionTimer() @@ -1227,25 +1187,18 @@ SetLossDetectionTimer(): loss_detection_timer.update(loss_time) return - if (has unacknowledged crypto data - || endpoint is client without 1-RTT keys): - // Crypto retransmission timer. - if (smoothed_rtt == 0): - timeout = 2 * kInitialRtt - else: - timeout = 2 * smoothed_rtt - timeout = max(timeout, kGranularity) - timeout = timeout * (2 ^ crypto_count) - loss_detection_timer.update( - time_of_last_sent_crypto_packet + timeout) - return - // Don't arm timer if there are no ack-eliciting packets - // in flight. - if (no ack-eliciting packets in flight): + // in flight and the handshake is complete. + if (endpoint is client with 1-RTT keys && + no ack-eliciting packets in flight): loss_detection_timer.cancel() return + // Use a default timeout if ther are no RTT measurements + if (smoothed_rtt == 0): + timeout = 2 * kInitialRtt + return + // Calculate PTO duration timeout = smoothed_rtt + max(4 * rttvar, kGranularity) + max_ack_delay @@ -1269,27 +1222,23 @@ OnLossDetectionTimeout(): if (loss_time != 0): // Time threshold loss Detection DetectLostPackets(pn_space) - // Retransmit crypto data if no packets were lost - // and there is crypto data to retransmit. - else if (has unacknowledged crypto data): - // Crypto retransmission timeout. - RetransmitUnackedCryptoData() - crypto_count++ - else if (endpoint is client without 1-RTT keys): + SetLossDetectionTimer() + return + + if (endpoint is client without 1-RTT keys): // Client sends an anti-deadlock packet: Initial is padded // to earn more anti-amplification credit, // a Handshake packet proves address ownership. if (has Handshake keys): - SendOneHandshakePacket() - else: - SendOnePaddedInitialPacket() - crypto_count++ + SendOneHandshakePacket() + else: + SendOnePaddedInitialPacket() else: // PTO. Send new data if available, else retransmit old data. // If neither is available, send a single PING frame. SendOneOrTwoPackets() - pto_count++ + pto_count++ SetLossDetectionTimer() ~~~ From 8006456f147c1ea32e80cc65fb33b04bf955ec00 Mon Sep 17 00:00:00 2001 From: tandf Date: Tue, 16 Jul 2019 14:17:23 +0800 Subject: [PATCH 12/17] Fix typo --- draft-ietf-quic-tls.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index df4be04f69..4cca126a9e 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1246,7 +1246,7 @@ messages, that tampering will cause the TLS handshake to fail. QUIC uses the TLS handshake for more than just negotiation of cryptographic parameters. The TLS handshake validates protocol version selection, provides preliminary values for QUIC transport parameters, and allows a server to perform -return routeability checks on clients. +return routability checks on clients. ## Protocol Negotiation {#protocol-negotiation} From d090d4d796abf702f7246c06cbae1011342c360f Mon Sep 17 00:00:00 2001 From: lucas Date: Mon, 1 Jul 2019 15:44:41 +0100 Subject: [PATCH 13/17] Don't state QUIC error codes. --- draft-ietf-quic-http.md | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 4a03b093f9..cf57c3ea80 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -2184,15 +2184,13 @@ INTERNAL_ERROR (0x2): : HTTP_INTERNAL_ERROR in {{http-error-codes}}. FLOW_CONTROL_ERROR (0x3): -: Not applicable, since QUIC handles flow control. Would provoke a - QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA from the QUIC layer. +: Not applicable, since QUIC handles flow control. SETTINGS_TIMEOUT (0x4): : Not applicable, since no acknowledgement of SETTINGS is defined. STREAM_CLOSED (0x5): -: Not applicable, since QUIC handles stream management. Would provoke a - QUIC_STREAM_DATA_AFTER_TERMINATION from the QUIC layer. +: Not applicable, since QUIC handles stream management. FRAME_SIZE_ERROR (0x6): : HTTP_MALFORMED_FRAME error codes defined in {{http-error-codes}}. @@ -2200,8 +2198,7 @@ FRAME_SIZE_ERROR (0x6): REFUSED_STREAM (0x7): : HTTP_REQUEST_REJECTED (in {{http-error-codes}}) is used to indicate that a request was not processed. Otherwise, not applicable because QUIC handles - stream management. A STREAM_ID_ERROR at the QUIC layer is used for streams - that are improperly opened. + stream management. CANCEL (0x8): : HTTP_REQUEST_CANCELLED in {{http-error-codes}}. From d432cd6f844cabbce899e21ed2e177dc0815bba0 Mon Sep 17 00:00:00 2001 From: ianswett Date: Wed, 17 Jul 2019 09:13:25 -0400 Subject: [PATCH 14/17] Fix lack of exponential backoff in pseudocode (#2902) * Fix lack of exponential backoff in pseudocode When there is no smoothed_rtt, PR #2806 inadvertently removed the exponential backoff from the pseudocode. * Update draft-ietf-quic-recovery.md * Update draft-ietf-quic-recovery.md --- draft-ietf-quic-recovery.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index c4b885293d..fc55bb4f33 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -1194,14 +1194,13 @@ SetLossDetectionTimer(): loss_detection_timer.cancel() return - // Use a default timeout if ther are no RTT measurements + // Use a default timeout if there are no RTT measurements if (smoothed_rtt == 0): timeout = 2 * kInitialRtt - return - - // Calculate PTO duration - timeout = - smoothed_rtt + max(4 * rttvar, kGranularity) + max_ack_delay + else: + // Calculate PTO duration + timeout = smoothed_rtt + max(4 * rttvar, kGranularity) + + max_ack_delay timeout = timeout * (2 ^ pto_count) loss_detection_timer.update( From c56d843044ed537a53487411438e2638bec1a46a Mon Sep 17 00:00:00 2001 From: lucas Date: Mon, 1 Jul 2019 12:23:06 +0100 Subject: [PATCH 15/17] Fix HPACK xref --- draft-ietf-quic-http.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index cf57c3ea80..bd1f2ab4bf 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -155,7 +155,7 @@ potential latency gain. Several HTTP/3 frames are used to manage server push, such as PUSH_PROMISE, DUPLICATE_PUSH, MAX_PUSH_ID, and CANCEL_PUSH. As in HTTP/2, request and response headers are compressed for transmission. -Because HPACK {{?HPACK=RFC7231}} relies on in-order transmission of compressed +Because HPACK {{?HPACK=RFC7541}} relies on in-order transmission of compressed header blocks (a guarantee not provided by QUIC), HTTP/3 replaces HPACK with QPACK [QPACK]. QPACK uses separate unidirectional streams to modify and track header table state, while header blocks refer to the state of the table without From bf59b827aeab949b66e62173dd6ec0f3c7d3d068 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 17 Jul 2019 10:04:44 -0400 Subject: [PATCH 16/17] Add one to sample offset for header protection With the changes to invariants, this calculation was off by one. Closes #2899. --- draft-ietf-quic-tls.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index df4be04f69..983e99d8c7 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1001,7 +1001,7 @@ QUIC packets might be included in the same UDP datagram and that each one is handled separately. ~~~ -sample_offset = 6 + len(destination_connection_id) + +sample_offset = 7 + len(destination_connection_id) + len(source_connection_id) + len(payload_length) + 4 if packet_type == Initial: From 94e02c1f34af486b0ef3cce6530ee1609da754b5 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Sat, 20 Jul 2019 15:11:44 -0400 Subject: [PATCH 17/17] Typo in change log --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index cb3f8c522d..6af192effc 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -5779,7 +5779,7 @@ Issue and pull request numbers are listed with a leading octothorp. - Allow reuse of stateless reset tokens (#2732, #2733) - Allow, but not require, enforcing non-duplicate transport parameters (#2689, #2691) -- Added a active_connection_id_limit transport parameter (#1994, #1998) +- Added an active_connection_id_limit transport parameter (#1994, #1998) - max_ack_delay transport parameter defaults to 0 (#2638, #2646) - When sending 0-RTT, only remembered transport parameters apply (#2458, #2360, #2466, #2461)