draft-ietf-tsvwg-ecn-experimentation-02.txt   draft-ietf-tsvwg-ecn-experimentation-03.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 April 28, 2017 Updates: 3168, 4341, 4342, 5622, 6679 June 21, 2017
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: October 30, 2017 Expires: December 23, 2017
Explicit Congestion Notification (ECN) Experimentation Explicit Congestion Notification (ECN) Experimentation
draft-ietf-tsvwg-ecn-experimentation-02 draft-ietf-tsvwg-ecn-experimentation-03
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 a replacement for packet drops as indicators of
network congestion. It relaxes restrictions in RFC 3168 that would network congestion. It relaxes restrictions in RFC 3168 that would
otherwise hinder experimentation towards benefits beyond just removal otherwise hinder experimentation towards benefits beyond just removal
of loss. This memo summarizes the anticipated areas of of loss. This memo summarizes the anticipated areas of
experimentation and updates RFC 3168 to enable experimentation in experimentation and updates RFC 3168 to enable experimentation in
these areas. An Experimental RFC is required to take advantage of these areas. An Experimental RFC is required to take advantage of
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 October 30, 2017. This Internet-Draft will expire on December 23, 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 52 skipping to change at page 2, line 52
4.3. Generalized ECN . . . . . . . . . . . . . . . . . . . . . 10 4.3. Generalized ECN . . . . . . . . . . . . . . . . . . . . . 10
4.4. Effective Congestion Control is Required . . . . . . . . 11 4.4. Effective Congestion Control is Required . . . . . . . . 11
5. ECN for RTP Updates to RFC 6679 . . . . . . . . . . . . . . . 11 5. ECN for RTP Updates to RFC 6679 . . . . . . . . . . . . . . . 11
6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622 . . . . . . 13 6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622 . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
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 a replacement for packet drops as
indicators of network congestion. It relaxes restrictions in RFC indicators of network congestion. It relaxes restrictions in RFC
3168 that would otherwise hinder experimentation towards benefits 3168 that would otherwise hinder experimentation towards benefits
beyond just removal of loss. This memo summarizes the proposed areas beyond just removal of loss. This memo summarizes the proposed areas
of experimentation and updates RFC 3168 to enable experimentation in of 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 MUST be published for any protocol
skipping to change at page 4, line 32 skipping to change at page 4, line 32
Congestion Response Differences: As discussed further in Congestion Response Differences: As discussed further in
Section 4.1, an ECN congestion indication communicates a higher Section 4.1, an ECN congestion indication communicates a higher
likelihood that a shorter queue exists at the network bottleneck likelihood that a shorter queue exists at the network bottleneck
node by comparison to a packet drop that indicates congestion node by comparison to a packet drop 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., reduce the response so that the sender
backs off by a smaller amount) may be appropriate by comparison to backs off by a smaller amount) may be appropriate by comparison to
the sender response to congestion indicated by loss, e.g., as the sender response to congestion indicated by loss, e.g., as
proposed in [I-D.ietf-tcpm-alternativebackoff-ecn] and proposed in [I-D.ietf-tcpm-alternativebackoff-ecn] and
[I-D.briscoe-tsvwg-ecn-l4s-id] - the experiment in the latter [I-D.ietf-tsvwg-ecn-l4s-id] - the experiment in the latter draft
draft couples the backoff change to Congestion Marking Differences couples the backoff change to Congestion Marking Differences
changes (next bullet). This is at variance with RFC 3168's changes (next bullet). This is at variance with RFC 3168's
requirement that a sender's congestion control response to ECN requirement that a sender's congestion control response to ECN
congestion indications be the same as to drops. IETF approval, congestion indications be the same as to drops. IETF approval,
e.g., via an Experimental RFC, is required for any sender e.g., via an Experimental RFC, is required for any sender
congestion response used in this area of experimentation. congestion response used in this area of experimentation.
Congestion Marking Differences: As discussed further in Section 4.2, Congestion Marking Differences: As discussed further in Section 4.2,
when taken to its limit, congestion marking at network nodes can when taken to its limit, congestion marking at network nodes can
be configured to maintain very shallow queues in conjunction with be configured to maintain very shallow queues in conjunction with
a different IETF-approved congestion response to congestion a different IETF-approved congestion response to congestion
indications (CE marks) at the sender, e.g., as proposed in indications (CE marks) at the sender, e.g., as proposed in
[I-D.briscoe-tsvwg-ecn-l4s-id]. The traffic involved needs to be [I-D.ietf-tsvwg-ecn-l4s-id]. The traffic involved needs to be
identified by the senders to the network nodes in order to avoid identified by the senders to the network nodes in order to avoid
damage to other network traffic whose senders do not expect the damage to other network traffic whose senders do not expect the
more frequent congestion marking used to maintain nearly empty more frequent congestion marking used to maintain nearly empty
queues. Use of different ECN codepoints, specifically ECT(0) and queues. Use of different ECN codepoints, specifically ECT(0) and
ECT(1), is a promising means of traffic identification for this ECT(1), is a promising means of traffic identification for this
purpose, but that technique is at variance with RFC 3168's purpose, but that technique is at variance with RFC 3168's
requirement that ECT(0)-marked traffic and ECT(1)-marked traffic requirement that ECT(0)-marked traffic and ECT(1)-marked traffic
not receive different treatment in the network. not receive different treatment in the network.
Generalized ECN: RFC 3168 limits the use of ECN with TCP to data Generalized ECN: RFC 3168 limits the use of ECN with TCP to data
skipping to change at page 6, line 5 skipping to change at page 6, line 5
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 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.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. The specific text updates are and use of ECT(1) for that Nonce. The specific text updates are
omitted for brevity. omitted for brevity.
4. Updates to RFC 3168 4. Updates to RFC 3168
skipping to change at page 7, line 48 skipping to change at page 7, line 48
separate network node treatments are essential, both to prevent the separate network node treatments are essential, both to prevent the
aggressive low latency traffic starving conventional traffic (if aggressive low latency traffic starving conventional traffic (if
present) and to prevent any conventional traffic disruption to any present) and to prevent any conventional traffic disruption to any
lower latency service that uses the shallow queues. Use of different lower latency service that uses the shallow queues. Use of different
ECN codepoints is a promising means of identifying these two classes ECN codepoints is a promising means of identifying these two classes
of traffic to network nodes, and hence this area of experimentation 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 is based on the use of the ECT(1) codepoint to request ECN congestion
marking behavior in the network that differs from ECT(0) marking behavior in the network that differs from ECT(0)
counterbalanced by use of a different IETF-approved congestion counterbalanced by use of a different IETF-approved congestion
response to CE marks at the sender, e.g., as proposed in response to CE marks at the sender, e.g., as proposed in
[I-D.briscoe-tsvwg-ecn-l4s-id]. [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. The specific change to
RFC 3168 is to insert the words "unless otherwise specified by an RFC 3168 is to insert the words "unless otherwise specified by an
Experimental RFC" at the end of the above sentence. Experimental RFC" at the end of the above sentence.
skipping to change at page 8, line 42 skipping to change at page 8, line 42
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
nearly empty queues at network nodes. When using loss as a nearly empty 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)
[I-D.briscoe-tsvwg-ecn-l4s-id] significantly increases the CE marking [I-D.ietf-tsvwg-ecn-l4s-id] significantly increases the CE marking
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 To avoid that interaction, this memo reserves ECT(1) for
experimentation, initially for L4S. The specific update to Section 5 experimentation, initially for L4S. The specific update to Section 5
of RFC 3168 is to remove the following text: of RFC 3168 is to remove the 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: and replace it 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. Guidelines
for senders and receivers to differentiate between the ECT(0) and 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
skipping to change at page 11, line 52 skipping to change at page 11, line 52
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.briscoe-tsvwg-ecn-l4s-id]. responses, e.g., as proposed in [I-D.ietf-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
notification that triggers the algorithm to react as if packet notification that triggers the algorithm to react as if packet
skipping to change at page 13, line 19 skipping to change at page 13, line 19
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, such DCCP
senders SHOULD set the ECT(0) codepoint. 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
skipping to change at page 14, line 14 skipping to change at page 14, line 14
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 discussed 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.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,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 15, line 19 skipping to change at page 15, line 19
<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-tcpm-generalized-ecn] [I-D.bagnulo-tcpm-generalized-ecn]
Bagnulo, M. and B. Briscoe, "Adding Explicit Congestion Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit
Notification (ECN) to TCP control packets and TCP Congestion Notification (ECN) to TCP Control Packets",
retransmissions", draft-bagnulo-tcpm-generalized-ecn-03 draft-bagnulo-tcpm-generalized-ecn-04 (work in progress),
(work in progress), April 2017. May 2017.
[I-D.briscoe-tsvwg-ecn-l4s-id]
Schepper, K., Briscoe, B., and I. Tsang, "Identifying
Modified Explicit Congestion Notification (ECN) Semantics
for Ultra-Low Queuing Delay", draft-briscoe-tsvwg-ecn-l4s-
id-02 (work in progress), October 2016.
[I-D.ietf-tcpm-alternativebackoff-ecn] [I-D.ietf-tcpm-alternativebackoff-ecn]
Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,
"TCP Alternative Backoff with ECN (ABE)", draft-ietf-tcpm- "TCP Alternative Backoff with ECN (ABE)", draft-ietf-tcpm-
alternativebackoff-ecn-00 (work in progress), February alternativebackoff-ecn-01 (work in progress), May 2017.
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-05 (work Control for Datacenters", draft-ietf-tcpm-dctcp-07 (work
in progress), March 2017. in progress), June 2017.
[I-D.ietf-tsvwg-ecn-l4s-id]
Schepper, K. and B. Briscoe, "Identifying Modified
Explicit Congestion Notification (ECN) Semantics for
Ultra-Low Queuing Delay", draft-ietf-tsvwg-ecn-l4s-id-00
(work in progress), May 2017.
[I-D.khademi-tsvwg-ecn-response] [I-D.khademi-tsvwg-ecn-response]
Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,
"Updating the Explicit Congestion Notification (ECN) "Updating the Explicit Congestion Notification (ECN)
Specification to Allow IETF Experimentation", draft- Specification to Allow IETF Experimentation", draft-
khademi-tsvwg-ecn-response-01 (work in progress), July khademi-tsvwg-ecn-response-01 (work in progress), July
2016. 2016.
[RFC4774] Floyd, S., "Specifying Alternate Semantics for the [RFC4774] Floyd, S., "Specifying Alternate Semantics for the
Explicit Congestion Notification (ECN) Field", BCP 124, Explicit Congestion Notification (ECN) Field", BCP 124,
skipping to change at page 16, line 17 skipping to change at page 16, line 17
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
[To be removed before RFC publication.] [To be removed before RFC publication.]
Changes from draft-black-tsvwg-ecn-experimentation-00 to -01:
o Section 4.2 - also update RFC 3168 to remove sentence indicating
that senders are free to use both ECT codepoints. Add a SHOULD
for ECT Differences experiments to use ECT(1).
o Section 5 - only discourage use of random ECT values, but use NOT
RECOMMENDED to do so. Consistent use of ECT(1) without using
ECT(0) is ok. Mention possible changes in endpoint response.
o Add more Acknowledgements and Change History
o Additional editorial changes.
Changes from draft-black-tsvwg-ecn-experimentation-01 to -02:
o Add DCCP RFC updates and one missing RFC 3168 update (probe
packets).
o Discourage RTP usage of ECT(1).
o Strengthen text on lack of ECN Nonce deployment.
o Cross-reference the L4S draft appendix that discusses ECN Nonce
alternatives.
o Additional editorial changes.
Changes from draft-black-tsvwg-ecn-experimentation-02 to -03:
o Clarify that "SHOULD use ECT(0)" guidance from RFC 3168 is about
IP headers.
o Add a "SHOULD NOT" requirement that middleboxes not discard TCP
control packets, etc. solely because they use ECN.
o Switch to pre-5378 boilerplate, due to vintage of RFCs being
updated.
o Additional editorial changes.
Changes from draft-black-tsvwg-ecn-experimentation-03 to -04:
o Use "Congestion Response Differences" as name of experimentation
area instead of "Alternative Backoff" to avoid confusion with
specific experiment.
o Change ECT(1) requirement to "MUST NOT use unless otherwise
specified by an Experimental RFC" This resulted in extensive
changes to Section 4.2.
o Clean up and tighten language requiring all congestion responses
to be IETF-approved
o Additional editorial changes.
Initial WG draft, draft-ietf-tsvwg-ecn-experimentation-00, has the
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: Changes from draft-ietf-tsvwg-ecn-experimentation-01 to -02:
o Generalize to describe rationale for areas of experimentation, o Generalize to describe rationale for areas of experimentation,
with less focus on individual experiments with less focus on individual experiments
skipping to change at page 18, line 12 skipping to change at page 16, line 47
o Add explanation of exception to "SHOULD NOT drop" requirement in o Add explanation of exception to "SHOULD NOT drop" requirement in
4.3 4.3
o Rework RFC 3540 status change text to provide rationale for a o Rework RFC 3540 status change text to provide rationale for a
separate status change document that makes RFC 3540 Historic. separate status change document that makes RFC 3540 Historic.
Don't obsolete RFC 3540. Don't obsolete RFC 3540.
o Significant editorial changes based on reviews by Mirja o Significant editorial changes based on reviews by Mirja
Kuehlewind, Michael Welzl and Bob Briscoe. Kuehlewind, Michael Welzl and Bob Briscoe.
Changes from draft-ietf-tsvwg-ecn-experimentation-02 to -03:
o Remove change history prior to WG adoption.
o Update L4S draft reference to reflect TSVWG adoption of draft.
o Change the "SHOULD" for DCCP sender use of ECT(0) to a "MUST"
(overlooked in earlier editing).
o Other minor edits.
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. 21 change blocks. 
92 lines changed or deleted 42 lines changed or added

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