From f51a23e2890da2a8558cee32b4375f99a7070965 Mon Sep 17 00:00:00 2001 From: ianswett Date: Sun, 6 Oct 2019 21:14:42 -0400 Subject: [PATCH 01/21] Retransmit server initial upon second Initial When the second duplicate client Initial is received, the server SHOULD retransmit the contents of it's Initial to speed up the handshake. --- draft-ietf-quic-recovery.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index a90cad46ad..8cda7ec51f 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -508,6 +508,11 @@ until it is certain that the server has finished its address validation probe timer if the client has not received an acknowledgement for one of its Handshake or 1-RTT packets. +When a server receives a second Initial packet after sending its first Initial +packet, it can assume the client did not receive it's Initial packet. To speed +handshake completion, it SHOULD retransmit the contents of its Initial packet. +After doing so, the PTO is re-armed. + Prior to handshake completion, when few to none RTT samples have been generated, it is possible that the probe timer expiration is due to an incorrect RTT estimate at the client. To allow the client to improve its RTT From 2e7bff7670dfde7068be546704bd33b5f74e0f7a Mon Sep 17 00:00:00 2001 From: ianswett Date: Sun, 6 Oct 2019 23:49:34 -0400 Subject: [PATCH 02/21] Update draft-ietf-quic-recovery.md --- draft-ietf-quic-recovery.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 8cda7ec51f..52a2ae7725 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -508,10 +508,11 @@ until it is certain that the server has finished its address validation probe timer if the client has not received an acknowledgement for one of its Handshake or 1-RTT packets. -When a server receives a second Initial packet after sending its first Initial -packet, it can assume the client did not receive it's Initial packet. To speed -handshake completion, it SHOULD retransmit the contents of its Initial packet. -After doing so, the PTO is re-armed. +When a server receives duplicate CRYPTO data in an Initial packet after sending +its Initial flight, it can assume the client did not receive all Initial CRYPTO +data. To speed handshake completion, it SHOULD retransmit all unacknowledged +Initial data subject to the path validation limits. After doing so, +the PTO is re-armed. Prior to handshake completion, when few to none RTT samples have been generated, it is possible that the probe timer expiration is due to an From 18c9bba3487c51d85f4797eb8dc4215ebbb728f3 Mon Sep 17 00:00:00 2001 From: ianswett Date: Mon, 7 Oct 2019 00:01:38 -0400 Subject: [PATCH 03/21] Update draft-ietf-quic-recovery.md --- draft-ietf-quic-recovery.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 52a2ae7725..91faa7ed5c 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -511,7 +511,7 @@ Handshake or 1-RTT packets. When a server receives duplicate CRYPTO data in an Initial packet after sending its Initial flight, it can assume the client did not receive all Initial CRYPTO data. To speed handshake completion, it SHOULD retransmit all unacknowledged -Initial data subject to the path validation limits. After doing so, +Initial CRYPTO data subject to the path validation limits. After doing so, the PTO is re-armed. Prior to handshake completion, when few to none RTT samples have been From ebb854354ccdc67a64e7e124f8af9c9ac52ba238 Mon Sep 17 00:00:00 2001 From: ianswett Date: Fri, 11 Oct 2019 16:50:57 -0400 Subject: [PATCH 04/21] Reword the paragraph --- draft-ietf-quic-recovery.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 91faa7ed5c..c0f3eaacbe 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -508,11 +508,11 @@ until it is certain that the server has finished its address validation probe timer if the client has not received an acknowledgement for one of its Handshake or 1-RTT packets. -When a server receives duplicate CRYPTO data in an Initial packet after sending -its Initial flight, it can assume the client did not receive all Initial CRYPTO -data. To speed handshake completion, it SHOULD retransmit all unacknowledged -Initial CRYPTO data subject to the path validation limits. After doing so, -the PTO is re-armed. +When a server receives duplicate Initial CRYPTO data when there +is unacknoweledged Initial CRYPTO data, it can assume the client did not +receive all Initial CRYPTO data or the client's estimated RTT is too short. +To speed handshake completion, it MAY retransmit unacknowledged Initial +CRYPTO data subject to the path validation limits, as though the PTO expired. Prior to handshake completion, when few to none RTT samples have been generated, it is possible that the probe timer expiration is due to an From 20435cf19a7461bf050033a0b04aa452afcde980 Mon Sep 17 00:00:00 2001 From: ianswett Date: Tue, 22 Oct 2019 18:42:43 -0400 Subject: [PATCH 05/21] Update draft-ietf-quic-recovery.md Co-Authored-By: Martin Thomson --- draft-ietf-quic-recovery.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index c0f3eaacbe..5b1cf43a9f 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -509,7 +509,7 @@ probe timer if the client has not received an acknowledgement for one of its Handshake or 1-RTT packets. When a server receives duplicate Initial CRYPTO data when there -is unacknoweledged Initial CRYPTO data, it can assume the client did not +is unacknowledged Initial CRYPTO data, it can assume the client did not receive all Initial CRYPTO data or the client's estimated RTT is too short. To speed handshake completion, it MAY retransmit unacknowledged Initial CRYPTO data subject to the path validation limits, as though the PTO expired. From 02080b75875107b2d0b6a17b9a7b304c714f0502 Mon Sep 17 00:00:00 2001 From: ianswett Date: Tue, 22 Oct 2019 18:59:31 -0400 Subject: [PATCH 06/21] Update based on interim feedback --- draft-ietf-quic-recovery.md | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 5b1cf43a9f..ed08e2e88b 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -508,12 +508,6 @@ until it is certain that the server has finished its address validation probe timer if the client has not received an acknowledgement for one of its Handshake or 1-RTT packets. -When a server receives duplicate Initial CRYPTO data when there -is unacknowledged Initial CRYPTO data, it can assume the client did not -receive all Initial CRYPTO data or the client's estimated RTT is too short. -To speed handshake completion, it MAY retransmit unacknowledged Initial -CRYPTO data subject to the path validation limits, as though the PTO expired. - Prior to handshake completion, when few to none RTT samples have been generated, it is possible that the probe timer expiration is due to an incorrect RTT estimate at the client. To allow the client to improve its RTT @@ -525,6 +519,22 @@ bytes. Initial packets and Handshake packets may never be acknowledged, but they are removed from bytes in flight when the Initial and Handshake keys are discarded. +### Speeding Handshake Completion + +When a server receives duplicate Initial CRYPTO data, it can assume the client +did not receive all Initial CRYPTO data or the client's estimated RTT is too +small. When a client receives undecryptable packets it may assume the server's +Initial was lost. + +To speed handshake completion, either peer MAY send a packet containing unacknowledged +Initial CRYPTO data subject to the path validation limits, as though the PTO +expired. A client may send a retransmittable packet if all Initial data has been +acknowledged. The PTO may only be shortened once in this way. Subsequently the PTO +uses the normal calculation with exponential backoff. + +Peers can also use coalesced packets to ensure each datagram elicits at least one +acknowledgement. + ### Sending Probe Packets When a PTO timer expires, a sender MUST send at least one ack-eliciting packet From f1c94bf510b5e06ec4c739241bce996bc03037dd Mon Sep 17 00:00:00 2001 From: ianswett Date: Tue, 22 Oct 2019 19:01:47 -0400 Subject: [PATCH 07/21] Update draft-ietf-quic-recovery.md --- draft-ietf-quic-recovery.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index ed08e2e88b..7f346b10ec 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -528,9 +528,9 @@ Initial was lost. To speed handshake completion, either peer MAY send a packet containing unacknowledged Initial CRYPTO data subject to the path validation limits, as though the PTO -expired. A client may send a retransmittable packet if all Initial data has been -acknowledged. The PTO may only be shortened once in this way. Subsequently the PTO -uses the normal calculation with exponential backoff. +expired. A client may send an ack-eliciting packet with no CRYPTO data if all Initial +data has been acknowledged. The PTO may only be shortened once in this way. +Subsequently the PTO uses the normal calculation with exponential backoff. Peers can also use coalesced packets to ensure each datagram elicits at least one acknowledgement. From 40cc163f42b57fb5ec514174e6173e38475359fc Mon Sep 17 00:00:00 2001 From: ianswett Date: Wed, 23 Oct 2019 22:22:37 -0400 Subject: [PATCH 08/21] line lengths --- draft-ietf-quic-recovery.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 7f346b10ec..7ab663c282 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -526,14 +526,15 @@ did not receive all Initial CRYPTO data or the client's estimated RTT is too small. When a client receives undecryptable packets it may assume the server's Initial was lost. -To speed handshake completion, either peer MAY send a packet containing unacknowledged -Initial CRYPTO data subject to the path validation limits, as though the PTO -expired. A client may send an ack-eliciting packet with no CRYPTO data if all Initial -data has been acknowledged. The PTO may only be shortened once in this way. -Subsequently the PTO uses the normal calculation with exponential backoff. - -Peers can also use coalesced packets to ensure each datagram elicits at least one -acknowledgement. +To speed handshake completion, either peer MAY send a packet containing +unacknowledged Initial CRYPTO data subject to the path validation limits, as +though the PTO expired. A client may send an ack-eliciting packet with no +CRYPTO data if all Initial data has been acknowledged. The PTO may only be +shortened once in this way. Subsequently the PTO uses the normal calculation +with exponential backoff. + +Peers can also use coalesced packets to ensure each datagram elicits at least +one acknowledgement. ### Sending Probe Packets From b9c84234ab1e9c6c1fbc61e181885491612d87d1 Mon Sep 17 00:00:00 2001 From: ianswett Date: Wed, 23 Oct 2019 22:25:57 -0400 Subject: [PATCH 09/21] Update draft-ietf-quic-recovery.md --- draft-ietf-quic-recovery.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 7ab663c282..a759321040 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -534,7 +534,10 @@ shortened once in this way. Subsequently the PTO uses the normal calculation with exponential backoff. Peers can also use coalesced packets to ensure each datagram elicits at least -one acknowledgement. +one acknowledgement. For example, clients can coalesce an Initial packet +containing a PING and PADDING with 0-RTT data packets and a server can +coalesce an Initial packet containing a PING with one or more packets in +it's first flight. ### Sending Probe Packets From 6851dbb3bfed9d4695abfd798a790addaaaa5775 Mon Sep 17 00:00:00 2001 From: ianswett Date: Wed, 23 Oct 2019 22:26:36 -0400 Subject: [PATCH 10/21] Update draft-ietf-quic-recovery.md --- draft-ietf-quic-recovery.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index a759321040..a7824b6a1a 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -537,7 +537,7 @@ Peers can also use coalesced packets to ensure each datagram elicits at least one acknowledgement. For example, clients can coalesce an Initial packet containing a PING and PADDING with 0-RTT data packets and a server can coalesce an Initial packet containing a PING with one or more packets in -it's first flight. +its first flight. ### Sending Probe Packets From bdcd8c75f213ddacd24f3450d69b623c3d814bc1 Mon Sep 17 00:00:00 2001 From: ianswett Date: Mon, 28 Oct 2019 18:10:19 -0400 Subject: [PATCH 11/21] Update draft-ietf-quic-recovery.md --- draft-ietf-quic-recovery.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index a7824b6a1a..420bae4478 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -523,8 +523,8 @@ removed from bytes in flight when the Initial and Handshake keys are discarded. When a server receives duplicate Initial CRYPTO data, it can assume the client did not receive all Initial CRYPTO data or the client's estimated RTT is too -small. When a client receives undecryptable packets it may assume the server's -Initial was lost. +small. When a client receives undecryptable Handshake packets it may assume +some or all of the server's Initial was lost. To speed handshake completion, either peer MAY send a packet containing unacknowledged Initial CRYPTO data subject to the path validation limits, as From 1ae98696a9afd8bd6adbe62661ec2adc74b02c14 Mon Sep 17 00:00:00 2001 From: ianswett Date: Mon, 28 Oct 2019 18:14:17 -0400 Subject: [PATCH 12/21] Update draft-ietf-quic-recovery.md --- draft-ietf-quic-recovery.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 420bae4478..4e1ed2e45a 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -523,14 +523,14 @@ removed from bytes in flight when the Initial and Handshake keys are discarded. When a server receives duplicate Initial CRYPTO data, it can assume the client did not receive all Initial CRYPTO data or the client's estimated RTT is too -small. When a client receives undecryptable Handshake packets it may assume -some or all of the server's Initial was lost. +small. When a client receives Handshake packets prior to obtaining Handshake +keys it may assume some or all of the server's Initial packets were lost. To speed handshake completion, either peer MAY send a packet containing unacknowledged Initial CRYPTO data subject to the path validation limits, as -though the PTO expired. A client may send an ack-eliciting packet with no -CRYPTO data if all Initial data has been acknowledged. The PTO may only be -shortened once in this way. Subsequently the PTO uses the normal calculation +though the PTO expired. A client MAY send an ack-eliciting packet with no +CRYPTO data if all Initial data has been acknowledged. The PTO can only be +shortened once in this way. Subsequently, the PTO uses the normal calculation with exponential backoff. Peers can also use coalesced packets to ensure each datagram elicits at least From 91ced9e8d46e8d9b4a649f106bb5fd555b2fa818 Mon Sep 17 00:00:00 2001 From: ianswett Date: Tue, 11 Feb 2020 13:10:25 -0500 Subject: [PATCH 13/21] Kazuho comments and remove one sentence --- 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 4e1ed2e45a..da139da5e7 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -523,15 +523,14 @@ removed from bytes in flight when the Initial and Handshake keys are discarded. When a server receives duplicate Initial CRYPTO data, it can assume the client did not receive all Initial CRYPTO data or the client's estimated RTT is too -small. When a client receives Handshake packets prior to obtaining Handshake -keys it may assume some or all of the server's Initial packets were lost. +small. When a client receives Handshake or 1-RTT packets prior to obtaining +Handshake keys it may assume some or all of the server's Initial packets were +lost. To speed handshake completion, either peer MAY send a packet containing unacknowledged Initial CRYPTO data subject to the path validation limits, as -though the PTO expired. A client MAY send an ack-eliciting packet with no -CRYPTO data if all Initial data has been acknowledged. The PTO can only be -shortened once in this way. Subsequently, the PTO uses the normal calculation -with exponential backoff. +though the PTO expired. The PTO MUST only be shortened once in this way. +Subsequently, the PTO uses the normal calculation with exponential backoff. Peers can also use coalesced packets to ensure each datagram elicits at least one acknowledgement. For example, clients can coalesce an Initial packet From fcfa095f3c0a11cd02e001464820ff8e3d515d99 Mon Sep 17 00:00:00 2001 From: ianswett Date: Sat, 15 Feb 2020 10:21:00 -0500 Subject: [PATCH 14/21] Update draft-ietf-quic-recovery.md Co-Authored-By: Jana Iyengar --- draft-ietf-quic-recovery.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index da139da5e7..392ce3c317 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -519,7 +519,7 @@ bytes. Initial packets and Handshake packets may never be acknowledged, but they are removed from bytes in flight when the Initial and Handshake keys are discarded. -### Speeding Handshake Completion +### Speeding Up Handshake Completion When a server receives duplicate Initial CRYPTO data, it can assume the client did not receive all Initial CRYPTO data or the client's estimated RTT is too From e3b814daa3fb57bddf8f60b4a2d2033c5dd99f14 Mon Sep 17 00:00:00 2001 From: ianswett Date: Sat, 15 Feb 2020 10:21:35 -0500 Subject: [PATCH 15/21] Update draft-ietf-quic-recovery.md Co-Authored-By: Jana Iyengar --- draft-ietf-quic-recovery.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 392ce3c317..8887619775 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -522,7 +522,7 @@ removed from bytes in flight when the Initial and Handshake keys are discarded. ### Speeding Up Handshake Completion When a server receives duplicate Initial CRYPTO data, it can assume the client -did not receive all Initial CRYPTO data or the client's estimated RTT is too +did not receive all of the server's CRYPTO data sent in Initial packets, or the client's estimated RTT is too small. When a client receives Handshake or 1-RTT packets prior to obtaining Handshake keys it may assume some or all of the server's Initial packets were lost. From 0c9c2f7f291ccc9633e7c9480a83833dc1f2b72c Mon Sep 17 00:00:00 2001 From: ianswett Date: Sat, 15 Feb 2020 10:21:54 -0500 Subject: [PATCH 16/21] Update draft-ietf-quic-recovery.md Co-Authored-By: Jana Iyengar --- draft-ietf-quic-recovery.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 8887619775..c25bc7522f 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -521,7 +521,7 @@ removed from bytes in flight when the Initial and Handshake keys are discarded. ### Speeding Up Handshake Completion -When a server receives duplicate Initial CRYPTO data, it can assume the client +When a server receives an Initial packet containing duplicate data in a CRYPTO frame, it can assume the client did not receive all of the server's CRYPTO data sent in Initial packets, or the client's estimated RTT is too small. When a client receives Handshake or 1-RTT packets prior to obtaining Handshake keys it may assume some or all of the server's Initial packets were From 2274b69508676e286b5b8ad3ba126f5d9dbd0846 Mon Sep 17 00:00:00 2001 From: ianswett Date: Sat, 15 Feb 2020 10:23:01 -0500 Subject: [PATCH 17/21] Update draft-ietf-quic-recovery.md Co-Authored-By: Jana Iyengar --- draft-ietf-quic-recovery.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index c25bc7522f..52bae729cd 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -527,7 +527,7 @@ small. When a client receives Handshake or 1-RTT packets prior to obtaining Handshake keys it may assume some or all of the server's Initial packets were lost. -To speed handshake completion, either peer MAY send a packet containing +To speed up handshake completion under these conditions, an endpoint MAY send a packet containing unacknowledged Initial CRYPTO data subject to the path validation limits, as though the PTO expired. The PTO MUST only be shortened once in this way. Subsequently, the PTO uses the normal calculation with exponential backoff. From acd4454394249a7337718ead9fad7258b183b01f Mon Sep 17 00:00:00 2001 From: ianswett Date: Sat, 15 Feb 2020 10:24:49 -0500 Subject: [PATCH 18/21] Jana's suggestions Co-Authored-By: Jana Iyengar --- draft-ietf-quic-recovery.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 52bae729cd..ca0cc1b6b6 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -528,14 +528,12 @@ Handshake keys it may assume some or all of the server's Initial packets were lost. To speed up handshake completion under these conditions, an endpoint MAY send a packet containing -unacknowledged Initial CRYPTO data subject to the path validation limits, as -though the PTO expired. The PTO MUST only be shortened once in this way. -Subsequently, the PTO uses the normal calculation with exponential backoff. +unacknowledged CRYPTO data, subject to path validation limits, earlier than the PTO period. -Peers can also use coalesced packets to ensure each datagram elicits at least +Peers can also use coalesced packets to ensure that each datagram elicits at least one acknowledgement. For example, clients can coalesce an Initial packet -containing a PING and PADDING with 0-RTT data packets and a server can -coalesce an Initial packet containing a PING with one or more packets in +containing PING and PADDING frames with a 0-RTT data packet and a server can +coalesce an Initial packet containing a PING frame with one or more packets in its first flight. ### Sending Probe Packets From 3b52d6f468e18aac7a8f0e51a820d0b64f23f2f3 Mon Sep 17 00:00:00 2001 From: ianswett Date: Sat, 15 Feb 2020 10:45:34 -0500 Subject: [PATCH 19/21] Reflow Jana's suggestions --- draft-ietf-quic-recovery.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index ca0cc1b6b6..06ac30b560 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -521,14 +521,15 @@ removed from bytes in flight when the Initial and Handshake keys are discarded. ### Speeding Up Handshake Completion -When a server receives an Initial packet containing duplicate data in a CRYPTO frame, it can assume the client -did not receive all of the server's CRYPTO data sent in Initial packets, or the client's estimated RTT is too -small. When a client receives Handshake or 1-RTT packets prior to obtaining -Handshake keys it may assume some or all of the server's Initial packets were -lost. - -To speed up handshake completion under these conditions, an endpoint MAY send a packet containing -unacknowledged CRYPTO data, subject to path validation limits, earlier than the PTO period. +When a server receives an Initial packet containing duplicate CRYPTO data, +it can assume the client did not receive all of the server's Initially +encrypted CRYPTO data, or the client's estimated RTT is too small. When a +client receives Handshake or 1-RTT packets prior to obtaining Handshake keys, +it may assume some or all of the server's Initial packets were lost. + +To speed up handshake completion under these conditions, an endpoint MAY send +a packet containing unacknowledged CRYPTO data earlier than the PTO expiry, +subject to address validation limits. (see Section 8.1 of {{QUIC-TRANSPORT}}) Peers can also use coalesced packets to ensure that each datagram elicits at least one acknowledgement. For example, clients can coalesce an Initial packet From da005487a8a902c672f362aab1d43263941f0ef8 Mon Sep 17 00:00:00 2001 From: ianswett Date: Sat, 15 Feb 2020 12:01:18 -0500 Subject: [PATCH 20/21] More like Jana's first suggestion Removes use of "Initially encrypted" --- draft-ietf-quic-recovery.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 06ac30b560..9dce30325a 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -522,8 +522,8 @@ removed from bytes in flight when the Initial and Handshake keys are discarded. ### Speeding Up Handshake Completion When a server receives an Initial packet containing duplicate CRYPTO data, -it can assume the client did not receive all of the server's Initially -encrypted CRYPTO data, or the client's estimated RTT is too small. When a +it can assume the client did not receive all of the server's CRYPTO data sent +in Initial packets, or the client's estimated RTT is too small. When a client receives Handshake or 1-RTT packets prior to obtaining Handshake keys, it may assume some or all of the server's Initial packets were lost. From 28959f9e29563bd0e7dff9185d760a8c1fb0175b Mon Sep 17 00:00:00 2001 From: ianswett Date: Wed, 26 Feb 2020 22:59:06 -0500 Subject: [PATCH 21/21] Update draft-ietf-quic-recovery.md Co-Authored-By: Martin Thomson --- draft-ietf-quic-recovery.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 9dce30325a..56c4dcd14c 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -529,7 +529,7 @@ it may assume some or all of the server's Initial packets were lost. To speed up handshake completion under these conditions, an endpoint MAY send a packet containing unacknowledged CRYPTO data earlier than the PTO expiry, -subject to address validation limits. (see Section 8.1 of {{QUIC-TRANSPORT}}) +subject to address validation limits; see Section 8.1 of {{QUIC-TRANSPORT}}. Peers can also use coalesced packets to ensure that each datagram elicits at least one acknowledgement. For example, clients can coalesce an Initial packet