RFC 8311

Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation

📅 published January 2018, from ietf

Part 1 of 5 🎀

Title block 📋

  • Stream: Internet Engineering Task Force (IETF) 🌸
  • RFC: 8311
  • Author: D. Black, from Dell EMC 💅
  • Date: January 2018
  • Category: Standards Track ✨
  • ISSN: 2070-1721
  • Updates: RFC 3168, RFC 4341, RFC 4342, RFC 5622, and RFC 6679 🦋

Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation 💖

Abstract ✨

okay so this memo updates RFC 3168, which is the spec that defines ECN as a way to tell endpoints about network congestion instead of just dropping packets 🫶 the thing is RFC 3168 has a bunch of rules that make it really hard to experiment with ECN for stuff that's way more than just "we avoided losing packets." this memo rounds up the experiments people are expecting to try and updates RFC 3168 so they're actually allowed to happen 🔥 to use any of these enabling updates, you need an Experimental RFC in the IETF document stream. and it's not just RFC 3168 getting glow-ups, this memo also makes related updates to the ECN specs for RTP in RFC 6679 and for the Datagram Congestion Control Protocol (DCCP) in RFCs 4341, 4342, and 5622 💜 it also records the end of the ECN nonce experiment in RFC 3540 and explains why RFC 3540 got moved from Experimental to Historic. that move is what frees up new experimental use of the ECT(1) codepoint 😭✨

Status of This Memo 📝

This is an Internet Standards Track document. 🌈

This document is a product of the Internet Engineering Task Force (IETF). it represents the consensus of the IETF community, it went through public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🎀 if you want more on Internet Standards, check out Section 2 of RFC 7841.

info about this doc's current status, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc8311 🍓

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. please actually read those, because they spell out your rights and restrictions for this document 🙈 any Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes.

this document might contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. the people who control the copyright in some of that material might not have given the IETF Trust permission to allow changes to it outside the IETF Standards Process. so unless you get a proper license from whoever controls that copyright, this document can't be modified outside the IETF Standards Process, and you can't make derivative works of it outside that process either. the one exceptions are formatting it for publication as an RFC or translating it into languages other than English 💅

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  ECN Terminology . . . . . . . . . . . . . . . . . . . . .   4
  1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   4
2.  ECN Experimentation: Overview . . . . . . . . . . . . . . . .   5
  2.1.  Effective Congestion Control is Required  . . . . . . . .   6
  2.2.  Network Considerations for ECN Experimentation  . . . . .   6
  2.3.  Operational and Management Considerations . . . . . . . .   7
3.  ECN Nonce and RFC 3540  . . . . . . . . . . . . . . . . . . .   8
4.  Updates to RFC 3168 . . . . . . . . . . . . . . . . . . . . .   9
  4.1.  Congestion Response Differences . . . . . . . . . . . . .   9
  4.2.  Congestion Marking Differences  . . . . . . . . . . . . .  10
  4.3.  TCP Control Packets and Retransmissions . . . . . . . . .  13
5.  ECN for RTP Updates to RFC 6679 . . . . . . . . . . . . . . .  14
6.  ECN for DCCP Updates to RFCs 4341, 4342, and 5622 . . . . . .  16
7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
8.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
  9.1.  Normative References  . . . . . . . . . . . . . . . . . .  17
  9.2.  Informative References  . . . . . . . . . . . . . . . . .  18
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  20
Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  20

1. Introduction 🦋

okay so this memo updates RFC 3168 [RFC3168], the one that defines ECN as an alternative to packet drops for signalling network congestion to endpoints. it loosens the RFC 3168 restrictions that get in the way of experiments aiming for benefits beyond just not losing packets 💖 this memo lays out the proposed areas of experimentation and updates RFC 3168 so experiments in those areas can happen. an Experimental RFC in the IETF document stream [RFC4844] is required to take advantage of any of these enabling updates. putting all of these updates in one document means experiments can move forward without a standards process exception for every Experimental RFC that needs changes to RFC 3168, which is a Proposed Standard RFC 🫶

there's no need for this memo to update RFC 3168 just to make it easier to standardize protocols and mechanisms documented in Standards Track RFCs. any Standards Track RFC can update RFC 3168 directly, without relying on this memo or using a standards process exception ✨

this memo also makes related updates to the ECN specification for RTP [RFC6679] and to three DCCP profiles ([RFC4341], [RFC4342], and [RFC5622]), for the same reason 🎀 every experiment still has to be documented in one or more separate RFCs. but using Experimental RFCs for this doesn't need a process exception to modify any of these Proposed Standard RFCs, as long as the change stays within the bounds this memo sets. (RFC 5622 is an Experimental RFC; this memo modifies it so it stays consistent with the changes to the other two DCCP RFCs 💅)

some of the expected experimentation involves the ECT(1) codepoint that was reserved for the ECN nonce experiment in RFC 3540 [RFC3540]. this memo records the conclusion of the ECN nonce experiment and explains why RFC 3540 is being reclassified from Experimental to Historic, so that new experimental use of the ECT(1) codepoint is enabled 🧚

1.1. ECN Terminology 📚

  • 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 ECN-capable sender sets one of these to show that both transport endpoints support ECN.
  • Not-ECT: the ECN codepoint that senders set to say the transport is not ECN capable 🙅‍♀️
  • CE: Congestion Experienced 🔥 the ECN codepoint an intermediate node sets to indicate congestion. a node sets an increasing proportion of ECT packets to Congestion Experienced (CE) as congestion gets worse 📈

1.2. Requirements Language 🔑

okay so this is the bit about the key words: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, exactly like that 🧠 if they're lowercase, they're just regular words 💖

2. ECN Experimentation: Overview 🌈

three areas of ECN experimentation are covered by this memo. you should check the cited documents for the detailed goals and reasoning behind each proposed experiment 🫶

Congestion Response Differences: an ECN congestion indication communicates a higher likelihood than a dropped packet that a short queue exists at the network bottleneck node [TCP-ABE]. that's why, for congestion indicated by ECN, a different sender congestion response (for example, the sender backs off by a smaller amount) may be appropriate compared to the sender response to congestion indicated by loss 👀 two examples of proposed sender congestion response changes are described in [TCP-ABE] and [ECN-L4S]. the proposal in the latter document couples the sender congestion response change to Congestion Marking Differences functionality (see next paragraph). these changes are at odds with the RFC 3168 requirement that a sender's congestion control response to ECN congestion indications be the same as its response to drops. IETF approval, for example via an Experimental RFC in the IETF document stream, is required for any sender congestion response used in this area of experimentation. see Section 4.1 for more on this 🔍

Congestion Marking Differences: congestion marking at network nodes can be configured to keep very shallow queues, together with a different sender response to congestion indications (CE marks), for example as proposed in [ECN-L4S] 💅 the traffic involved needs to be identified to the network nodes by the senders, so that other network traffic whose senders don't expect the more frequent congestion marking used to keep queues shallow doesn't get harmed. using different ECN codepoints, specifically ECT(0) and ECT(1), is a promising way to identify traffic for this purpose. but that technique goes against the RFC 3168 requirement that traffic marked as ECT(0) must not receive different treatment in the network compared to traffic marked as ECT(1). IETF approval, for example via an Experimental RFC in the IETF document stream, is required for any differences in congestion marking or sender congestion response used in this area of experimentation. see Section 4.2 for further discussion 🧩

TCP Control Packets and Retransmissions: RFC 3168 limits the use of ECN with TCP to data packets, excluding retransmissions. now that ECN has been successfully deployed across large parts of the Internet, there's interest in extending its benefits to TCP control packets (for example SYNs) and retransmitted packets, as proposed in [ECN-TCP] 🥹 this conflicts with RFC 3168's prohibition on ECN for TCP control packets and retransmitted packets. see Section 4.3 for further discussion 🌸

the scope of this memo is limited to these three areas of experimentation. it expresses no view on the likely outcomes of the proposed experiments and doesn't specify the experiments in detail 🙈 more experiments in these areas are possible, for example on using ECN to support deployment of a protocol similar to Data Center TCP (DCTCP) [RFC8257] beyond DCTCP's current applicability, which is limited to data center environments. the whole point of this memo is to remove constraints in Standards Track RFCs that stand in the way of these areas of experimentation 🚀✨

2.1. Effective Congestion Control is Required 🦋

Okay so congestion control is still a huge deal for the Internet, bestie 💅 [RFC2914]. Any Experimental RFC in the IETF document stream that takes advantage of this memo's updates to any RFC is required to discuss the congestion control implications of the experiment(s) 🫶. The whole point is to give assurance that deploying the experiment(s) does not pose a congestion-based threat to the operation of the Internet 😭. No chaos allowed, periodt 🔥.

2.2. Network Considerations for ECN Experimentation 🌸

ECN functionality [RFC3168] is blowing up across the Internet and is getting built into even more protocols, like Transparent Interconnection of Lots of Links (TRILL) [ECN-TRILL] 🌈. ECN experiments are expected to coexist with the ECN stuff that's already deployed, and the responsibility for that coexistence falls mostly on the designers of experimental changes to ECN 💜. Also, protocol designers, implementers, and network operators may want to anticipate and/or support ECN experiments ✨. These guidelines will help avoid conflicts with the areas of ECN experimentation enabled by this memo 🧚:

  1. Forwarding behavior as described in RFC 3168 remains the preferred approach for routers that are not involved in ECN experiments 🍓. That means continuing to treat the ECT(0) and ECT(1) codepoints as equivalent, as specified in Section 4.2 below 💖.
  2. Network nodes that forward packets SHOULD NOT assume that the ECN CE codepoint indicates the packet would have been dropped if ECN were not in use 👑. The reason is that Congestion Response Differences experiments respond differently to dropped packets than to CE-marked packets (see Section 4.1 below), so CE-marked packets SHOULD NOT be arbitrarily dropped 🙈. A similar difference in congestion responses already happens when the ECN field is used for Pre-Congestion Notification (PCN) [RFC6660] ✨.
  3. A network node MUST NOT originate traffic marked with ECT(1) unless the network node is participating in a Congestion Marking Differences experiment that uses ECT(1), as specified in Section 4.2 below 💀.

Some ECN experiments use ECN on packets where ECN hasn't been used before, specifically TCP control packets and retransmissions 🦋. See Section 4.3 below for those details, because the new middlebox behavior requirements in that section are super important 🔥. In general, any system or protocol that inspects or monitors network traffic SHOULD be prepared to encounter ECN usage on packets and traffic that currently don't use ECN 👀.

ECN field handling requirements for tunnel encapsulation and decapsulation are specified in [RFC6040], which is in the process of being updated by [ECN-SHIM] 🎀. Related guidance for encapsulations whose outer headers are not IP headers can be found in [ECN-ENCAP] 🫧. These requirements and guidance apply to all traffic, including traffic that is part of any ECN experiment 💅.

2.3. Operational and Management Considerations 🌷

Changes in network traffic behavior from ECN experimentation are likely to affect network operations and management, so designers of ECN experiments are expected to anticipate possible impacts and think about how to handle them 😤. Specific topics to consider include possible network management changes or extensions, monitoring of the experimental deployment, collecting data to evaluate the experiment, and possible interactions with other protocols, especially protocols that encapsulate network traffic 🧁.

For more, check out [RFC5706]. The questions in Appendix A of RFC 5706 give a concise survey of some important aspects to consider 📚✨.

  1. ECN Nonce and RFC 3540 🎀

As specified in RFC 3168, ECN uses two ECN-Capable Transport (ECT) codepoints, ECT(0) and ECT(1), to indicate that a packet supports ECN 🦋. RFC 3168 assigned the second codepoint, ECT(1), to support ECN nonce functionality, which discourages receivers from exploiting ECN to boost their throughput at the expense of other network users 💅. That ECN nonce functionality is fully specified in RFC 3540 [RFC3540] 📖. This section explains why RFC 3540 has been reclassified from Experimental to Historic and makes associated updates to RFC 3168 🌸.

The ECN nonce works as specified and has been deployed in limited environments, but widespread usage in the Internet never really happened 😅. A study of the ECN behavior of the top one million web servers using 2014 data [Trammell15] found that after ECN was negotiated, none of the 581,711 IPv4 servers tested were using both ECT codepoints, which would have been a possible sign of ECN nonce usage 🙀. Of the 17,028 IPv6 servers tested, four set both ECT(0) and ECT(1) on data packets 👀. That might have been evidence of the ECN nonce being used by those four servers, but it could just as easily have been erroneous re-marking of the ECN field by a middlebox or router 🤷‍♀️.

With new experimental functionality emerging that depends on the ECT(1) codepoint for other purposes, keeping that codepoint reserved for the ECN nonce experiment is no longer justified 🧚. Other approaches to discouraging receivers from exploiting ECN have also come up; see Appendix B.1 of [ECN-L4S] ✨. So, to support ECN experimentation with the ECT(1) codepoint, this memo:

  • Declares that the ECN nonce experiment [RFC3540] has concluded and notes the absence of widespread deployment 🫶.
  • Updates RFC 3168 [RFC3168] to remove discussion of the ECN nonce and use of ECT(1) for that nonce 💜.

The four main updates to RFC 3168 that remove discussion of the ECN nonce and use of ECT(1) for that nonce are these:

  1. Remove the paragraph in Section 5 that immediately follows Figure 1. That 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 alternative uses for the fourth ECN codepoint 🌈.

Besides those, other less-substantive changes to RFC 3168 are needed to remove every other mention of the ECN nonce and to remove any implication that ECT(1) is meant for the ECN nonce. These specific text updates are omitted for brevity 🙈.

  1. Updates to RFC 3168 💖

The following subsections specify updates to RFC 3168 that enable the three areas of experimentation summarized in Section 2 ✨.

4.1. Congestion Response Differences 🦋

RFC 3168 specifies that senders respond identically to packet drops and ECN congestion indications 🙃. ECN congestion indications are mostly generated by Active Queue Management (AQM) mechanisms in intermediate buffers 🌊. AQM mechanisms are usually set up to keep queues shorter than non-AQM mechanisms do, especially non-AQM drop-based ones like tail-drop, since AQM signals congestion before the queue overflows 🏃‍♀️. Loss doesn't easily tell the receiver whether AQM is in use, but receiving an ECN CE mark is a strong hint that AQM was used to manage the bottleneck queue 🕵️‍♀️. So an ECN congestion indication is more likely than a dropped packet to mean a short queue exists at the network bottleneck node [TCP-ABE] 🧠. This difference suggests that for congestion signalled by ECN, a different sender congestion response (for example, backing off by a smaller amount) may be appropriate compared to the sender response to congestion signalled by loss 💅.

However, Section 5 of RFC 3168 specifies that:

Upon the receipt by an ECN-Capable transport of a single CE packet, the congestion control algorithms followed at the end-systems MUST be essentially the same as the congestion control response to a single dropped packet.

This memo updates that text from RFC 3168 so the congestion control response (including the TCP Sender's congestion control response) to a CE-marked packet can differ from the response to a dropped packet, as long as the changes from RFC 3168 are documented in an Experimental RFC in the IETF document stream 🎀. The specific change to RFC 3168 is to insert the words "unless otherwise specified by an Experimental RFC in the IETF document stream" at the end of the sentence quoted above 🫶.

RFC 4774 [RFC4774] quotes the text above from RFC 3168 as background, but it doesn't impose requirements based on that text 🌸. So no update to RFC 4774 is needed to enable this area of experimentation 💜.

Section 6.1.2 of RFC 3168 specifies that:

If the sender receives an ECN-Echo (ECE) ACK packet (that is, an ACK packet with the ECN-Echo flag set in the TCP header), then the sender knows that congestion was encountered in the network on the path from the sender to the receiver. The indication of congestion should be treated just as a congestion loss in non-ECN-Capable TCP. That is, the TCP source halves the congestion window "cwnd" and reduces the slow start threshold "ssthresh".

This memo also updates that text from RFC 3168 so the congestion control response (including the TCP Sender's congestion control response) to a CE-marked packet can differ from the response to a dropped packet, as long as the changes from RFC 3168 are documented in an Experimental RFC in the IETF document stream 🌈. The specific change to RFC 3168 is to insert the words "Unless otherwise specified by an Experimental RFC in the IETF document stream" at the beginning of the second sentence quoted above ⭐.

4.2. Congestion Marking Differences ✨

Okay so, if you push an AQM that uses ECN congestion indications all the way to the limit, it can keep queues super shallow 🌸. That cuts network latency compared to keeping a bigger queue. But senders have to be way more aggressive in how they respond to ECN to actually make good use of those tiny queues. "Datacenter TCP (DCTCP)" [RFC8257] is an example 💅. Because of that, separate treatment at network nodes is essential, for two reasons: to stop the aggressive low-latency traffic from starving conventional traffic (if there is any), and to stop conventional traffic from disrupting any lower-latency service that uses those very shallow queues 🙈. Using different ECN codepoints looks like a promising way to tell these two classes of traffic apart for network nodes. So this area of experimentation is based on using the ECT(1) codepoint to ask for ECN congestion marking behavior in the network that differs from ECT(0) 🦋. It is essential that any such change in ECN congestion marking behavior be counterbalanced by use of a different IETF-approved congestion response to CE marks at the sender, e.g., as proposed in [ECN-L4S].

Section 5 of RFC 3168 specifies that "Routers treat the ECT(0) and ECT(1) codepoints as equivalent." 🤓

This memo updates RFC 3168 to let routers treat the ECT(0) and ECT(1) codepoints differently, provided that the changes from RFC 3168 are documented in an Experimental RFC in the IETF document stream 🎀. The specific change to RFC 3168 is to insert the words "unless otherwise specified by an Experimental RFC in the IETF document stream" at the end of the above sentence.

When an AQM is configured to use ECN congestion indications to maintain a very shallow queue, congestion indications get marked on packets that would not have been dropped if ECN wasn't in use 👀. Section 5 of RFC 3168 specifies that:

"For a router, the CE codepoint of an ECN-Capable packet SHOULD only be set if the router would otherwise have dropped the packet 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 a packet to inform end nodes of incipient congestion, the router 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, the router MAY instead set the CE codepoint in the IP header."

This memo updates RFC 3168 to allow congestion indications that are not equivalent to drops, provided that the changes from RFC 3168 are documented in an Experimental RFC in the IETF document stream 🌈. The specific change is to change "For a router" to "Unless otherwise specified by an Experimental RFC in the IETF document stream" at the beginning of the first sentence of the above paragraph.

A larger update to RFC 3168 is needed to enable sender usage of ECT(1) to request network congestion marking behavior that maintains very shallow queues at network nodes 😭. When using loss as a congestion signal, the number of signals provided should be reduced to a minimum, so only the presence or absence of congestion gets communicated. ECN, on the other hand, can provide a richer signal, e.g., to indicate the current level of congestion, without the downside of a bigger pile of packet losses ✨. A proposed experiment in this area, Low Latency Low Loss Scalable throughput (L4S) [ECN-L4S], significantly increases the CE marking probability for traffic marked as ECT(1). That would interact badly with existing sender congestion response functionality, because that functionality assumes the network marks ECT packets as frequently as it would drop Not-ECT packets 💀. If network traffic using such a conventional sender congestion response hit L4S's increased marking probability (and therefore rate) at a network bottleneck queue, the resulting throughput is likely to be much less than intended for the level of congestion at that bottleneck queue.

This memo updates RFC 3168 to remove that interaction for ECT(1) 🧚. The specific update to Section 5 of RFC 3168 is to replace the following two paragraphs:

"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)."

with this paragraph:

"Protocols and senders MUST use the ECT(0) codepoint to indicate ECT unless otherwise specified by an Experimental RFC in the IETF document stream. Protocols and senders MUST NOT use the ECT(1) codepoint to indicate ECT unless otherwise specified by an Experimental RFC in the IETF document stream. Guidelines for 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."

Congestion Marking Differences experiments SHOULD modify the network behavior for traffic marked as ECT(1) rather than ECT(0) if network behavior for only one ECT codepoint is modified 🍓. Congestion Marking Differences experiments MUST NOT modify the network behavior for traffic marked as ECT(0) in a fashion that requires changes to the sender congestion response to obtain the desired network behavior. If a Congestion Marking Differences experiment modifies the network behavior for traffic marked as ECT(1) (e.g., CE-marking behavior) in a fashion that requires changes to the sender congestion response to obtain the desired network behavior, then the Experimental RFC in the IETF document stream for that experiment MUST specify:

  • The sender congestion response to CE marking in the network, and
  • Router behavior changes, or the absence thereof, in forwarding CE-marked packets that are part of the experiment.

In addition, this memo updates RFC 3168 to remove discussion of the ECN nonce, as noted in Section 3 above 🫶.

4.3. TCP Control Packets and Retransmissions

With the successful use of ECN for traffic across large portions of the Internet, there's interest in extending the benefits of ECN to TCP control packets (e.g., SYNs) and retransmitted packets, e.g., as proposed by ECN++ [ECN-TCP] 🚀.

RFC 3168 prohibits use of ECN for TCP control packets and retransmitted packets in a number of places:

  • Section 5.2: "To ensure the reliable delivery of the congestion indication of 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 the end nodes and interpreted as an indication of congestion."
  • Section 6.1.1: "A host MUST NOT set ECT on SYN or SYN-ACK packets"
  • Section 6.1.4: "...pure acknowledgement packets (e.g., packets that do not contain any accompanying data) MUST be sent with the not-ECT codepoint."
  • Section 6.1.5: "This document specifies ECN-capable TCP implementations MUST NOT set either ECT codepoint (ECT(0) or ECT(1)) in the IP header for retransmitted data packets, and that the TCP data receiver SHOULD ignore the ECN field on arriving data packets that are outside of the receiver's current window."
  • Section 6.1.6: "...the TCP data sender MUST NOT set either an ECT codepoint or the CWR bit on window probe packets."

This memo updates RFC 3168 to allow the use of ECT codepoints on SYN and SYN-ACK packets, pure acknowledgement packets, window probe packets, and retransmissions of packets that were originally sent with an ECT codepoint, provided that the changes from RFC 3168 are documented in an Experimental RFC in the IETF document stream 🦋. The specific change to RFC 3168 is to insert the words "unless otherwise specified by an Experimental RFC in the IETF document stream" at the end of each sentence quoted above.

Also, beyond requiring TCP senders not to set ECT on TCP control packets and retransmitted packets, RFC 3168 is silent on whether it's appropriate for a network element (e.g., a firewall) to discard such a packet as invalid 🙈. For this area of ECN experimentation to be useful, middleboxes ought not to do that. So RFC 3168 gets updated by adding the following text to the end of Section 6.1.1.1 on Middlebox Issues:

"Unless otherwise specified by an Experimental RFC in the IETF document stream, middleboxes SHOULD NOT discard TCP control packets and retransmitted TCP packets solely because the ECN field in the IP header does not contain Not-ECT. An exception to this requirement occurs in responding to an attack that uses ECN codepoints other than Not-ECT. For example, as part of the response, it may be appropriate to drop ECT-marked TCP SYN packets with higher probability than TCP SYN packets marked with Not-ECT. Any such exceptional discarding of TCP control packets and retransmitted 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 determined that the use of ECN is contributing to the attack."

5. ECN for RTP Updates to RFC 6679 ✨

Okay bestie, so RFC 6679 🎀 is the one that sets up ECN for RTP traffic 📞, and it lets senders use both the ECT(0) and ECT(1) codepoints 🦋. In its Section 7.3.1 it gives this guidance on picking between them:

The sender SHOULD mark packets as ECT(0) unless the receiver expresses a preference for ECT(1) or for a random ECT value using the "ect" parameter in the "a=ecn-capable-rtp:" attribute.

Now, the Congestion Marking Differences experiment makes using ECT(1) instead of ECT(0) way more consequential 💀, so this memo adds two more sentences to that guidance. Here's the new version:

Random ECT values MUST NOT be used, as that may expose RTP to differences in network treatment of traffic marked with ECT(1) and ECT(0) and differences in associated endpoint congestion responses. In addition, ECT(0) MUST be used unless otherwise specified in an Experimental RFC in the IETF document stream.

Section 7.3.3 of RFC 6679 says that when RTP sees CE-marked packets, it should respond exactly the same way it would to dropped packets 📉:

The reception of RTP packets with ECN-CE marks in the IP header is a notification that congestion is being experienced. The default reaction on the reception of these ECN-CE-marked packets MUST be to provide the congestion control algorithm with a congestion notification that triggers the algorithm to react as if packet loss had occurred. There should be no difference in congestion response if ECN-CE marks or packet drops are detected.

For the Congestion Response Differences experiment 🧪, this memo updates that text in the same style as RFC 3168 💅. The RTP congestion control response to a CE-marked packet is allowed to differ from the response to a dropped packet, but only if the changes from RFC 6679 are documented in an Experimental RFC in the IETF document stream 🌈. The specific change is to add the words "Unless otherwise specified by an Experimental RFC in the IETF document stream" and to reformat the last two sentences so they fall under that condition:

The reception of RTP packets with ECN-CE marks in the IP header is a notification that congestion is being experienced. Unless otherwise specified by an Experimental RFC in the IETF document stream:

  • The default reaction on the reception of these ECN-CE-marked packets MUST be to provide the congestion control algorithm with a congestion notification that triggers the algorithm to react as if packet loss had occurred.
  • There should be no difference in congestion response if ECN-CE marks or packet drops are detected.

The second sentence of the next paragraph in Section 7.3.3 of RFC 6679 needs a matching update 🫶:

Other reactions to ECN-CE may be specified in the future, following IETF Review. Detailed designs of such alternative reactions MUST be specified in a Standards Track RFC and be reviewed to ensure they are safe for deployment under any restrictions specified.

The change is to swap "Standards Track RFC" for "Standards Track RFC or Experimental RFC in the IETF document stream", so it lines up with the first update 🎯.

6. ECN for DCCP Updates to RFCs 4341, 4342, and 5622 🌸

The specs for the three DCCP Congestion Control IDs (CCIDs), namely 2 [RFC4341], 3 [RFC4342], and 4 [RFC5622], all say basically the same thing 👯‍♀️:

each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable with either the ECT(0) or the ECT(1) codepoint set.

This memo updates those sentences in each of the three RFCs like so 🍓:

each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable. Unless otherwise specified by an Experimental RFC in the IETF document stream, such DCCP senders MUST set the ECT(0) codepoint.

For the Congestion Marking Differences experiment (see Section 3 🧁), this memo also updates all three of those RFCs to remove the discussion of the ECN nonce 🙈. The exact text changes are left out for brevity.

7. IANA Considerations 📋

Since RFC 3540 has been reclassified as Historic 🕰️, IANA has updated the "Transmission Control Protocol (TCP) Header Flags" registry <https://www.iana.org/assignments/tcp-header-flags> 🗂️. Bit 7 is no longer registered as the NS (Nonce Sum) bit, and the registry now has an annotation saying bit 7 was used by Historic RFC 3540 as the NS (Nonce Sum) bit but is now Reserved 💜.

8. Security Considerations 🔐

Okay, so this is a process memo that only loosens restrictions on experimentation 🧪, which means there are no protocol security considerations of its own 🙌. The security considerations for any experiment that uses the relaxed restrictions live in the documents that propose those experiments 📄.

BUT 😭, effective congestion control is crucial to the Internet staying up 🌐, so this memo puts the responsibility for not breaking Internet congestion control on the experiments and on the experimenters who propose them 💀. That responsibility includes writing up the congestion control implications in an Experimental RFC in the IETF document stream for each experiment, as Section 2.1 requires ✍️. The IETF community and the IESG review that discussion before RFC publication, and that review is meant to give us assurance that each experiment does not break Internet congestion control 🛡️.

See Appendix C.1 of [ECN-L4S] for a discussion of alternatives to the ECN nonce 🔍.

9. References 📚

9.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, <https://www.rfc-editor.org/info/rfc2914>.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.

[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, DOI 10.17487/RFC3540, June 2003, <https://www.rfc-editor.org/info/rfc3540>.

[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 2006, <https://www.rfc-editor.org/info/rfc4341>.

[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, DOI 10.17487/RFC4342, March 2006, <https://www.rfc-editor.org/info/rfc4342>.

[RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)", RFC 5622, DOI 10.17487/RFC5622, August 2009, <https://www.rfc-editor.org/info/rfc5622>.

[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, <https://www.rfc-editor.org/info/rfc6679>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2. Informative References

[ECN-ENCAP] Briscoe, B., Kaippallimalil, J., and P. Thaler, "Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP", Work in Progress, draft-ietf-tsvwg-ecn-encap-guidelines-09, July 2017.

[ECN-EXPERIMENT] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, "Updating the Explicit Congestion Notification (ECN) Specification to Allow IETF Experimentation", Work in Progress, draft-khademi-tsvwg-ecn-response-01, July 2016.

[ECN-L4S] Schepper, K. and B. Briscoe, "Identifying Modified Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queuing Delay", Work in Progress, draft-ietf-tsvwg-ecn-l4s-id-01, October 2017.

[ECN-SHIM] Briscoe, B., "Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim", Work in Progress, draft-ietf-tsvwg-rfc6040update-shim-05, November 2017.

[ECN-TCP] Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets", Work in Progress, draft-ietf-tcpm-generalized-ecn-02, October 2017.

[ECN-TRILL] Eastlake, D. and B. Briscoe, "TRILL: ECN (Explicit Congestion Notification) Support", Work in Progress, draft-ietf-trill-ecn-support-04, November 2017.

[RFC4774] Floyd, S., "Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field", BCP 124, RFC 4774, DOI 10.17487/RFC4774, November 2006, <https://www.rfc-editor.org/info/rfc4774>.

[RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, July 2007, <https://www.rfc-editor.org/info/rfc4844>.

[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, DOI 10.17487/RFC5706, November 2009, <https://www.rfc-editor.org/info/rfc5706>.

[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, <https://www.rfc-editor.org/info/rfc6040>.

[RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)", RFC 6660, DOI 10.17487/RFC6660, July 2012, <https://www.rfc-editor.org/info/rfc6660>.

[RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., and G. Judd, "Data Center TCP (DCTCP): TCP Congestion Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257, October 2017, <https://www.rfc-editor.org/info/rfc8257>.

[TCP-ABE] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, "TCP Alternative Backoff with ECN (ABE)", Work in Progress, draft-ietf-tcpm-alternativebackoff-ecn-05, December 2017.

[Trammell15] Trammell, B., Kuehlewind, M., Boppart, D., Learmonth, I., Fairhurst, G., and R. Scheffenegger, "Enabling Internet- Wide Deployment of Explicit Congestion Notification", In Conference Proceedings of Passive and Active Measurement (PAM), pp. 193-205, March 2015, <https://doi.org/10.1007/978-3-319-15509-8_15>.

Acknowledgements ✨

okay bestie, the thank-you section is my fave 🥹🫶 The spec's whole body leans hard on [ECN-EXPERIMENT], so the authors of that one get the biggest shoutout. The people who ran those experiments kicked this whole memo off just by being curious and innovating, and that energy is so valid 💅✨

Colin Perkins also gets credit for suggesting that RFC 6679 on RTP should be updated, and for helping figure out where those updates should go 🎀

The spec got way better because a bunch of reviewers read it and gave feedback 🌸 Shoutout to Ben Campbell, Brian Carpenter, Benoit Claise, Spencer Dawkins, Gorry Fairhurst, Sue Hares, Ingemar Johansson, Naeem Khademi, Mirja Kuehlewind, Karen Nielsen, Hilarie Orman, Eric Rescorla, Adam Roach, and Michael Welzl 👑💖 Bob Briscoe reviewed multiple draft versions in a super thorough way, and that's how we ended up with lots of improvements, including the updates to the DCCP RFCs 🦋🔥

Author's Address 🧚

The author of this one is David Black, and here's where you can find them 💌

David Black
Dell EMC
176 South Street
Hopkinton, MA  01748
United States of America

Email: david.black@dell.com
📦 where this page comes from