draft-ietf-tsvwg-ecn-experimentation-07.txt   draft-ietf-tsvwg-ecn-experimentation-08.txt 
Transport Area Working Group D. Black Transport Area Working Group D. Black
Internet-Draft Dell EMC Internet-Draft Dell EMC
Updates: 3168, 4341, 4342, 5622, 6679 October 20, 2017 Updates: 3168, 4341, 4342, 5622, 6679 November 13, 2017
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: April 23, 2018 Expires: May 17, 2018
Relaxing Restrictions on Explicit Congestion Notification (ECN) Relaxing Restrictions on Explicit Congestion Notification (ECN)
Experimentation Experimentation
draft-ietf-tsvwg-ecn-experimentation-07 draft-ietf-tsvwg-ecn-experimentation-08
Abstract Abstract
This memo updates RFC 3168, which specifies Explicit Congestion This memo updates RFC 3168, which specifies Explicit Congestion
Notification (ECN) as an alternative to packet drops for indicating Notification (ECN) as an alternative to packet drops for indicating
network congestion to endpoints. It relaxes restrictions in RFC 3168 network congestion to endpoints. It relaxes restrictions in RFC 3168
that hinder experimentation towards benefits beyond just removal of that hinder experimentation towards benefits beyond just removal of
loss. This memo summarizes the anticipated areas of experimentation loss. This memo summarizes the anticipated areas of experimentation
and updates RFC 3168 to enable experimentation in these areas. An and updates RFC 3168 to enable experimentation in these areas. An
Experimental RFC in the IETF document stream is required to take Experimental RFC in the IETF document stream is required to take
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 23, 2018. This Internet-Draft will expire on May 17, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 39 skipping to change at page 2, line 39
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. ECN Terminology . . . . . . . . . . . . . . . . . . . . . 3 1.1. ECN Terminology . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. ECN Experimentation: Overview . . . . . . . . . . . . . . . . 4 2. ECN Experimentation: Overview . . . . . . . . . . . . . . . . 4
2.1. Effective Congestion Control is Required . . . . . . . . 5 2.1. Effective Congestion Control is Required . . . . . . . . 5
2.2. Considerations for Other Protocols . . . . . . . . . . . 5 2.2. Network Considerations for ECN Experimentation . . . . . 5
2.3. Operational and Management Considerations . . . . . . . . 6 2.3. Operational and Management Considerations . . . . . . . . 6
3. ECN Nonce and RFC 3540 . . . . . . . . . . . . . . . . . . . 7 3. ECN Nonce and RFC 3540 . . . . . . . . . . . . . . . . . . . 7
4. Updates to RFC 3168 . . . . . . . . . . . . . . . . . . . . . 8 4. Updates to RFC 3168 . . . . . . . . . . . . . . . . . . . . . 8
4.1. Congestion Response Differences . . . . . . . . . . . . . 8 4.1. Congestion Response Differences . . . . . . . . . . . . . 8
4.2. Congestion Marking Differences . . . . . . . . . . . . . 9 4.2. Congestion Marking Differences . . . . . . . . . . . . . 9
4.3. TCP Control Packets and Retransmissions . . . . . . . . . 12 4.3. TCP Control Packets and Retransmissions . . . . . . . . . 12
5. ECN for RTP Updates to RFC 6679 . . . . . . . . . . . . . . . 13 5. ECN for RTP Updates to RFC 6679 . . . . . . . . . . . . . . . 13
6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622 . . . . . . 14 6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622 . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
This memo updates RFC 3168 [RFC3168] which specifies Explicit This memo updates RFC 3168 [RFC3168] which specifies Explicit
Congestion Notification (ECN) as an alternative to packet drops for Congestion Notification (ECN) as an alternative to packet drops for
skipping to change at page 4, line 26 skipping to change at page 4, line 26
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
2. ECN Experimentation: Overview 2. ECN Experimentation: Overview
Three areas of ECN experimentation are covered by this memo; the Three areas of ECN experimentation are covered by this memo; the
cited Internet-Drafts should be consulted for the detailed goals and cited Internet-Drafts should be consulted for the detailed goals and
rationale of each proposed experiment: rationale of each proposed experiment:
Congestion Response Differences: An ECN congestion indication Congestion Response Differences: An ECN congestion indication
communicates a higher likelihood that a shorter queue exists at communicates a higher likelihood than a dropped packet that a
the network bottleneck node by comparison to a longer queue that short queue exists at the network bottleneck node
is more likely when a packet drop occurs that indicates congestion
[I-D.ietf-tcpm-alternativebackoff-ecn]. This difference suggests [I-D.ietf-tcpm-alternativebackoff-ecn]. This difference suggests
that for congestion indicated by ECN, a different sender that for congestion indicated by ECN, a different sender
congestion response (e.g., sender backs off by a smaller amount) congestion response (e.g., sender backs off by a smaller amount)
may be appropriate by comparison to the sender response to may be appropriate by comparison to the sender response to
congestion indicated by loss. Two examples of proposed sender congestion indicated by loss. Two examples of proposed sender
congestion response changes are described in congestion response changes are described in
[I-D.ietf-tcpm-alternativebackoff-ecn] and [I-D.ietf-tcpm-alternativebackoff-ecn] and
[I-D.ietf-tsvwg-ecn-l4s-id] - the proposal in the latter draft [I-D.ietf-tsvwg-ecn-l4s-id] - the proposal in the latter draft
couples the sender congestion response change to Congestion couples the sender congestion response change to Congestion
Marking Differences changes (see next paragraph). This is at Marking Differences functionality (see next paragraph). These
variance with RFC 3168's requirement that a sender's congestion changes are at variance with RFC 3168's requirement that a
control response to ECN congestion indications be the same as to sender's congestion control response to ECN congestion indications
drops. IETF approval, e.g., via an Experimental RFC in the IETF be the same as to drops. IETF approval, e.g., via an Experimental
document stream, is required for any sender congestion response RFC in the IETF document stream, is required for any sender
used in this area of experimentation. See Section 4.1 for further congestion response used in this area of experimentation. See
discussion. Section 4.1 for further discussion.
Congestion Marking Differences: Congestion marking at network nodes Congestion Marking Differences: Congestion marking at network nodes
can be configured to maintain very shallow queues in conjunction can be configured to maintain very shallow queues in conjunction
with a different sender response to congestion indications (CE with a different sender response to congestion indications (CE
marks), e.g., as proposed in [I-D.ietf-tsvwg-ecn-l4s-id]. The marks), e.g., as proposed in [I-D.ietf-tsvwg-ecn-l4s-id]. The
traffic involved needs to be identified by the senders to the traffic involved needs to be identified by the senders to the
network nodes in order to avoid damage to other network traffic network nodes in order to avoid damage to other network traffic
whose senders do not expect the more frequent congestion marking whose senders do not expect the more frequent congestion marking
used to maintain very shallow queues. Use of different ECN used to maintain very shallow queues. Use of different ECN
codepoints, specifically ECT(0) and ECT(1), is a promising means codepoints, specifically ECT(0) and ECT(1), is a promising means
of traffic identification for this purpose, but that technique is of traffic identification for this purpose, but that technique is
at variance with RFC 3168's requirement that ECT(0)-marked traffic at variance with RFC 3168's requirement that ECT(0)-marked traffic
and ECT(1)-marked traffic not receive different treatment in the and ECT(1)-marked traffic not receive different treatment in the
network. IETF approval, e.g., via an Experimental RFC in the IETF network. IETF approval, e.g., via an Experimental RFC in the IETF
document stream, is required for any sender congestion response document stream, is required for any differences in congestion
used in this area of experimentation. See Section 4.2 for further marking or sender congestion response used in this area of
discussion. experimentation. See Section 4.2 for further discussion.
TCP Control Packets and Retransmissions: RFC 3168 limits the use of TCP Control Packets and Retransmissions: RFC 3168 limits the use of
ECN with TCP to data packets, excluding retransmissions. With the ECN with TCP to data packets, excluding retransmissions. With the
successful deployment of ECN in large portions of the Internet, successful deployment of ECN in large portions of the Internet,
there is interest in extending the benefits of ECN to TCP control there is interest in extending the benefits of ECN to TCP control
packets (e.g., SYNs) and retransmitted packets, e.g., as proposed packets (e.g., SYNs) and retransmitted packets, e.g., as proposed
in [I-D.bagnulo-tcpm-generalized-ecn]. This is at variance with in [I-D.bagnulo-tcpm-generalized-ecn]. This is at variance with
RFC 3168's prohibition of use of ECN for TCP control packets and RFC 3168's prohibition of use of ECN for TCP control packets and
retransmitted packets. See Section 4.3 for further discussion. retransmitted packets. See Section 4.3 for further discussion.
skipping to change at page 5, line 43 skipping to change at page 5, line 42
2.1. Effective Congestion Control is Required 2.1. Effective Congestion Control is Required
Congestion control remains an important aspect of the Internet Congestion control remains an important aspect of the Internet
architecture [RFC2914]. Any Experimental RFC in the IETF document architecture [RFC2914]. Any Experimental RFC in the IETF document
stream that takes advantage of this memo's updates to any RFC is stream that takes advantage of this memo's updates to any RFC is
required to discuss the congestion control implications of the required to discuss the congestion control implications of the
experiment(s) in order to provide assurance that deployment of the experiment(s) in order to provide assurance that deployment of the
experiment(s) does not pose a congestion-based threat to the experiment(s) does not pose a congestion-based threat to the
operation of the Internet. operation of the Internet.
2.2. Considerations for Other Protocols 2.2. Network Considerations for ECN Experimentation
ECN is widely deployed in the Internet and is being designed into ECN functionality [RFC3168] is becoming widely deployed in the
additional protocols such as TRILL [I-D.ietf-trill-ecn-support]. Internet and is being designed into additional protocols such as
While the responsibility for coexistence with other protocols and TRILL [I-D.ietf-trill-ecn-support]. ECN experiments are expected to
transition from current ECN functionality falls primary upon the coexist with deployed ECN functionality, with the responsibility for
designers of experimental changes to ECN, this subsection provides that coexistence falling primarily upon designers of experimental
some general guidelines for designers and users of other protocols changes to ECN. In addition, protocol designers and implementers, as
that minimize the likelihood of interaction with the areas of ECN well as network operators, may desire to anticipate and/or support
experimentation enabled by this memo. ECN experiments. The following guidelines will help avoid conflicts
with the areas of ECN experimentation enabled by this memo:
1. RFC 3168's forwarding behavior remains the preferred approach for 1. RFC 3168's forwarding behavior remains the preferred approach for
routers that are not involved in ECN experiments, in particular routers that are not involved in ECN experiments, in particular
continuing to treat the ECT(0) and ECT(1) codepoints as continuing to treat the ECT(0) and ECT(1) codepoints as
equivalent, as specified in Section 4.2 below. equivalent, as specified in Section 4.2 below.
2. The ECN CE codepoint SHOULD NOT be assumed to indicate that the 2. Network nodes that forward packets SHOULD NOT assume that the ECN
packet would have been dropped if ECN were not in use, as that is CE codepoint indicates that the packet would have been dropped if
not the case for either Congestion Response Differences ECN were not in use. This is because Congestion Response
experiments (see Section 4.1 below) or Congestion Marking Differences experiments employ different congestion responses to
Differences experiments (see Section 4.2 below). This is already dropped packets by comparison to receipt of CE-marked packets
the case when the ECN field is used for Pre-Congestion (see Section 4.1 below), so CE-marked packets SHOULD NOT be
Notification (PCN) [RFC6660]. arbitrarily dropped. A corresponding difference in congestion
responses already occurs when the ECN field is used for Pre-
Congestion Notification (PCN) [RFC6660].
3. Traffic marked with ECT(1) MUST NOT be originated, as specified 3. A network node MUST NOT originate traffic marked with ECT(1)
in Section 4.2 below. unless the network node is participating in a Congestion Marking
Differences experiment that uses ECT(1), as specified in
Section 4.2 below.
4. ECN may now be used on packets where it has not been used Some ECN experiments use ECN with packets where it has not been used
previously, specifically TCP control packets and retransmissions, previously, specifically TCP control packets and retransmissions, see
see Section 4.3 below, and in particular its new requirements for Section 4.3 below, and in particular its new requirements for
middlebox behavior. In general, any system or protocol that middlebox behavior. In general, any system or protocol that inspects
inspects or monitors network traffic SHOULD be prepared to or monitors network traffic SHOULD be prepared to encounter ECN usage
encounter ECN usage on packets and traffic that currently do not on packets and traffic that currently do not use ECN.
use ECN.
5. Requirements for handling of the ECN field by tunnel ECN field handling requirements for tunnel encapsulation and
encapsulation and decapsulation are specified in [RFC6040]. decapsulation are specified in [RFC6040] which is in the process of
Additional related guidance can be found in being updated by [I-D.ietf-tsvwg-rfc6040update-shim]. Related
[I-D.ietf-tsvwg-ecn-encap-guidelines] and guidance for encapsulations whose outer headers are not IP headers
[I-D.ietf-tsvwg-rfc6040update-shim]. can be found in [I-D.ietf-tsvwg-ecn-encap-guidelines]. These
requirements and guidance apply to all traffic, including traffic
that is part of any ECN experiment.
2.3. Operational and Management Considerations 2.3. Operational and Management Considerations
Changes in network traffic behavior that result from ECN Changes in network traffic behavior that result from ECN
experimentation are likely to impact network operations and experimentation are likely to impact network operations and
management. Designers of ECN experiments are expected to anticipate management. Designers of ECN experiments are expected to anticipate
possible impacts and consider how they may be dealt with. Specific possible impacts and consider how they may be dealt with. Specific
topics to consider include possible network management changes or topics to consider include possible network management changes or
extensions, monitoring of the experimental deployment, collection of extensions, monitoring of the experimental deployment, collection of
data for evaluation of the experiment and possible interactions with data for evaluation of the experiment and possible interactions with
other protocols, particularly protocols that encapsulate network other protocols, particularly protocols that encapsulate network
traffic. traffic.
For further discussion, see [RFC5706]; the questions in Appendix A For further discussion, see [RFC5706]; the questions in Appendix A of
provide a concise survey of some important aspects to consider. RFC 5706 provide a concise survey of some important aspects to
consider.
3. ECN Nonce and RFC 3540 3. ECN Nonce and RFC 3540
As specified in RFC 3168, ECN uses two ECN Capable Transport (ECT) As specified in RFC 3168, ECN uses two ECN Capable Transport (ECT)
codepoints to indicate that a packet supports ECN, ECT(0) and ECT(1). codepoints to indicate that a packet supports ECN, ECT(0) and ECT(1).
The second codepoint, ECT(1), is used to support ECN nonce RFC 3168 assigned the second codepoint, ECT(1), to support ECN nonce
functionality that discourages receivers from exploiting ECN to functionality that discourages receivers from exploiting ECN to
improve their throughput at the expense of other network users, as improve their throughput at the expense of other network users. That
specified in Experimental RFC 3540 [RFC3540]. This section explains ECN nonce functionality is fully specified in Experimental RFC 3540
why RFC 3540 is being reclassified as Historic and makes associated [RFC3540]. This section explains why RFC 3540 is being reclassified
updates to RFC 3168. as Historic and makes associated updates to RFC 3168.
While the ECN nonce works as specified, and has been deployed in While the ECN nonce works as specified, and has been deployed in
limited environments, widespread usage in the Internet has not limited environments, widespread usage in the Internet has not
materialized. A study of the ECN behaviour of the top one million materialized. A study of the ECN behaviour of the top one million
web servers using 2014 data [Trammell15] found that after ECN was web servers using 2014 data [Trammell15] found that after ECN was
negotiated, none of the 581,711 IPv4 servers tested were using both negotiated, none of the 581,711 IPv4 servers tested were using both
ECT codepoints, which would have been a possible sign of ECN nonce ECT codepoints, which would have been a possible sign of ECN nonce
usage. Of the 17,028 IPv6 servers tested, 4 set both ECT(0) and usage. Of the 17,028 IPv6 servers tested, 4 set both ECT(0) and
ECT(1) on data packets. This might have been evidence of use of the ECT(1) on data packets. This might have been evidence of use of the
ECN nonce by these 4 servers, but might equally have been due to ECN nonce by these 4 servers, but might equally have been due to
skipping to change at page 8, line 7 skipping to change at page 8, line 17
motivation for two ECT codepoints. motivation for two ECT codepoints.
2. Remove Section 11.2 "A Discussion of the ECN nonce." in its 2. Remove Section 11.2 "A Discussion of the ECN nonce." in its
entirety. entirety.
3. Remove the last paragraph of Section 12, which states that ECT(1) 3. Remove the last paragraph of Section 12, which states that ECT(1)
may be used as part of the implementation of the ECN nonce. may be used as part of the implementation of the ECN nonce.
4. Remove the first two paragraphs of Section 20.2, which discuss 4. Remove the first two paragraphs of Section 20.2, which discuss
the ECN nonce and alternatives. No changes are made to the rest the ECN nonce and alternatives. No changes are made to the rest
of Section 20.2, which discusses alternate uses for the fourth of Section 20.2, which discusses alternative uses for the fourth
ECN codepoint. ECN codepoint.
In addition, other less substantive RFC 3168 changes are required to In addition, other less substantive RFC 3168 changes are required to
remove all other mentions of the ECN nonce and to remove implications remove all other mentions of the ECN nonce and to remove implications
that ECT(1) is intended for use by the ECN nonce; these specific text that ECT(1) is intended for use by the ECN nonce; these specific text
updates are omitted for brevity. updates are omitted for brevity.
4. Updates to RFC 3168 4. Updates to RFC 3168
The following subsections specify updates to RFC 3168 to enable the The following subsections specify updates to RFC 3168 to enable the
skipping to change at page 8, line 33 skipping to change at page 8, line 43
and ECN congestion indications. ECN congestion indications are and ECN congestion indications. ECN congestion indications are
predominately originated by Active Queue Management (AQM) mechanisms predominately originated by Active Queue Management (AQM) mechanisms
in intermediate buffers. AQM mechanisms are usually configured to in intermediate buffers. AQM mechanisms are usually configured to
maintain shorter queue lengths than non-AQM based mechanisms, maintain shorter queue lengths than non-AQM based mechanisms,
particularly non-AQM drop-based mechanisms such as tail-drop, as AQM particularly non-AQM drop-based mechanisms such as tail-drop, as AQM
mechanisms indicate congestion before the queue overflows. While the mechanisms indicate congestion before the queue overflows. While the
occurrence of loss does not easily enable the receiver to determine occurrence of loss does not easily enable the receiver to determine
if AQM is used, the receipt of an ECN Congestion Experienced (CE) if AQM is used, the receipt of an ECN Congestion Experienced (CE)
mark conveys a strong likelihood that AQM was used to manage the mark conveys a strong likelihood that AQM was used to manage the
bottleneck queue. Hence an ECN congestion indication communicates a bottleneck queue. Hence an ECN congestion indication communicates a
higher likelihood that a shorter queue exists at the network higher likelihood than a dropped packet that a short queue exists at
bottleneck node by comparison to a packet drop that indicates the network bottleneck node [I-D.ietf-tcpm-alternativebackoff-ecn].
congestion [I-D.ietf-tcpm-alternativebackoff-ecn]. This difference This difference suggests that for congestion indicated by ECN, a
suggests that for congestion indicated by ECN, a different sender different sender congestion response (e.g., sender backs off by a
congestion response (e.g., sender backs off by a smaller amount) may smaller amount) may be appropriate by comparison to the sender
be appropriate by comparison to the sender response to congestion response to congestion indicated by loss. However, section 5 of RFC
indicated by loss. However, section 5 of RFC 3168 specifies that: 3168 specifies that:
Upon the receipt by an ECN-Capable transport of a single CE Upon the receipt by an ECN-Capable transport of a single CE
packet, the congestion control algorithms followed at the end- packet, the congestion control algorithms followed at the end-
systems MUST be essentially the same as the congestion control systems MUST be essentially the same as the congestion control
response to a *single* dropped packet. response to a *single* dropped packet.
This memo updates this RFC 3168 text to allow the congestion control This memo updates this RFC 3168 text to allow the congestion control
response (including the TCP Sender's congestion control response) to response (including the TCP Sender's congestion control response) to
a CE-marked packet to differ from the response to a dropped packet, a CE-marked packet to differ from the response to a dropped packet,
provided that the changes from RFC 3168 are documented in an provided that the changes from RFC 3168 are documented in an
skipping to change at page 9, line 47 skipping to change at page 10, line 8
are needed to make effective use of such very shallow queues; are needed to make effective use of such very shallow queues;
Datacenter TCP (DCTCP) [I-D.ietf-tcpm-dctcp] provides an example. In Datacenter TCP (DCTCP) [I-D.ietf-tcpm-dctcp] provides an example. In
this case, separate network node treatments are essential, both to this case, separate network node treatments are essential, both to
prevent the aggressive low latency traffic from starving conventional prevent the aggressive low latency traffic from starving conventional
traffic (if present) and to prevent any conventional traffic traffic (if present) and to prevent any conventional traffic
disruption to any lower latency service that uses the very shallow disruption to any lower latency service that uses the very shallow
queues. Use of different ECN codepoints is a promising means of queues. Use of different ECN codepoints is a promising means of
identifying these two classes of traffic to network nodes, and hence identifying these two classes of traffic to network nodes, and hence
this area of experimentation is based on the use of the ECT(1) this area of experimentation is based on the use of the ECT(1)
codepoint to request ECN congestion marking behavior in the network codepoint to request ECN congestion marking behavior in the network
that differs from ECT(0) counterbalanced by use of a different IETF- that differs from ECT(0). It is essential that any such change in
approved congestion response to CE marks at the sender, e.g., as ECN congestion marking behavior be counterbalanced by use of a
proposed in [I-D.ietf-tsvwg-ecn-l4s-id]. different IETF-approved congestion response to CE marks at the
sender, e.g., as proposed in [I-D.ietf-tsvwg-ecn-l4s-id].
Section 5 of RFC 3168 specifies that: Section 5 of RFC 3168 specifies that:
Routers treat the ECT(0) and ECT(1) codepoints as equivalent. Routers treat the ECT(0) and ECT(1) codepoints as equivalent.
This memo updates RFC 3168 to allow routers to treat the ECT(0) and This memo updates RFC 3168 to allow routers to treat the ECT(0) and
ECT(1) codepoints differently, provided that the changes from RFC ECT(1) codepoints differently, provided that the changes from RFC
3168 are documented in an Experimental RFC in the IETF document 3168 are documented in an Experimental RFC in the IETF document
stream. The specific change to RFC 3168 is to insert the words stream. The specific change to RFC 3168 is to insert the words
"unless otherwise specified by an Experimental RFC in the IETF "unless otherwise specified by an Experimental RFC in the IETF
skipping to change at page 15, line 36 skipping to change at page 15, line 46
experiments have motivated the production of this memo - their experiments have motivated the production of this memo - their
interest in innovation is welcome and heartily acknowledged. Colin interest in innovation is welcome and heartily acknowledged. Colin
Perkins suggested updating RFC 6679 on RTP and provided guidance on Perkins suggested updating RFC 6679 on RTP and provided guidance on
where to make the updates. where to make the updates.
The draft has been improved as a result of comments from a number of The draft has been improved as a result of comments from a number of
reviewers, including Ben Campbell, Brian Carpenter, Benoit Claise, reviewers, including Ben Campbell, Brian Carpenter, Benoit Claise,
Spencer Dawkins, Gorry Fairhurst, Sue Hares, Ingemar Johansson, Naeem Spencer Dawkins, Gorry Fairhurst, Sue Hares, Ingemar Johansson, Naeem
Khademi, Mirja Kuehlewind, Karen Nielsen, Hilarie Orman, Eric Khademi, Mirja Kuehlewind, Karen Nielsen, Hilarie Orman, Eric
Rescorla, Adam Roach and Michael Welzl. Bob Briscoe's thorough Rescorla, Adam Roach and Michael Welzl. Bob Briscoe's thorough
review of an early version of this memo resulted in numerous reviews of multiple versions of this memo resulted in numerous
improvements including addition of the updates to the DCCP RFCs. improvements including addition of the updates to the DCCP RFCs.
8. IANA Considerations 8. IANA Considerations
To reflect the reclassification of RFC 3540 as Historic, IANA is To reflect the reclassification of RFC 3540 as Historic, IANA is
requested to update the Transmission Control Protocol (TCP) Header requested to update the Transmission Control Protocol (TCP) Header
Flags registry (https://www.iana.org/assignments/tcp-header-flags/ Flags registry (https://www.iana.org/assignments/tcp-header-flags/
tcp-header-flags.xhtml#tcp-header-flags-1) to remove the registration tcp-header-flags.xhtml#tcp-header-flags-1) to remove the registration
of bit 7 as the NS (Nonce Sum) bit and add an annotation to the of bit 7 as the NS (Nonce Sum) bit and add an annotation to the
registry to state that bit 7 was used by Historic RFC 3540 as the NS registry to state that bit 7 was used by Historic RFC 3540 as the NS
skipping to change at page 17, line 38 skipping to change at page 17, line 48
[I-D.bagnulo-tcpm-generalized-ecn] [I-D.bagnulo-tcpm-generalized-ecn]
Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit
Congestion Notification (ECN) to TCP Control Packets", Congestion Notification (ECN) to TCP Control Packets",
draft-bagnulo-tcpm-generalized-ecn-04 (work in progress), draft-bagnulo-tcpm-generalized-ecn-04 (work in progress),
May 2017. May 2017.
[I-D.ietf-tcpm-alternativebackoff-ecn] [I-D.ietf-tcpm-alternativebackoff-ecn]
Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,
"TCP Alternative Backoff with ECN (ABE)", draft-ietf-tcpm- "TCP Alternative Backoff with ECN (ABE)", draft-ietf-tcpm-
alternativebackoff-ecn-01 (work in progress), May 2017. alternativebackoff-ecn-03 (work in progress), October
2017.
[I-D.ietf-tcpm-dctcp] [I-D.ietf-tcpm-dctcp]
Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L.,
and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion
Control for Datacenters", draft-ietf-tcpm-dctcp-10 (work Control for Datacenters", draft-ietf-tcpm-dctcp-10 (work
in progress), August 2017. in progress), August 2017.
[I-D.ietf-trill-ecn-support] [I-D.ietf-trill-ecn-support]
Eastlake, D. and B. Briscoe, "TRILL: ECN (Explicit Eastlake, D. and B. Briscoe, "TRILL: ECN (Explicit
Congestion Notification) Support", draft-ietf-trill-ecn- Congestion Notification) Support", draft-ietf-trill-ecn-
skipping to change at page 18, line 14 skipping to change at page 18, line 25
[I-D.ietf-tsvwg-ecn-encap-guidelines] [I-D.ietf-tsvwg-ecn-encap-guidelines]
Briscoe, B., Kaippallimalil, J., and P. Thaler, Briscoe, B., Kaippallimalil, J., and P. Thaler,
"Guidelines for Adding Congestion Notification to "Guidelines for Adding Congestion Notification to
Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn- Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn-
encap-guidelines-09 (work in progress), July 2017. encap-guidelines-09 (work in progress), July 2017.
[I-D.ietf-tsvwg-ecn-l4s-id] [I-D.ietf-tsvwg-ecn-l4s-id]
Schepper, K. and B. Briscoe, "Identifying Modified Schepper, K. and B. Briscoe, "Identifying Modified
Explicit Congestion Notification (ECN) Semantics for Explicit Congestion Notification (ECN) Semantics for
Ultra-Low Queuing Delay", draft-ietf-tsvwg-ecn-l4s-id-00 Ultra-Low Queuing Delay", draft-ietf-tsvwg-ecn-l4s-id-01
(work in progress), May 2017. (work in progress), October 2017.
[I-D.ietf-tsvwg-rfc6040update-shim] [I-D.ietf-tsvwg-rfc6040update-shim]
Briscoe, B., "Propagating Explicit Congestion Notification Briscoe, B., "Propagating Explicit Congestion Notification
Across IP Tunnel Headers Separated by a Shim", draft-ietf- Across IP Tunnel Headers Separated by a Shim", draft-ietf-
tsvwg-rfc6040update-shim-04 (work in progress), July 2017. tsvwg-rfc6040update-shim-05 (work in progress), November
2017.
[I-D.khademi-tsvwg-ecn-response] [I-D.khademi-tsvwg-ecn-response]
Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,
"Updating the Explicit Congestion Notification (ECN) "Updating the Explicit Congestion Notification (ECN)
Specification to Allow IETF Experimentation", draft- Specification to Allow IETF Experimentation", draft-
khademi-tsvwg-ecn-response-01 (work in progress), July khademi-tsvwg-ecn-response-01 (work in progress), July
2016. 2016.
[RFC4774] Floyd, S., "Specifying Alternate Semantics for the [RFC4774] Floyd, S., "Specifying Alternate Semantics for the
Explicit Congestion Notification (ECN) Field", BCP 124, Explicit Congestion Notification (ECN) Field", BCP 124,
skipping to change at page 21, line 10 skipping to change at page 21, line 25
o Improve explanation of attack response exception to not dropping o Improve explanation of attack response exception to not dropping
packets "solely because the ECN field in the IP header does not packets "solely because the ECN field in the IP header does not
contain Not-ECT" in Section 4.3 contain Not-ECT" in Section 4.3
o Fix L4S draft reference for discussion of ECN Nonce alternatives - o Fix L4S draft reference for discussion of ECN Nonce alternatives -
it's Appendix C.1, not B.1. it's Appendix C.1, not B.1.
o Numerous additional editorial changes from IESG Evaluation o Numerous additional editorial changes from IESG Evaluation
Changes from draft-ietf-tsvwg-ecn-experimentation-07 to -08:
o Edits from another careful review by Bob Briscoe. The primary
change is an editorial rewrite of Section 2.2 including changing
its name to better reflect its content.
Author's Address Author's Address
David Black David Black
Dell EMC Dell EMC
176 South Street 176 South Street
Hopkinton, MA 01748 Hopkinton, MA 01748
USA USA
Email: david.black@dell.com Email: david.black@dell.com
 End of changes. 27 change blocks. 
73 lines changed or deleted 88 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/