diff options
Diffstat (limited to 'doc/rfc/rfc8087.txt')
| -rw-r--r-- | doc/rfc/rfc8087.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc8087.txt b/doc/rfc/rfc8087.txt new file mode 100644 index 0000000..4441eff --- /dev/null +++ b/doc/rfc/rfc8087.txt @@ -0,0 +1,1067 @@ + + + + + + +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) + +Abstract + + 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. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8087. + + + + + + + + + + + + + + +Fairhurst & Welzl Informational [Page 1] + +RFC 8087 Benefits of ECN March 2017 + + +Copyright Notice + + Copyright (c) 2017 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 + (http://trustee.ietf.org/license-info) 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. + +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 + + + + + + + +Fairhurst & Welzl Informational [Page 2] + +RFC 8087 Benefits of ECN March 2017 + + +1. Introduction + + 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 + + + +Fairhurst & Welzl Informational [Page 3] + +RFC 8087 Benefits of ECN March 2017 + + + 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 | + +-----+-----+---------+ + + 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 + + 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. + + + + + + +Fairhurst & Welzl Informational [Page 4] + +RFC 8087 Benefits of ECN March 2017 + + + 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 + + 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 + + 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% + + + + +Fairhurst & Welzl Informational [Page 5] + +RFC 8087 Benefits of ECN March 2017 + + + 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 + + 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 + + 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 + + + +Fairhurst & Welzl Informational [Page 6] + +RFC 8087 Benefits of ECN March 2017 + + + 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. + +2.4. Applications That Do Not Retransmit Lost Packets + + 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 + + + +Fairhurst & Welzl Informational [Page 7] + +RFC 8087 Benefits of ECN March 2017 + + + 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 + + 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 + + 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. + + + + +Fairhurst & Welzl Informational [Page 8] + +RFC 8087 Benefits of ECN March 2017 + + + 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 + + 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 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]. + + + + + + + +Fairhurst & Welzl Informational [Page 9] + +RFC 8087 Benefits of ECN March 2017 + + + 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 + + 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 + + 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. + + + + +Fairhurst & Welzl Informational [Page 10] + +RFC 8087 Benefits of ECN March 2017 + + +3.3. Enabling ECN in Network Devices + + 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 + + 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 + + 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. + + + + +Fairhurst & Welzl Informational [Page 11] + +RFC 8087 Benefits of ECN March 2017 + + + 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 + + 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 + + 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 + + + +Fairhurst & Welzl Informational [Page 12] + +RFC 8087 Benefits of ECN March 2017 + + + 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 + + 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 + + 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]. + + + +Fairhurst & Welzl Informational [Page 13] + +RFC 8087 Benefits of ECN March 2017 + + +4.3. Detecting ECN-Receiver Feedback Cheating + + 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 + + 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 | + +---------+-----------------------------------------------------+ + + 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 A network device may support alternate ECN semantics (see + Section 3.1). + + + +Fairhurst & Welzl Informational [Page 14] + +RFC 8087 Benefits of ECN March 2017 + + + 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 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 Network devices need to be able to forward both ECN-capable and + not-ECN-capable flows (see Section 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). + + 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 An ECN-capable transport/application must return feedback + indicating congestion to the sending endpoint and perform an + appropriate congestion response (see Section 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 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). + +6. Security Considerations + + This document introduces no new security considerations. Each RFC + listed in this document discusses the security considerations of the + specification it contains. + + + + + + + + + +Fairhurst & Welzl Informational [Page 15] + +RFC 8087 Benefits of ECN March 2017 + + +7. References + +7.1. Normative References + + [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, + <http://www.rfc-editor.org/info/rfc2474>. + + [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, + <http://www.rfc-editor.org/info/rfc3168>. + + [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion + Notification", RFC 6040, DOI 10.17487/RFC6040, November + 2010, <http://www.rfc-editor.org/info/rfc6040>. + + [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF + Recommendations Regarding Active Queue Management", + BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, + <http://www.rfc-editor.org/info/rfc7567>. + + [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage + Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, + March 2017, <http://www.rfc-editor.org/info/rfc8085>. + +7.2. Informative References + + [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. + + [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. + + [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. + + + + + +Fairhurst & Welzl Informational [Page 16] + +RFC 8087 Benefits of ECN March 2017 + + + [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. + + [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + DOI 10.17487/RFC0768, August 1980, + <http://www.rfc-editor.org/info/rfc768>. + + [RFC1349] Almquist, P., "Type of Service in the Internet Protocol + Suite", RFC 1349, DOI 10.17487/RFC1349, July 1992, + <http://www.rfc-editor.org/info/rfc1349>. + + [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", + RFC 3649, DOI 10.17487/RFC3649, December 2003, + <http://www.rfc-editor.org/info/rfc3649>. + + [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, + <http://www.rfc-editor.org/info/rfc3758>. + + [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram + Congestion Control Protocol (DCCP)", RFC 4340, + DOI 10.17487/RFC4340, March 2006, + <http://www.rfc-editor.org/info/rfc4340>. + + + + + +Fairhurst & Welzl Informational [Page 17] + +RFC 8087 Benefits of ECN March 2017 + + + [RFC4774] Floyd, S., "Specifying Alternate Semantics for the + Explicit Congestion Notification (ECN) Field", BCP 124, + RFC 4774, DOI 10.17487/RFC4774, November 2006, + <http://www.rfc-editor.org/info/rfc4774>. + + [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, + <http://www.rfc-editor.org/info/rfc5562>. + + [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion + Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, + <http://www.rfc-editor.org/info/rfc5681>. + + [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, <http://www.rfc-editor.org/info/rfc6679>. + + [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, + <http://www.rfc-editor.org/info/rfc6789>. + + [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, <http://www.rfc-editor.org/info/rfc7928>. + + [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. + + + + + + + + + + + +Fairhurst & Welzl Informational [Page 18] + +RFC 8087 Benefits of ECN March 2017 + + +Acknowledgements + + 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 + + Email: gorry@erg.abdn.ac.uk + + + Michael Welzl + University of Oslo + PO Box 1080 Blindern + Oslo N-0316 + Norway + + Phone: +47 22 85 24 20 + Email: michawe@ifi.uio.no + + + + + + + + + + + + + + + + + + + +Fairhurst & Welzl Informational [Page 19] + |