< draft-ietf-tsvwg-ecn-experimentation-06.txt   draft-ietf-tsvwg-ecn-experimentation-07.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 September 20, 2017 Updates: 3168, 4341, 4342, 5622, 6679 October 20, 2017
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: March 24, 2018 Expires: April 23, 2018
Explicit Congestion Notification (ECN) Experimentation Relaxing Restrictions on Explicit Congestion Notification (ECN)
draft-ietf-tsvwg-ecn-experimentation-06 Experimentation
draft-ietf-tsvwg-ecn-experimentation-07
Abstract Abstract
This memo updates RFC 3168, which specifies Explicit Congestion This memo updates RFC 3168, which specifies Explicit Congestion
Notification (ECN) as a replacement for packet drops as indicators of Notification (ECN) as an alternative to packet drops for indicating
network congestion. It relaxes restrictions in RFC 3168 that would network congestion to endpoints. It relaxes restrictions in RFC 3168
otherwise hinder experimentation towards benefits beyond just removal that hinder experimentation towards benefits beyond just removal of
of loss. This memo summarizes the anticipated areas of loss. This memo summarizes the anticipated areas of experimentation
experimentation and updates RFC 3168 to enable experimentation in and updates RFC 3168 to enable experimentation in these areas. An
these areas. An Experimental RFC is required to take advantage of Experimental RFC in the IETF document stream is required to take
any of these enabling updates. In addition, this memo makes related advantage of any of these enabling updates. In addition, this memo
updates to the ECN specifications for RTP in RFC 6679 and for DCCP in makes related updates to the ECN specifications for RTP in RFC 6679
RFC 4341, RFC 4342 and RFC 5622. This memo also records the and for DCCP in RFC 4341, RFC 4342 and RFC 5622. This memo also
conclusion of the ECN nonce experiment in RFC 3540, and provides the records the conclusion of the ECN nonce experiment in RFC 3540, and
rationale for reclassification of RFC 3540 as Historic; this provides the rationale for reclassification of RFC 3540 as Historic;
reclassification enables new experimental use of the ECT(1) this reclassification enables new experimental use of the ECT(1)
codepoint. codepoint.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 March 24, 2018. This Internet-Draft will expire on April 23, 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 37 skipping to change at page 2, line 37
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
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. Proposed ECN Experiments: Background . . . . . . . . . . . . 4 2. ECN Experimentation: Overview . . . . . . . . . . . . . . . . 4
3. ECN Nonce and RFC 3540 . . . . . . . . . . . . . . . . . . . 5 2.1. Effective Congestion Control is Required . . . . . . . . 5
4. Updates to RFC 3168 . . . . . . . . . . . . . . . . . . . . . 6 2.2. Considerations for Other Protocols . . . . . . . . . . . 5
4.1. Congestion Response Differences . . . . . . . . . . . . . 6 2.3. Operational and Management Considerations . . . . . . . . 6
4.2. Congestion Marking Differences . . . . . . . . . . . . . 8 3. ECN Nonce and RFC 3540 . . . . . . . . . . . . . . . . . . . 7
4.3. TCP Control Packets and Retransmissions . . . . . . . . . 10 4. Updates to RFC 3168 . . . . . . . . . . . . . . . . . . . . . 8
4.4. Effective Congestion Control is Required . . . . . . . . 11 4.1. Congestion Response Differences . . . . . . . . . . . . . 8
5. ECN for RTP Updates to RFC 6679 . . . . . . . . . . . . . . . 12 4.2. Congestion Marking Differences . . . . . . . . . . . . . 9
6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622 . . . . . . 13 4.3. TCP Control Packets and Retransmissions . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 5. ECN for RTP Updates to RFC 6679 . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622 . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 17
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 a replacement for packet drops as Congestion Notification (ECN) as an alternative to packet drops for
indicators of network congestion. It relaxes restrictions in RFC indicating network congestion to endpoints. It relaxes restrictions
3168 that would otherwise hinder experimentation towards benefits in RFC 3168 that hinder experimentation towards benefits beyond just
beyond just removal of loss. This memo summarizes the proposed areas removal of loss. This memo summarizes the proposed areas of
of experimentation and updates RFC 3168 to enable experimentation in experimentation and updates RFC 3168 to enable experimentation in
these areas. An Experimental RFC MUST be published for any protocol these areas. An Experimental RFC in the IETF document stream
or mechanism that takes advantage of any of these enabling updates. [RFC4844] is required to take advantage of any of these enabling
Putting all of these updates into a single document enables updates. Putting all of these updates into a single document enables
experimentation to proceed without requiring a standards process experimentation to proceed without requiring a standards process
exception for each Experimental RFC that needs changes to RFC 3168, a exception for each Experimental RFC that needs changes to RFC 3168, a
Proposed Standard RFC. Proposed Standard RFC.
There is no need to make changes for protocols and mechanisms that There is no need for this memo to update RFC 3168 to simplify
are documented in Standards Track RFCs, as any Standards Track RFC standardization of protocols and mechanisms that are documented in
can update RFC 3168 without needing a standards process exception. Standards Track RFCs, as any Standards Track RFC can update RFC 3168
directly without either relying on updates in this memo or using a
standards process exception.
In addition, this memo makes related updates to the ECN specification In addition, this memo makes related updates to the ECN specification
for RTP [RFC6679] and for three DCCP profiles ([RFC4341], [RFC4342] for RTP [RFC6679] and for three DCCP profiles ([RFC4341], [RFC4342]
and [RFC5622]) for the same reason. Each experiment is still and [RFC5622]) for the same reason. Each experiment is still
required to be documented in one or more separate RFCs, but use of required to be documented in one or more separate RFCs, but use of
Experimental RFCs for this purpose does not require a process Experimental RFCs for this purpose does not require a process
exception to modify any of these Proposed Standard RFCs when the exception to modify any of these Proposed Standard RFCs when the
modification falls within the bounds established by this memo (RFC modification falls within the bounds established by this memo (RFC
5622 is an Experimental RFC; it is modified by this memo for 5622 is an Experimental RFC; it is modified by this memo for
consistency with modifications to the other two DCCP RFCs). consistency with modifications to the other two DCCP RFCs).
skipping to change at page 4, line 16 skipping to change at page 4, line 19
node sets to indicate congestion. A node sets an increasing node sets to indicate congestion. A node sets an increasing
proportion of ECT packets to CE as the level of congestion increases. proportion of ECT packets to CE as the level of congestion increases.
1.2. Requirements Language 1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"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. Proposed ECN Experiments: Background 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: As discussed further in Congestion Response Differences: An ECN congestion indication
Section 4.1, an ECN congestion indication communicates a higher communicates a higher likelihood that a shorter queue exists at
likelihood that a shorter queue exists at the network bottleneck the network bottleneck node by comparison to a longer queue that
node by comparison to a packet drop that indicates congestion 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., reduce the response so that the sender congestion response (e.g., sender backs off by a smaller amount)
backs off by a smaller amount) may be appropriate by comparison to may be appropriate by comparison to the sender response to
the sender response to congestion indicated by loss, e.g., as congestion indicated by loss. Two examples of proposed sender
proposed in [I-D.ietf-tcpm-alternativebackoff-ecn] and congestion response changes are described in
[I-D.ietf-tsvwg-ecn-l4s-id] - the experiment in the latter draft [I-D.ietf-tcpm-alternativebackoff-ecn] and
couples the backoff change to Congestion Marking Differences [I-D.ietf-tsvwg-ecn-l4s-id] - the proposal in the latter draft
changes (next bullet). This is at variance with RFC 3168's couples the sender congestion response change to Congestion
requirement that a sender's congestion control response to ECN Marking Differences changes (see next paragraph). This is at
congestion indications be the same as to drops. IETF approval, variance with RFC 3168's requirement that a sender's congestion
e.g., via an Experimental RFC, is required for any sender control response to ECN congestion indications be the same as to
congestion response used in this area of experimentation. drops. IETF approval, e.g., via an Experimental RFC in the IETF
document stream, is required for any sender congestion response
used in this area of experimentation. See Section 4.1 for further
discussion.
Congestion Marking Differences: As discussed further in Section 4.2, Congestion Marking Differences: Congestion marking at network nodes
when taken to its limit, congestion marking at network nodes can can be configured to maintain very shallow queues in conjunction
be configured to maintain very shallow queues in conjunction with with a different sender response to congestion indications (CE
a different IETF-approved congestion response to congestion marks), e.g., as proposed in [I-D.ietf-tsvwg-ecn-l4s-id]. The
indications (CE marks) at the sender, e.g., as proposed in traffic involved needs to be identified by the senders to the
[I-D.ietf-tsvwg-ecn-l4s-id]. The traffic involved needs to be network nodes in order to avoid damage to other network traffic
identified by the senders to the network nodes in order to avoid whose senders do not expect the more frequent congestion marking
damage to other network traffic whose senders do not expect the used to maintain very shallow queues. Use of different ECN
more frequent congestion marking used to maintain very shallow codepoints, specifically ECT(0) and ECT(1), is a promising means
queues. Use of different ECN codepoints, specifically ECT(0) and of traffic identification for this purpose, but that technique is
ECT(1), is a promising means of traffic identification for this at variance with RFC 3168's requirement that ECT(0)-marked traffic
purpose, but that technique is at variance with RFC 3168's and ECT(1)-marked traffic not receive different treatment in the
requirement that ECT(0)-marked traffic and ECT(1)-marked traffic network. IETF approval, e.g., via an Experimental RFC in the IETF
not receive different treatment in the network. document stream, is required for any sender congestion response
used in this area of 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. retransmitted packets. See Section 4.3 for further discussion.
The scope of this memo is limited to these three areas of The scope of this memo is limited to these three areas of
experimentation. This memo expresses no view on the likely outcomes experimentation. This memo expresses no view on the likely outcomes
of the proposed experiments and does not specify the experiments in of the proposed experiments and does not specify the experiments in
detail. Additional experiments in these areas are possible, e.g., on detail. Additional experiments in these areas are possible, e.g., on
use of ECN to support deployment of a protocol similar to DCTCP use of ECN to support deployment of a protocol similar to DCTCP
[I-D.ietf-tcpm-dctcp] beyond DCTCP's current applicability that is [I-D.ietf-tcpm-dctcp] beyond DCTCP's current applicability that is
limited to data center environments. The purpose of this memo is to limited to data center environments. The purpose of this memo is to
remove constraints in standards track RFCs that stand in the way of remove constraints in standards track RFCs that stand in the way of
these areas of experimentation. these areas of experimentation.
2.1. Effective Congestion Control is Required
Congestion control remains an important aspect of the Internet
architecture [RFC2914]. Any Experimental RFC in the IETF document
stream that takes advantage of this memo's updates to any RFC is
required to discuss the congestion control implications of the
experiment(s) in order to provide assurance that deployment of the
experiment(s) does not pose a congestion-based threat to the
operation of the Internet.
2.2. Considerations for Other Protocols
ECN is widely deployed in the Internet and is being designed into
additional protocols such as TRILL [I-D.ietf-trill-ecn-support].
While the responsibility for coexistence with other protocols and
transition from current ECN functionality falls primary upon the
designers of experimental changes to ECN, this subsection provides
some general guidelines for designers and users of other protocols
that minimize the likelihood of interaction with the areas of ECN
experimentation enabled by this memo.
1. RFC 3168's forwarding behavior remains the preferred approach for
routers that are not involved in ECN experiments, in particular
continuing to treat the ECT(0) and ECT(1) codepoints as
equivalent, as specified in Section 4.2 below.
2. The ECN CE codepoint SHOULD NOT be assumed to indicate that the
packet would have been dropped if ECN were not in use, as that is
not the case for either Congestion Response Differences
experiments (see Section 4.1 below) or Congestion Marking
Differences experiments (see Section 4.2 below). This is already
the case when the ECN field is used for Pre-Congestion
Notification (PCN) [RFC6660].
3. Traffic marked with ECT(1) MUST NOT be originated, as specified
in Section 4.2 below.
4. ECN may now be used on packets where it has not been used
previously, specifically TCP control packets and retransmissions,
see Section 4.3 below, and in particular its new requirements for
middlebox behavior. In general, any system or protocol that
inspects or monitors network traffic SHOULD be prepared to
encounter ECN usage on packets and traffic that currently do not
use ECN.
5. Requirements for handling of the ECN field by tunnel
encapsulation and decapsulation are specified in [RFC6040].
Additional related guidance can be found in
[I-D.ietf-tsvwg-ecn-encap-guidelines] and
[I-D.ietf-tsvwg-rfc6040update-shim].
2.3. Operational and Management Considerations
Changes in network traffic behavior that result from ECN
experimentation are likely to impact network operations and
management. Designers of ECN experiments are expected to anticipate
possible impacts and consider how they may be dealt with. Specific
topics to consider include possible network management changes or
extensions, monitoring of the experimental deployment, collection of
data for evaluation of the experiment and possible interactions with
other protocols, particularly protocols that encapsulate network
traffic.
For further discussion, see [RFC5706]; the questions in Appendix A
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).
with the second codepoint used to support ECN nonce functionality to The second codepoint, ECT(1), is used to support ECN nonce
discourage receivers from exploiting ECN to improve their throughput functionality that discourages receivers from exploiting ECN to
at the expense of other network users, as specified in experimental improve their throughput at the expense of other network users, as
RFC 3540 [RFC3540]. This section explains why RFC 3540 is being specified in Experimental RFC 3540 [RFC3540]. This section explains
reclassified as Historic and makes associated updates to RFC 3168. why RFC 3540 is being reclassified 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 re- ECN nonce by these 4 servers, but might equally have been due to
marking of the ECN field by an erroneous middlebox or router. erroneous re-marking of the ECN field by a middlebox or router.
With the emergence of new experimental functionality that depends on With the emergence of new experimental functionality that depends on
use of the ECT(1) codepoint for other purposes, continuing to reserve use of the ECT(1) codepoint for other purposes, continuing to reserve
that codepoint for the ECN nonce experiment is no longer justified. that codepoint for the ECN nonce experiment is no longer justified.
In addition, other approaches to discouraging receivers from In addition, other approaches to discouraging receivers from
exploiting ECN have emerged, see Appendix B.1 of exploiting ECN have emerged, see Appendix B.1 of
[I-D.ietf-tsvwg-ecn-l4s-id]. Therefore, in support of ECN [I-D.ietf-tsvwg-ecn-l4s-id]. Therefore, in support of ECN
experimentation with the ECT(1) codepoint, this memo: experimentation with the ECT(1) codepoint, this memo:
o Declares that the ECN nonce experiment [RFC3540] has concluded, o Declares that the ECN nonce experiment [RFC3540] has concluded,
and notes the absence of widespread deployment. and notes the absence of widespread deployment.
o Updates RFC 3168 [RFC3168] to remove discussion of the ECN nonce o Updates RFC 3168 [RFC3168] to remove discussion of the ECN nonce
and use of ECT(1) for that nonce. and use of ECT(1) for that nonce.
The four primary updates to RFC 3168 that remove discussion of the The four primary updates to RFC 3168 that remove discussion of the
skipping to change at page 6, line 32 skipping to change at page 8, line 10
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 alternate uses for the fourth
ECN codepoint. ECN codepoint.
Additional minor changes remove other mentions of the ECN nonce and In addition, other less substantive RFC 3168 changes are required to
implications that ECT(1) is intended for use by the ECN nonce; the remove all other mentions of the ECN nonce and to remove implications
specific text updates are omitted for brevity. that ECT(1) is intended for use by the ECN nonce; these specific text
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
three areas of experimentation summarized in Section 2. three areas of experimentation summarized in Section 2.
4.1. Congestion Response Differences 4.1. Congestion Response Differences
RFC 3168 specifies that senders respond identically to packet drops RFC 3168 specifies that senders respond identically to packet drops
and ECN congestion indications. ECN congestion indications are and ECN congestion indications. ECN congestion indications are
skipping to change at page 7, line 9 skipping to change at page 8, line 37
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 that a shorter queue exists at the network
bottleneck node by comparison to a packet drop that indicates bottleneck node by comparison to a packet drop that indicates
congestion [I-D.ietf-tcpm-alternativebackoff-ecn]. This difference congestion [I-D.ietf-tcpm-alternativebackoff-ecn]. This difference
suggests that for congestion indicated by ECN, a different sender suggests that for congestion indicated by ECN, a different sender
congestion response (e.g., reduce the response so that the sender congestion response (e.g., sender backs off by a smaller amount) may
backs off by a smaller amount) may be appropriate by comparison to be appropriate by comparison to the sender response to congestion
the sender response to congestion indicated by loss. However, indicated by loss. However, section 5 of RFC 3168 specifies that:
section 5 of RFC 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
Experimental RFC. The specific change to RFC 3168 is to insert the Experimental RFC in the IETF document stream. The specific change to
words "unless otherwise specified by an Experimental RFC" at the end RFC 3168 is to insert the words "unless otherwise specified by an
of the sentence quoted above. Experimental RFC in the IETF document stream" at the end of the
sentence quoted above.
RFC 4774 [RFC4774] quotes the above text from RFC 3168 as background, RFC 4774 [RFC4774] quotes the above text from RFC 3168 as background,
but does not impose requirements based on that text. Therefore no but does not impose requirements based on that text. Therefore no
update to RFC 4774 is required to enable this area of update to RFC 4774 is required to enable this area of
experimentation. experimentation.
Section 6.1.2 of RFC 3168 specifies that: Section 6.1.2 of RFC 3168 specifies that:
If the sender receives an ECN-Echo (ECE) ACK packet (that is, an If the sender receives an ECN-Echo (ECE) ACK packet (that is, an
ACK packet with the ECN-Echo flag set in the TCP header), then the ACK packet with the ECN-Echo flag set in the TCP header), then the
sender knows that congestion was encountered in the network on the sender knows that congestion was encountered in the network on the
path from the sender to the receiver. The indication of path from the sender to the receiver. The indication of
congestion should be treated just as a congestion loss in non- congestion should be treated just as a congestion loss in non-
ECN-Capable TCP. That is, the TCP source halves the congestion ECN-Capable TCP. That is, the TCP source halves the congestion
window "cwnd" and reduces the slow start threshold "ssthresh". window "cwnd" and reduces the slow start threshold "ssthresh".
This memo also updates this RFC 3168 text to allow the congestion This memo also updates this RFC 3168 text to allow the congestion
control response (including the TCP Sender's congestion control control response (including the TCP Sender's congestion control
response) to a CE-marked packet to differ from the response to a response) to a CE-marked packet to differ from the response to a
dropped packet, provided that the changes from RFC 3168 are dropped packet, provided that the changes from RFC 3168 are
documented in an Experimental RFC. The specific change to RFC 3168 documented in an Experimental RFC in the IETF document stream. The
is to insert the words "Unless otherwise specified by an Experimental specific change to RFC 3168 is to insert the words "Unless otherwise
RFC" at the beginning of the second sentence quoted above. specified by an Experimental RFC in the IETF document stream" at the
beginning of the second sentence quoted above.
4.2. Congestion Marking Differences 4.2. Congestion Marking Differences
Taken to its limit, an AQM algorithm that uses ECN congestion Taken to its limit, an AQM algorithm that uses ECN congestion
indications can be configured to maintain very shallow queues, indications can be configured to maintain very shallow queues,
thereby reducing network latency by comparison to maintaining a thereby reducing network latency by comparison to maintaining a
larger queue. Significantly more aggressive sender responses to ECN larger queue. Significantly more aggressive sender responses to ECN
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 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) counterbalanced by use of a different IETF-
approved congestion response to CE marks at the sender, e.g., as approved congestion response to CE marks at the sender, e.g., as
proposed in [I-D.ietf-tsvwg-ecn-l4s-id]. 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. The specific change to 3168 are documented in an Experimental RFC in the IETF document
RFC 3168 is to insert the words "unless otherwise specified by an stream. The specific change to RFC 3168 is to insert the words
Experimental RFC" at the end of the above sentence. "unless otherwise specified by an Experimental RFC in the IETF
document stream" at the end of the above sentence.
When an AQM is configured to use ECN congestion indications to When an AQM is configured to use ECN congestion indications to
maintain a very shallow queue, congestion indications are marked on maintain a very shallow queue, congestion indications are marked on
packets that would not have been dropped if ECN was not in use. packets that would not have been dropped if ECN was not in use.
Section 5 of RFC 3168 specifies that: Section 5 of RFC 3168 specifies that:
For a router, the CE codepoint of an ECN-Capable packet SHOULD For a router, the CE codepoint of an ECN-Capable packet SHOULD
only be set if the router would otherwise have dropped the packet only be set if the router would otherwise have dropped the packet
as an indication of congestion to the end nodes. When the as an indication of congestion to the end nodes. When the
router's buffer is not yet full and the router is prepared to drop router's buffer is not yet full and the router is prepared to drop
a packet to inform end nodes of incipient congestion, the router a packet to inform end nodes of incipient congestion, the router
should first check to see if the ECT codepoint is set in that should first check to see if the ECT codepoint is set in that
packet's IP header. If so, then instead of dropping the packet, packet's IP header. If so, then instead of dropping the packet,
the router MAY instead set the CE codepoint in the IP header. the router MAY instead set the CE codepoint in the IP header.
This memo updates RFC 3168 to allow congestion indications that are This memo updates RFC 3168 to allow congestion indications that are
not equivalent to drops, provided that the changes from RFC 3168 are not equivalent to drops, provided that the changes from RFC 3168 are
documented in an Experimental RFC. The specific change is to change documented in an Experimental RFC in the IETF document stream. The
"For a router," to "Unless otherwise specified by an Experimental specific change is to change "For a router," to "Unless otherwise
RFC" at the beginning of the first sentence of the above paragraph. specified by an Experimental RFC in the IETF document stream" at the
beginning of the first sentence of the above paragraph.
A larger update to RFC 3168 is necessary to enable sender usage of A larger update to RFC 3168 is necessary to enable sender usage of
ECT(1) to request network congestion marking behavior that maintains ECT(1) to request network congestion marking behavior that maintains
very shallow queues at network nodes. When using loss as a very shallow queues at network nodes. When using loss as a
congestion signal, the number of signals provided should be reduced congestion signal, the number of signals provided should be reduced
to a minimum and hence only presence or absence of congestion is to a minimum and hence only presence or absence of congestion is
communicated. In contrast, ECN can provide a richer signal, e.g., to communicated. In contrast, ECN can provide a richer signal, e.g., to
indicate the current level of congestion, without the disadvantage of indicate the current level of congestion, without the disadvantage of
a larger number of packet losses. A proposed experiment in this a larger number of packet losses. A proposed experiment in this
area, Low Latency Low Loss Scalable throughput (L4S) area, Low Latency Low Loss Scalable throughput (L4S)
skipping to change at page 9, line 27 skipping to change at page 11, line 7
probability for ECT(1)-marked traffic in a fashion that would probability for ECT(1)-marked traffic in a fashion that would
interact badly with existing sender congestion response functionality interact badly with existing sender congestion response functionality
because that functionality assumes that the network marks ECT packets because that functionality assumes that the network marks ECT packets
as frequently as it would drop Not-ECT packets. If network traffic as frequently as it would drop Not-ECT packets. If network traffic
that uses such a conventional sender congestion response were to that uses such a conventional sender congestion response were to
encounter L4S's increased marking probability (and hence rate) at a encounter L4S's increased marking probability (and hence rate) at a
network bottleneck queue, the resulting traffic throughput is likely network bottleneck queue, the resulting traffic throughput is likely
to be much less than intended for the level of congestion at the to be much less than intended for the level of congestion at the
bottleneck queue. bottleneck queue.
To avoid that interaction, this memo reserves ECT(1) for This memo updates RFC 3168 to remove that interaction for ECT(1).
experimentation, initially for L4S. The specific update to Section 5 The specific update to Section 5 of RFC 3168 is to replace the
of RFC 3168 is to remove the following two paragraphs: following two paragraphs:
Senders are free to use either the ECT(0) or the ECT(1) codepoint Senders are free to use either the ECT(0) or the ECT(1) codepoint
to indicate ECT, on a packet-by-packet basis. to indicate ECT, on a packet-by-packet basis.
The use of both the two codepoints for ECT, ECT(0) and ECT(1), is The use of both the two codepoints for ECT, ECT(0) and ECT(1), is
motivated primarily by the desire to allow mechanisms for the data motivated primarily by the desire to allow mechanisms for the data
sender to verify that network elements are not erasing the CE sender to verify that network elements are not erasing the CE
codepoint, and that data receivers are properly reporting to the codepoint, and that data receivers are properly reporting to the
sender the receipt of packets with the CE codepoint set, as sender the receipt of packets with the CE codepoint set, as
required by the transport protocol. Guidelines for the senders required by the transport protocol. Guidelines for the senders
and receivers to differentiate between the ECT(0) and ECT(1) and receivers to differentiate between the ECT(0) and ECT(1)
codepoints will be addressed in separate documents, for each codepoints will be addressed in separate documents, for each
transport protocol. In particular, this document does not address transport protocol. In particular, this document does not address
mechanisms for TCP end-nodes to differentiate between the ECT(0) mechanisms for TCP end-nodes to differentiate between the ECT(0)
and ECT(1) codepoints. Protocols and senders that only require a and ECT(1) codepoints. Protocols and senders that only require a
single ECT codepoint SHOULD use ECT(0). single ECT codepoint SHOULD use ECT(0).
and replace it with this paragraph: with this paragraph:
Protocols and senders MUST use the ECT(0) codepoint to indicate Protocols and senders MUST use the ECT(0) codepoint to indicate
ECT unless otherwise specified by an Experimental RFC. Guidelines ECT unless otherwise specified by an Experimental RFC in the IETF
for senders and receivers to differentiate between the ECT(0) and document stream. Protocols and senders MUST NOT use the ECT(1)
codepoint to indicate ECT unless otherwise specified by an
Experimental RFC in the IETF document stream. Guidelines for
senders and receivers to differentiate between the ECT(0) and
ECT(1) codepoints will be addressed in separate documents, for ECT(1) codepoints will be addressed in separate documents, for
each transport protocol. In particular, this document does not each transport protocol. In particular, this document does not
address mechanisms for TCP end-nodes to differentiate between the address mechanisms for TCP end-nodes to differentiate between the
ECT(0) and ECT(1) codepoints. ECT(0) and ECT(1) codepoints.
Congestion Marking Differences experiments SHOULD modify the network Congestion Marking Differences experiments SHOULD modify the network
behavior for ECT(1)-marked traffic rather than ECT(0)-marked traffic behavior for ECT(1)-marked traffic rather than ECT(0)-marked traffic
if network behavior for only one ECT codepoint is modified. if network behavior for only one ECT codepoint is modified.
Congestion Marking Differences experiments MUST NOT modify the Congestion Marking Differences experiments MUST NOT modify the
network behavior for ECT(0)-marked traffic in a fashion that requires network behavior for ECT(0)-marked traffic in a fashion that requires
changes to sender congestion response to obtain desired network changes to sender congestion response to obtain desired network
behavior. If a Congestion Marking Differences experiment modifies behavior. If a Congestion Marking Differences experiment modifies
the network behavior for ECT(1)-marked traffic, e.g., CE-marking the network behavior for ECT(1)-marked traffic, e.g., CE-marking
behavior, in a fashion that requires changes to sender congestion behavior, in a fashion that requires changes to sender congestion
response to obtain desired network behavior, then the Experimental response to obtain desired network behavior, then the Experimental
RFC for that experiment MUST specify: RFC in the IETF document stream for that experiment MUST specify:
o The sender congestion response to CE marking in the network, and o The sender congestion response to CE marking in the network, and
o Router behavior changes, or the absence thereof, in forwarding CE- o Router behavior changes, or the absence thereof, in forwarding CE-
marked packets that are part of the experiment. marked packets that are part of the experiment.
In addition, until the conclusion of the L4S experiment, use of
ECT(1) in IETF RFCs is not appropriate, as the IETF may decide to
allocate ECT(1) exclusively for L4S usage if the L4S experiment is
successful.
In addition, this memo updates RFC 3168 to remove discussion of the In addition, this memo updates RFC 3168 to remove discussion of the
ECN nonce, as noted in Section 3 above. ECN nonce, as noted in Section 3 above.
4.3. TCP Control Packets and Retransmissions 4.3. TCP Control Packets and Retransmissions
With the successful use of ECN for traffic in large portions of the With the successful use of ECN for traffic in large portions of the
Internet, there is interest in extending the benefits of ECN to TCP Internet, there is interest in extending the benefits of ECN to TCP
control packets (e.g., SYNs) and retransmitted packets, e.g., as control packets (e.g., SYNs) and retransmitted packets, e.g., as
proposed by ECN++ [I-D.bagnulo-tcpm-generalized-ecn]. proposed by ECN++ [I-D.bagnulo-tcpm-generalized-ecn].
skipping to change at page 11, line 22 skipping to change at page 12, line 49
ignore the ECN field on arriving data packets that are outside of ignore the ECN field on arriving data packets that are outside of
the receiver's current window." (Section 6.1.5) the receiver's current window." (Section 6.1.5)
o "the TCP data sender MUST NOT set either an ECT codepoint or the o "the TCP data sender MUST NOT set either an ECT codepoint or the
CWR bit on window probe packets." (Section 6.1.6) CWR bit on window probe packets." (Section 6.1.6)
This memo updates RFC 3168 to allow the use of ECT codepoints on SYN This memo updates RFC 3168 to allow the use of ECT codepoints on SYN
and SYN-ACK packets, pure acknowledgement packets, window probe and SYN-ACK packets, pure acknowledgement packets, window probe
packets and retransmissions of packets that were originally sent with packets and retransmissions of packets that were originally sent with
an ECT codepoint, provided that the changes from RFC 3168 are an ECT codepoint, provided that the changes from RFC 3168 are
documented in an Experimental RFC. The specific change to RFC 3168 documented in an Experimental RFC in the IETF document stream. The
is to insert the words "unless otherwise specified by an Experimental specific change to RFC 3168 is to insert the words "unless otherwise
RFC" at the end of each sentence quoted above. specified by an Experimental RFC in the IETF document stream" at the
end of each sentence quoted above.
In addition, beyond requiring TCP senders not to set ECT on TCP In addition, beyond requiring TCP senders not to set ECT on TCP
control packets and retransmitted packets, RFC 3168 is silent on control packets and retransmitted packets, RFC 3168 is silent on
whether it is appropriate for a network element, e.g. a firewall, to whether it is appropriate for a network element, e.g. a firewall, to
discard such a packet as invalid. For this area of ECN discard such a packet as invalid. For this area of ECN
experimentation to be useful, middleboxes ought not to do that, experimentation to be useful, middleboxes ought not to do that,
therefore RFC 3168 is updated by adding the following text to the end therefore RFC 3168 is updated by adding the following text to the end
of Section 6.1.1.1 on Middlebox Issues: of Section 6.1.1.1 on Middlebox Issues:
Unless otherwise specified by an Experimental RFC, middleboxes Unless otherwise specified by an Experimental RFC in the IETF
SHOULD NOT discard TCP control packets and retransmitted TCP document stream, middleboxes SHOULD NOT discard TCP control
packets solely because the ECN field in the IP header does not packets and retransmitted TCP packets solely because the ECN field
contain Not-ECT. An exception to this requirement occurs in in the IP header does not contain Not-ECT. An exception to this
responding to an ongoing attack. For example, as part of the requirement occurs in responding to an attack that uses ECN
response, it may be appropriate to drop more ECT-marked TCP SYN codepoints other than Not-ECT. For example, as part of the
packets than TCP SYN packets marked with not-ECT. Any such response, it may be appropriate to drop ECT-marked TCP SYN packets
exceptional discarding of TCP control packets and retransmitted with higher probability than TCP SYN packets marked with not-ECT.
TCP packets in response to an attack MUST NOT be done routinely in Any such exceptional discarding of TCP control packets and
the absence of an attack and SHOULD only be done if it is retransmitted TCP packets in response to an attack MUST NOT be
determined that the ECT capability is contributing to the attack. done routinely in the absence of an attack and SHOULD only be done
if it is determined that the use of ECN is contributing to the
4.4. Effective Congestion Control is Required attack.
Congestion control remains an important aspect of the Internet
architecture [RFC2914]. Any Experimental RFC that takes advantage of
this memo's updates to any RFC is required to discuss the congestion
control implications of the experiment(s) in order to provide
assurance that deployment of the experiment(s) does not pose a
congestion-based threat to the operation of the Internet.
5. ECN for RTP Updates to RFC 6679 5. ECN for RTP Updates to RFC 6679
RFC 6679 [RFC6679] specifies use of ECN for RTP traffic; it allows RFC 6679 [RFC6679] specifies use of ECN for RTP traffic; it allows
use of both the ECT(0) and ECT(1) codepoints, and provides the use of both the ECT(0) and ECT(1) codepoints, and provides the
following guidance on use of these codepoints in section 7.3.1 : following guidance on use of these codepoints in section 7.3.1 :
The sender SHOULD mark packets as ECT(0) unless the receiver The sender SHOULD mark packets as ECT(0) unless the receiver
expresses a preference for ECT(1) or for a random ECT value using expresses a preference for ECT(1) or for a random ECT value using
the "ect" parameter in the "a=ecn-capable-rtp:" attribute. the "ect" parameter in the "a=ecn-capable-rtp:" attribute.
The Congestion Marking Differences area of experimentation increases The Congestion Marking Differences area of experimentation increases
the potential consequences of using ECT(1) instead of ECT(0), and the potential consequences of using ECT(1) instead of ECT(0), and
hence the above guidance is updated by adding the following two hence the above guidance is updated by adding the following two
sentences: sentences:
Random ECT values MUST NOT be used, as that may expose RTP to Random ECT values MUST NOT be used, as that may expose RTP to
differences in network treatment of traffic marked with ECT(1) and differences in network treatment of traffic marked with ECT(1) and
ECT(0) and differences in associated endpoint congestion ECT(0) and differences in associated endpoint congestion
responses, e.g., as proposed in [I-D.ietf-tsvwg-ecn-l4s-id]. In responses. In addition, ECT(0) MUST be used unless otherwise
addition, ECT(0) MUST be used unless otherwise specified in an specified in an Experimental RFC in the IETF document stream.
Experimental RFC.
Section 7.3.3 of RFC 6679 specifies RTP's response to receipt of CE Section 7.3.3 of RFC 6679 specifies RTP's response to receipt of CE
marked packets as being identical to the response to dropped packets: marked packets as being identical to the response to dropped packets:
The reception of RTP packets with ECN-CE marks in the IP header is The reception of RTP packets with ECN-CE marks in the IP header is
a notification that congestion is being experienced. The default a notification that congestion is being experienced. The default
reaction on the reception of these ECN-CE-marked packets MUST be reaction on the reception of these ECN-CE-marked packets MUST be
to provide the congestion control algorithm with a congestion to provide the congestion control algorithm with a congestion
notification that triggers the algorithm to react as if packet notification that triggers the algorithm to react as if packet
loss had occurred. There should be no difference in congestion loss had occurred. There should be no difference in congestion
response if ECN-CE marks or packet drops are detected. response if ECN-CE marks or packet drops are detected.
In support of Congestion Response Differences experimentation, this In support of Congestion Response Differences experimentation, this
memo updates this text in a fashion similar to RFC 3168 to allow the memo updates this text in a fashion similar to RFC 3168 to allow the
RTP congestion control response to a CE-marked packet to differ from RTP congestion control response to a CE-marked packet to differ from
the response to a dropped packet, provided that the changes from RFC the response to a dropped packet, provided that the changes from RFC
6679 are documented in an Experimental RFC. The specific change to 6679 are documented in an Experimental RFC in the IETF document
RFC 6679 is to insert the words "Unless otherwise specified by an stream. The specific change to RFC 6679 is to insert the words
Experimental RFC" and reformat the last two sentences to be subject "Unless otherwise specified by an Experimental RFC in the IETF
to that condition, i.e.: document stream" and reformat the last two sentences to be subject to
that condition, i.e.:
The reception of RTP packets with ECN-CE marks in the IP header is The reception of RTP packets with ECN-CE marks in the IP header is
a notification that congestion is being experienced. Unless a notification that congestion is being experienced. Unless
otherwise specified by an Experimental RFC: otherwise specified by an Experimental RFC in the IETF document
stream:
* The default reaction on the reception of these ECN-CE-marked * The default reaction on the reception of these ECN-CE-marked
packets MUST be to provide the congestion control algorithm packets MUST be to provide the congestion control algorithm
with a congestion notification that triggers the algorithm to with a congestion notification that triggers the algorithm to
react as if packet loss had occurred. react as if packet loss had occurred.
* There should be no difference in congestion response if ECN-CE * There should be no difference in congestion response if ECN-CE
marks or packet drops are detected. marks or packet drops are detected.
The second sentence of the immediately following paragraph in RFC The second sentence of the immediately following paragraph in RFC
6679 requires a related update: 6679 requires a related update:
Other reactions to ECN-CE may be specified in the future, Other reactions to ECN-CE may be specified in the future,
following IETF Review. Detailed designs of such additional following IETF Review. Detailed designs of such additional
reactions MUST be specified in a Standards Track RFC and be reactions MUST be specified in a Standards Track RFC and be
reviewed to ensure they are safe for deployment under any reviewed to ensure they are safe for deployment under any
restrictions specified. restrictions specified.
The update is to change "Standards Track RFC" to "Standards Track RFC The update is to change "Standards Track RFC" to "Standards Track RFC
or Experimental RFC" for consistency with the first update. or Experimental RFC in the IETF document stream" for consistency with
the first update.
6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622 6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622
The specifications of the three DCCP Congestion Control IDs (CCIDs) 2 The specifications of the three DCCP Congestion Control IDs (CCIDs) 2
[RFC4341], 3 [RFC4342] and 4 [RFC5622] contain broadly the same [RFC4341], 3 [RFC4342] and 4 [RFC5622] contain broadly the same
wording as follows: wording as follows:
each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable with each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable with
either the ECT(0) or the ECT(1) codepoint set. either the ECT(0) or the ECT(1) codepoint set.
This memo updates these sentences in each of the three RFCs as This memo updates these sentences in each of the three RFCs as
follows: follows:
each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable. each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable.
Unless otherwise specified by an Experimental RFC, such DCCP Unless otherwise specified by an Experimental RFC in the IETF
senders MUST set the ECT(0) codepoint. document stream, such DCCP senders MUST set the ECT(0) codepoint.
In support of Congestion Marking Differences experimentation (as In support of Congestion Marking Differences experimentation (as
noted in Section 3), this memo also updates all three of these RFCs noted in Section 3), this memo also updates all three of these RFCs
to remove discussion of the ECN nonce. The specific text updates are to remove discussion of the ECN nonce. The specific text updates are
omitted for brevity. omitted for brevity.
7. Acknowledgements 7. Acknowledgements
The content of this draft, including the specific portions of RFC The content of this draft, including the specific portions of RFC
3168 that are updated draws heavily from 3168 that are updated draws heavily from
[I-D.khademi-tsvwg-ecn-response], whose authors are gratefully [I-D.khademi-tsvwg-ecn-response], whose authors are gratefully
acknowledged. The authors of the Internet Drafts describing the acknowledged. The authors of the Internet Drafts describing the
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 Brian Carpenter, Spencer Dawkins, Gorry reviewers, including Ben Campbell, Brian Carpenter, Benoit Claise,
Fairhurst, Ingemar Johansson, Naeem Khademi, Mirja Kuehlewind, Karen Spencer Dawkins, Gorry Fairhurst, Sue Hares, Ingemar Johansson, Naeem
Nielsen, Hilarie Orman and Michael Welzl. Bob Briscoe's thorough Khademi, Mirja Kuehlewind, Karen Nielsen, Hilarie Orman, Eric
review of an early version of this draft resulted in numerous Rescorla, Adam Roach and Michael Welzl. Bob Briscoe's thorough
review of an early version 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
(Nonce Sum) bit. (Nonce Sum) bit.
9. Security Considerations 9. Security Considerations
As a process memo that only removes limitations on proposed As a process memo that only relaxes restrictions on experimentation,
experiments, there are no protocol security considerations. Security there are no protocol security considerations, as security
considerations for the proposed experiments are discussed in the considerations for any experiments that take advantage of the relaxed
Internet-Drafts that propose them. restrictions are discussed in the Internet-Drafts that propose the
experiments.
However, effective congestion control is crucial to the continued However, effective congestion control is crucial to the continued
operation of the Internet, and hence this memo places the operation of the Internet, and hence this memo places the
responsibility for not breaking Internet congestion control on the responsibility for not breaking Internet congestion control on the
experiments and the experimenters who propose them. This experiments and the experimenters who propose them. This
responsibility includes the requirement to discuss congestion control responsibility includes the requirement to discuss congestion control
implications in an Experimental RFC for each experiment, as stated in implications in an IETF document stream Experimental RFC for each
Section 4.4; review of that discussion by the IETF community and the experiment, as stated in Section 2.1; review of that discussion by
IESG prior to RFC publication is intended to provide assurance that the IETF community and the IESG prior to RFC publication is intended
each experiment does not break Internet congestion control. to provide assurance that each experiment does not break Internet
congestion control.
See Appendix B.1 of [I-D.ietf-tsvwg-ecn-l4s-id] for discussion of See Appendix C.1 of [I-D.ietf-tsvwg-ecn-l4s-id] for discussion of
alternatives to the ECN nonce. alternatives to the ECN nonce.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 16, line 16 skipping to change at page 17, line 46
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-01 (work in progress), May 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]
Eastlake, D. and B. Briscoe, "TRILL: ECN (Explicit
Congestion Notification) Support", draft-ietf-trill-ecn-
support-03 (work in progress), May 2017.
[I-D.ietf-tsvwg-ecn-encap-guidelines]
Briscoe, B., Kaippallimalil, J., and P. Thaler,
"Guidelines for Adding Congestion Notification to
Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn-
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-00
(work in progress), May 2017. (work in progress), May 2017.
[I-D.ietf-tsvwg-rfc6040update-shim]
Briscoe, B., "Propagating Explicit Congestion Notification
Across IP Tunnel Headers Separated by a Shim", draft-ietf-
tsvwg-rfc6040update-shim-04 (work in progress), July 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,
RFC 4774, DOI 10.17487/RFC4774, November 2006, RFC 4774, DOI 10.17487/RFC4774, November 2006,
<https://www.rfc-editor.org/info/rfc4774>. <https://www.rfc-editor.org/info/rfc4774>.
[RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC
Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844,
July 2007, <https://www.rfc-editor.org/info/rfc4844>.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions",
RFC 5706, DOI 10.17487/RFC5706, November 2009,
<https://www.rfc-editor.org/info/rfc5706>.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, DOI 10.17487/RFC6040, November
2010, <https://www.rfc-editor.org/info/rfc6040>.
[RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three
Pre-Congestion Notification (PCN) States in the IP Header
Using a Single Diffserv Codepoint (DSCP)", RFC 6660,
DOI 10.17487/RFC6660, July 2012,
<https://www.rfc-editor.org/info/rfc6660>.
[Trammell15] [Trammell15]
Trammell, B., Kuehlewind, M., Boppart, D., Learmonth, I., Trammell, B., Kuehlewind, M., Boppart, D., Learmonth, I.,
Fairhurst, G., and R. Scheffenegger, "Enabling Internet- Fairhurst, G., and R. Scheffenegger, "Enabling Internet-
Wide Deployment of Explicit Congestion Notification". Wide Deployment of Explicit Congestion Notification".
In Proc Passive & Active Measurement (PAM'15) Conference In Proc Passive & Active Measurement (PAM'15) Conference
(2015) (2015)
Appendix A. Change History Appendix A. Change History
skipping to change at page 18, line 14 skipping to change at page 20, line 33
o Add summary of RFC 3168 changes to remove the ECN nonce, and use o Add summary of RFC 3168 changes to remove the ECN nonce, and use
lower-case "nonce" instead of "Nonce" to match RFC 3168 usage. lower-case "nonce" instead of "Nonce" to match RFC 3168 usage.
o Add security considerations sentence to indicate that review of o Add security considerations sentence to indicate that review of
Experimental RFCs prior to publication approval is the means to Experimental RFCs prior to publication approval is the means to
ensure that congestion control is not broken by experiments. ensure that congestion control is not broken by experiments.
o Other minor editorial changes from IETF Last Call o Other minor editorial changes from IETF Last Call
Changes from draft-ietf-tsvwg-ecn-experimentation-06 to -07:
o Change draft title to make scope clear - this only covers relaxing
of restrictions on ECN experimentation.
o Any Experimental RFC that takes advantage of this memo has to be
in the IETF document stream.
o Added sections 2.2 and 2.3 on considerations for other protocols
and O&M, relocated discussion of congestion control requirement to
section 2.1 from section 4.4
o Remove text indicating that ECT(1) may be assigned to L4S - the
requirement for an Experimental RFC suffices to ensure that
coordination with L4S will occur.
o Improve explanation of attack response exception to not dropping
packets "solely because the ECN field in the IP header does not
contain Not-ECT" in Section 4.3
o Fix L4S draft reference for discussion of ECN Nonce alternatives -
it's Appendix C.1, not B.1.
o Numerous additional editorial changes from IESG Evaluation
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. 44 change blocks. 
163 lines changed or deleted 300 lines changed or added

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