Explicit Congestion Notification
From Wikipedia, the free encyclopedia
The five-layer TCP/IP model |
---|
5. Application layer |
DHCP · DNS · FTP · Gopher · HTTP · IMAP4 · IRC · NNTP · XMPP · POP3 · RTP · SIP · SMTP · SNMP · SSH · TELNET · RPC · RTCP · RTSP · TLS (and SSL) · SDP · SOAP · GTP · STUN · NTP · (more) |
4. Transport layer |
TCP · UDP · DCCP · SCTP · RSVP · ECN · (more) |
3. Network/internet layer |
IP (IPv4 · IPv6) · OSPF · IS-IS · BGP · IPsec · ARP · RARP · RIP · ICMP · ICMPv6 · IGMP · (more) |
2. Data link layer |
802.11 (WLAN) · 802.16 · Wi-Fi · WiMAX · ATM · DTM · Token ring · Ethernet · FDDI · Frame Relay · GPRS · EVDO · HSPA · HDLC · PPP · PPTP · L2TP · ISDN · ARCnet · LLTD · (more) |
1. Physical layer |
Ethernet physical layer · RS-232 · SONET/SDH · G.709 · Optical fiber · Coaxial cable · Twisted pair · (more) |
ECN is an extension to the Internet Protocol which allows end-to-end notification of network congestion without dropping packets. ECN 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[1].
Contents |
[edit] Operation of ECN
ECN requires specific support at the transport layer.
[edit] 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.
[edit] 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[2] 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[3].
[edit] 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.
[edit] 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[4], 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[5], 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[6]. Modern AQM implementations avoid this pitfall by dropping rather than marking packets at very high load.
[edit] Implementations of ECN
Many modern implementations of the TCP/IP protocol suite have some support for ECN; however, they usually ship with ECN disabled.
[edit] ECN support in hosts
Windows Server 2008 and Windows Vista support ECN but it is disabled by default.[7] 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:[8] 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[9], it can be activated through the sysctl interface: sysctl net.inet.tcp.ecn.enable=1
[edit] 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 [10].
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).
[edit] See also
[edit] References
- ^ Measuring Interactions Between Transport Protocols and Middleboxes. Alberto Medina, Mark Allman, and Sally Floyd. Internet Measurement Conference 2004, August 2004.
- ^ Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets. Sally Floyd. Work in Progress. 2008
- ^ Aleksandar Kuzmanovic. The power of explicit congestion notification. In Proceedings of the 2005 conference on Applications, technologies, architectures, and protocols for computer communications. 2005.
- ^ Jamal Hadi Salim and Uvaiz Ahmed. Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks. RFC 2884. July 2000
- ^ Marek Malowidzki, Simulation-based Study of ECN Performance in RED Networks, In Proc. SPECTS'03. 2003.
- ^ Aleksandar Kuzmanovic. The power of explicit congestion notification. In Proceedings of the 2005 conference on Applications, technologies, architectures, and protocols for computer communications. 2005
- ^ "New Networking Features in Windows Server 2008 and Windows Vista.
- ^ "ECN (Explicit Congestion Notification) in TCP/IP".
- ^ Paulo, Rui (November 26, 2007). TCP ECN patch for review. Retrieved on 2007-11-26.
- ^ Cisco Systems - Redirect to
[edit] 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