Explicit Congestion Notification

Explicit Congestion Notification (ECN) is an extension to the Internet Protocol and is defined in RFC 3168 (2001). ECN allows end-to-end notification of network congestion without dropping packets. It is an optional feature, and is only used when both endpoints signal that they want to use it.

Traditionally, TCP/IP networks signal congestion by dropping packets. When ECN is successfully negotiated, an ECN-aware router may set a bit in the IP header instead of dropping a packet in order to signal the beginning of congestion. The receiver of the packet echoes the congestion indication to the sender, which must react as though a packet drop were detected.

ECN uses two bits in the Differentiated Services field in the IP header, in the IPv4 TOS Byte or the IPv6 Traffic Class Octet. These two bits can be used to encode one of the values "ECN-unaware transport", "ECN-aware transport" or "congestion experienced".

Some outdated or buggy network equipment drops packets with the ECN bit set, rather than ignoring the bit [Measuring Interactions Between Transport Protocols and Middleboxes. Alberto Medina, Mark Allman, and Sally Floyd. Internet Measurement Conference 2004, August 2004.] .

Operation

ECN requires specific support at the transport layer.

Operation of ECN with TCP

In addition to the two ECN bits in the IP header, TCP uses two flags in the TCP header to signal the sender to reduce the amount of information it sends. These are the "ECN-echo" and "Congestion Window Reduced" bits.

Use of ECN on a TCP connection is optional; for ECN to be used, it must be negotiated at connection establishment by including suitable options in the SYN and SYN-ACK segments.

When ECN has been negotiated on a TCP connection, the sender marks all data segments with the "ECN-capable" codepoint. A router that detects impending congestion may choose to mark an ECN-capable packet with the "congestion experienced" codepoint rather than dropping it outright.

Upon receiving a TCP segment with the "Congestion Experienced" codepoint, the TCP receiver sends an acknowledgement with the "ECN-echo" flag set. The "ECN-echo" bit indicates congestion to the sender, which reduces its congestion window as for a packet drop. It then acknowledges the congestion indication by sending a segment with the "Congestion Window Reduced" codepoint.

ECN and TCP control packets

Since TCP does not perform congestion control on control packets (pure ACKs, SYN, FIN segments), control packets are usually not marked as ECN-capable.

A recent proposal [ [http://www.ietf.org/internet-drafts/draft-ietf-tcpm-ecnsyn-06.txt "Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets."] Sally Floyd. Work in Progress. 2008] suggests marking SYN-ACK packets as ECN-capable. This improvement, known as ECN+, has been shown to provide dramatic improvements to performance of short-lived TCP connections [Aleksandar Kuzmanovic. The power of explicit congestion notification. In "Proceedings of the 2005 conference on Applications, technologies, architectures, and protocols for computer communications". 2005.] .

Operation of ECN with other transport protocols

ECN is also defined for other transport-layer protocols that perform congestion control, notably DCCP and SCTP. The general principle is similar to TCP, although the details of the on-the-wire encoding differ.

It should in principle be possible to use ECN with protocols layered above UDP. However, UDP requires that congestion control be performed by the application, and current networking APIs do not give access to the ECN bits. Currently, DCCP is the only choice for datagram-based applications that wish to use ECN.

Effects on performance

Since ECN is only effective in combination with an Active Queue Management (AQM) policy, the benefits of ECN depend on the precise AQM being used. A few observations, however, appear to hold across different AQMs.

As expected, ECN reduces the number of packets dropped by a TCP connection, which, by avoiding a retransmission, reduces latency and especially jitter. This effect is most drastic when the TCP connection has a single outstanding segment [Jamal Hadi Salim and Uvaiz Ahmed. Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks. RFC 2884. July 2000] , when it is able to avoid an RTO timeout; this is often the case for interactive connections (such as remote logins) and transactional protocols (such as HTTP requests, the conversational phase of SMTP, or SQL requests).

Effects of ECN on bulk throughput are less clear [Marek Malowidzki, Simulation-based Study of ECN Performance in RED Networks, In "Proc. SPECTS'03". 2003.] , due to the fact that modern TCP implementations are fairly good at resending dropped segments in a timely manner when the sender's window is large.

Use of ECN has been found to be detrimental to performance on highly congested networks when using AQM algorithms that never drop packets [Aleksandar Kuzmanovic. The power of explicit congestion notification. In "Proceedings of the 2005 conference on Applications, technologies, architectures, and protocols for computer communications". 2005] . Modern AQM implementations avoid this pitfall by dropping rather than marking packets at very high load.

Implementations

Many modern implementations of the TCP/IP protocol suite have some support for ECN; however, they usually ship with ECN disabled.

ECN support in hosts

Windows Server 2008 and Windows Vista support ECN but it is disabled by default. cite web | url = http://technet.microsoft.com/en-us/library/bb726965.aspx | title = "New Networking Features in Windows Server 2008 and Windows Vista ] ECN support can be enabled with the following shell command:netsh interface tcp set global ecncapability=enabled

Mac OS X 10.5 implements ECN. It is controlled using the following sysctl interface: cite web | url = http://www.icir.org/floyd/ecn.html#implementations | title = "ECN (Explicit Congestion Notification) in TCP/IP" ] net.inet.tcp.ecn_negotiate_in, net.inet.tcp.ecn_initiate_out.

The Linux kernel has supported ECN for some time now; however, it is disabled by default. In most kernel versions, it can be activated through the sysctl interface: sysctl net.ipv4.tcp_ecn=1

ECN support is available as a patch for FreeBSD cite web | url = http://lists.freebsd.org/pipermail/freebsd-net/2007-November/016007.html | title = TCP ECN patch for review | first = Rui | last = Paulo | accessdate = 2007-11-26 | date = November 26 2007] , it can be activated through the sysctl interface: sysctl net.inet.tcp.ecn.enable=1

ECN support in routers

Since ECN marking in routers is dependent on some form of active queue management, routers must be configured with a suitable queue discipline in order to perform ECN marking.

Cisco IOS routers perform ECN marking if configured with the WRED queuing discipline since version 12.2(8)T [ [http://cco.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a0080443160.html Cisco Systems - Redirect to ] ] .

Linux routers perform ECN marking if configured with one of the RED or GRED queue disciplines with an explicit "ecn" parameter, or by using the sfb discipline.

Modern BSD implementations (FreeBSD, NetBSD) have support for ECN marking in the "altq" queueing implementation for a number of queuing disciplines (notably RED and Blue).

ee also

* Network congestion avoidance
* Type of Service field
* Transmission Control Protocol

References

External links

* RFC 3168 – The Addition of Explicit Congestion Notification (ECN) to IP
* RFC 4774 – Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field
* http://www.icir.org/floyd/ecn.html – Sally Floyd's ECN page