From 8e468187d66a3357f39b7bf7cad62aa09e1094a3 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Wed, 22 May 2019 16:54:46 +0100 Subject: [PATCH 01/14] ECN verification text --- draft-ietf-quic-transport.md | 45 ++++++++++++++++++------------------ 1 file changed, 22 insertions(+), 23 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 9463f748ab..86d7464998 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3113,19 +3113,21 @@ Handshake packet number space will be incremented by one and the counts for the ### ECN Verification {#ecn-verification} -Each endpoint independently verifies and enables use of ECN by setting the IP -header ECN codepoint to ECN Capable Transport (ECT) for the path from it to the -other peer. Even if not setting ECN codepoints on packets it transmits, the -endpoint SHOULD provide feedback about ECN markings received (if accessible). - -To verify both that a path supports ECN and the peer can provide ECN feedback, -an endpoint sets the ECT(0) codepoint in the IP header of all outgoing -packets {{!RFC8311}}. - -If an ECT codepoint set in the IP header is not corrupted by a network device, -then a received packet contains either the codepoint sent by the peer or the -Congestion Experienced (CE) codepoint set by a network device that is -experiencing congestion. +It is possible for network devices on path to corrupt or erroneously drop all IP +packets with ECN Capable Transport (ECT) codepoints set. To provide robust +connectivity in the presence of such devices, each endpoint independently +verifies and enables use of ECN. Even if not setting ECT codepoints on packets +it transmits, the endpoint SHOULD provide feedback about ECN markings received +if they are accessible. + +To verify both that a path supports ECN and that the peer can provide ECN +feedback, an endpoint initially sets the ECT(0) codepoint in the IP header of +all outgoing packets {{!RFC8311}}. + +If all packets with ECT codepoints are dropped by a network device, endpoints +can detect loss of the packets and MAY cease setting ECT codepoints in +subsequent packets. As one concrete strategy, an endpoint could disable setting +of ECT codepoints if Initial packets with ECT codepoints set are deemed lost. If a QUIC packet sent with an ECT codepoint is newly acknowledged by the peer in an ACK frame without ECN feedback, the endpoint stops setting ECT codepoints in @@ -3160,20 +3162,17 @@ with packet number lower than a previously received ACK frame. Verifying based on ACK frames that arrive out of order can result in disabling ECN unnecessarily. -Upon successful verification, an endpoint continues to set ECT codepoints in -subsequent packets with the expectation that the path is ECN-capable. - If verification fails, then the endpoint ceases setting ECT codepoints in subsequent IP packets with the expectation that either the network path or the peer does not support ECN. -If an endpoint sets ECT codepoints on outgoing IP packets and encounters a -retransmission timeout due to the absence of acknowledgments from the peer (see -{{QUIC-RECOVERY}}), or if an endpoint has reason to believe that an element on -the network path might be corrupting ECN codepoints, the endpoint MAY cease -setting ECT codepoints in subsequent packets. Doing so allows the connection to -be resilient to network elements that corrupt ECN codepoints in the IP header or -drop packets with ECT or CE codepoints in the IP header. +If an ECT codepoint set is not dropped or corrupted by a network device, then a +received packet contains either the codepoint sent by the peer or the Congestion +Experienced (CE) codepoint set by a network device that is experiencing +congestion. + +Upon successful verification, an endpoint continues to set ECT codepoints in +subsequent packets with the expectation that the path is ECN-capable. # Packet Size {#packet-size} From 41630b27548b15447a704b8389c846dcb0158a02 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Wed, 22 May 2019 16:56:29 +0100 Subject: [PATCH 02/14] faulty, not all --- draft-ietf-quic-transport.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 86d7464998..41e6f19600 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3113,9 +3113,9 @@ Handshake packet number space will be incremented by one and the counts for the ### ECN Verification {#ecn-verification} -It is possible for network devices on path to corrupt or erroneously drop all IP -packets with ECN Capable Transport (ECT) codepoints set. To provide robust -connectivity in the presence of such devices, each endpoint independently +It is possible for faulty network devices on path to corrupt or erroneously drop +all IP packets with ECN Capable Transport (ECT) codepoints set. To provide +robust connectivity in the presence of such devices, each endpoint independently verifies and enables use of ECN. Even if not setting ECT codepoints on packets it transmits, the endpoint SHOULD provide feedback about ECN markings received if they are accessible. From b00e3a6d9f30f45a79658e299dde8b5ce9af205f Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Wed, 22 May 2019 16:54:46 +0100 Subject: [PATCH 03/14] ECN verification text --- draft-ietf-quic-transport.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 41e6f19600..3fe5d259b5 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3114,8 +3114,8 @@ Handshake packet number space will be incremented by one and the counts for the ### ECN Verification {#ecn-verification} It is possible for faulty network devices on path to corrupt or erroneously drop -all IP packets with ECN Capable Transport (ECT) codepoints set. To provide -robust connectivity in the presence of such devices, each endpoint independently +all packets with ECN Capable Transport (ECT) codepoints set. To provide robust +connectivity in the presence of such devices, each endpoint independently verifies and enables use of ECN. Even if not setting ECT codepoints on packets it transmits, the endpoint SHOULD provide feedback about ECN markings received if they are accessible. From c548966151f284e0074ca3726ccc548c5ab8ad86 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Wed, 22 May 2019 16:56:29 +0100 Subject: [PATCH 04/14] faulty, not all --- draft-ietf-quic-transport.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 3fe5d259b5..41e6f19600 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3114,8 +3114,8 @@ Handshake packet number space will be incremented by one and the counts for the ### ECN Verification {#ecn-verification} It is possible for faulty network devices on path to corrupt or erroneously drop -all packets with ECN Capable Transport (ECT) codepoints set. To provide robust -connectivity in the presence of such devices, each endpoint independently +all IP packets with ECN Capable Transport (ECT) codepoints set. To provide +robust connectivity in the presence of such devices, each endpoint independently verifies and enables use of ECN. Even if not setting ECT codepoints on packets it transmits, the endpoint SHOULD provide feedback about ECN markings received if they are accessible. From f3e8aafc87f00d454e6229078ed80ee08e6085db Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Mon, 5 Aug 2019 18:26:44 -0700 Subject: [PATCH 05/14] ... and I thought this was going to be easy --- draft-ietf-quic-transport.md | 106 +++++++++++++++++++++-------------- 1 file changed, 63 insertions(+), 43 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 41e6f19600..808d007607 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3076,8 +3076,8 @@ rate in response, as described in {{QUIC-RECOVERY}}. To use ECN, QUIC endpoints first determine whether a path supports ECN marking and the peer is able to access the ECN codepoint in the IP header. A network path does not support ECN if ECN marked packets get dropped or ECN markings are -rewritten on the path. An endpoint verifies the path, both during connection -establishment and when migrating to a new path (see {{migration}}). +rewritten on the path. An endpoint validates the use of ECN on the path, both +during connection establishment and when migrating to a new path ({{migration}}). ### ECN Counts @@ -3111,38 +3111,57 @@ Handshake packet number space will be incremented by one and the counts for the 1-RTT packet number space will be increased by two. -### ECN Verification {#ecn-verification} +### ECN Validation {#ecn-validation} -It is possible for faulty network devices on path to corrupt or erroneously drop -all IP packets with ECN Capable Transport (ECT) codepoints set. To provide -robust connectivity in the presence of such devices, each endpoint independently -verifies and enables use of ECN. Even if not setting ECT codepoints on packets -it transmits, the endpoint SHOULD provide feedback about ECN markings received -if they are accessible. +It is possible for faulty network devices to corrupt or erroneously drop IP +packets which have ECN markings. To provide robust connectivity in the presence +of such devices, each endpoint independently validates, and enables or disables +ECN marking on packets it transmits. -To verify both that a path supports ECN and that the peer can provide ECN -feedback, an endpoint initially sets the ECT(0) codepoint in the IP header of -all outgoing packets {{!RFC8311}}. +ECN validation is local to a path, and MUST be independently performed for each +path from an endpoint to its peer. An endpoint thus independently validates ECN +on new connection establishment, when switching to a new server preferred +address, and on active connection migration to a new path. -If all packets with ECT codepoints are dropped by a network device, endpoints -can detect loss of the packets and MAY cease setting ECT codepoints in -subsequent packets. As one concrete strategy, an endpoint could disable setting -of ECT codepoints if Initial packets with ECT codepoints set are deemed lost. +Even if an endpoint does not use ECN markings on packets it transmits, the +endpoint SHOULD provide feedback about ECN markings received from the peer if +they are accessible. Not doing so will cause the peer to disable ECN marking. -If a QUIC packet sent with an ECT codepoint is newly acknowledged by the peer in -an ACK frame without ECN feedback, the endpoint stops setting ECT codepoints in -subsequent IP packets, with the expectation that either the network path or the -peer no longer supports ECN. +#### Sending ECN Markings -Network devices that corrupt or apply non-standard ECN markings might result in -reduced throughput or other undesirable side-effects. To reduce this risk, an -endpoint uses the following steps to verify the counts it receives in an ACK -frame. +To start ECN validation, an endpoint SHOULD do the following when sending +packets on a new path to a peer: + +* Set the ECT(0) codepoint in the IP header of early outgoing packets sent on a + new path to the peer {{!RFC8311}}. + +* If all packets that were sent with the ECT(0) codepoint are eventually deemed + lost {{QUIC-RECOVERY}}, validation is deemed to have failed. + +To reduce the chances of misinterpreting congestive loss as packets dropped by a +faulty network element, an endpoint could set the ECT(0) codepoint in the first +ten outgoing packets on a path, or for a period of three RTTs, whichever occurs +first. Alternate strategies are possible. For example, an endpoint could send +the first ten packets interleaved: five ECT(0)-marked packets interleaved with +five unmarked packets. This allows the endpoint to more clearly identify +congestive loss as such. Implementations MAY experiment with and use other +strategies. -* The total increase in ECT(0), ECT(1), and CE counts MUST be no smaller than - the total number of QUIC packets sent with an ECT codepoint that are newly - acknowledged in this ACK frame. This step detects any network remarking from - ECT(0), ECT(1), or CE codepoints to Not-ECT. +#### Receiving ACK Frames + +An endpoint that sets ECT(0) or ECT(1) codepoints on packets it transmits MUST +use the following steps on receiving an ACK frame to validate ECN. + +* If this ACK frame newly acknowledges a packet that the endpoint sent with + either ECT(0) or ECT(1) codepoints set, and if no ECN feedback is present in + the ACK frame, validation fails. This step protects against both a network + element that zeroes out ECN bits and a peer that is unable to access ECN + markings, since the peer could respond without ECN feedback in these cases. + +* For validation to succeed, the total increase in ECT(0), ECT(1), and CE counts + MUST be no smaller than the total number of QUIC packets sent with an ECT + codepoint that are newly acknowledged in this ACK frame. This step detects + any network remarking from ECT(0), ECT(1), or CE codepoints to Not-ECT. * Any increase in either ECT(0) or ECT(1) counts, plus any increase in the CE count, MUST be no smaller than the number of packets sent with the @@ -3150,29 +3169,30 @@ frame. This step detects any erroneous network remarking from ECT(0) to ECT(1) (or vice versa). +Processing counts out of order can result in validation failure. An endpoint +SHOULD NOT perform this validation if the ACK frame is received in a packet with +packet number lower than a previously received ACK frame. Validating based on +ACK frames that arrive out of order can result in disabling ECN unnecessarily. + An endpoint could miss acknowledgements for a packet when ACK frames are lost. It is therefore possible for the total increase in ECT(0), ECT(1), and CE counts to be greater than the number of packets acknowledged in an ACK frame. When -this happens, and if verification succeeds, the local reference counts MUST be +this happens, and if validation succeeds, the local reference counts MUST be increased to match the counts in the ACK frame. -Processing counts out of order can result in verification failure. An endpoint -SHOULD NOT perform this verification if the ACK frame is received in a packet -with packet number lower than a previously received ACK frame. Verifying based -on ACK frames that arrive out of order can result in disabling ECN -unnecessarily. +#### Validation Outcomes -If verification fails, then the endpoint ceases setting ECT codepoints in -subsequent IP packets with the expectation that either the network path or the -peer does not support ECN. +If validation fails, then the endpoint stops sending ECN markings in subsequent +IP packets with the expectation that either the network path or the peer does +not support ECN. -If an ECT codepoint set is not dropped or corrupted by a network device, then a -received packet contains either the codepoint sent by the peer or the Congestion -Experienced (CE) codepoint set by a network device that is experiencing -congestion. +Upon successful validation, an endpoint can continue to set ECT codepoints in +subsequent packets with the expectation that the path is ECN-capable. Network +routing and path elements can change mid-connection however; an endpoint MUST +disable ECN if validation fails at any point in the connection. -Upon successful verification, an endpoint continues to set ECT codepoints in -subsequent packets with the expectation that the path is ECN-capable. +Even if validation fails, an endpoint MAY re-validate ECN on the same path to +the peer at any later time in the connection. # Packet Size {#packet-size} From 9f88dc3d29f074e5a9fab10595292f3783ce80fc Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Mon, 5 Aug 2019 18:33:30 -0700 Subject: [PATCH 06/14] gah... git --- draft-ietf-quic-transport.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 808d007607..775a5778b5 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3113,10 +3113,10 @@ Handshake packet number space will be incremented by one and the counts for the ### ECN Validation {#ecn-validation} -It is possible for faulty network devices to corrupt or erroneously drop IP -packets which have ECN markings. To provide robust connectivity in the presence -of such devices, each endpoint independently validates, and enables or disables -ECN marking on packets it transmits. +It is possible for faulty network devices to corrupt or erroneously drop packets +which have ECN markings. To provide robust connectivity in the presence of such +devices, each endpoint independently validates, and enables or disables ECN +marking on packets it transmits. ECN validation is local to a path, and MUST be independently performed for each path from an endpoint to its peer. An endpoint thus independently validates ECN From 99c3d3f27f0f21ccdec9e298afbb80308c398ea2 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Mon, 5 Aug 2019 18:47:30 -0700 Subject: [PATCH 07/14] fix ref --- 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 775a5778b5..c77e9a4c71 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1241,7 +1241,7 @@ a 1232 byte QUIC packet payload. This includes overheads that reduce the space available to the cryptographic handshake protocol. An endpoint can verify support for Explicit Congestion Notification (ECN) in the -first packets it sends, as described in {{ecn-verification}}. +first packets it sends, as described in {{ecn-validation}}. The CRYPTO frame can be sent in different packet number spaces. The sequence numbers used by CRYPTO frames to ensure ordered delivery of cryptographic From 9e1257ac44cdf76f4ca87bc7e3d5ee7daf1de961 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Wed, 7 Aug 2019 18:20:12 -0700 Subject: [PATCH 08/14] Apply suggestions from code review Co-Authored-By: Martin Thomson --- draft-ietf-quic-transport.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index c77e9a4c71..a1b0f77f1e 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3114,18 +3114,19 @@ Handshake packet number space will be incremented by one and the counts for the ### ECN Validation {#ecn-validation} It is possible for faulty network devices to corrupt or erroneously drop packets -which have ECN markings. To provide robust connectivity in the presence of such -devices, each endpoint independently validates, and enables or disables ECN +with ECN markings. To provide robust connectivity in the presence of such +devices, each endpoint independently validates ECN counts and disables ECN +if errors are detected. marking on packets it transmits. -ECN validation is local to a path, and MUST be independently performed for each -path from an endpoint to its peer. An endpoint thus independently validates ECN +Endpoints validate ECN for packets sent on each network path independently. +An endpoint thus validates ECN on new connection establishment, when switching to a new server preferred address, and on active connection migration to a new path. Even if an endpoint does not use ECN markings on packets it transmits, the -endpoint SHOULD provide feedback about ECN markings received from the peer if -they are accessible. Not doing so will cause the peer to disable ECN marking. +endpoint MUST provide feedback about ECN markings received from the peer if +they are accessible. Failing to report ECN counts will cause the peer to disable ECN marking. #### Sending ECN Markings @@ -3169,7 +3170,7 @@ use the following steps on receiving an ACK frame to validate ECN. This step detects any erroneous network remarking from ECT(0) to ECT(1) (or vice versa). -Processing counts out of order can result in validation failure. An endpoint +Processing ECN counts out of order can result in validation failure. An endpoint SHOULD NOT perform this validation if the ACK frame is received in a packet with packet number lower than a previously received ACK frame. Validating based on ACK frames that arrive out of order can result in disabling ECN unnecessarily. From 9d5d575289e3c8cdcadf38e3ec5bb3f53a42e651 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Wed, 7 Aug 2019 18:22:13 -0700 Subject: [PATCH 09/14] reflow --- draft-ietf-quic-transport.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index a1b0f77f1e..b5ab4d76fd 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3115,18 +3115,17 @@ Handshake packet number space will be incremented by one and the counts for the It is possible for faulty network devices to corrupt or erroneously drop packets with ECN markings. To provide robust connectivity in the presence of such -devices, each endpoint independently validates ECN counts and disables ECN -if errors are detected. -marking on packets it transmits. +devices, each endpoint independently validates ECN counts and disables ECN if +errors are detected. -Endpoints validate ECN for packets sent on each network path independently. -An endpoint thus validates ECN -on new connection establishment, when switching to a new server preferred -address, and on active connection migration to a new path. +Endpoints validate ECN for packets sent on each network path independently. An +endpoint thus validates ECN on new connection establishment, when switching to a +new server preferred address, and on active connection migration to a new path. Even if an endpoint does not use ECN markings on packets it transmits, the -endpoint MUST provide feedback about ECN markings received from the peer if -they are accessible. Failing to report ECN counts will cause the peer to disable ECN marking. +endpoint MUST provide feedback about ECN markings received from the peer if they +are accessible. Failing to report ECN counts will cause the peer to disable ECN +marking. #### Sending ECN Markings @@ -3170,10 +3169,11 @@ use the following steps on receiving an ACK frame to validate ECN. This step detects any erroneous network remarking from ECT(0) to ECT(1) (or vice versa). -Processing ECN counts out of order can result in validation failure. An endpoint -SHOULD NOT perform this validation if the ACK frame is received in a packet with -packet number lower than a previously received ACK frame. Validating based on -ACK frames that arrive out of order can result in disabling ECN unnecessarily. +Processing ECN counts out of order can result in validation failure. An +endpoint SHOULD NOT perform this validation if the ACK frame is received in a +packet with packet number lower than a previously received ACK frame. +Validating based on ACK frames that arrive out of order can result in disabling +ECN unnecessarily. An endpoint could miss acknowledgements for a packet when ACK frames are lost. It is therefore possible for the total increase in ECT(0), ECT(1), and CE counts From d91799d50a76b2e9bcc00e22deebc1c31fe30816 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Wed, 7 Aug 2019 18:35:52 -0700 Subject: [PATCH 10/14] comments --- draft-ietf-quic-transport.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index b5ab4d76fd..2f41df081a 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3141,11 +3141,11 @@ packets on a new path to a peer: To reduce the chances of misinterpreting congestive loss as packets dropped by a faulty network element, an endpoint could set the ECT(0) codepoint in the first ten outgoing packets on a path, or for a period of three RTTs, whichever occurs -first. Alternate strategies are possible. For example, an endpoint could send -the first ten packets interleaved: five ECT(0)-marked packets interleaved with -five unmarked packets. This allows the endpoint to more clearly identify -congestive loss as such. Implementations MAY experiment with and use other -strategies. +first. Implementations MAY experiment with and use other strategies. An +endpoint could send the first ten packets interleaved: five packets marked with +ECT(0) or ECT(1) interleaved with five unmarked packets. An endpoint could also +simply send all packets marked with ECT(0) or ECT(1) until validation fails. + #### Receiving ACK Frames From 86eaad8e15dc026bbe3d87c4fe3da3425b2a7a0b Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Wed, 7 Aug 2019 18:42:03 -0700 Subject: [PATCH 11/14] use largest acked, not packet number --- draft-ietf-quic-transport.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 2f41df081a..d043d74be1 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3170,10 +3170,9 @@ use the following steps on receiving an ACK frame to validate ECN. vice versa). Processing ECN counts out of order can result in validation failure. An -endpoint SHOULD NOT perform this validation if the ACK frame is received in a -packet with packet number lower than a previously received ACK frame. -Validating based on ACK frames that arrive out of order can result in disabling -ECN unnecessarily. +endpoint SHOULD perform this validation only if the largest packet number +acknowledged in this ACK frame is greater than the largest packet number +acknowledged so far in this connection. An endpoint could miss acknowledgements for a packet when ACK frames are lost. It is therefore possible for the total increase in ECT(0), ECT(1), and CE counts From ee89e45f5c47a6c17c848e43f360b88baabb0d8c Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Wed, 7 Aug 2019 18:45:56 -0700 Subject: [PATCH 12/14] the best words --- draft-ietf-quic-transport.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index d043d74be1..58ccdbf9dc 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3170,9 +3170,8 @@ use the following steps on receiving an ACK frame to validate ECN. vice versa). Processing ECN counts out of order can result in validation failure. An -endpoint SHOULD perform this validation only if the largest packet number -acknowledged in this ACK frame is greater than the largest packet number -acknowledged so far in this connection. +endpoint SHOULD NOT perform this validation if this ACK frame does not advance +the largest packet number acknowledged in this connection. An endpoint could miss acknowledgements for a packet when ACK frames are lost. It is therefore possible for the total increase in ECT(0), ECT(1), and CE counts From 08ed6f08a0a67f38737fb1b95c6e923fc2dd5911 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Wed, 7 Aug 2019 18:49:16 -0700 Subject: [PATCH 13/14] lint --- draft-ietf-quic-transport.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 58ccdbf9dc..51525aab21 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3077,7 +3077,8 @@ To use ECN, QUIC endpoints first determine whether a path supports ECN marking and the peer is able to access the ECN codepoint in the IP header. A network path does not support ECN if ECN marked packets get dropped or ECN markings are rewritten on the path. An endpoint validates the use of ECN on the path, both -during connection establishment and when migrating to a new path ({{migration}}). +during connection establishment and when migrating to a new path +({{migration}}). ### ECN Counts From 78a9f6dbb9fcfebdfdca7723526c5d9370429f92 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Thu, 8 Aug 2019 13:19:51 -0700 Subject: [PATCH 14/14] more words --- draft-ietf-quic-transport.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 51525aab21..fda55370c6 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3142,10 +3142,12 @@ packets on a new path to a peer: To reduce the chances of misinterpreting congestive loss as packets dropped by a faulty network element, an endpoint could set the ECT(0) codepoint in the first ten outgoing packets on a path, or for a period of three RTTs, whichever occurs -first. Implementations MAY experiment with and use other strategies. An -endpoint could send the first ten packets interleaved: five packets marked with -ECT(0) or ECT(1) interleaved with five unmarked packets. An endpoint could also -simply send all packets marked with ECT(0) or ECT(1) until validation fails. +first. + +Implementations MAY experiment with and use other strategies for use of ECN. +Other methods of probing paths for ECN support are possible, as are different +marking strategies. Implementations can also use the ECT(1) codepoint, as +specified in {{?RFC8311}}. #### Receiving ACK Frames @@ -3191,8 +3193,8 @@ subsequent packets with the expectation that the path is ECN-capable. Network routing and path elements can change mid-connection however; an endpoint MUST disable ECN if validation fails at any point in the connection. -Even if validation fails, an endpoint MAY re-validate ECN on the same path to -the peer at any later time in the connection. +Even if validation fails, an endpoint MAY revalidate ECN on the same path at any +later time in the connection. # Packet Size {#packet-size}