< draft-ietf-tsvwg-ecn-experimentation-01.txt   draft-ietf-tsvwg-ecn-experimentation-02.txt >
Transport Area Working Group D. Black Transport Area Working Group D. Black
Internet-Draft Dell EMC Internet-Draft Dell EMC
Obsoletes: 3540 (if approved) March 8, 2017 Updates: 3168, 4341, 4342, 5622, 6679 April 28, 2017
Updates: 3168, 4341, 4342, 5622, 6679
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: September 9, 2017 Expires: October 30, 2017
Explicit Congestion Notification (ECN) Experimentation Explicit Congestion Notification (ECN) Experimentation
draft-ietf-tsvwg-ecn-experimentation-01 draft-ietf-tsvwg-ecn-experimentation-02
Abstract Abstract
Multiple protocol experiments have been proposed that involve changes This memo updates RFC 3168, which specifies Explicit Congestion
to Explicit Congestion Notification (ECN) as specified in RFC 3168. Notification (ECN) as a replacement for packet drops as indicators of
This memo summarizes the proposed areas of experimentation to provide network congestion. It relaxes restrictions in RFC 3168 that would
an overview to the Internet community and updates RFC 3168, a otherwise hinder experimentation towards benefits beyond just removal
Proposed Standard RFC, to allow the experiments to proceed without of loss. This memo summarizes the anticipated areas of
requiring a standards process exception for each Experimental RFC to experimentation and updates RFC 3168 to enable experimentation in
update RFC 3168. Each experiment is still required to be documented these areas. An Experimental RFC is required to take advantage of
in an Experimental RFC. In addition, this memo makes related updates any of these enabling updates. In addition, this memo makes related
to the ECN specifications for RTP in RFC 6679 and to the ECN updates to the ECN specifications for RTP in RFC 6679 and for DCCP in
specifications for DCCP in RFC 4341, RFC 4342 and RFC 5622. This RFC 4341, RFC 4342 and RFC 5622. This memo also records the
memo also records the conclusion of the ECN Nonce experiment in RFC conclusion of the ECN Nonce experiment in RFC 3540, and provides the
3540, obsoletes RFC 3540 and reclassifies it as Historic to enable rationale for reclassification of RFC 3540 as Historic; this
new experimental use of the ECT(1) codepoint. reclassification enables new experimental use of the ECT(1)
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 September 9, 2017. This Internet-Draft will expire on October 30, 2017.
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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 35 skipping to change at page 2, line 35
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
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. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. ECN Terminology . . . . . . . . . . . . . . . . . . . . . 3
2. Scope of ECN Experiments . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. ECN Nonce and RFC 3540 . . . . . . . . . . . . . . . . . . . 4 2. Proposed ECN Experiments: Background . . . . . . . . . . . . 4
4. Updates to RFC 3168 . . . . . . . . . . . . . . . . . . . . . 5 3. ECN Nonce and RFC 3540 . . . . . . . . . . . . . . . . . . . 5
4.1. Congestion Response Differences . . . . . . . . . . . . . 5 4. Updates to RFC 3168 . . . . . . . . . . . . . . . . . . . . . 6
4.2. ECT Differences . . . . . . . . . . . . . . . . . . . . . 6 4.1. Congestion Response Differences . . . . . . . . . . . . . 6
4.3. Generalized ECN . . . . . . . . . . . . . . . . . . . . . 7 4.2. Congestion Marking Differences . . . . . . . . . . . . . 7
4.4. Effective Congestion Control is Required . . . . . . . . 8 4.3. Generalized ECN . . . . . . . . . . . . . . . . . . . . . 10
5. ECN for RTP Updates to RFC 6679 . . . . . . . . . . . . . . . 9 4.4. Effective Congestion Control is Required . . . . . . . . 11
6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622 . . . . . . 10 5. ECN for RTP Updates to RFC 6679 . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622 . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Multiple protocol experiments have been proposed that involve changes This memo updates RFC 3168 [RFC3168] which specifies Explicit
to Explicit Congestion Notification (ECN) as specified in RFC 3168 Congestion Notification (ECN) as a replacement for packet drops as
[RFC3168]. This memo summarizes the proposed areas of indicators of network congestion. It relaxes restrictions in RFC
experimentation to provide an overview to the Internet community and 3168 that would otherwise hinder experimentation towards benefits
updates RFC 3168 to allow the experiments to proceed without beyond just removal of loss. This memo summarizes the proposed areas
requiring a standards process exception for each Experimental RFC to of experimentation and updates RFC 3168 to enable experimentation in
update RFC 3168, a Proposed Standard RFC. This memo also makes these areas. An Experimental RFC MUST be published for any protocol
related updates to the ECN specification for RTP in RFC 6679 or mechanism that takes advantage of any of these enabling updates.
[RFC6679] for the same reason. Each experiment is still required to Putting all of these updates into a single document enables
be documented in one or more separate RFCs, but use of Experimental experimentation to proceed without requiring a standards process
RFCs for this purpose does not require a process exception to modify exception for each Experimental RFC that needs changes to RFC 3168, a
RFC 3168 or RFC 6679 when the modification falls within the bounds Proposed Standard RFC.
established by this memo.
One of these areas of experimentation involves use of the ECT(1) There is no need to make changes for protocols and mechanisms that
codepoint that was dedicated to the ECN Nonce experiment as described are documented in Standards Track RFCs, as any Standards Track RFC
in RFC 3540 [RFC3540]. This memo records the conclusion of the ECN can update RFC 3168 without needing a standards process exception.
Nonce experiment, obsoletes RFC 3540 and reclassifies it as Historic.
1.1. Requirements Language In addition, this memo makes related updates to the ECN specification
for RTP [RFC6679] and for three DCCP profiles ([RFC4341], [RFC4342]
and [RFC5622]) for the same reason. Each experiment is still
required to be documented in one or more separate RFCs, but use of
Experimental RFCs for this purpose does not require a process
exception to modify any of these Proposed Standard RFCs when the
modification falls within the bounds established by this memo (RFC
5622 is an Experimental RFC; it is modified by this memo for
consistency with modifications to the other two DCCP RFCs).
Some of the anticipated experimentation includes use of the ECT(1)
codepoint that was dedicated to the ECN Nonce experiment in RFC 3540
[RFC3540]. This memo records the conclusion of the ECN Nonce
experiment and provides the explanation for reclassification of RFC
3540 as Historic in order to enable new experimental use of the
ECT(1) codepoint.
1.1. ECN Terminology
ECT: ECN-Capable Transport. One of the two codepoints ECT(0) or
ECT(1) in the ECN field [RFC3168] of the IP header (v4 or v6). An
ECN-capable sender sets one of these to indicate that both transport
end-points support ECN.
Not-ECT: The ECN codepoint set by senders that indicates that the
transport is not ECN-capable.
CE: Congestion Experienced. The ECN codepoint that an intermediate
node sets to indicate congestion. A node sets an increasing
proportion of ECT packets to CE as the level of congestion increases.
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. Scope of ECN Experiments 2. Proposed ECN Experiments: Background
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 goals and rationale cited Internet-Drafts should be consulted for the detailed goals and
of each proposed experiment: rationale of each proposed experiment:
Congestion Response Differences: For congestion indicated by ECN, Congestion Response Differences: As discussed further in
use a different IETF-approved sender congestion response (e.g., Section 4.1, an ECN congestion indication communicates a higher
reduce the response so that the sender backs off by a smaller likelihood that a shorter queue exists at the network bottleneck
amount) by comparison to congestion indicated by loss, e.g., as node by comparison to a packet drop that indicates congestion
proposed in [I-D.khademi-tcpm-alternativebackoff-ecn] and [I-D.ietf-tcpm-alternativebackoff-ecn]. This difference suggests
that for congestion indicated by ECN, a different sender
congestion response (e.g., reduce the response so that the sender
backs off by a smaller amount) may be appropriate by comparison to
the sender response to congestion indicated by loss, e.g., as
proposed in [I-D.ietf-tcpm-alternativebackoff-ecn] and
[I-D.briscoe-tsvwg-ecn-l4s-id] - the experiment in the latter [I-D.briscoe-tsvwg-ecn-l4s-id] - the experiment in the latter
draft couples the backoff change to ECT Differences functionality draft couples the backoff change to Congestion Marking Differences
(next bullet). This is at variance with RFC 3168's requirement changes (next bullet). This is at variance with RFC 3168's
that a sender's congestion control response to ECN congestion requirement that a sender's congestion control response to ECN
indications be the same as to drops. congestion indications be the same as to drops. IETF approval,
e.g., via an Experimental RFC, is required for any sender
congestion response used in this area of experimentation.
ECT Differences: Use ECT(1) to request ECN congestion marking Congestion Marking Differences: As discussed further in Section 4.2,
behavior in the network that differs from ECT(0) counterbalanced when taken to its limit, congestion marking at network nodes can
by use of a different IETF-approved congestion response to CE be configured to maintain very shallow queues in conjunction with
marks at the sender, e.g., as proposed in a different IETF-approved congestion response to congestion
[I-D.briscoe-tsvwg-ecn-l4s-id]. This is at variance with RFC indications (CE marks) at the sender, e.g., as proposed in
3168's requirement that ECT(0)-marked traffic and ECT(1)-marked [I-D.briscoe-tsvwg-ecn-l4s-id]. The traffic involved needs to be
traffic not receive different treatment in the network. identified by the senders to the network nodes in order to avoid
damage to other network traffic whose senders do not expect the
more frequent congestion marking used to maintain nearly empty
queues. Use of different ECN codepoints, specifically ECT(0) and
ECT(1), is a promising means of traffic identification for this
purpose, but that technique is at variance with RFC 3168's
requirement that ECT(0)-marked traffic and ECT(1)-marked traffic
not receive different treatment in the network.
Generalized ECN: Use ECN for TCP control packets (i.e., send control Generalized ECN: RFC 3168 limits the use of ECN with TCP to data
packets such as SYN with ECT marking) and for retransmitted packets, excluding retransmissions. With the successful
packets, e.g., as proposed in [I-D.bagnulo-tsvwg-generalized-ecn]. deployment of ECN in large portions of the Internet, there is
This is at variance with RFC 3168's prohibition of use of ECN for interest in extending the benefits of ECN to TCP control packets
TCP control packets and retransmitted packets (e.g., SYNs) and retransmitted packets, e.g., as proposed 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
retransmitted packets.
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 neither prejudges the outcomes of the experimentation. This memo expresses no view on the likely outcomes
proposed experiments nor specifies the experiments in detail. of the proposed experiments and does not specify the experiments in
Additional experiments in these areas are possible, e.g., on use of detail. Additional experiments in these areas are possible, e.g., on
ECN to support deployment of Datacenter TCP (DCTCP) use of ECN to support deployment of a protocol similar to DCTCP
[I-D.ietf-tcpm-dctcp] beyond its current applicablity limitation to [I-D.ietf-tcpm-dctcp] beyond DCTCP's current applicability that is
data center environments. The purpose of this memo is to remove limited to data center environments. The purpose of this memo is to
constraints in standards track RFCs that serve to prohibit these remove constraints in standards track RFCs that stand in the way of
areas of experimentation. these areas of experimentation.
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 with the second codepoint used to support ECN nonce functionality to
discourage receivers from exploiting ECN to improve their throughput discourage receivers from exploiting ECN to improve their throughput
at the expense of other network users, as specified in experimental at the expense of other network users, as specified in experimental
RFC 3540 [RFC3540]. RFC 3540 [RFC3540]. This section explains 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 Alexa top 1M web materialized. A study of the ECN behaviour of the Alexa top 1M web
servers using 2014 data [Trammell15] found that after ECN was 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 equally it might have been due to ECN Nonce by these 4 servers, but might equally have been due to re-
re-marking of the ECN field by an erroneous middlebox or router. marking of the ECN field by an erroneous 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.briscoe-tsvwg-ecn-l4s-id]. Therefore, in support of ECN [I-D.briscoe-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 Obsoletes RFC 3540 in order to facilitate experimental use of the
ECT(1) codepoint.
o Reclassifies RFC 3540 as Historic to document the ECN Nonce
experiment and discourage further implementation of the ECN Nonce.
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. The specific text updates are and use of ECT(1) for that Nonce. The specific text updates are
omitted for brevity. omitted for brevity.
The following guidance on ECT codepoint usage in the ECN field of IP
headers from Section 5 of RFC 3168 is relevant when the ECN Nonce is
not implemented:
Protocols and senders that only require a single ECT codepoint
SHOULD use ECT(0).
OPEN ISSUE: Change the above requirement in RFC 3168 from SHOULD to
MUST towards reserving ECT(1) for experimentation?
4. Updates to RFC 3168 4. Updates to RFC 3168
RFC 3168 is a Proposed Standard RFC, so updating RFC 3168 requires The following subsections specify updates to RFC 3168 to enable the
publishing a standards track RFC unless a standards process exception three areas of experimentation summarized in Section 2.
is approved by the IESG, e.g., to allow an Experimental RFC to update
RFC 3168. In support of the above areas of experimentation, and
specifically to avoid multiple uncoordinated requests to the IESG for
standards process exceptions, this memo updates RFC 3168 [RFC3168]
ito allow changes in the following areas, provided that the changes
are documented by an Experimental RFC. It is also possible to change
RFC 3168 via publication of another standards track RFC.
4.1. Congestion Response Differences 4.1. Congestion Response Differences
Section 5 of RFC 3168 specifies that: RFC 3168 specifies that senders respond identically to packet drops
and ECN congestion indications. ECN congestion indications are
predominately originated by Active Queue Management (AQM) mechanisms
in intermediate buffers. AQM mechanisms are usually configured to
maintain shorter queue lengths than non-AQM based mechanisms,
particularly non-AQM drop-based mechanisms such as tail-drop, as AQM
mechanisms indicate congestion before the queue overflows. While the
occurrence of loss does not easily enable the receiver to determine
if AQM is used, the receipt of an ECN Congestion Experienced (CE)
mark conveys a strong likelihood that AQM was used to manage the
bottleneck queue. Hence an ECN congestion indication communicates a
higher likelihood that a shorter queue exists at the network
bottleneck node by comparison to a packet drop that indicates
congestion [I-D.ietf-tcpm-alternativebackoff-ecn]. This difference
suggests that for congestion indicated by ECN, a different sender
congestion response (e.g., reduce the response so that the sender
backs off by a smaller amount) may be appropriate by comparison to
the sender response to congestion indicated by loss. However,
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.
In support of Congestion Response Differences experimentation, this This memo updates this RFC 3168 text to allow the congestion control
memo updates RFC 3168 to allow the congestion control response response (including the TCP Sender's congestion control response) to
(including the TCP Sender's congestion control response) to a CE- a CE-marked packet to differ from the response to a dropped packet,
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. The specific change to RFC 3168 is to insert the
words "unless otherwise specified by an Experimental RFC" at the end words "unless otherwise specified by an Experimental RFC" at the end
of the sentence quoted above. 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.
4.2. ECT Differences Section 6.1.2 of RFC 3168 specifies that:
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
sender knows that congestion was encountered in the network on the
path from the sender to the receiver. The indication of
congestion should be treated just as a congestion loss in non-
ECN-Capable TCP. That is, the TCP source halves the congestion
window "cwnd" and reduces the slow start threshold "ssthresh".
This memo also updates this RFC 3168 text to allow the congestion
control response (including the TCP Sender's congestion control
response) to a CE-marked packet to differ from the response to a
dropped packet, provided that the changes from RFC 3168 are
documented in an Experimental RFC. The specific change to RFC 3168
is to insert the words "Unless otherwise specified by an Experimental
RFC" at the beginning of the second sentence quoted above.
4.2. Congestion Marking Differences
Taken to its limit, an AQM algorithm that uses ECN congestion
indications can be configured to maintain very shallow queues,
thereby reducing network latency by comparison to maintaining a
larger queue. Significantly more aggressive sender responses to ECN
are required to make effective use of such shallow queues; Datacenter
TCP (DCTCP) [I-D.ietf-tcpm-dctcp] provides an example. In this case,
separate network node treatments are essential, both to prevent the
aggressive low latency traffic starving conventional traffic (if
present) and to prevent any conventional traffic disruption to any
lower latency service that uses the shallow queues. Use of different
ECN codepoints is a promising means of identifying these two classes
of traffic to network nodes, and hence this area of experimentation
is based on the use of the ECT(1) codepoint to request ECN congestion
marking behavior in the network that differs from ECT(0)
counterbalanced by use of a different IETF-approved congestion
response to CE marks at the sender, e.g., as proposed in
[I-D.briscoe-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.
In support of ECT Differences experimentation, this memo updates RFC This memo updates RFC 3168 to allow routers to treat the ECT(0) and
3168 to allow routers to treat the ECT(0) and ECT(1) codepoints ECT(1) codepoints differently, provided that the changes from RFC
differently, provided that the changes from RFC 3168 are documented 3168 are documented in an Experimental RFC. The specific change to
in an Experimental RFC. The specific change to RFC 3168 is to insert RFC 3168 is to insert the words "unless otherwise specified by an
the words "unless otherwise specified by an Experimental RFC" at the Experimental RFC" at the end of the above sentence.
end of the above sentence.
In support of ECT Differences experimentation, this memo updates RFC When an AQM is configured to use ECN congestion indications to
3168 to enable effective endpoint use of ECT(1) for large scale maintain a nearly empty queue, congestion indications are marked on
experimentation. The proposed L4S experiment packets that would not have been dropped if ECN was not in use.
Section 5 of RFC 3168 specifies that:
For a router, the CE codepoint of an ECN-Capable packet SHOULD
only be set if the router would otherwise have dropped the packet
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
a packet to inform end nodes of incipient congestion, the router
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,
the router MAY instead set the CE codepoint in the IP header.
This memo updates RFC 3168 to allow congestion indications that are
not equivalent to drops, provided that the changes from RFC 3168 are
documented in an Experimental RFC. The specific change is to change
"For a router," to "Unless otherwise specified by an Experimental
RFC" at the beginning of the first sentence of the above paragraph.
A larger update to RFC 3168 is necessary to enable sender usage of
ECT(1) to request network congestion marking behavior that maintains
nearly empty queues at network nodes. When using loss as a
congestion signal, the number of signals provided should be reduced
to a minimum and hence only presence or absence of congestion is
communicated. In contrast, ECN can provide a richer signal, e.g., to
indicate the current level of congestion, without the disadvantage of
a larger number of packet losses. A proposed experiment in this
area, Low Latency Low Loss Scalable throughput (L4S)
[I-D.briscoe-tsvwg-ecn-l4s-id] significantly increases the CE marking [I-D.briscoe-tsvwg-ecn-l4s-id] significantly increases the CE marking
probability for ECT(1)-marked traffic in a fashion that interacts probability for ECT(1)-marked traffic in a fashion that would
badly with existing sender congestion response functionality because interact badly with existing sender congestion response functionality
that functionality assumes that a CE-marked packet would have been because that functionality assumes that the network marks ECT packets
dropped by the network. If network traffic that uses such a sender as frequently as it would drop Not-ECT packets . If network traffic
congestion response encounters L4S's increased marking probability that uses such a conventional sender congestion response were to
(and hence rate) at a network bottleneck queue, the resulting traffic encounter L4S's increased marking probability (and hence rate) at a
throughput is likely to be much less than intended for the level of network bottleneck queue, the resulting traffic throughput is likely
congestion at the bottleneck queue. To avoid that interaction, this to be much less than intended for the level of congestion at the
memo reserves ECT(1) for experimentation, initially L4S. The bottleneck queue.
specific update to Section 5 of RFC 3168 is to remove the following
text: To avoid that interaction, this memo reserves ECT(1) for
experimentation, initially for L4S. The specific update to Section 5
of RFC 3168 is to remove the following text:
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: and replace it with:
Unless otherwise modified by an Experimental RFC, senders MUST use Protocols and senders MUST use the ECT(0) codepoint to indicate
the ECT(0) codepoint to indicate ECT and MUST NOT use the ECT(1) ECT unless otherwise specified by an Experimental RFC. Guidelines
codepoint to indicate ECT. for senders and receivers to differentiate between the ECT(0) and
ECT(1) codepoints will be addressed in separate documents, for
each transport protocol. In particular, this document does not
address mechanisms for TCP end-nodes to differentiate between the
ECT(0) and ECT(1) codepoints.
ECT Differences experiments SHOULD modify the network behavior for Congestion Marking Differences experiments SHOULD modify the network
ECT(1)-marked traffic rather than ECT(0)-marked traffic if network behavior for ECT(1)-marked traffic rather than ECT(0)-marked traffic
behavior for only one ECT codepoint is modified. ECT Differences if network behavior for only one ECT codepoint is modified.
experiments MUST NOT modify the network behavior for ECT(0)-marked Congestion Marking Differences experiments MUST NOT modify the
traffic in a fashion that requires changes to sender congestion network behavior for ECT(0)-marked traffic in a fashion that requires
response to obtain desired network behavior. If an ECT Differences changes to sender congestion response to obtain desired network
experiment modifies the network behavior for ECT(1)-marked traffic, behavior. If a Congestion Marking Differences experiment modifies
e.g., CE-marking behavior, in a fashion that requires changes to the network behavior for ECT(1)-marked traffic, e.g., CE-marking
sender congestion response to obtain desired network behavior, then behavior, in a fashion that requires changes to sender congestion
the Experimental RFC for that experiment MUST specify: response to obtain desired network behavior, then the Experimental
RFC 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 fowarding 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 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 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 allocate ECT(1) exclusively for L4S usage if the L4S experiment is
successful. successful.
In support of ECT Differences experimentation, this memo also updates In addition, this memo updates RFC 3168 to remove discussion of the
RFC 3168 to remove discussion of the ECN Nonce, as noted in Section 3 ECN Nonce, as noted in Section 3 above.
above.
4.3. Generalized ECN 4.3. Generalized ECN
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
control packets (e.g., SYNs) and retransmitted packets, e.g., as
proposed in [I-D.bagnulo-tcpm-generalized-ecn].
RFC 3168 prohibits use of ECN for TCP control packets and RFC 3168 prohibits use of ECN for TCP control packets and
retransmitted packets in a number of places: retransmitted packets in a number of places:
o "To ensure the reliable delivery of the congestion indication of o "To ensure the reliable delivery of the congestion indication of
the CE codepoint, an ECT codepoint MUST NOT be set in a packet the CE codepoint, an ECT codepoint MUST NOT be set in a packet
unless the loss of that packet in the network would be detected by unless the loss of that packet in the network would be detected by
the end nodes and interpreted as an indication of congestion." the end nodes and interpreted as an indication of congestion."
(Section 5.2) (Section 5.2)
o "A host MUST NOT set ECT on SYN or SYN-ACK packets." o "A host MUST NOT set ECT on SYN or SYN-ACK packets."
skipping to change at page 8, line 21 skipping to change at page 10, line 45
o "This document specifies ECN-capable TCP implementations MUST NOT o "This document specifies ECN-capable TCP implementations MUST NOT
set either ECT codepoint (ECT(0) or ECT(1)) in the IP header for set either ECT codepoint (ECT(0) or ECT(1)) in the IP header for
retransmitted data packets, and that the TCP data receiver SHOULD retransmitted data packets, and that the TCP data receiver SHOULD
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)
In support of Generalized ECN experimentation, this memo updates RFC This memo updates RFC 3168 to allow the use of ECT codepoints on SYN
3168 to allow the use of ECT codepoints on SYN and SYN-ACK packets, and SYN-ACK packets, pure acknowledgement packets, window probe
pure acknowledgement packets, window probe packets and packets and retransmissions of packets that were originally sent with
retransmissions of packets that were originally sent with an ECT an ECT codepoint, provided that the changes from RFC 3168 are
codepoint, provided that the changes from RFC 3168 are documented in documented in an Experimental RFC. The specific change to RFC 3168
an Experimental RFC. The specific change to RFC 3168 is to insert is to insert the words "unless otherwise specified by an Experimental
the words "unless otherwise specified by an Experimental RFC" at the RFC" at the end of each sentence quoted above.
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 Generalized ECN discard such a packet as invalid. For Generalized 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, middleboxes
SHOULD NOT discard TCP control packets and retransmitted TCP SHOULD NOT discard TCP control packets and retransmitted TCP
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. contain Not-ECT. An exception to this requirement occurs in
responding to an ongoing attack. For example, as part of the
response, it may be appropriate to drop more ECT-marked TCP SYN
packets than TCP SYN packets marked with not-ECT. Any such
exceptional discarding of TCP control packets and retransmitted
TCP packets in response to an attack MUST NOT be done routinely in
the absence of an attack and SHOULD only be done if it is
determined that the ECT capability is contributing to the attack.
4.4. Effective Congestion Control is Required 4.4. 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 that takes advantage of architecture [RFC2914]. Any Experimental RFC that takes advantage of
this memo's updates to RFC 3168 or RFC 6679 is required to discuss this memo's updates to RFC 3168 or RFC 6679 is required to discuss
the congestion control implications of the experiment(s) in order to the congestion control implications of the experiment(s) in order to
provide assurance that deployment of the experiment(s) does not pose provide assurance that deployment of the experiment(s) does not pose
a congestion-based threat to the operation of the Internet. 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 ECT Differences area of experimentation increases the potential The Congestion Marking Differences area of experimentation increases
consequences of using ECT(1) instead of ECT(0), and hence the above the potential consequences of using ECT(1) instead of ECT(0), and
guidance is updated by adding the following two sentences: hence the above guidance is updated by adding the following two
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.briscoe-tsvwg-ecn-l4s-id]. responses, e.g., as proposed in [I-D.briscoe-tsvwg-ecn-l4s-id].
In addition, ECT(0) MUST be used unless otherwise specified in an In addition, ECT(0) MUST be used unless otherwise specified in an
Experimental RFC. 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
skipping to change at page 10, line 38 skipping to change at page 13, line 21
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, such DCCP
senders SHOULD set the ECT(0) codepoint. senders SHOULD set the ECT(0) codepoint.
In support of ECT Differences experimentation (as noted in In support of Congestion Marking Differences experimentation (as
Section 3), this memo also updates all three of these RFCs to remove noted in Section 3), this memo also updates all three of these RFCs
discussion of the ECN Nonce. The specific text updates are omitted to remove discussion of the ECN Nonce. The specific text updates are
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 Spencer Dawkins, Gorry Fairhurst, Ingemar reviewers, including Spencer Dawkins, Gorry Fairhurst, Ingemar
Johansson, Naeem Khademi, Mirja Kuehlewind, Karen Nielsen and Michael Johansson, Naeem Khademi, Mirja Kuehlewind, Karen Nielsen and Michael
Welzl. Bob Briscoe's thorough review of an early version of this Welzl. Bob Briscoe's thorough review of an early version of this
draft resulted in numerous improvments including addition of the draft resulted in numerous improvements including addition of the
updates to the DCCP RFCs. updates to the DCCP RFCs.
8. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
9. Security Considerations 9. Security Considerations
As a process memo that makes no changes to existing protocols, there As a process memo that makes no changes to existing protocols, there
are no protocol security considerations. are no protocol security considerations.
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, as specified in experiments and the experimenters who propose them, as specified in
Section 4.4. Section 4.4.
Security considerations for the proposed experiments are dicussed in Security considerations for the proposed experiments are discussed in
the Internet-Drafts that propose them. the Internet-Drafts that propose them.
See Appendix B.1 of [I-D.briscoe-tsvwg-ecn-l4s-id] for discussion of See Appendix B.1 of [I-D.briscoe-tsvwg-ecn-l4s-id] for discussion of
alteratives 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,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 12, line 34 skipping to change at page 15, line 18
DOI 10.17487/RFC5622, August 2009, DOI 10.17487/RFC5622, August 2009,
<http://www.rfc-editor.org/info/rfc5622>. <http://www.rfc-editor.org/info/rfc5622>.
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN) and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August
2012, <http://www.rfc-editor.org/info/rfc6679>. 2012, <http://www.rfc-editor.org/info/rfc6679>.
10.2. Informative References 10.2. Informative References
[I-D.bagnulo-tsvwg-generalized-ecn] [I-D.bagnulo-tcpm-generalized-ecn]
Bagnulo, M. and B. Briscoe, "Adding Explicit Congestion Bagnulo, M. and B. Briscoe, "Adding Explicit Congestion
Notification (ECN) to TCP control packets", draft-bagnulo- Notification (ECN) to TCP control packets and TCP
tsvwg-generalized-ecn-01 (work in progress), July 2016. retransmissions", draft-bagnulo-tcpm-generalized-ecn-03
(work in progress), April 2017.
[I-D.briscoe-tsvwg-ecn-l4s-id] [I-D.briscoe-tsvwg-ecn-l4s-id]
Schepper, K., Briscoe, B., and I. Tsang, "Identifying Schepper, K., Briscoe, B., and I. Tsang, "Identifying
Modified Explicit Congestion Notification (ECN) Semantics Modified Explicit Congestion Notification (ECN) Semantics
for Ultra-Low Queuing Delay", draft-briscoe-tsvwg-ecn-l4s- for Ultra-Low Queuing Delay", draft-briscoe-tsvwg-ecn-l4s-
id-02 (work in progress), October 2016. id-02 (work in progress), October 2016.
[I-D.ietf-tcpm-alternativebackoff-ecn]
Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,
"TCP Alternative Backoff with ECN (ABE)", draft-ietf-tcpm-
alternativebackoff-ecn-00 (work in progress), February
2017.
[I-D.ietf-tcpm-dctcp] [I-D.ietf-tcpm-dctcp]
Bensley, S., Eggert, L., Thaler, D., Balasubramanian, P., 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-04 (work Control for Datacenters", draft-ietf-tcpm-dctcp-05 (work
in progress), February 2017. in progress), March 2017.
[I-D.khademi-tcpm-alternativebackoff-ecn]
Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,
"TCP Alternative Backoff with ECN (ABE)", draft-khademi-
tcpm-alternativebackoff-ecn-01 (work in progress), October
2016.
[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 14, line 42 skipping to change at page 17, line 25
o Change ECT(1) requirement to "MUST NOT use unless otherwise o Change ECT(1) requirement to "MUST NOT use unless otherwise
specified by an Experimental RFC" This resulted in extensive specified by an Experimental RFC" This resulted in extensive
changes to Section 4.2. changes to Section 4.2.
o Clean up and tighten language requiring all congestion responses o Clean up and tighten language requiring all congestion responses
to be IETF-approved to be IETF-approved
o Additional editorial changes. o Additional editorial changes.
Initial WG draft, draft-ietf-tsvwg-ecn-experimentation-00, has same Initial WG draft, draft-ietf-tsvwg-ecn-experimentation-00, has the
contents as draft-black-tsvwg-ecn-experimentation-04. same contents as draft-black-tsvwg-ecn-experimentation-04.
Changes from draft-ietf-tsvwg-ecn-experimentation-00 to -01: Changes from draft-ietf-tsvwg-ecn-experimentation-00 to -01:
o Add mention of DCTCP as another protocol that could benefit from o Add mention of DCTCP as another protocol that could benefit from
ECN experimentation (near end of Section 2). ECN experimentation (near end of Section 2).
Changes from draft-ietf-tsvwg-ecn-experimentation-01 to -02:
o Generalize to describe rationale for areas of experimentation,
with less focus on individual experiments
o Add ECN terminology section
o Change name of "ECT Differences" experimentation area to
"Congestion Marking Differences"
o Add overlooked RFC 3168 modification to Section 4.1
o Clarify text for Experimental RFC exception to ECT(1) non-usage
requirement
o Add explanation of exception to "SHOULD NOT drop" requirement in
4.3
o Rework RFC 3540 status change text to provide rationale for a
separate status change document that makes RFC 3540 Historic.
Don't obsolete RFC 3540.
o Significant editorial changes based on reviews by Mirja
Kuehlewind, Michael Welzl and Bob Briscoe.
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. 49 change blocks. 
190 lines changed or deleted 339 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/