The Benefits and Pitfalls of using Explicit Congestion Notification (ECN)

Internet Transports (such as TCP and SCTP) have two ways to detect congestion: the loss of a packet and, if Explicit Congestion Notification (ECN) is enabled, by reception of a packet with a Congestion Experienced (CE)-marking in the IP header. Both of these are treated by transports as indications of (potential) congestion. ECN may also be enabled by other transports: UDP applications may enable ECN when they are able to correctly process the ECN signals (e.g. ECN with RTP ). A network device (router, middlebox, or other device that forwards packets through the network) that does not support AQM, typically uses a drop-tail policy to discard excess IP packets when its queue becomes full. The discard of packets serves as a signal to the end-to-end transport that there may be congestion on the network path being used. This triggers a congestion control reaction to reduce the maximum rate permitted by the sending endpoint. When an application uses a transport that enables the use of ECN, 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, packets in periods of congestion. This marking is generally performed by Active Queue Management (AQM) and may be the result of various AQM algorithms, where the exact combination of AQM/ECN algorithms does not need to be known by the transport endpoints. The focus of this document is on usage of ECN by transport and application layer flows, not its implementation in hosts, routers and other network devices. ECN makes it possible for the network to signal the presence of congestion without incurring packet loss. This 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 ECN-marking instead of dropping packets. Several of these benefits have to do with reducing latency in some way (e.g., reduced Head-of-Line Blocking and potentially smaller queuing delay, depending on the marking rules in routers). There are also some potential pitfalls when enabling ECN. The remainder of this document discusses the potential for ECN to positively benefit an application without making specific assumptions about configuration or implementation. describes a method in which a network device sets the CE codepoint of an ECN-Capable packet at the time that the router 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, separate configuration of the drop and mark thresholds is known to be supported in some network devices and this is recommended . Some benefits of ECN that are discussed rely upon network devices marking packets at a lower level of congestion, before they would otherwise drop packets from queue overflow . The ability to use ECN relies upon using a transport that can support ECN. Some benefits are also only realised when the transport endpoint behaviour is also updated, this is discussed further in .

For an application to use ECN requires that the endpoint first enables ECN within the transport. The ability to use ECN requires network devices along the path to at least pass IP packets that set ECN codepoints, and do not drop packets because these codepoints are used . This is the recommended behaviour for network devices . Applications and transports (such as TCP or SCTP) can be designed to fall-back to not using ECN when they discover they are using a path that does not allow use of ECN (e.g., a firewall or other network device configured to drop the ECN codepoint) . For an application at an endpoint to gain benefit from ECN, network devices need to enable ECN marking. However, not all network devices along the path need to enable ECN, for the application to benefit. Any network device that does not mark an ECN-enabled packet with a CE-codepoint can be expected to drop packets under congestion. Applications that experience congestion in these network devices do not see any benefit from using ECN, but would see benefit if the congestion were to occur within a network device that did support ECN. ECN can be deployed in the general Internet and in controlled environments: ECN can be incrementally deployed in the general Internet. The IETF has provided guidance on configuration and usage in . A recent survey reported growing support for ECN on common network paths . ECN may also be deployed within a controlled environment, for example within a data centre or within a well-managed private network. In this case, the use of ECN may be tuned to the specific use-case. An example is Datacenter TCP (DCTCP) . Network deployment needs also to consider the requirements for processing ECN at tunnel endpoints of network tunnels, and guidance on the treatment of ECN is provided in . Further guidance on the encapsulation and use of ECN by non-IP network devices is provided in . Some pitfalls in deploying ECN are noted in .

When packet loss is a result of (mild) congestion, an ECN-enabled router may be expected to CE-mark, rather than drop an ECN-enabled packet . An application can benefit from this marking in several ways:

ECN can improve the throughput performance of applications, although this increase in throughput offered by ECN is often not the most significant gain. When an application uses a light to moderately loaded network path, the number of packets that are dropped due to congestion is small. Using an example from Table 1 of , for a standard TCP sender with a Round Trip Time, RTT, of 0.1 seconds, a packet size of 1500 bytes and an average throughput of 1 Mbps, the average packet drop ratio is 0.02. This translates into an approximate 2% throughput gain if ECN is enabled. In heavy congestion, packet loss may be unavoidable with, or without, ECN.

Many transports provide in-order delivery of received data segments to the applications they support. This requires that the transport stalls (or waits) for all data that was sent ahead of a particular segment to be correctly received before it can forward any later data. This is the usual requirement for TCP and SCTP. PR-SCTP , UDP, and DCCP provide a transport that does not have this requirement. Delaying data to provide in-order transmission to an application results in additional latency when segments are dropped as indications of congestion. The congestive loss creates a delay of at least one RTT for a loss event before data can be delivered to an application. We call this Head-of-Line (HOL) blocking. In contrast, using ECN can remove the resulting delay following a loss that is a result of congestion: First, the application receives the data normally. This also avoids the inefficiency of dropping data that has already made it across at least part of the network path. It also avoids the additional delay of waiting for recovery of the lost segment. Second, the transport receiver notes that it has received CE-marked packets, and then requests the sender to make an appropriate congestion-response to reduce the maximum transmission rate for future traffic.

In some situations, ECN can help reduce the chance of a retransmission timer expiring (e.g., expiry of the TCP or SCTP retransmission timeout, RTO . When an application sends a burst of segments and then 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), the last segment of the burst may be lost. It is often not possible to recover this last segment (or last few segments) using standard methods such as Fast Recovery , since the receiver generates no feedback because it is unaware that the lost segments were actually sent. In addition to avoiding HOL blocking, this allows the transport to avoid the consequent loss of state about the network path it is using, which would have arisen had there been a retransmission timeout. Typical impacts of a transport timeout are to reset path estimates such as the RTT, the congestion window, and possibly other transport state that can reduce the performance of the transport until it again adapts to the path. Avoiding timeouts can hence improve the throughput of the application. This benefits applications that send intermittent bursts of data, and rely upon timer-based recovery of packet loss. It can be especially significant when ECN is used on TCP SYN/ACK packets where the RTO interval may be large because in this case TCP cannot base the timeout period on prior RTT measurements from the same connection.

Some latency-critical applications do not retransmit lost packets, yet they may be able to adjust the sending rate in the presence of 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 many therefore employ loss-hiding mechanisms (e.g., packet forward error correction, or data duplication) to mitigate the effect of congestion loss on the application. However, such mechanisms add complexity and can themselves consume additional network capacity reducing the capacity for application data and contributing to the path latency when congestion is experienced. By decoupling congestion control from loss, ECN can allow the transports supporting these applications to reduce their rate before the application experiences loss from congestion, especially when the congestion is mild and the application/transport can react promptly to reception of a CE-marked packet. Because this reduces the negative impact of using loss-hiding mechanisms, ECN can have a direct positive impact on the quality experienced by the users of these applications.

An application can further benefit from using ECN, when the network devices are configured such that they mark packets at a lower level of congestion before they would otherwise have dropped packets from queue overflow:

Internet transports do not know apriori how much capacity exists along a network path. Transports therefore try to measure the capacity available to an application by probing the network path with increasing traffic to the point where they detect the onset of congestion (such as TCP or SCTP Slow Start). ECN can help capacity probing algorithms (such as Slow Start) from significantly exceeding the bottleneck capacity of a network path. Since a transport that enables ECN can receive congestion signals before there is significant congestion, an early-marking method in network devices can help a transport respond before it induces significant congestion with resultant loss to itself or other applications sharing a common bottleneck. For example, an application/transport can avoid incurring significant congestion during Slow Start, or a bulk application that tries to increase its rate as fast as possible, may quickly detect the presence of congestion, causing it to promptly reduce its rate. Use of ECN is more effective than schemes such as Limited Slow-Start because it provides direct information about the state of the network path. An ECN-enabled application/transport that probes for capacity can reduce its rate as soon as it discovers CE-marked packets are received, and before the applications increases its rate to the point where it builds a queue in a network device that induces congestion loss. This benefits an application seeking to increase its rate - but perhaps more significantly, it eliminates the often unwanted loss and queueing delay that otherwise may be inflicted on flows that share a common bottleneck.

A characteristic of using ECN is that it exposes the presence of congestion on a network path to the transport and network layers. This information can be used for monitoring performance of the path, and could be used to directly meter the amount of congestion that has been encountered upstream on a path; metering packet loss is harder. ECN measurements are used by Congestion Exposure (CoNex) . A network flow that only experiences CE-marks and no loss implies that the sending endpoint is experiencing only congestion and not other sources of packet loss (e.g., link corruption or loss in middleboxes). The converse is not true - a flow may experience a mixture of ECN-marks and loss when there is only congestion or when there is a combination of packet loss and congestion . Recording the presence of CE-marked packets can therefore provide information about the performance of the network path.

ECN requires a definition of both how packets are CE-marked and how applications/transports need to react to reception of CE-marked packets. This section describes the benefits when updated methods are used. Benefit has been noted when packets are CE-marked earlier than they would otherwise be dropped, using an instantaneous queue, and if the receiver provides precise feedback about the number of packet marks encountered, a better sender behavior is possible. This has been shown by Datacenter TCP (DCTCP) . Precise feedback about the number of packet marks encountered is supported by the Real Time Protocol (RTP) when used over UDP and proposed for SCTP and TCP . An underlying assumption of DCTCP is that it is deployed in confined environments such as a datacenter. It is currently unknown whether or how such behaviour could be safely introduced into the Internet.

Early deployment of ECN encountered a number of operationl difficulties when the network deonly partially supports the use of ECN, or to respond to the challenges due to misbehaving network devices and/or endpoints. These problems have been observed to diminish with time, but may still be encountered on some Internet paths . This section describes transport mechanisms that allow ECN-enabled endpoints to continue to work effectively over a path with partial ECN support.

Cases have been noted where a sending endpoint marks a packet with a non-zero ECN mark, but the packet is received with a zero ECN value by the remote endpoint. The current IPv4 and IPv6 specifications assign usage of 2 bits in the IP header to carry the ECN codepoint . A previous usage assigned these bits as a part of the now deprecated Type of Service (ToS) field . Network devices that conform to this older specification may still remark or erase the ECN codepoints, such equipment needs to be updated to the current specifications to support ECN . Some network devices have been observed to implement a policy that erases or "bleaches" the ECN marks at a network edge (resetting these to zero). This may be implemented for various reasons (including normalising packets to hide which equipment supports ECN). This policy prevents use of ECN by applications. A network device should therefore not remark an ECT(0) or ECT(1) mark to zero. A network device must not change a packet with a CE mark to a zero codepoint (if the CE marking is not propagated, the packet must be discarded). Such a packet has already received ECN treatment in the network, and remarking it would then hide the congestion signal from the endpoints. Some networks may use ECN internally or tunnel ECN for traffic engineering or security. Guidance on the correct use of ECN in this case is provided in .

ECN transport and applications need to implement a mechanisms to verify ECN support on the path that they use. This is expected to be a normal feature of IETF-defined transports supporting ECN. Before a transport relies on the presence or absence of CE-marked packets, it may need to verify that any ECN marks applied to packets passed by the path are indeed delivered to the remote endpoint. This may be achieved by the sender setting known ECN codepoints into specific packets in a network flow and then verifying that these reach the remote endpoint. Such methods typically rely on Accurate ECN Feedback , . Endpoints also need to be robust to path changes. A change in the set of network devices along a path may 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. As a necessary, but short term fix, transports could implement mechanisms that detect this and fall-back to disabling use of ECN .

It is important that receiving endpoints accurately report the loss they experience when using a transport that uses loss-based congestion control. So also, when using ECN. a receiver must correctly report the congestion marking that it receives and then provide a mechanism to feed the congestion information back to the sending endpoint. The transport at endpoint receivers must not try to conceal reception of CE-marked packets in the ECN feedback information that they provide to the sending endpoint . Transport protocols are actively encouraged to include mechanisms that can detect and appropriately respond to such misbehavior (e.g., disabling use of ECN, and relying on loss-based congestion detection ).

Network devices should enable ECN and people configuring host stacks should also enable ECN. These are prerequisites to allow applications to gain the benefits of ECN. Prerequisites for network devices (including IP routers) to enable use of ECN include: should not reset the ECN codepoint to zero by default . should correctly update the ECN codepoint in the presence of congestion. should correctly support alternate ECN semantics (). Prerequisites for network endpoints to enable use of ECN include: should use transports that can set and receive ECN marks. should correctly return feedback of congestion to the sending endpoint. must use transports that react appropriately to received ECN feedback . should use transports that can detect misuse of ECN and detect paths that do not support ECN, providing fallback to loss-based congestion detection when ECN is not supported . Application developers should where possible use transports that enable the benefits of ECN. Applications that directly use UDP need to provide support to implement the functions required for ECN. 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. Table 1 summarises some of these benefits.

The authors were part-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 versions of this document: Bob Briscoe, David Collier-Brown, John Leslie, Colin Perkins, Richard Scheffenegger, Dave Taht

XX RFC ED - PLEASE REMOVE THIS SECTION XXX This memo includes no request to IANA.

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

XXX RFC-Ed please remove this section prior to publication. Revision 00 was the first WG draft. Revision 01 includes updates to complete all the sections and a rewrite to improve readability. Added section 2. Author list reversed, since Gorry has become the lead author. Corrections following feedback from Wes Eddy upon review of an interim version of this draft. Note: Wes Eddy raised a question about whether discussion of the ECN Pitfalls could be improved or restrcutured - this is expected to be addressed in the next revision. We think this draft is ready for wider review. Comments are welcome to the authors or via the IETF AQM or TSVWG mailing lists.