From 9d20ea501c0c72ffe593af6179ebbdad9d2abf87 Mon Sep 17 00:00:00 2001 From: EKR Date: Sat, 15 Dec 2018 06:02:17 -0800 Subject: [PATCH 1/3] Make the ECN requirements match the the discussion in #2156. Fixes #2156 1. Implementations are free to enable sending or not. 2, Implementations MAY read the ECN code points if they can and send ECN ACKs. 3. Implementations MUST accept the 0x03 ACK type and if they are sending ECN SHOULD use the ECN section. I recognize that some people want to have stronger language here, based on this discussion I think this is where we are. I'll defer to the chairs to judge whether more is needed here and can change the PR as required. --- draft-ietf-quic-transport.md | 28 ++++++++++++++++------------ 1 file changed, 16 insertions(+), 12 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 91920b6246..3707eb4a11 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2969,8 +2969,8 @@ The details of loss detection and congestion control are described in ## Explicit Congestion Notification {#ecn} -QUIC endpoints use Explicit Congestion Notification (ECN) {{!RFC3168}} to detect -and respond to network congestion. ECN allows a network node to indicate +QUIC endpoints can use Explicit Congestion Notification (ECN) {{!RFC3168}} to +detect and respond to network congestion. ECN allows a network node to indicate congestion in the network by setting a codepoint in the IP header of a packet instead of dropping it. Endpoints react to congestion by reducing their sending rate in response, as described in {{QUIC-RECOVERY}}. @@ -2984,10 +2984,11 @@ establishment and when migrating to a new path (see {{migration}}). ### ECN Counters -On receiving a QUIC packet with an ECT or CE codepoint, an endpoint that can -access the ECN codepoints from the enclosing IP packet increases the -corresponding ECT(0), ECT(1), or CE count, and includes these counters in -subsequent ACK frames (see {{processing-and-ack}} and {{frame-ack}}). +On receiving a QUIC packet with an ECT or CE codepoint, an ECN enabled QUIC +implementation increases the corresponding ECT(0), ECT(1), or CE count, and +includes these counters in subsequent ACK frames (see {{processing-and-ack}} and +{{frame-ack}}). Note that this requires being able to read the ECN codepoints +from the enclosing IP packet, which is not possible on all platforms. A packet detected by a receiver as a duplicate does not affect the receiver's local ECN codepoint counts; see ({{security-ecn}}) for relevant security @@ -2995,8 +2996,9 @@ concerns. If an endpoint receives a QUIC packet without an ECT or CE codepoint in the IP packet header, it responds per {{processing-and-ack}} with an ACK frame without -increasing any ECN counters. Similarly, if an endpoint does not have access to -received ECN codepoints, it does not increase ECN counters. +increasing any ECN counters. Similarly, if an endpoint does not implement ECN +support or does not have access to received ECN codepoints, it does not increase +ECN counters. Coalesced packets (see {{packet-coalesce}}) mean that several packets can share the same IP header. The ECN counter for the ECN codepoint received in the @@ -3014,11 +3016,11 @@ the 1-RTT packet number space will be increased by two. 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 ECN is not used on the path to the peer, the endpoint MUST -provide feedback about ECN markings received (if accessible). +other peer. Even if not setting ECN codepoints on packets it transmits, the +endpoint MAY 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 MUST set the ECT(0) codepoint in the IP header of all outgoing +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, @@ -4133,7 +4135,9 @@ Receivers send ACK frames (types 0x02 and 0x03) to inform senders of packets they have received and processed. The ACK frame contains one or more ACK Blocks. ACK Blocks are ranges of acknowledged packets. If the frame type is 0x03, ACK frames also contain the sum of QUIC packets with associated ECN marks received -on the connection up until this point. +on the connection up until this point. QUIC implementations MUST properly handle +both types 0x02 and 0x03 and if they have enabled ECN for packets they send, +SHOULD use the information in the ECN section to manage their congestion state. QUIC acknowledgements are irrevocable. Once acknowledged, a packet remains acknowledged, even if it does not appear in a future ACK frame. This is unlike From 029d7294a27ff24dd6f027bba50feb0b289b871f Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 19 Dec 2018 10:17:30 +1100 Subject: [PATCH 2/3] SHOULD ECN --- 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 3707eb4a11..b30038886f 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3017,7 +3017,7 @@ the 1-RTT packet number space will be increased by two. 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 MAY provide feedback about ECN markings received (if accessible). +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 From 2941ecca0823f0f6fcda1930bd120824f616841d Mon Sep 17 00:00:00 2001 From: janaiyengar Date: Tue, 18 Dec 2018 15:24:29 -0800 Subject: [PATCH 3/3] editorial nit --- 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 591c0715ef..7851cf3491 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -4157,8 +4157,8 @@ they have received and processed. The ACK frame contains one or more ACK Blocks. ACK Blocks are ranges of acknowledged packets. If the frame type is 0x03, ACK frames also contain the sum of QUIC packets with associated ECN marks received on the connection up until this point. QUIC implementations MUST properly handle -both types 0x02 and 0x03, and if they have enabled ECN for packets they send, -SHOULD use the information in the ECN section to manage their congestion state. +both types and, if they have enabled ECN for packets they send, they SHOULD use +the information in the ECN section to manage their congestion state. QUIC acknowledgements are irrevocable. Once acknowledged, a packet remains acknowledged, even if it does not appear in a future ACK frame. This is unlike