| Internet protocol suite |
|---|
| Application layer |
| Transport layer |
| Internet layer |
| Link layer |
Explicit Congestion Notification (ECN) is an extension to theInternet Protocol and to theTransmission Control Protocol and is defined inRFC 3168 (2001). ECN allows end-to-end notification ofnetwork congestion without dropping packets. ECN is an optional feature that may be used between two ECN-enabled endpoints when the underlying network infrastructure also supports it.
Conventionally, TCP/IP networks signal congestion by dropping packets. When ECN is successfully negotiated, an ECN-aware router may set a mark in the IP header instead of dropping a packet in order to signal impending congestion. The receiver of the packet echoes the congestion indication to the sender, which reduces its transmission rate as if it detected a dropped packet.
Rather than responding properly or ignoring the bits, some outdated or faulty network equipment has historically dropped or mangled packets that have ECN bits set.[1][2][3] As of 2015[update], measurements suggested that the fraction ofweb servers on the public Internet for which setting ECN prevents network connections had been reduced to less than 1%.[4]
Passive support has existed in Ubuntu Linux since 12.04 and in Windows Server since 2012.[5] Passive support in the most popular websites has increased from 8.5% in 2012 to over 70% in May 2017.[5] Adoption across the Internet now requires clients to actively request ECN. In June 2015,Apple announced that ECN will be enabled by default on its supported and future products, to help drive the adoption of ECN signaling industry-wide.[6]
ECN requires specific support at both the Internet layer and thetransport layer for the following reasons:
Without ECN, congestion indication echo is achieved indirectly by the detection of lost packets. With ECN, the congestion is indicated by setting the ECN field within an IP packet to CE (Congestion Experienced) and is echoed back by the receiver to the transmitter by setting proper bits in the header of the transport protocol. For example, when using TCP, the congestion indication is echoed back by setting the ECE bit.
ECN uses the twoleast significant (right-most) bits of theTraffic Class field in theIPv4 orIPv6 header to encode four different code points:
00 – Not ECN-Capable Transport, Not-ECT01 – ECN Capable Transport(1), ECT(1)10 – ECN Capable Transport(0), ECT(0)11 – Congestion Experienced, CE.When both endpoints support ECN they mark their packets with ECT(0) or ECT(1). Routers treat the ECT(0) and ECT(1) codepoints as equivalent. If the packet traverses anactive queue management (AQM) queue (e.g., a queue that usesrandom early detection (RED)) that is experiencing congestion and the correspondingrouter supports ECN, it may change the code point toCE instead ofdropping the packet. This act is referred to as "marking" and its purpose is to inform the receiving endpoint of impendingcongestion. At the receiving endpoint, this congestion indication is handled by the upper layer protocol (transport layer protocol) and needs to be echoed back to the transmitting node in order to signal it to reduce its transmission rate.
Because the CE indication can only be handled effectively by an upper layer protocol that supports it, ECN is only used in conjunction with upper layer protocols, such asTCP, that support congestion control and have a method for echoing the CE indication to the transmitting endpoint.
TCP supports ECN using two flags in the TCP header. The first,ECN-Echo (ECE) is used to echo back the congestion indication (i.e., signal the sender to reduce the transmission rate). The second,Congestion Window Reduced (CWR), to acknowledge that the congestion-indication echoing was received. 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 indicates that IP packets that carry TCP segments of that connection are carrying traffic from an ECN Capable Transport by marking them with an ECT code point. This allows intermediate routers that support ECN to mark those IP packets with the CE code point instead of dropping them in order to signal impending congestion.
Upon receiving an IP packet with theCongestion Experienced code point, the TCP receiver echoes back this congestion indication using the ECE flag in the TCP header. When an endpoint receives a TCP segment with the ECE bit it reduces its congestion window as for a packet drop. It then acknowledges the congestion indication by sending a segment with the CWR bit set.
A node keeps transmitting TCP segments with the ECE bit set until it receives a segment with the CWR bit set.
To see affected packets withtcpdump, use the filter predicate(tcp[13] & 0xc0 != 0).
Since theTransmission Control Protocol (TCP) does not perform congestion control on control packets (pure ACKs, SYN, FIN segments), control packets are usually not marked as ECN-capable.
A 2009 proposal[7] 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.[8]
ECN is also defined for other transport layer protocols that perform congestion control, notablyDCCP andStream Control Transmission Protocol (SCTP). The general principle is similar to TCP, although the details of the on-the-wire encoding differ.
It is possible to use ECN with protocols layered aboveUDP. However, UDP requires that congestion control be performed by the application, and early UDP based protocols such asDNS did not use ECN. More recent UDP based protocols such asQUIC are using ECN for congestion control.
Since ECN is only effective in combination with anactive 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,[9] when it is able to avoid anRTO 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[10] because modern TCP implementations are fairly good at resending dropped segments in a timely manner when the sender'swindow 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.[8] Modern AQM implementations avoid this pitfall by dropping rather than marking packets at very high load.
Many modern implementations of the TCP/IP protocol suite have some support for ECN; however, they usually ship with ECN disabled.
Windows versions since Windows Server 2008 and Windows Vista support ECN for TCP.[11] Since Windows Server 2012, it is enabled by default in Windows Server versions, becauseData Center Transmission Control Protocol (DCTCP) is used.[12] In previous Windows versions and non-server versions it is disabled by default.
ECN support can be enabled using a shell command such asnetsh interface tcp set global ecncapability=enabled.
OnFreeBSD, ECN for TCP can be configured using thenet.inet.tcp.ecn.enablesysctl. By default, it is enabled only for incoming connections that request it. It can also be enabled for all connections or disabled entirely.[13]
NetBSD 4.0 implements ECN support for TCP; it can be activated through thesysctl interface by setting 1 as value for the sysctl parameternet.inet.tcp.ecn.enable.[14]
Likewise, onOpenBSD, the sysctlnet.inet.tcp.ecn can be used.[15]
Since version 2.4.20 of theLinux kernel, released in November 2002,[16] Linux supports three working modes of the ECN for TCP, as configured through thesysctl interface by setting parameter/proc/sys/net/ipv4/tcp_ecn to one of the following values:[17]
Beginning with version 4.1 of the Linux kernel, released in June 2015, thetcp_ecn_fallback mechanism[18]: §6.1.1.1 is enabled by default[19] when ECN is enabled (the value of 1). The fallback mechanism attempts ECN connectivity in the initial setup of outgoing connections, with a graceful fallback for transmissions without ECN capability, mitigating issues with ECN-intolerant hosts or firewalls.
Mac OS X 10.5 and 10.6 implement ECN support for TCP. It is controlled using the Booleansysctl variablesnet.inet.tcp.ecn_negotiate_in andnet.inet.tcp.ecn_initiate_out.[20] The first variable enables ECN on incoming connections that already have ECN flags set; the second one tries to initiate outgoing connections with ECN enabled. Both variables default to0,[failed verification] but can be set to1 to enable the respective behavior.
In June 2015,Apple Inc. announced thatOS X 10.11 would have ECN turned on by default,[6] but the OS shipped without that default behavior. In macOS Sierra, ECN is enabled for half of TCP sessions.[21]
In June 2015,Apple Inc. announced thatiOS 9, its next version of iOS, would support ECN and have it turned on by default.[6] TCP ECN negotiation is enabled on 5% of randomly selected connections over Wi-Fi / Ethernet in iOS 9 and 50% of randomly selected connections over Wi-Fi / Ethernet and a few cellular carriers iniOS 10[22][23] and 100% foriOS 11[24]
TheSolaris kernel supports three states of ECN for TCP:[25]
As of Solaris 11.4, the default behavior isactive. ECN usage can be modified viaipadm set-prop -p ecn=active tcp.[26]
Since ECN marking in routers is dependent on some form ofactive 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 theWRED queuing discipline since version 12.2(8)T.
Linux routers perform ECN marking if configured with one of theRED or GRED queue disciplines with an explicitecn parameter, by using thesfb discipline, by using theCoDel Fair Queuing (fq_codel) discipline, or the CAKE[27] queuing discipline.
Modern BSD implementations, such asFreeBSD,NetBSD andOpenBSD, have support for ECN marking in theALTQ queueing implementation for a number ofqueuing disciplines, notablyRED andBlue.FreeBSD 11 includedCoDel, PIE, FQ-CoDel and FQ-PIEqueuing disciplines implementation inipfw anddummynet framework with ECN marking capability.[28]
Data Center Transmission Control Protocol (Data Center TCP orDCTCP) utilizes ECN to enhance theTransmission Control Protocol congestion control algorithm.[29] It is used indata center networks. Whereas the standardTCP congestion control algorithm is only able to detect thepresence of congestion, DCTCP, using ECN, is able to gauge theextent of congestion.[30]
DCTCP modifies the TCP receiver to always relay the exact ECN marking of incoming packets at the cost of ignoring a function that is meant to preserve signalling reliability. This makes a DCTCP sender vulnerable to loss of ACKs from the receiver, which it has no mechanism to detect or cope with.[31] As of July 2014[update], algorithms that provide equivalent or better receiver feedback in a more reliable approach are an active research topic.[31]
{{cite web}}:|last= has generic name (help){{cite web}}:|last= has generic name (help)