< draft-ietf-tsvwg-ecn-experimentation-03.txt   draft-ietf-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
Updates: 3168, 4341, 4342, 5622, 6679 June 21, 2017 Updates: 3168, 4341, 4342, 5622, 6679 August 4, 2017
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: December 23, 2017 Expires: February 5, 2018
Explicit Congestion Notification (ECN) Experimentation Explicit Congestion Notification (ECN) Experimentation
draft-ietf-tsvwg-ecn-experimentation-03 draft-ietf-tsvwg-ecn-experimentation-04
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 December 23, 2017. This Internet-Draft will expire on February 5, 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 2, line 42 skipping to change at page 2, line 42
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 . . . . . . . . . . . . . 7
4.3. Generalized ECN . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . 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
skipping to change at page 5, line 7 skipping to change at page 5, line 7
[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 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 TCP Control Packets and Retransmissions: RFC 3168 limits the use of
packets, excluding retransmissions. With the successful ECN with TCP to data packets, excluding retransmissions. With the
deployment of ECN in large portions of the Internet, there is successful deployment of ECN in large portions of the Internet,
interest in extending the benefits of ECN to TCP control packets there is interest in extending the benefits of ECN to TCP control
(e.g., SYNs) and retransmitted packets, e.g., as proposed in packets (e.g., SYNs) and retransmitted packets, e.g., as proposed
[I-D.bagnulo-tcpm-generalized-ecn]. This is at variance with RFC in [I-D.bagnulo-tcpm-generalized-ecn]. This is at variance with
3168's prohibition of use of ECN for TCP control packets and RFC 3168's prohibition of use of ECN for TCP control packets and
retransmitted packets. 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 expresses no view on the likely outcomes experimentation. This memo expresses no view on the likely outcomes
of the proposed experiments and does not specify the experiments in of the proposed experiments and does not specify the experiments in
detail. Additional experiments in these areas are possible, e.g., on detail. Additional experiments in these areas are possible, e.g., on
use of ECN to support deployment of a protocol similar to DCTCP use of ECN to support deployment of a protocol similar to DCTCP
[I-D.ietf-tcpm-dctcp] beyond DCTCP's current applicability that is [I-D.ietf-tcpm-dctcp] beyond DCTCP's current applicability that is
limited to data center environments. The purpose of this memo is to limited to data center environments. The purpose of this memo is to
remove constraints in standards track RFCs that stand in the way of remove constraints in standards track RFCs that stand in the way of
skipping to change at page 10, line 13 skipping to change at page 10, line 13
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. Generalized ECN 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 in [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:
o "To ensure the reliable delivery of the congestion indication of o "To ensure the reliable delivery of the congestion indication of
the CE codepoint, an ECT codepoint MUST NOT be set in a packet the CE codepoint, an ECT codepoint MUST NOT be set in a packet
unless the loss of that packet in the network would be detected by unless the loss of that packet in the network would be detected by
the end nodes and interpreted as an indication of congestion." the end nodes and interpreted as an indication of congestion."
(Section 5.2) (Section 5.2)
skipping to change at page 11, line 8 skipping to change at page 11, line 8
and SYN-ACK packets, pure acknowledgement packets, window probe and SYN-ACK packets, pure acknowledgement packets, window probe
packets and retransmissions of packets that were originally sent with packets and retransmissions of packets that were originally sent with
an ECT codepoint, provided that the changes from RFC 3168 are an ECT codepoint, provided that the changes from RFC 3168 are
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 end of each sentence quoted above. RFC" at the 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 this area of 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. An exception to this requirement occurs in contain Not-ECT. An exception to this requirement occurs in
responding to an ongoing attack. For example, as part of the responding to an ongoing attack. For example, as part of the
response, it may be appropriate to drop more ECT-marked TCP SYN response, it may be appropriate to drop more ECT-marked TCP SYN
packets than TCP SYN packets marked with not-ECT. Any such packets than TCP SYN packets marked with not-ECT. Any such
exceptional discarding of TCP control packets and retransmitted exceptional discarding of TCP control packets and retransmitted
TCP packets in response to an attack MUST NOT be done routinely in TCP packets in response to an attack MUST NOT be done routinely in
the absence of an attack and SHOULD only be done if it is the absence of an attack and SHOULD only be done if it is
determined that the ECT capability is contributing to the attack. determined that the ECT capability is contributing to the attack.
4.4. Effective Congestion Control is Required 4.4. Effective Congestion Control is Required
Congestion control remains an important aspect of the Internet Congestion control remains an important aspect of the Internet
architecture [RFC2914]. Any Experimental RFC that takes advantage of architecture [RFC2914]. Any Experimental RFC that takes advantage of
this memo's updates to RFC 3168 or RFC 6679 is required to discuss this memo's updates to any RFC is required to discuss the congestion
the congestion control implications of the experiment(s) in order to control implications of the experiment(s) in order to provide
provide assurance that deployment of the experiment(s) does not pose assurance that deployment of the experiment(s) does not pose a
a congestion-based threat to the operation of the Internet. congestion-based threat to the operation of the Internet.
5. ECN for RTP Updates to RFC 6679 5. ECN for RTP Updates to RFC 6679
RFC 6679 [RFC6679] specifies use of ECN for RTP traffic; it allows RFC 6679 [RFC6679] specifies use of ECN for RTP traffic; it allows
use of both the ECT(0) and ECT(1) codepoints, and provides the use of both the ECT(0) and ECT(1) codepoints, and provides the
following guidance on use of these codepoints in section 7.3.1 : following guidance on use of these codepoints in section 7.3.1 :
The sender SHOULD mark packets as ECT(0) unless the receiver The sender SHOULD mark packets as ECT(0) unless the receiver
expresses a preference for ECT(1) or for a random ECT value using expresses a preference for ECT(1) or for a random ECT value using
the "ect" parameter in the "a=ecn-capable-rtp:" attribute. the "ect" parameter in the "a=ecn-capable-rtp:" attribute.
skipping to change at page 13, line 46 skipping to change at page 13, line 46
The draft has been improved as a result of comments from a number of The draft has been improved as a result of comments from a number of
reviewers, including Spencer Dawkins, Gorry Fairhurst, Ingemar reviewers, including Spencer Dawkins, Gorry Fairhurst, Ingemar
Johansson, Naeem Khademi, Mirja Kuehlewind, Karen Nielsen and Michael Johansson, Naeem Khademi, Mirja Kuehlewind, Karen Nielsen and Michael
Welzl. Bob Briscoe's thorough review of an early version of this Welzl. Bob Briscoe's thorough review of an early version of this
draft resulted in numerous improvements including addition of the draft resulted in numerous improvements including addition of the
updates to the DCCP RFCs. updates to the DCCP RFCs.
8. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. To reflect the reclassification of RFC 3540 as Historic, IANA is
requested to update the Transmission Control Protocol (TCP) Header
Flags registry (https://www.iana.org/assignments/tcp-header-flags/
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
registry to state that bit 7 was used by Historic RFC 3540 as the NS
(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 makes no changes to existing protocols, there
are no protocol security considerations. are no protocol security considerations.
However, effective congestion control is crucial to the continued However, effective congestion control is crucial to the continued
operation of the Internet, and hence this memo places the operation of the Internet, and hence this memo places the
responsibility for not breaking Internet congestion control on the responsibility for not breaking Internet congestion control on the
experiments and the experimenters who propose them, as specified in experiments and the experimenters who propose them, as specified in
skipping to change at page 15, line 32 skipping to change at page 15, line 38
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-07 (work Control for Datacenters", draft-ietf-tcpm-dctcp-09 (work
in progress), June 2017. in progress), July 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)
skipping to change at page 17, line 10 skipping to change at page 17, line 14
o Remove change history prior to WG adoption. o Remove change history prior to WG adoption.
o Update L4S draft reference to reflect TSVWG adoption of draft. 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" o Change the "SHOULD" for DCCP sender use of ECT(0) to a "MUST"
(overlooked in earlier editing). (overlooked in earlier editing).
o Other minor edits. o Other minor edits.
Changes from draft-ietf-tsvwg-ecn-experimentation-03 to -04:
o Change name of "Generalized ECN" experimentation area to "TCP
Control Packets and Retransmissions."
o Add IANA Considerations text to request removal of the
registration of the NS bit in the TCP header.
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. 14 change blocks. 
23 lines changed or deleted 37 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/