Internet Engineering Task Force (IETF)                      G. Fairhurst
Request for Comments: 8087                        University of Aberdeen
Category: Informational                                         M. Welzl
ISSN: 2070-1721                                       University of Oslo
                                                              March 2017
Internet Engineering Task Force (IETF)                      G. Fairhurst
Request for Comments: 8087                        University of Aberdeen
Category: Informational                                         M. Welzl
ISSN: 2070-1721                                       University of Oslo
                                                              March 2017

The Benefits of Using Explicit Congestion Notification (ECN)




The goal of this document is to describe the potential benefits of applications using a transport that enables Explicit Congestion Notification (ECN). The document outlines the principal gains in terms of increased throughput, reduced delay, and other benefits when ECN is used over a network path that includes equipment that supports Congestion Experienced (CE) marking. It also discusses challenges for successful deployment of ECN. It does not propose new algorithms to use ECN nor does it describe the details of implementation of ECN in endpoint devices (Internet hosts), routers, or other network devices.


Status of This Memo


This document is not an Internet Standards Track specification; it is published for informational purposes.


This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准;见RFC 7841第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at


Copyright Notice


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

版权所有(c)2017 IETF信托基金和确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

Table of Contents


   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Benefit of Using ECN to Avoid Congestion Loss . . . . . . . .   5
     2.1.  Improved Throughput . . . . . . . . . . . . . . . . . . .   5
     2.2.  Reduced Head-of-Line Blocking . . . . . . . . . . . . . .   6
     2.3.  Reduced Probability of RTO Expiry . . . . . . . . . . . .   6
     2.4.  Applications That Do Not Retransmit Lost Packets  . . . .   7
     2.5.  Making Incipient Congestion Visible . . . . . . . . . . .   8
     2.6.  Opportunities for New Transport Mechanisms  . . . . . . .   8
   3.  Network Support for ECN . . . . . . . . . . . . . . . . . . .   9
     3.1.  The ECN Field . . . . . . . . . . . . . . . . . . . . . .  10
     3.2.  Forwarding ECN-Capable IP Packets . . . . . . . . . . . .  10
     3.3.  Enabling ECN in Network Devices . . . . . . . . . . . . .  11
     3.4.  Coexistence of ECN and Non-ECN Flows  . . . . . . . . . .  11
     3.5.  Bleaching and Middlebox Requirements to Deploy ECN  . . .  11
     3.6.  Tunneling ECN and the Use of ECN by Lower-Layer Networks   12
   4.  Using ECN across the Internet . . . . . . . . . . . . . . . .  12
     4.1.  Partial Deployment  . . . . . . . . . . . . . . . . . . .  13
     4.2.  Detecting Whether a Path Really Supports ECN  . . . . . .  13
     4.3.  Detecting ECN-Receiver Feedback Cheating  . . . . . . . .  14
   5.  Summary: Enabling ECN in Network Devices and Hosts  . . . . .  14
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Benefit of Using ECN to Avoid Congestion Loss . . . . . . . .   5
     2.1.  Improved Throughput . . . . . . . . . . . . . . . . . . .   5
     2.2.  Reduced Head-of-Line Blocking . . . . . . . . . . . . . .   6
     2.3.  Reduced Probability of RTO Expiry . . . . . . . . . . . .   6
     2.4.  Applications That Do Not Retransmit Lost Packets  . . . .   7
     2.5.  Making Incipient Congestion Visible . . . . . . . . . . .   8
     2.6.  Opportunities for New Transport Mechanisms  . . . . . . .   8
   3.  Network Support for ECN . . . . . . . . . . . . . . . . . . .   9
     3.1.  The ECN Field . . . . . . . . . . . . . . . . . . . . . .  10
     3.2.  Forwarding ECN-Capable IP Packets . . . . . . . . . . . .  10
     3.3.  Enabling ECN in Network Devices . . . . . . . . . . . . .  11
     3.4.  Coexistence of ECN and Non-ECN Flows  . . . . . . . . . .  11
     3.5.  Bleaching and Middlebox Requirements to Deploy ECN  . . .  11
     3.6.  Tunneling ECN and the Use of ECN by Lower-Layer Networks   12
   4.  Using ECN across the Internet . . . . . . . . . . . . . . . .  12
     4.1.  Partial Deployment  . . . . . . . . . . . . . . . . . . .  13
     4.2.  Detecting Whether a Path Really Supports ECN  . . . . . .  13
     4.3.  Detecting ECN-Receiver Feedback Cheating  . . . . . . . .  14
   5.  Summary: Enabling ECN in Network Devices and Hosts  . . . . .  14
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19
1. Introduction
1. 介绍

Internet transports (such as TCP and Stream Control Transmission Protocol (SCTP)) are implemented in endpoints (Internet hosts) and are designed to detect and react to network congestion. Congestion may be detected by loss of an IP packet or, if Explicit Congestion Notification (ECN) [RFC3168] is enabled, by the reception of a packet with a Congestion Experienced (CE) marking in the IP header. Both of these are treated by transports as indications of congestion. ECN may also be enabled by other transports: UDP applications that provide congestion control may enable ECN when they are able to correctly process the ECN signals [RFC8085] (e.g., ECN with RTP [RFC6679]).


Active Queue Management (AQM) [RFC7567] is a class of techniques that can be used by network devices (a router, middlebox, or other device that forwards packets through the network) to manage the size of queues in network buffers.


A network device that does not support AQM typically uses a drop-tail policy to drop excess IP packets when its queue becomes full. The discard of packets is treated by transport protocols as a signal that indicates congestion on the end-to-end network path. End-to-end transports, such as TCP, can cause a low level of loss while seeking to share capacity with other flows. Although losses are not always due to congestion (loss may be due to link corruption, receiver overrun, etc.), endpoints have to conservatively presume that all loss is potentially due to congestion and reduce their rate. Observed loss therefore results in a congestion control reaction by the transport to reduce the maximum rate permitted by the sending endpoint.


ECN makes it possible for the network to signal the presence of incipient congestion without incurring packet loss; it lets the network deliver some packets to an application that would otherwise have been dropped if the application or transport did not support ECN. This packet-loss reduction is the most obvious benefit of ECN, but it is often relatively modest. However, enabling ECN can also result in a number of beneficial side effects, some of which may be much more significant than the immediate packet-loss reduction from receiving a CE marking instead of dropping packets. Several benefits reduce latency (e.g., reduced head-of-line blocking).


The use of ECN is indicated in the ECN field [RFC3168], which is carried in the packet header of all IPv4 and IPv6 packets. This field may be set to one of the four values shown in Figure 1. The Not-ECT codepoint '00' indicates a packet that is not using ECN. The ECT(0) codepoint '01' and the ECT(1) codepoint '10' both indicate

ECN的使用在ECN字段[RFC3168]中指示,该字段包含在所有IPv4和IPv6数据包的数据包头中。该字段可以设置为图1所示的四个值之一。Not ECT代码点“00”表示未使用ECN的数据包。ECT(0)代码点“01”和ECT(1)代码点“10”都指示

that the transport protocol using the IP layer supports the use of ECN. The CE codepoint '11' is set by an ECN-capable network device to indicate congestion to the transport endpoint.


   | ECN FIELD |  Name   |
   |  0  |  0  | Not-ECT |
   |  0  |  1  | ECT(1)  |
   |  1  |  0  | ECT(0)  |
   |  1  |  1  | CE      |
   | ECN FIELD |  Name   |
   |  0  |  0  | Not-ECT |
   |  0  |  1  | ECT(1)  |
   |  1  |  0  | ECT(0)  |
   |  1  |  1  | CE      |

Figure 1: The ECN Field in the IP Packet Header (based on [RFC3168])


When an application uses a transport that enables use of ECN [RFC3168], the transport layer sets the ECT(0) or ECT(1) codepoint in the IP header of packets that it sends. This indicates to network devices that they may mark, rather than drop, the ECN-capable IP packets. An ECN-capable network device can then signal incipient congestion (network queuing) at a point before a transport experiences congestion loss or high queuing delay. The marking is generally performed as the result of various AQM algorithms [RFC7567] where the exact combination of AQM/ECN algorithms does not need to be known by the transport endpoints.


The focus of the document is on usage of ECN by transport- and application-layer flows, not its implementation in endpoint hosts, routers, and other network devices.


1.1. Terminology
1.1. 术语

The following terms are used:


AQM: Active Queue Management.


CE: Congestion Experienced; a codepoint value '11' marked in the ECN field of the IP packet header.


ECN-capable IP Packet: A packet where the ECN field is set to a non-zero ECN value (i.e., with ECT(0), ECT(1), or the CE codepoint).


ECN-capable network device: An ECN-capable network device may forward, drop, or queue an ECN-capable packet and may choose to CE mark this packet when there is incipient congestion.


ECN-capable transport/application: A transport that sends ECN-capable IP Packets, monitors reception of the ECN field, and generates appropriate feedback to control the rate of the sending endpoint to provide end-to-end congestion control.


ECN field: A 2-bit field specified for use with explicit congestion signaling in the IPv4 and IPv6 packet headers.


Endpoint: An Internet host that terminates a transport protocol connection across an Internet path.


Incipient Congestion: The detection of congestion when it is starting, perhaps by a network device noting that the arrival rate exceeds the forwarding rate.


Network device: A router, middlebox, or other device that forwards IP packets through the network.


non-ECN-capable: A network device or endpoint that does not interpret the ECN field. Such a device is not permitted to change the ECN codepoint.


not-ECN-capable IP Packet: An IP packet with the ECN field set to a value of zero ('00'). A not-ECN-capable packet may be forwarded, dropped, or queued by a network device.


2. Benefit of Using ECN to Avoid Congestion Loss
2. 使用ECN避免拥塞损失的好处

An ECN-capable network device is expected to CE mark an ECN-capable IP packet as a CE when an AQM method detects incipient congestion rather than drop the packet [RFC7567]. An application can benefit from this marking in several ways, which are detailed in the rest of this section.


2.1. Improved Throughput
2.1. 提高吞吐量

ECN seeks to avoid the inefficiency of dropping data that has already made it across at least part of the network path.


ECN can improve the throughput of an application, although this increase in throughput is often not the most significant gain. When an application uses a lightly to moderately loaded network path, the number of packets that are dropped due to congestion is small. Using an example from Table 1 of [RFC3649], for a standard TCP sender with an RTT of 0.1 seconds, a packet size of 1500 bytes, and an average throughput of 1 Mbps, the average packet-drop ratio would be 0.02 (i.e., 1 in 50 packets). This translates into an approximate 2%


throughput gain if ECN is enabled. (Note that in heavy congestion, packet loss may be unavoidable with or without ECN.)


2.2. Reduced Head-of-Line Blocking
2.2. 减少线路阻塞的水头

Many Internet transports provide in-order delivery of received data segments to the applications they support. For these applications, use of ECN can reduce the delay that can result when these applications experience packet loss.


Packet loss may occur for various reasons. One cause arises when an AQM scheme drops a packet as a signal of incipient congestion. Whatever the cause of loss, a missing packet needs to trigger a congestion control response. A reliable transport also triggers retransmission to recover the lost data. For a transport providing in-order delivery, this requires that the transport receiver stall (or wait) for all data that was sent ahead of a lost segment to be correctly received before it can forward any later data to the application. A loss therefore creates a delay of at least one RTT after a loss event before data can be delivered to an application. We call this head-of-line blocking. This is the usual requirement for TCP and SCTP. Partially Reliable SCTP (PR-SCTP) [RFC3758], UDP [RFC768] [RFC8085], and the Datagram Congestion Control Protocol (DCCP) [RFC4340] provide a transport that does not provide reordering.


By enabling ECN, a transport continues to receive in-order data when there is incipient congestion and can pass this data to the receiving application. Use of ECN avoids the additional reordering delay in a reliable transport. The sender still needs to make an appropriate congestion response to reduce the maximum transmission rate for future traffic, which usually will require a reduction in the sending rate [RFC8085].


2.3. Reduced Probability of RTO Expiry
2.3. RTO失效概率降低

Some patterns of packet loss can result in a Retransmission Timeout (RTO), which causes a sudden and significant change in the allowed rate at which a transport/application can forward packets. Because ECN provides an alternative to drop for network devices to signal incipient congestion, this can reduce the probability of loss and hence reduce the likelihood of RTO expiry.


Internet transports/applications generally use an RTO timer as a last resort to detect and recover loss [RFC8085] [RFC5681]. Specifically, an RTO timer detects loss of a packet that is not followed by other packets, such as at the end of a burst of data segments or when an application becomes idle (either because the application has no


further data to send or the network prevents sending further data, e.g., flow or congestion control at the transport layer). This loss of the last segment (or last few segments) of a traffic burst is also known as a "tail loss". Standard transport recovery methods, such as Fast Recovery [RFC5681], are often unable to recover from a tail loss. This is because the endpoint receiver is unaware that the lost segments were actually sent and therefore generates no feedback [Fla13]. Retransmission of these segments relies on expiry of a transport retransmission timer. This timer is also used to detect a lack of forwarding along a path. Expiry of the RTO results in the consequent loss of state about the network path being used. This typically includes resetting path estimates such as the RTT, reinitializing the congestion window, and possibly making updates to other transport state. This can reduce the performance of the transport until it again adapts to the path.


An ECN-capable network device cannot eliminate the possibility of tail loss because a drop may occur due to a traffic burst exceeding the instantaneous available capacity of a network buffer or as a result of the AQM algorithm (e.g., overload protection mechanisms [RFC7567]). However, an ECN-capable network device that observes incipient congestion may be expected to buffer the IP packets of an ECN-capable flow and set a CE mark in one or more packet(s) rather than triggering packet drop. Setting a CE mark signals incipient congestion without forcing the transport/application to enter retransmission timeout. This reduces application-level latency and can improve the throughput for applications that send intermittent bursts of data.


The benefit of avoiding retransmission loss is expected to be significant when ECN is used on TCP SYN/ACK packets [RFC5562] where the RTO interval may be large because TCP cannot base the timeout period on prior RTT measurements from the same connection.

当ECN用于TCP SYN/ACK数据包[RFC5562]时,避免重传丢失的好处是显著的,其中RTO间隔可能很大,因为TCP不能基于来自同一连接的先前RTT测量值来确定超时时间。

2.4. Applications That Do Not Retransmit Lost Packets
2.4. 不重新传输丢失数据包的应用程序

A transport that enables ECN can receive timely congestion signals without the need to retransmit packets each time it receives a congestion signal.


Some latency-critical applications do not retransmit lost packets, yet they may be able to adjust their sending rate following detection of incipient congestion. Examples of such applications include UDP-based services that carry Voice over IP (VoIP), interactive video, or real-time data. The performance of many such applications degrades rapidly with increasing packet loss, and the transport/application may therefore employ mechanisms (e.g., packet forward error correction, data duplication, or media codec error concealment) to


mitigate the immediate effect of congestion loss on the application. Some mechanisms consume additional network capacity, some require additional processing, and some contribute additional path latency when congestion is experienced. By decoupling congestion control from loss, ECN can allow transports that support these applications to reduce their rate before the application experiences loss from congestion. This can reduce the negative impact of triggering loss-hiding mechanisms with a direct positive impact on the quality experienced by the users of these applications.


2.5. Making Incipient Congestion Visible
2.5. 使初期拥堵可见

A characteristic of using ECN is that it exposes the presence of congestion on a network path to the transport and network layers, thus allowing information to be collected about the presence of incipient congestion.


Recording the presence of CE-marked packets can provide information about the current congestion level experienced on a network path. A network flow that only experiences CE marking and no loss implies that the sending endpoint is experiencing only congestion. A network flow may also experience loss (e.g., due to queue overflow, AQM methods that protect other flows, link corruption, or loss in middleboxes). When a mixture of CE marking and packet loss is experienced, transports and measurements need to assume there is congestion [RFC7567]. Therefore, an absence of CE marks does not indicate a path has not experienced congestion.


The reception of CE-marked packets can be used to monitor the level of congestion by a transport/application or a network operator. For example, ECN measurements are used by Congestion Exposure (ConEx) [RFC6789]. In contrast, metering packet loss is harder.


2.6. Opportunities for New Transport Mechanisms
2.6. 新运输机制的机会

ECN can enable design and deployment of new algorithms in network devices and Internet transports. Internet transports need to regard both loss and CE marking as an indication of congestion. However, while the amount of feedback provided by drop ought naturally be minimized, this is not the case for ECN. In contrast, an ECN-capable network device could provide richer (more frequent and fine-grained) indication of its congestion state to the transport.


For any ECN-capable transport (ECT), the receiving endpoint needs to provide feedback to the transport sender to indicate that CE marks have been received. [RFC3168] provides one method that signals once each round-trip time (RTT) that CE-marked packets have been received.


A receiving endpoint may provide more detailed feedback to the congestion controller at the sender (e.g., describing the set of received ECN codepoints or indicating each received CE-marked packet). Precise feedback about the number of CE marks encountered is supported by RTP when used over UDP [RFC6679] and has been proposed for SCTP [ST14] and TCP [ECN-FEEDBACK].


More detailed feedback is expected to enable evolution of transport protocols allowing the congestion control mechanism to make a more appropriate decision on how to react to congestion. Designers of transport protocols need to consider not only how network devices CE-mark packets but also how the control loop in the application/ transport reacts to reception of these CE-marked packets.


Benefit has been noted when packets are CE marked early using an instantaneous queue, and if the receiving endpoint provides feedback about the number of packet marks encountered, an improved sender behavior has been shown to be possible, e.g, Data Center TCP (DCTCP) [AL10]. DCTCP is targeted at controlled environments such as a data center. This is a work in progress, and it is currently unknown whether or how such behavior could be safely introduced into the Internet. Any update to an Internet transport protocol requires careful consideration of the robustness of the behavior when working with endpoints or network devices that were not designed for the new congestion reaction.


3. Network Support for ECN
3. ECN的网络支持

For an application to use ECN requires that the endpoints enable ECN within the transport being used. It also requires that all network devices along the path at least forward IP packets that set a non-zero ECN codepoint.


ECN can be deployed both in the general Internet and in controlled environments:


o ECN can be incrementally deployed in the general Internet. The IETF has provided guidance on configuration and usage in [RFC7567].

o ECN可以增量地部署在通用Internet中。IETF在[RFC7567]中提供了配置和使用指南。

o ECN may be deployed within a controlled environment, for example, within a data center or within a well-managed private network. This use of ECN may be tuned to the specific use case. An example is DCTCP [AL10] [DCTCP].

o ECN可以部署在受控环境中,例如,数据中心或管理良好的专用网络中。ECN的这种使用可以根据特定的用例进行调整。例如,DCTCP[AL10][DCTCP]。

Early experience of using ECN across the general Internet encountered a number of operational difficulties when the network path either failed to transfer ECN-capable packets or inappropriately changed the ECN codepoints [BA11]. A recent survey reported a growing support for network paths to pass ECN codepoints [TR15].


The remainder of this section identifies what is needed for network devices to effectively support ECN.


3.1. The ECN Field
3.1. ECN字段

The current IPv4 and IPv6 specifications assign usage of 2 bits in the IP header to carry the ECN codepoint. This 2-bit field was reserved in [RFC2474] and assigned in [RFC3168].


[RFC4774] discusses some of the issues in defining alternate semantics for the ECN field and specifies requirements for a safe coexistence in an Internet that could include routers that do not understand the defined alternate semantics.


Some network devices were configured to use a routing hash that included the set of 8 bits forming the now deprecated Type of Service (TOS) field [RFC1349]. The present use of this field assigns 2 of these bits to carry the ECN field. This is incompatible with use in a routing hash because it could lead to IP packets that carry a CE mark being routed over a different path to those packets that carried an ECT mark. The resultant reordering would impact the performance of transport protocols (such as TCP or SCTP) and UDP-based applications that are sensitive to reordering. A network device that conforms to this older specification needs to be updated to the current specifications [RFC2474] to support ECN. Configuration of network devices must note that the ECN field may be updated by any ECN-capable network device along a path.


3.2. Forwarding ECN-Capable IP Packets
3.2. 转发支持ECN的IP数据包

Not all network devices along a path need to be ECN-capable (i.e., perform CE marking). However, all network devices need to be configured not to drop packets solely because the ECT(0) or ECT(1) codepoints are used.


Any network device that does not perform CE marking of an ECN-capable packet can be expected to drop these packets under congestion. Applications that experience congestion at these network devices do not see any benefit from enabling ECN. However, they may see benefit if the congestion were to occur within a network device that did support ECN.


3.3. Enabling ECN in Network Devices
3.3. 在网络设备中启用ECN

Network devices should use an AQM algorithm that CE-marks ECN-capable traffic when making decisions about the response to congestion [RFC7567]. An ECN method should set a CE mark on ECN-capable packets in the presence of incipient congestion. A CE-marked packet will be interpreted as an indication of incipient congestion by the transport endpoints.


There is an opportunity to design an AQM method for an ECN-capable network device that differs from an AQM method designed to drop packets. [RFC7567] states that the network device should allow this behavior to be configurable.


[RFC3168] describes a method in which a network device sets the CE mark at the time that the network device would otherwise have dropped the packet. While it has often been assumed that network devices should CE-mark packets at the same level of congestion at which they would otherwise have dropped them, [RFC7567] recommends that network devices allow independent configuration of the settings for AQM dropping and ECN marking. Such separate configuration of the drop and mark policies is supported in some network devices.


3.4. Coexistence of ECN and Non-ECN Flows
3.4. ECN和非ECN流共存

Network devices need to be able to forward all IP flows and provide appropriate treatment for both ECN and non-ECN traffic.


The design considerations for an AQM scheme supporting ECN needs to consider the impact of queueing during incipient congestion. For example, a simple AQM scheme could choose to queue ECN-capable and non-ECN-capable flows in the same queue with an ECN scheme that CE-marks packets during incipient congestion. The CE-marked packets that remain in the queue during congestion can continue to contribute to queueing delay. In contrast, non-ECN-capable packets would normally be dropped by an AQM scheme under incipient congestion. This difference in queueing is one motivation for consideration of more advanced AQM schemes and may provide an incentive for enabling flow isolation using scheduling [RFC7567]. The IETF is defining methods to evaluate the suitability of AQM schemes for deployment in the general Internet [RFC7928].


3.5. Bleaching and Middlebox Requirements to Deploy ECN
3.5. 部署ECN的漂白和中间盒要求

Network devices should not be configured to change the ECN codepoint in the packets that they forward, except to set the CE codepoint to signal incipient congestion.


Cases have been noted where an endpoint sends a packet with a non-zero ECN mark, but the packet is received by the remote endpoint with a zero ECN codepoint [TR15]. This could be a result of a policy that erases or "bleaches" the ECN codepoint values at a network edge (resetting the codepoint to zero). Bleaching may occur for various reasons (including normalizing packets to hide which equipment supports ECN). This policy prevents use of ECN by applications.


When ECN-capable IP packets, marked as ECT(0) or ECT(1), are re-marked to non-ECN-capable (i.e., the ECN field is set to the zero codepoint), this could result in the packets being dropped by ECN-capable network devices further along the path. This eliminates the advantage of using of ECN.


A network device must not change a packet with a CE mark to a zero codepoint; if the network device decides not to forward the packet with the CE mark, it has to instead drop the packet and not bleach the marking. This is because a CE-marked packet has already received ECN treatment in the network, and re-marking it would then hide the congestion signal from the receiving endpoint. This eliminates the benefits of ECN. It can also slow down the response to congestion compared to using AQM because the transport will only react if it later discovers congestion by some other mechanism.


Prior to [RFC2474], a previous usage assigned the bits now forming the ECN field as a part of the now deprecated TOS field [RFC1349]. A network device that conforms to this older specification was allowed to re-mark or erase the ECN codepoints, and such equipment needs to be updated to the current specifications in order to support ECN.


3.6. Tunneling ECN and the Use of ECN by Lower-Layer Networks
3.6. 隧道ECN和低层网络对ECN的使用

Some networks may use ECN internally or tunnel ECN (e.g., for traffic engineering or security). These methods need to ensure that the ECN field of the tunnel packets is handled correctly at the ingress and egress of the tunnel. Guidance on the correct use of ECN is provided in [RFC6040].


Further guidance on the encapsulation and use of ECN by non-IP network devices is provided in [ECN-ENCAP].


4. Using ECN across the Internet
4. 在Internet上使用ECN

A receiving endpoint needs to report the loss it experiences when it uses loss-based congestion control. So also, when ECN is enabled, a receiving endpoint must correctly report the presence of CE marks by providing a mechanism to feed this congestion information back to the sending endpoint [RFC3168] [RFC8085], thus enabling the sender to


react to experienced congestion. This mechanism needs to be designed to operate robustly across a wide range of Internet path characteristics. This section describes partial deployment, that is, how ECN-enabled endpoints can continue to work effectively over a path that experiences misbehaving network devices or when an endpoint does not correctly provide feedback of ECN information.


4.1. Partial Deployment
4.1. 部分部署

Use of ECN is negotiated between the endpoints prior to using the mechanism.


ECN has been designed to allow incremental partial deployment [RFC3168]. Any network device can choose to use either ECN or some other loss-based policy to manage its traffic. Similarly, transport/ application negotiation allows sending and receiving endpoints to choose whether ECN will be used to manage congestion for a particular network flow.


4.2. Detecting Whether a Path Really Supports ECN
4.2. 检测路径是否真正支持ECN

Internet transports and applications need to be robust to the variety and sometimes varying path characteristics that are encountered in the general Internet. They need to monitor correct forwarding of ECN over the entire path and duration of a session.


To be robust, applications and transports need to be designed with the expectation of heterogeneous forwarding (e.g., where some IP packets are CE marked by one network device and some by another, possibly using a different AQM algorithm, or when a combination of CE marking and loss-based congestion indications are used). Note that [RFC7928] describes methodologies for evaluating AQM schemes.


A transport/application also needs to be robust to path changes. A change in the set of network devices along a path could impact the ability to effectively signal or use ECN across the path, e.g., when a path changes to use a middlebox that bleaches ECN codepoints (see Section 3.5).


A sending endpoint can check that any CE marks applied to packets received over the path are indeed delivered to the remote receiving endpoint and that appropriate feedback is provided. (This could be done by a sender setting a known CE codepoint for specific packets in a network flow and then checking whether the remote endpoint correctly reports these marks [ECN-FALLBACK] [TR15].) If a sender detects persistent misuse of ECN, it needs to fall back to using loss-based recovery and congestion control. Guidance on a suitable transport reaction is provided in [ECN-FALLBACK].


4.3. Detecting ECN-Receiver Feedback Cheating
4.3. 检测ECN接收机反馈欺骗

Appropriate feedback requires that the endpoint receiver not try to conceal reception of CE-marked packets in the ECN feedback information provided to the sending endpoint [RFC7567]. Designers of applications/transports are therefore encouraged to include mechanisms that can detect this misbehavior. If a sending endpoint detects that a receiver is not correctly providing this feedback, it needs to fall back to using loss-based recovery instead of ECN.


5. Summary: Enabling ECN in Network Devices and Hosts
5. 摘要:在网络设备和主机中启用ECN

This section summarizes the benefits of deploying and using ECN within the Internet. It also provides a list of prerequisites to achieve ECN deployment.


Application developers should, where possible, use transports that enable ECN. Applications that directly use UDP need to provide support to implement the functions required for ECN [RFC8085]. Once enabled, an application that uses a transport that supports ECN will experience the benefits of ECN as network deployment starts to enable ECN. The application does not need to be rewritten to gain these benefits. Figure 2 summarizes the key benefits.


   | Section | Benefit                                             |
   |   2.1   | Improved Throughput                                 |
   |   2.2   | Reduced Head-of-Line Blocking                       |
   |   2.3   | Reduced Probability of RTO Expiry                   |
   |   2.4   | Applications that do not Retransmit Lost Packets    |
   |   2.5   | Making Incipient Congestion Visible                 |
   |   2.6   | Opportunities for New Transport Mechanisms          |
   | Section | Benefit                                             |
   |   2.1   | Improved Throughput                                 |
   |   2.2   | Reduced Head-of-Line Blocking                       |
   |   2.3   | Reduced Probability of RTO Expiry                   |
   |   2.4   | Applications that do not Retransmit Lost Packets    |
   |   2.5   | Making Incipient Congestion Visible                 |
   |   2.6   | Opportunities for New Transport Mechanisms          |

Figure 2: Summary of Key Benefits


Network operators and people configuring network devices should enable ECN [RFC7567].


Prerequisites for network devices (including IP routers) to enable use of ECN include:


o A network device that updates the ECN field in IP packets must use IETF-specified methods (see Section 3.1).

o 更新IP数据包中ECN字段的网络设备必须使用IETF指定的方法(见第3.1节)。

o A network device may support alternate ECN semantics (see Section 3.1).

o 网络设备可支持备用ECN语义(见第3.1节)。

o A network device must not choose a different network path solely because a packet carries a CE-codepoint set in the ECN Field; CE-marked packets need to follow the same path as packets with an ECT(0) or ECT(1) codepoint (see Section 3.1). Network devices need to be configured not to drop packets solely because the ECT(0) or ECT(1) codepoints are used (see Section 3.2).

o 网络设备不得仅因为分组携带ECN字段中设置的CE码点而选择不同的网络路径;CE标记的数据包需要遵循与具有ECT(0)或ECT(1)码点的数据包相同的路径(参见第3.1节)。网络设备需要配置为不丢弃数据包,这仅仅是因为使用了ECT(0)或ECT(1)码点(参见第3.2节)。

o An ECN-capable network device should correctly update the ECN codepoint of ECN-capable packets in the presence of incipient congestion (see Section 3.3).

o 支持ECN的网络设备应在出现初期拥塞时正确更新支持ECN的数据包的ECN码点(见第3.3节)。

o Network devices need to be able to forward both ECN-capable and not-ECN-capable flows (see Section 3.4).

o 网络设备需要能够转发支持ECN和不支持ECN的流(参见第3.4节)。

o A network device must not change a packet with a CE mark to a not-ECN-capable codepoint ('00'); if the network device decides not to forward the packet with the CE mark, it has to instead drop the packet and not bleach the marking (see Section 3.5).

o 网络设备不得将带有CE标记的数据包更改为不支持ECN的代码点(“00”);如果网络设备决定不转发带有CE标记的数据包,则必须丢弃该数据包,并且不漂白该标记(参见第3.5节)。

Prerequisites for network endpoints to enable use of ECN include the following:


o An application should use an Internet transport that can set and receive ECN marks (see Section 4).

o 应用程序应该使用可以设置和接收ECN标记的Internet传输(参见第4节)。

o An ECN-capable transport/application must return feedback indicating congestion to the sending endpoint and perform an appropriate congestion response (see Section 4).

o 支持ECN的传输/应用程序必须向发送端点返回指示拥塞的反馈,并执行适当的拥塞响应(参见第4节)。

o An ECN-capable transport/application should detect paths where there is persistent misuse of ECN and fall back to not sending ECT(0) or ECT(1) (see Section 4.2).

o 支持ECN的传输/应用程序应检测持续误用ECN的路径,并退回到不发送ECT(0)或ECT(1)(参见第4.2节)。

o Designers of applications/transports are encouraged to include mechanisms that can detect and react appropriately to misbehaving receivers that fail to report CE-marked packets (see Section 4.3).

o 鼓励应用程序/传输的设计人员包括能够检测并适当响应未能报告CE标记数据包的行为不端的接收器的机制(见第4.3节)。

6. Security Considerations
6. 安全考虑

This document introduces no new security considerations. Each RFC listed in this document discusses the security considerations of the specification it contains.


7. References
7. 工具书类
7.1. Normative References
7.1. 规范性引用文件

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <>.

[RFC2474]Nichols,K.,Blake,S.,Baker,F.,和D.Black,“IPv4和IPv6报头中区分服务字段(DS字段)的定义”,RFC 2474,DOI 10.17487/RFC2474,1998年12月<>.

[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, <>.

[RFC3168]Ramakrishnan,K.,Floyd,S.,和D.Black,“向IP添加显式拥塞通知(ECN)”,RFC 3168,DOI 10.17487/RFC3168,2001年9月<>.

[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, <>.

[RFC6040]Briscoe,B.,“明确拥塞通知的隧道挖掘”,RFC 6040,DOI 10.17487/RFC6040,2010年11月<>.

[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, <>.

[RFC7567]Baker,F.,Ed.和G.Fairhurst,Ed.,“IETF关于主动队列管理的建议”,BCP 197,RFC 7567,DOI 10.17487/RFC7567,2015年7月<>.

[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <>.

[RFC8085]Eggert,L.,Fairhurst,G.和G.Shepherd,“UDP使用指南”,BCP 145,RFC 8085,DOI 10.17487/RFC8085,2017年3月<>.

7.2. Informative References
7.2. 资料性引用

[AL10] Alizadeh, M., Greenberg, A., Maltz, D., Padhye, J., Patel, P., Prabhakar, B., Sengupta, S., and M. Sridharan, "Data Center TCP (DCTCP)", ACM SIGCOMM Computer Communication Review, Volume 40, Issue 4, pages 63-74, DOI 10.1145/1851182.1851192, October 2010.

[AL10]Alizadeh,M.,Greenberg,A.,Maltz,D.,Padhye,J.,Patel,P.,Prabhakar,B.,Sengupta,S.,和M.Sridharan,“数据中心TCP(DCTCP)”,ACM SIGCOMM计算机通信评论,第40卷,第4期,第63-74页,DOI 10.1145/1851182.1851192,2010年10月。

[BA11] Bauer, Steven., Beverly, Robert., and Arthur. Berger, "Measuring the State of ECN Readiness in Servers, Clients, and Routers", Proceedings of the 2011 ACM SIGCOMM Conference on ICM, pages 171-180, DOI 10.1145/2068816.2068833, November 2011.

[BA11]鲍尔、史蒂文、贝弗利、罗伯特和亚瑟。Berger,“测量服务器、客户端和路由器的ECN就绪状态”,2011年ACM SIGCOMM ICM会议记录,第171-180页,DOI 10.1145/2068816.2068833,2011年11月。

[DCTCP] Bensley, S., Eggert, L., Thaler, D., Balasubramanian, P., and G. Judd, "Microsoft's Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters", Work in Progress, draft-bensley-tcpm-dctcp-05, July 2015.


[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-07, July 2016.


[ECN-FALLBACK] Kuehlewind, M. and B. Trammell, "A Mechanism for ECN Path Probing and Fallback", Work in Progress, draft-kuehlewind-tcpm-ecn-fallback-01, September 2013.


[ECN-FEEDBACK] Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More Accurate ECN Feedback in TCP", Work in Progress, draft-ietf-tcpm-accurate-ecn-02, October 2016.


[Fla13] Flach, Tobias., Dukkipati, Nandita., Terzis, Andreas., Raghavan, Barath., Cardwell, Neal., Cheng, Yuchung., Jain, Ankur., Hao, Shuai., Katz-Bassett, Ethan., and Ramesh. Govindan, "Reducing web latency: the virtue of gentle aggression", ACM SIGCOMM Computer Communication Review, Volume 43, Issue 4, pages 159-170, DOI 10.1145/2534169.2486014, October 2013.

[Flach、Tobias、Dukkipati、Nandita、Terzis、Andreas、Raghavan、Barath、Cardwell、Neal、Cheng、Yuchong、Jain、Ankur、Hao、Shuai、Katz Bassett、Ethan和Ramesh。Govindan,“减少网络延迟:温和攻击的优点”,《ACM SIGCOMM计算机通信评论》,第43卷,第4期,第159-170页,DOI 10.1145/2534169.2486014,2013年10月。

[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <>.

[RFC768]Postel,J.,“用户数据报协议”,STD 6,RFC 768,DOI 10.17487/RFC0768,1980年8月<>.

[RFC1349] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, DOI 10.17487/RFC1349, July 1992, <>.

[RFC1349]Almquist,P.,“互联网协议套件中的服务类型”,RFC 1349,DOI 10.17487/RFC1349,1992年7月<>.

[RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", RFC 3649, DOI 10.17487/RFC3649, December 2003, <>.

[RFC3649]Floyd,S.,“用于大拥塞窗口的高速TCP”,RFC 3649,DOI 10.17487/RFC3649,2003年12月<>.

[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, DOI 10.17487/RFC3758, May 2004, <>.

[RFC3758]Stewart,R.,Ramalho,M.,Xie,Q.,Tuexen,M.,和P.Conrad,“流控制传输协议(SCTP)部分可靠性扩展”,RFC 3758,DOI 10.17487/RFC3758,2004年5月<>.

[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, <>.

[RFC4340]Kohler,E.,Handley,M.和S.Floyd,“数据报拥塞控制协议(DCCP)”,RFC 4340,DOI 10.17487/RFC4340,2006年3月<>.

[RFC4774] Floyd, S., "Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field", BCP 124, RFC 4774, DOI 10.17487/RFC4774, November 2006, <>.

[RFC4774]Floyd,S.,“为显式拥塞通知(ECN)字段指定替代语义”,BCP 124,RFC 4774,DOI 10.17487/RFC4774,2006年11月<>.

[RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K. Ramakrishnan, "Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets", RFC 5562, DOI 10.17487/RFC5562, June 2009, <>.

[RFC5562]Kuzmanovic,A.,Mondal,A.,Floyd,S.,和K.Ramakrishnan,“向TCP的SYN/ACK数据包添加显式拥塞通知(ECN)功能”,RFC 5562,DOI 10.17487/RFC5562,2009年6月<>.

[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <>.

[RFC5681]Allman,M.,Paxson,V.和E.Blanton,“TCP拥塞控制”,RFC 5681,DOI 10.17487/RFC56812009年9月<>.

[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, <>.

[RFC6679]Westerlund,M.,Johansson,I.,Perkins,C.,O'Hanlon,P.,和K.Carlberg,“UDP上RTP的显式拥塞通知(ECN)”,RFC 6679,DOI 10.17487/RFC66792012年8月<>.

[RFC6789] Briscoe, B., Ed., Woundy, R., Ed., and A. Cooper, Ed., "Congestion Exposure (ConEx) Concepts and Use Cases", RFC 6789, DOI 10.17487/RFC6789, December 2012, <>.

[RFC6789]Briscoe,B.,Ed.,Woundy,R.,Ed.,和A.Cooper,Ed.,“拥塞暴露(ConEx)概念和用例”,RFC 6789,DOI 10.17487/RFC6789,2012年12月<>.

[RFC7928] Kuhn, N., Ed., Natarajan, P., Ed., Khademi, N., Ed., and D. Ros, "Characterization Guidelines for Active Queue Management (AQM)", RFC 7928, DOI 10.17487/RFC7928, July 2016, <>.

[RFC7928]Kuhn,N.,Ed.,Natarajan,P.,Ed.,Khademi,N.,Ed.,和D.Ros,“主动队列管理(AQM)的特征化指南”,RFC 7928,DOI 10.17487/RFC7928,2016年7月<>.

[ST14] Stewart, R., Tuexen, M., and X. Dong, "ECN for Stream Control Transmission Protocol (SCTP)", Work in Progress, draft-stewart-tsvwg-sctpecn-05, January 2014.


[TR15] Tranmmel, Brian., Kuehlewind, Mirja., Boppart, Damiano, Learmonth, Iain., and Gorry. Fairhurst, "Enabling Internet-Wide Deployment of Explicit Congestion Notification", Lecture Notes in Computer Science, Volume 8995, pp 193-205, DOI 10.1007/978-3-319-15509-8_15, March 2015.

[TR15]特兰梅尔、布赖恩、库勒温德、米尔贾、波帕、达米亚诺、利尔蒙、伊恩和戈里。Fairhurst,“实现显式拥塞通知在互联网范围内的部署”,《计算机科学》第8995卷,第193-205页,DOI 10.1007/978-3-319-15509-8_15,2015年3月。



The authors were partly funded by the European Community under its Seventh Framework Programme through the Reducing Internet Transport Latency (RITE) project (ICT-317700). The views expressed are solely those of the authors.


The authors would like to thank the following people for their comments on prior draft versions of this document: Bob Briscoe, David Collier-Brown, Colin Perkins, Richard Scheffenegger, Dave Taht, Wes Eddy, Fred Baker, Mikael Abrahamsson, Mirja Kuehlewind, John Leslie, and other members of the TSVWG and AQM working groups.


Authors' Addresses


Godred Fairhurst University of Aberdeen School of Engineering, Fraser Noble Building Aberdeen AB24 3UE United Kingdom

GoRead FelHurt阿伯丁大学工程学院,弗雷泽贵族大厦阿伯丁Ab24 3UE英国


Michael Welzl University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway


   Phone: +47 22 85 24 20
   Phone: +47 22 85 24 20