1. Introduction
1. Introduction
We first describe the mechanism by which TCP uses packet drops as an indication of congestion. Next, we explain that by adding Active Queue Management (AQM, such as RED) to the Internet infrastructure, routers can detect congestion before queues overflow, so routers are no longer limited to using packet drops as an indication of congestion. Routers can instead set the Congestion Experienced (CE) codepoint in the IP header of packets from ECN-capable transport protocols. We describe when the CE codepoint is set in routers, and describe the modifications needed to make TCP ECN-capable. Modifications for other transport protocols (e.g., unreliable unicast or multicast, reliable multicast, other reliable unicast transport protocols) can be considered as such protocols are developed and go through the standards process. We also describe in this document issues related to the use of ECN inside IP tunnels, and particularly inside IPsec tunnels.
One guiding principle of this document is that, to the extent possible, the mechanisms specified here should be incrementally deployable. One challenge to the incremental deployment principle is that some pre-existing IP tunnels are incompatible with the use of ECN. As ECN is deployed, incompatible IP tunnels will have to be upgraded to conform to the specifications in this document.
This document obsoletes RFC 2481 "A Proposal to add Explicit Congestion Notification (ECN) to IP", which defined ECN as an Experimental Protocol for the Internet community. This document also updates RFC 2474 "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers" regarding the definition of the ECN field in the IP header, updates RFC 2401 "Security Architecture for the Internet Protocol" to change the handling of the IPv4 TOS byte and IPv6 Traffic Class octet in tunnel mode header construction to be compatible with the use of ECN, and updates RFC 793 "Transmission Control Protocol" regarding the definition of two new flags in the TCP header.
TCP's congestion control and avoidance algorithms are based on the concept of treating the network as a black-box [Jacobson88, Jacobson90]. Congestion or other state of the network is determined by end-systems probing the network state, i.e., by gradually increasing the load on the network (by increasing the window of outstanding packets in the network) until the network becomes congested and loses packets. Treating the network as a "black-box" and loss as an indication of network congestion is appropriate for pure best-effort data carried by TCP, which has little or no sensitivity to the latency or loss of individual packets. In addition, TCP's congestion management algorithms incorporate techniques (such as Fast Retransmit and Fast Recovery) to minimize the impact of loss from a throughput perspective. However, these mechanisms are not designed to help applications that are in fact sensitive to the latency or loss of one or more individual packets. Interactive traffic (such as telnet, web browsing, and audio and video data transfers) can be sensitive to packet loss (particularly when using an unreliable data transmission protocol such as UDP), or sensitive to the increased packet latency resulting from the need to retransmit packets after loss (in the reliable data transmission semantics provided by TCP).
Because TCP determines the appropriate congestion window by gradually increasing the window size until it encounters lost packets, this results in queue buildup at bottleneck routers. For most packet dropping policies in routers that are not sensitive to the load imposed by each individual flow (e.g., tail-drop when the queue overflows), this means that packets from some delay-sensitive flows may be dropped. In addition, such dropping policies cause loss synchronization across multiple flows.
Active queue management mechanisms detect congestion before queues overflow and provide an indication of this congestion to end-nodes. Therefore, active queue management can reduce unnecessary queueing delay for all traffic sharing that queue. The advantages of active queue management are discussed in RFC 2309 [RFC2309]. Active queue management avoids some of the undesirable properties of dropping when queues overflow, including the undesired loss synchronization across multiple flows. Even more importantly, active queue management means that transport protocols with congestion control mechanisms (e.g., TCP) do not have to rely solely on buffer overflow as the only indication of congestion.
Active queue management mechanisms can use one of several methods to indicate congestion to end-nodes. One approach is to use packet dropping, which is the current practice. However, active queue management allows routers to separate the policy for queuing or dropping packets from the policy for indicating congestion. Therefore, active queue management allows routers to use the Congestion Experienced (CE) codepoint in the packet header as an indication of congestion, instead of relying solely on packet dropping. This has the potential to reduce the impact of loss on delay-sensitive flows.
There are some middleboxes (such as firewalls, load balancers, or intrusion detection systems) in the Internet that either drop TCP SYN packets configured to negotiate ECN, or respond with an RST. This document specifies procedures that TCP implementations can use to provide robust connectivity in the presence of such devices.