Explicit Congestion Notification: Wikis

  

Note: Many of our articles have direct quotes from sources you can cite, within the Wikipedia article! This article doesn't yet, but we're working on it! See more info or our list of citable articles.

Encyclopedia

From Wikipedia, the free encyclopedia

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-Capable Transport (ECT), Not-ECN-Capable Transport (Not-ECT) or Congestion Experienced (CE).

Some outdated or buggy network equipment drops packets with the ECN bit set, rather than ignoring the bit[1].

The Internet Protocol Suite
Application Layer
BGP · DHCP · DNS · FTP · GTP · HTTP · IMAP · IRC · Megaco · MGCP · NNTP · NTP · POP · RIP · RPC · RTP · RTSP · SDP · SIP · SMTP · SNMP · SOAP · SSH · Telnet · TLS/SSL · XMPP · (more)
Transport Layer
TCP · UDP · DCCP · SCTP · RSVP · ECN · (more)
Internet Layer
IP (IPv4, IPv6) · ICMP · ICMPv6 · IGMP · IPsec · (more)
Link Layer
ARP/InARP · NDP · OSPF · Tunnels (L2TP) · PPP · Media Access Control (Ethernet, DSL, ISDN, FDDI) · (more)

Contents

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[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].

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.

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] because 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.

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.[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

FreeBSD 8.0 implements ECN. 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.

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, such as FreeBSD, NetBSD and OpenBSD, have support for ECN marking in the ALTQ queueing implementation for a number of queuing disciplines, notably RED and Blue.

See also

References

  1. ^ Measuring Interactions Between Transport Protocols and Middleboxes. Alberto Medina, Mark Allman, and Sally Floyd. Internet Measurement Conference 2004, August 2004.
  2. ^ Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets. Sally Floyd. Work in Progress. 2008
  3. ^ Aleksandar Kuzmanovic. The power of explicit congestion notification. In Proceedings of the 2005 conference on Applications, technologies, architectures, and protocols for computer communications. 2005.
  4. ^ Jamal Hadi Salim and Uvaiz Ahmed. Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks. RFC 2884. July 2000
  5. ^ Marek Malowidzki, Simulation-based Study of ECN Performance in RED Networks, In Proc. SPECTS'03. 2003.
  6. ^ Aleksandar Kuzmanovic. The power of explicit congestion notification. In Proceedings of the 2005 conference on Applications, technologies, architectures, and protocols for computer communications. 2005
  7. ^ ""New Networking Features in Windows Server 2008 and Windows Vista". http://technet.microsoft.com/en-us/library/bb726965.aspx. 
  8. ^ ""ECN (Explicit Congestion Notification) in TCP/IP"". http://www.icir.org/floyd/ecn.html#implementations. 

External links








Got something to say? Make a comment.
Your name
Your email address
Message