< draft-ietf-tsvwg-ecn-experimentation-05.txt   draft-ietf-tsvwg-ecn-experimentation-06.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 30, 2017 Updates: 3168, 4341, 4342, 5622, 6679 September 20, 2017
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: March 3, 2018 Expires: March 24, 2018
Explicit Congestion Notification (ECN) Experimentation Explicit Congestion Notification (ECN) Experimentation
draft-ietf-tsvwg-ecn-experimentation-05 draft-ietf-tsvwg-ecn-experimentation-06
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
any of these enabling updates. In addition, this memo makes related any of these enabling updates. In addition, this memo makes related
updates to the ECN specifications for RTP in RFC 6679 and for DCCP in updates to the ECN specifications for RTP in RFC 6679 and for DCCP in
RFC 4341, RFC 4342 and RFC 5622. This memo also records the RFC 4341, RFC 4342 and RFC 5622. This memo also records the
conclusion of the ECN Nonce experiment in RFC 3540, and provides the conclusion of the ECN nonce experiment in RFC 3540, and provides the
rationale for reclassification of RFC 3540 as Historic; this rationale for reclassification of RFC 3540 as Historic; this
reclassification enables new experimental use of the ECT(1) reclassification enables new experimental use of the ECT(1)
codepoint. codepoint.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 3, 2018. This Internet-Draft will expire on March 24, 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 (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
skipping to change at page 2, line 41 skipping to change at page 2, line 41
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. ECN Terminology . . . . . . . . . . . . . . . . . . . . . 3 1.1. ECN Terminology . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Proposed ECN Experiments: Background . . . . . . . . . . . . 4 2. Proposed ECN Experiments: Background . . . . . . . . . . . . 4
3. ECN Nonce and RFC 3540 . . . . . . . . . . . . . . . . . . . 5 3. ECN Nonce and RFC 3540 . . . . . . . . . . . . . . . . . . . 5
4. Updates to RFC 3168 . . . . . . . . . . . . . . . . . . . . . 6 4. Updates to RFC 3168 . . . . . . . . . . . . . . . . . . . . . 6
4.1. Congestion Response Differences . . . . . . . . . . . . . 6 4.1. Congestion Response Differences . . . . . . . . . . . . . 6
4.2. Congestion Marking Differences . . . . . . . . . . . . . 7 4.2. Congestion Marking Differences . . . . . . . . . . . . . 8
4.3. TCP Control Packets and Retransmissions . . . . . . . . . 10 4.3. TCP Control Packets and Retransmissions . . . . . . . . . 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 . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
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 3, line 35 skipping to change at page 3, line 35
for RTP [RFC6679] and for three DCCP profiles ([RFC4341], [RFC4342] for RTP [RFC6679] and for three DCCP profiles ([RFC4341], [RFC4342]
and [RFC5622]) for the same reason. Each experiment is still and [RFC5622]) for the same reason. Each experiment is still
required to be documented in one or more separate RFCs, but use of required to be documented in one or more separate RFCs, but use of
Experimental RFCs for this purpose does not require a process Experimental RFCs for this purpose does not require a process
exception to modify any of these Proposed Standard RFCs when the exception to modify any of these Proposed Standard RFCs when the
modification falls within the bounds established by this memo (RFC modification falls within the bounds established by this memo (RFC
5622 is an Experimental RFC; it is modified by this memo for 5622 is an Experimental RFC; it is modified by this memo for
consistency with modifications to the other two DCCP RFCs). consistency with modifications to the other two DCCP RFCs).
Some of the anticipated experimentation includes use of the ECT(1) Some of the anticipated experimentation includes use of the ECT(1)
codepoint that was dedicated to the ECN Nonce experiment in RFC 3540 codepoint that was dedicated to the ECN nonce experiment in RFC 3540
[RFC3540]. This memo records the conclusion of the ECN Nonce [RFC3540]. This memo records the conclusion of the ECN nonce
experiment and provides the explanation for reclassification of RFC experiment and provides the explanation for reclassification of RFC
3540 as Historic in order to enable new experimental use of the 3540 as Historic in order to enable new experimental use of the
ECT(1) codepoint. ECT(1) codepoint.
1.1. ECN Terminology 1.1. ECN Terminology
ECT: ECN-Capable Transport. One of the two codepoints ECT(0) or 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 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 ECN-capable sender sets one of these to indicate that both transport
end-points support ECN. end-points support ECN.
skipping to change at page 5, line 36 skipping to change at page 5, line 36
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]. 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 top one million materialized. A study of the ECN behaviour of the top one million
web servers using 2014 data [Trammell15] found that after ECN was web servers using 2014 data [Trammell15] found that after ECN was
negotiated, none of the 581,711 IPv4 servers tested were using both negotiated, none of the 581,711 IPv4 servers tested were using both
ECT codepoints, which would have been a possible sign of ECN Nonce ECT codepoints, which would have been a possible sign of ECN nonce
usage. Of the 17,028 IPv6 servers tested, 4 set both ECT(0) and usage. Of the 17,028 IPv6 servers tested, 4 set both ECT(0) and
ECT(1) on data packets. This might have been evidence of use of the ECT(1) on data packets. This might have been evidence of use of the
ECN Nonce by these 4 servers, but might equally have been due to re- ECN nonce by these 4 servers, but might equally have been due to 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.ietf-tsvwg-ecn-l4s-id]. Therefore, in support of ECN [I-D.ietf-tsvwg-ecn-l4s-id]. Therefore, in support of ECN
experimentation with the ECT(1) codepoint, this memo: experimentation with the ECT(1) codepoint, this memo:
o Declares that the ECN Nonce experiment [RFC3540] has concluded, o Declares that the ECN nonce experiment [RFC3540] has concluded,
and notes the absence of widespread deployment. and notes the absence of widespread deployment.
o Updates RFC 3168 [RFC3168] to remove discussion of the ECN Nonce o Updates RFC 3168 [RFC3168] to remove discussion of the ECN nonce
and use of ECT(1) for that Nonce. The specific text updates are and use of ECT(1) for that nonce.
omitted for brevity.
The four primary updates to RFC 3168 that remove discussion of the
ECN nonce and use of ECT(1) for that nonce are:
1. Remove the paragraph in Section 5 that immediately follows
Figure 1; this paragraph discusses the ECN nonce as the
motivation for two ECT codepoints.
2. Remove Section 11.2 "A Discussion of the ECN nonce." in its
entirety.
3. Remove the last paragraph of Section 12, which states that ECT(1)
may be used as part of the implementation of the ECN nonce.
4. Remove the first two paragraphs of Section 20.2, which discuss
the ECN nonce and alternatives. No changes are made to the rest
of Section 20.2, which discusses alternate uses for the fourth
ECN codepoint.
Additional minor changes remove other mentions of the ECN nonce and
implications that ECT(1) is intended for use by the ECN nonce; the
specific text updates are omitted for brevity.
4. Updates to RFC 3168 4. Updates to RFC 3168
The following subsections specify updates to RFC 3168 to enable the The following subsections specify updates to RFC 3168 to enable the
three areas of experimentation summarized in Section 2. three areas of experimentation summarized in Section 2.
4.1. Congestion Response Differences 4.1. Congestion Response Differences
RFC 3168 specifies that senders respond identically to packet drops RFC 3168 specifies that senders respond identically to packet drops
and ECN congestion indications. ECN congestion indications are and ECN congestion indications. ECN congestion indications are
skipping to change at page 10, line 11 skipping to change at page 10, line 32
o Router behavior changes, or the absence thereof, in forwarding CE- o Router behavior changes, or the absence thereof, in forwarding CE-
marked packets that are part of the experiment. marked packets that are part of the experiment.
In addition, until the conclusion of the L4S experiment, use of 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 addition, this memo updates RFC 3168 to remove discussion of the In addition, this memo updates RFC 3168 to remove discussion of the
ECN Nonce, as noted in Section 3 above. ECN nonce, as noted in Section 3 above.
4.3. TCP Control Packets and Retransmissions 4.3. TCP Control Packets and Retransmissions
With the successful use of ECN for traffic in large portions of the With the successful use of ECN for traffic in large portions of the
Internet, there is interest in extending the benefits of ECN to TCP Internet, there is interest in extending the benefits of ECN to TCP
control packets (e.g., SYNs) and retransmitted packets, e.g., as control packets (e.g., SYNs) and retransmitted packets, e.g., as
proposed by ECN++ [I-D.bagnulo-tcpm-generalized-ecn]. proposed by ECN++ [I-D.bagnulo-tcpm-generalized-ecn].
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:
skipping to change at page 13, line 23 skipping to change at page 13, line 43
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 MUST 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
[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 Brian Carpenter, Spencer Dawkins, Gorry
Johansson, Naeem Khademi, Mirja Kuehlewind, Karen Nielsen and Michael Fairhurst, Ingemar Johansson, Naeem Khademi, Mirja Kuehlewind, Karen
Welzl. Bob Briscoe's thorough review of an early version of this Nielsen, Hilarie Orman and Michael Welzl. Bob Briscoe's thorough
draft resulted in numerous improvements including addition of the review of an early version of this draft resulted in numerous
updates to the DCCP RFCs. improvements including addition of the updates to the DCCP RFCs.
8. IANA Considerations 8. IANA Considerations
To reflect the reclassification of RFC 3540 as Historic, IANA is To reflect the reclassification of RFC 3540 as Historic, IANA is
requested to update the Transmission Control Protocol (TCP) Header requested to update the Transmission Control Protocol (TCP) Header
Flags registry (https://www.iana.org/assignments/tcp-header-flags/ Flags registry (https://www.iana.org/assignments/tcp-header-flags/
tcp-header-flags.xhtml#tcp-header-flags-1) to remove the registration tcp-header-flags.xhtml#tcp-header-flags-1) to remove the registration
of bit 7 as the NS (Nonce Sum) bit and add an annotation to the of bit 7 as the NS (Nonce Sum) bit and add an annotation to the
registry to state that bit 7 was used by Historic RFC 3540 as the NS registry to state that bit 7 was used by Historic RFC 3540 as the NS
(Nonce Sum) bit. (Nonce Sum) bit.
skipping to change at page 14, line 15 skipping to change at page 14, line 35
9. Security Considerations 9. Security Considerations
As a process memo that only removes limitations on proposed As a process memo that only removes limitations on proposed
experiments, there are no protocol security considerations. Security experiments, there are no protocol security considerations. Security
considerations for the proposed experiments are discussed in the considerations for the proposed experiments are discussed in the
Internet-Drafts that propose them. 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. This
Section 4.4. responsibility includes the requirement to discuss congestion control
implications in an Experimental RFC for each experiment, as stated in
Section 4.4; review of that discussion by the IETF community and the
IESG prior to RFC publication is intended to provide assurance that
each experiment does not break Internet congestion control.
See Appendix B.1 of [I-D.ietf-tsvwg-ecn-l4s-id] for discussion of See Appendix 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, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-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,
<https://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,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
skipping to change at page 15, line 8 skipping to change at page 15, line 32
<https://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, <https://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, <https://www.rfc- DOI 10.17487/RFC4342, March 2006,
editor.org/info/rfc4342>. <https://www.rfc-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, <https://www.rfc- DOI 10.17487/RFC5622, August 2009,
editor.org/info/rfc5622>. <https://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, <https://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
skipping to change at page 17, line 26 skipping to change at page 17, line 51
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: Changes from draft-ietf-tsvwg-ecn-experimentation-04 to -05:
o Minor editorial changes from Area Director review o Minor editorial changes from Area Director review
Changes from draft-ietf-tsvwg-ecn-experimentation-05 to -06:
o Add summary of RFC 3168 changes to remove the ECN nonce, and use
lower-case "nonce" instead of "Nonce" to match RFC 3168 usage.
o Add security considerations sentence to indicate that review of
Experimental RFCs prior to publication approval is the means to
ensure that congestion control is not broken by experiments.
o Other minor editorial changes from IETF Last Call
Author's Address Author's Address
David Black David Black
Dell EMC Dell EMC
176 South Street 176 South Street
Hopkinton, MA 01748 Hopkinton, MA 01748
USA USA
Email: david.black@dell.com Email: david.black@dell.com
 End of changes. 27 change blocks. 
37 lines changed or deleted 73 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/