< draft-black-tsvwg-ecn-experimentation-03.txt   draft-black-tsvwg-ecn-experimentation-04.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) October 31, 2016 Obsoletes: 3540 (if approved) November 17, 2016
Updates: 3168, 4341, 4342, 5622, 6679 Updates: 3168, 4341, 4342, 5622, 6679
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: May 4, 2017 Expires: May 21, 2017
Explicit Congestion Notification (ECN) Experimentation Explicit Congestion Notification (ECN) Experimentation
draft-black-tsvwg-ecn-experimentation-03 draft-black-tsvwg-ecn-experimentation-04
Abstract Abstract
Multiple protocol experiments have been proposed that involve changes Multiple protocol experiments have been proposed that involve changes
to Explicit Congestion Notification (ECN) as specified in RFC 3168. to Explicit Congestion Notification (ECN) as specified in RFC 3168.
This memo summarizes the proposed areas of experimentation to provide This memo summarizes the proposed areas of experimentation to provide
an overview to the Internet community and updates RFC 3168, a an overview to the Internet community and updates RFC 3168, a
Proposed Standard RFC, to allow the experiments to proceed without Proposed Standard RFC, to allow the experiments to proceed without
requiring a standards process exception for each Experimental RFC to requiring a standards process exception for each Experimental RFC to
update RFC 3168. Each experiment is still required to be documented update RFC 3168. Each experiment is still required to be documented
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 May 4, 2017. This Internet-Draft will expire on May 21, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 39 skipping to change at page 2, line 39
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. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Scope of ECN Experiments . . . . . . . . . . . . . . . . . . 3 2. Scope of ECN Experiments . . . . . . . . . . . . . . . . . . 3
3. ECN Nonce and RFC 3540 . . . . . . . . . . . . . . . . . . . 4 3. ECN Nonce and RFC 3540 . . . . . . . . . . . . . . . . . . . 4
4. Updates to RFC 3168 . . . . . . . . . . . . . . . . . . . . . 5 4. Updates to RFC 3168 . . . . . . . . . . . . . . . . . . . . . 5
4.1. Alternative Backoff . . . . . . . . . . . . . . . . . . . 5 4.1. Congestion Response Differences . . . . . . . . . . . . . 5
4.2. ECT Differences . . . . . . . . . . . . . . . . . . . . . 6 4.2. ECT Differences . . . . . . . . . . . . . . . . . . . . . 6
4.3. Generalized ECN . . . . . . . . . . . . . . . . . . . . . 6 4.3. Generalized ECN . . . . . . . . . . . . . . . . . . . . . 7
4.4. Effective Congestion Control is Required . . . . . . . . 7 4.4. Effective Congestion Control is Required . . . . . . . . 8
5. ECN for RTP Updates to RFC 6679 . . . . . . . . . . . . . . . 8 5. ECN for RTP Updates to RFC 6679 . . . . . . . . . . . . . . . 9
6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622 . . . . . . 9 6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622 . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
Multiple protocol experiments have been proposed that involve changes Multiple protocol experiments have been proposed that involve changes
to Explicit Congestion Notification (ECN) as specified in RFC 3168 to Explicit Congestion Notification (ECN) as specified in RFC 3168
[RFC3168]. This memo summarizes the proposed areas of [RFC3168]. This memo summarizes the proposed areas of
experimentation to provide an overview to the Internet community and experimentation to provide an overview to the Internet community and
updates RFC 3168 to allow the experiments to proceed without updates RFC 3168 to allow the experiments to proceed without
requiring a standards process exception for each Experimental RFC to requiring a standards process exception for each Experimental RFC to
update RFC 3168, a Proposed Standard RFC. This memo also makes update RFC 3168, a Proposed Standard RFC. This memo also makes
skipping to change at page 3, line 39 skipping to change at page 3, line 39
"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. Scope of ECN Experiments
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 goals and rationale
of each proposed experiment: of each proposed experiment:
Alternative Backoff: For congestion indicated by ECN, use a Congestion Response Differences: For congestion indicated by ECN,
different IETF-approved TCP sender response (e.g., reduce the use a different IETF-approved sender congestion response (e.g.,
response so that the sender backs off by a smaller amount) by reduce the response so that the sender backs off by a smaller
comparison to congestion indicated by loss, e.g., as proposed in amount) by comparison to congestion indicated by loss, e.g., as
[I-D.khademi-tcpm-alternativebackoff-ecn] and proposed in [I-D.khademi-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 ECT Differences functionality
(next bullet). This is at variance with RFC 3168's requirement (next bullet). This is at variance with RFC 3168's requirement
that a TCP sender's congestion control response to ECN congestion that a sender's congestion control response to ECN congestion
indications be the same as to drops. indications be the same as to drops.
ECT Differences: Use ECT(1) to request ECN congestion marking ECT Differences: Use ECT(1) to request ECN congestion marking
behavior in the network that differs from ECT(0) counterbalanced behavior in the network that differs from ECT(0) counterbalanced
by a changed response to each mark at the sender, e.g., as by use of a different IETF-approved congestion response to CE
proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]. This is at variance marks at the sender, e.g., as proposed in
with RFC 3168's requirement that ECT(0)-marked traffic and ECT(1)- [I-D.briscoe-tsvwg-ecn-l4s-id]. This is at variance with RFC
marked traffic not receive different treatment in the network. 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: Use ECN for TCP control packets (i.e., send control
packets such as SYN with ECT marking) and for retransmitted packets such as SYN with ECT marking) and for retransmitted
packets, e.g., as proposed in [I-D.bagnulo-tsvwg-generalized-ecn]. packets, e.g., as proposed in [I-D.bagnulo-tsvwg-generalized-ecn].
This is at variance with RFC 3168's prohibition of use of ECN for This is at variance with RFC 3168's prohibition of use of ECN for
TCP control packets and retransmitted packets 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 neither prejudges the outcomes of the
proposed experiments nor specifies the experiments in detail. The proposed experiments nor specifies the experiments in detail. The
skipping to change at page 4, line 43 skipping to change at page 4, line 44
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 equally it might have been due to
re-marking of the ECN field by an erroneous middlebox or router. re-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, alternative 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 o Obsoletes RFC 3540 in order to facilitate experimental use of the
ECT(1) codepoint. ECT(1) codepoint.
skipping to change at page 5, line 27 skipping to change at page 5, line 27
not implemented: not implemented:
Protocols and senders that only require a single ECT codepoint Protocols and senders that only require a single ECT codepoint
SHOULD use ECT(0). SHOULD use ECT(0).
OPEN ISSUE: Change the above requirement in RFC 3168 from SHOULD to OPEN ISSUE: Change the above requirement in RFC 3168 from SHOULD to
MUST towards reserving ECT(1) for experimentation? MUST towards reserving ECT(1) for experimentation?
4. Updates to RFC 3168 4. Updates to RFC 3168
RFC 3168 can only be updated directly by another standards track RFC RFC 3168 is a Proposed Standard RFC, so updating RFC 3168 requires
unless a standards process exception is approved by the IESG. In publishing a standards track RFC unless a standards process exception
support of the above areas of experimentation, and specifically to is approved by the IESG, e.g., to allow an Experimental RFC to update
avoid multiple uncoordinated requests to the IESG for process RFC 3168. In support of the above areas of experimentation, and
exceptions, this memo updates RFC 3168 [RFC3168] ito allow changes in specifically to avoid multiple uncoordinated requests to the IESG for
the following areas, provided that the changes are documented by an standards process exceptions, this memo updates RFC 3168 [RFC3168]
Experimental RFC. It is also possible to change RFC 3168 via ito allow changes in the following areas, provided that the changes
publication of another standards track RFC. are documented by an Experimental RFC. It is also possible to change
RFC 3168 via publication of another standards track RFC.
4.1. Alternative Backoff 4.1. Congestion Response Differences
Section 5 of RFC 3168 specifies that: Section 5 of RFC 3168 specifies that:
"Upon the receipt by an ECN-Capable transport of a single CE Upon the receipt by an ECN-Capable transport of a single CE
packet, the congestion control algorithms followed at the end- packet, the congestion control algorithms followed at the end-
systems MUST be essentially the same as the congestion control systems MUST be essentially the same as the congestion control
response to a *single* dropped packet." response to a *single* dropped packet.
In support of Alternative Backoff experimentation, this memo updates In support of Congestion Response Differences experimentation, this
RFC 3168 to allow the congestion control response (including the TCP memo updates RFC 3168 to allow the congestion control response
Sender's congestion control response) to a CE-marked packet to differ (including the TCP Sender's congestion control response) to a CE-
from the response to a dropped packet, provided that the changes from marked packet to differ from the response to a dropped packet,
RFC 3168 are documented in an Experimental RFC. The specific change provided that the changes from RFC 3168 are documented in an
to RFC 3168 is to insert the words "unless otherwise specified by an Experimental RFC. The specific change to RFC 3168 is to insert the
Experimental RFC" at the end of the sentence quoted above. words "unless otherwise specified by an Experimental RFC" at the end
of the sentence quoted above.
RFC 4774 [RFC4774] quotes the above text from RFC 3168 as background, RFC 4774 [RFC4774] quotes the above text from RFC 3168 as background,
but does not impose requirements based on that text. Therefore no but does not impose requirements based on that text. Therefore no
update to RFC 4774 is required to enable this area of update to RFC 4774 is required to enable this area of
experimentation. experimentation.
4.2. ECT Differences 4.2. ECT Differences
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.
Senders are free to use either the ECT(0) or the ECT(1) codepoint
to indicate ECT, on a packet-by-packet basis."
In support of ECT Differences experimentation, this memo updates RFC In support of ECT Differences experimentation, this memo updates RFC
3168 to allow routers to treat the ECT(0) and ECT(1) codepoints 3168 to allow routers to treat the ECT(0) and ECT(1) codepoints
differently, and allow requirements to be imposed on sender usage of differently, provided that the changes from RFC 3168 are documented
ECT(0) and ECT(1), provided that the changes from RFC 3168 are in an Experimental RFC. The specific change to RFC 3168 is to insert
documented in an Experimental RFC. That change makes the second
sentence quoted above misleading, so RFC 3168 is also updated to
remove that sentence. The specific change to RFC 3168 is to insert
the words "unless otherwise specified by an Experimental RFC" at the the words "unless otherwise specified by an Experimental RFC" at the
end of the first sentence, and remove the second sentence with this end of the above sentence.
result:
"Routers treat the ECT(0) and ECT(1) codepoints as equivalent In support of ECT Differences experimentation, this memo updates RFC
unless otherwise specified by an Experimental RFC." 3168 to enable effective endpoint use of ECT(1) for large scale
experimentation. The proposed L4S experiment
[I-D.briscoe-tsvwg-ecn-l4s-id] significantly increases the CE marking
probability for ECT(1)-marked traffic in a fashion that interacts
badly with existing sender congestion response functionality because
that functionality assumes that a CE-marked packet would have been
dropped by the network. If network traffic that uses such a sender
congestion response encounters L4S's increased marking probability
(and hence rate) at a network bottleneck queue, the resulting traffic
throughput is likely to be much less than intended for the level of
congestion at the bottleneck queue. To avoid that interaction, this
memo reserves ECT(1) for experimentation, initially 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
to indicate ECT, on a packet-by-packet basis.
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
sender to verify that network elements are not erasing the CE
codepoint, and that data receivers are properly reporting to the
sender the receipt of packets with the CE codepoint set, as
required by the transport protocol. Guidelines for the 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. Protocols and senders that only require a
single ECT codepoint SHOULD use ECT(0).
and replace it with:
Unless otherwise modified by an Experimental RFC, senders MUST use
the ECT(0) codepoint to indicate ECT and MUST NOT use the ECT(1)
codepoint to indicate ECT.
As ECT(0) was the original codepoint used to signal ECN capability,
ECT Differences experiments SHOULD modify the network behavior for ECT Differences experiments SHOULD modify the network behavior for
ECT(1) rather than ECT(0) if network behavior for only one ECT ECT(1)-marked traffic rather than ECT(0)-marked traffic if network
codepoint is modified. behavior for only one ECT codepoint is modified. ECT Differences
experiments MUST NOT modify the network behavior for ECT(0)-marked
traffic in a fashion that requires changes to sender congestion
response to obtain desired network behavior. If an ECT Differences
experiment modifies the network behavior for ECT(1)-marked traffic,
e.g., CE-marking behavior, in a fashion that requires changes to
sender congestion 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 Router behavior changes, or the absence thereof, in fowarding CE-
marked packets that are part of the experiment.
In addition, until the conclusion of the L4S experiment, use of
ECT(1) in IETF RFCs is not appropriate, as the IETF may decide to
allocate ECT(1) exclusively for L4S usage if the L4S experiment is
successful.
In support of ECT Differences experimentation, this memo also updates In support of ECT Differences experimentation, this memo also updates
RFC 3168 to remove discussion of the ECN Nonce, as noted in Section 3 RFC 3168 to remove discussion of the ECN Nonce, as noted in Section 3
above. above.
4.3. Generalized ECN 4.3. 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 7, line 38 skipping to change at page 8, line 38
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.
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.
skipping to change at page 8, line 19 skipping to change at page 9, line 19
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 ECT Differences area of experimentation increases the potential
consequences of using ECT(1) instead of ECT(0), and hence the above consequences of using ECT(1) instead of ECT(0), and hence the above
guidance is updated by adding the following two sentences: guidance is updated by adding the following two sentences:
Use of random ECT values is NOT RECOMMENDED, as that may expose Random ECT values MUST NOT be used, as that may expose RTP to
RTP to differences in network treatment of traffic marked with differences in network treatment of traffic marked with ECT(1) and
ECT(1) and ECT(0) and differences in associated endpoint ECT(0) and differences in associated endpoint congestion
congestion responses, e.g., as proposed in responses, e.g., as proposed in [I-D.briscoe-tsvwg-ecn-l4s-id].
[I-D.briscoe-tsvwg-ecn-l4s-id]. ECT(0) SHOULD be used unless In addition, ECT(0) MUST be used unless otherwise specified in an
there is a need for more than one ECT codepoint or unless Experimental RFC.
otherwise specified in an Experimental RFC.
Section 7.3.3 of RFC 6679 specifies RTP's response to receipt of CE Section 7.3.3 of RFC 6679 specifies RTP's response to receipt of CE
marked packets as being identical to the response to dropped packets: marked packets as being identical to the response to dropped packets:
The reception of RTP packets with ECN-CE marks in the IP header is The reception of RTP packets with ECN-CE marks in the IP header is
a notification that congestion is being experienced. The default a notification that congestion is being experienced. The default
reaction on the reception of these ECN-CE-marked packets MUST be reaction on the reception of these ECN-CE-marked packets MUST be
to provide the congestion control algorithm with a congestion to provide the congestion control algorithm with a congestion
notification that triggers the algorithm to react as if packet notification that triggers the algorithm to react as if packet
loss had occurred. There should be no difference in congestion loss had occurred. There should be no difference in congestion
response if ECN-CE marks or packet drops are detected. response if ECN-CE marks or packet drops are detected.
In support of Alternative Backoff experimentation, this memo updates In support of Congestion Response Differences experimentation, this
this text in a fashion similar to RFC 3168 to allow the RTP memo updates this text in a fashion similar to RFC 3168 to allow the
congestion control response to a CE-marked packet to differ from the RTP congestion control response to a CE-marked packet to differ from
response to a dropped packet, provided that the changes from RFC 6679 the response to a dropped packet, provided that the changes from RFC
are documented in an Experimental RFC. The specific change to RFC 6679 are documented in an Experimental RFC. The specific change to
6679 is to insert the words "Unless otherwise specified by an RFC 6679 is to insert the words "Unless otherwise specified by an
Experimental RFC" and reformat the last two sentences to be subject Experimental RFC" and reformat the last two sentences to be subject
to that condition, i.e.: to that condition, i.e.:
The reception of RTP packets with ECN-CE marks in the IP header is The reception of RTP packets with ECN-CE marks in the IP header is
a notification that congestion is being experienced. Unless a notification that congestion is being experienced. Unless
otherwise specified by an Experimental RFC: otherwise specified by an Experimental RFC:
* The default reaction on the reception of these ECN-CE-marked * The default reaction on the reception of these ECN-CE-marked
packets MUST be to provide the congestion control algorithm packets MUST be to provide the congestion control algorithm
with a congestion notification that triggers the algorithm to with a congestion notification that triggers the algorithm to
react as if packet loss had occurred. react as if packet loss had occurred.
* There should be no difference in congestion response if ECN-CE * There should be no difference in congestion response if ECN-CE
marks or packet drops are detected. marks or packet drops are detected.
The second sentence of the immediately following paragraph in RFC The second sentence of the immediately following paragraph in RFC
6679 requires a related update: 6679 requires a related update:
Other reactions to ECN-CE may be specified in the future, Other reactions to ECN-CE may be specified in the future,
following IETF Review. Detailed designs of such alternative following IETF Review. Detailed designs of such additional
reactions MUST be specified in a Standards Track RFC and be reactions MUST be specified in a Standards Track RFC and be
reviewed to ensure they are safe for deployment under any reviewed to ensure they are safe for deployment under any
restrictions specified. restrictions specified.
The update is to change "Standards Track RFC" to "Standards Track RFC The update is to change "Standards Track RFC" to "Standards Track RFC
or Experimental RFC" for consistency with the first update. or Experimental RFC" for consistency with the first update.
6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622 6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622
The specifications of the three DCCP Congestion Control IDs (CCIDs) 2 The specifications of the three DCCP Congestion Control IDs (CCIDs) 2
skipping to change at page 13, line 21 skipping to change at page 14, line 21
o Clarify that "SHOULD use ECT(0)" guidance from RFC 3168 is about o Clarify that "SHOULD use ECT(0)" guidance from RFC 3168 is about
IP headers. IP headers.
o Add a "SHOULD NOT" requirement that middleboxes not discard TCP o Add a "SHOULD NOT" requirement that middleboxes not discard TCP
control packets, etc. solely because they use ECN. control packets, etc. solely because they use ECN.
o Switch to pre-5378 boilerplate, due to vintage of RFCs being o Switch to pre-5378 boilerplate, due to vintage of RFCs being
updated. 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.
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. 
76 lines changed or deleted 140 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/