draft-ietf-tsvwg-ecn-experimentation-04.txt   draft-ietf-tsvwg-ecn-experimentation-05.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 August 4, 2017 Updates: 3168, 4341, 4342, 5622, 6679 August 30, 2017
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: February 5, 2018 Expires: March 3, 2018
Explicit Congestion Notification (ECN) Experimentation Explicit Congestion Notification (ECN) Experimentation
draft-ietf-tsvwg-ecn-experimentation-04 draft-ietf-tsvwg-ecn-experimentation-05
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 February 5, 2018. This Internet-Draft will expire on March 3, 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
(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 4, line 48 skipping to change at page 4, line 48
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.ietf-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 very shallow
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.
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
skipping to change at page 5, line 38 skipping to change at page 5, line 38
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]. This section explains why RFC 3540 is being RFC 3540 [RFC3540]. This section explains why RFC 3540 is being
reclassified as Historic and makes associated updates to RFC 3168. 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 top one million
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 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.
skipping to change at page 7, line 36 skipping to change at page 7, line 36
documented in an Experimental RFC. The specific change to RFC 3168 documented in an Experimental RFC. The specific change to RFC 3168
is to insert the words "Unless otherwise specified by an Experimental is to insert the words "Unless otherwise specified by an Experimental
RFC" at the beginning of the second sentence quoted above. RFC" 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 required to make effective use of such shallow queues; Datacenter are needed to make effective use of such very shallow queues;
TCP (DCTCP) [I-D.ietf-tcpm-dctcp] provides an example. In this case, Datacenter TCP (DCTCP) [I-D.ietf-tcpm-dctcp] provides an example. In
separate network node treatments are essential, both to prevent the this case, separate network node treatments are essential, both to
aggressive low latency traffic starving conventional traffic (if prevent the aggressive low latency traffic starving conventional
present) and to prevent any conventional traffic disruption to any traffic (if present) and to prevent any conventional traffic
lower latency service that uses the shallow queues. Use of different disruption to any lower latency service that uses the very shallow
ECN codepoints is a promising means of identifying these two classes queues. Use of different ECN codepoints is a promising means of
of traffic to network nodes, and hence this area of experimentation identifying these two classes of traffic to network nodes, and hence
is based on the use of the ECT(1) codepoint to request ECN congestion this area of experimentation is based on the use of the ECT(1)
marking behavior in the network that differs from ECT(0) codepoint to request ECN congestion marking behavior in the network
counterbalanced by use of a different IETF-approved congestion that differs from ECT(0) counterbalanced by use of a different IETF-
response to CE marks at the sender, e.g., as proposed in approved congestion response to CE marks at the sender, e.g., as
[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. 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.
When an AQM is configured to use ECN congestion indications to When an AQM is configured to use ECN congestion indications to
maintain a nearly empty 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. The specific change is to change
"For a router," to "Unless otherwise specified by an Experimental "For a router," to "Unless otherwise specified by an Experimental
RFC" at the beginning of the first sentence of the above paragraph. 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 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 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)
[I-D.ietf-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
skipping to change at page 14, line 7 skipping to change at page 14, line 7
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 makes no changes to existing protocols, there As a process memo that only removes limitations on proposed
are no protocol security considerations. experiments, there are no protocol security considerations. Security
considerations for the proposed experiments are discussed in the
Internet-Drafts that propose them.
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
the Internet-Drafts that propose them.
See Appendix B.1 of [I-D.ietf-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, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, DOI 10.17487/RFC2914, September 2000, RFC 2914, DOI 10.17487/RFC2914, September 2000,
<http://www.rfc-editor.org/info/rfc2914>. <https://www.rfc-editor.org/info/rfc2914>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces", Congestion Notification (ECN) Signaling with Nonces",
RFC 3540, DOI 10.17487/RFC3540, June 2003, RFC 3540, DOI 10.17487/RFC3540, June 2003,
<http://www.rfc-editor.org/info/rfc3540>. <https://www.rfc-editor.org/info/rfc3540>.
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion
Control Protocol (DCCP) Congestion Control ID 2: TCP-like Control Protocol (DCCP) Congestion Control ID 2: TCP-like
Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March
2006, <http://www.rfc-editor.org/info/rfc4341>. 2006, <https://www.rfc-editor.org/info/rfc4341>.
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for
Datagram Congestion Control Protocol (DCCP) Congestion Datagram Congestion Control Protocol (DCCP) Congestion
Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342,
DOI 10.17487/RFC4342, March 2006, DOI 10.17487/RFC4342, March 2006, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc4342>. editor.org/info/rfc4342>.
[RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion [RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion
Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate
Control for Small Packets (TFRC-SP)", RFC 5622, Control for Small Packets (TFRC-SP)", RFC 5622,
DOI 10.17487/RFC5622, August 2009, DOI 10.17487/RFC5622, August 2009, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5622>. 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, <https://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, "ECN++: Adding Explicit Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit
Congestion Notification (ECN) to TCP Control Packets", Congestion Notification (ECN) to TCP Control Packets",
draft-bagnulo-tcpm-generalized-ecn-04 (work in progress), draft-bagnulo-tcpm-generalized-ecn-04 (work in progress),
May 2017. May 2017.
[I-D.ietf-tcpm-alternativebackoff-ecn] [I-D.ietf-tcpm-alternativebackoff-ecn]
Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,
"TCP Alternative Backoff with ECN (ABE)", draft-ietf-tcpm- "TCP Alternative Backoff with ECN (ABE)", draft-ietf-tcpm-
alternativebackoff-ecn-01 (work in progress), May 2017. alternativebackoff-ecn-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-09 (work Control for Datacenters", draft-ietf-tcpm-dctcp-10 (work
in progress), July 2017. in progress), August 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.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,
<http://www.rfc-editor.org/info/rfc4774>. <https://www.rfc-editor.org/info/rfc4774>.
[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 17, line 22 skipping to change at page 17, line 22
o Other minor edits. o Other minor edits.
Changes from draft-ietf-tsvwg-ecn-experimentation-03 to -04: Changes from draft-ietf-tsvwg-ecn-experimentation-03 to -04:
o Change name of "Generalized ECN" experimentation area to "TCP o Change name of "Generalized ECN" experimentation area to "TCP
Control Packets and Retransmissions." Control Packets and Retransmissions."
o Add IANA Considerations text to request removal of the o Add IANA Considerations text to request removal of the
registration of the NS bit in the TCP header. registration of the NS bit in the TCP header.
Changes from draft-ietf-tsvwg-ecn-experimentation-04 to -05:
o Minor editorial changes from Area Director review
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. 22 change blocks. 
41 lines changed or deleted 44 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/