Editing Explicit Congestion Notification (section)

==Operation==
ECN requires specific support at both the Internet layer and the [[transport layer]] for the following reasons:
* In TCP/IP, routers operate within the Internet layer, while the transmission rate is handled by the endpoints at the transport layer.
* Congestion may be handled only by the transmitter, but since it is known to have happened only after a packet was sent, there must be an echo of the congestion indication by the receiver to the transmitter.

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.

===Operation of ECN with IP===
ECN uses the two [[Least significant bit|least significant]] (right-most) bits of the [[IPv6 packet#Fixed header|Traffic Class]] field in the [[IPv4 header|IPv4]] or [[IPv6 header]] to encode four different code points:
* <code>00</code> &ndash; Not ECN-Capable Transport, Not-ECT
* <code>01</code> &ndash; ECN Capable Transport(1), ECT(1)
* <code>10</code> &ndash; ECN Capable Transport(0), ECT(0)
* <code>11</code> &ndash; 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 an [[active queue management]] (AQM) queue (e.g., a queue that uses [[random early detection]] (RED)) that is experiencing congestion and the corresponding [[router (computing)|router]] supports ECN, it may change the code point to <code>CE</code> instead of [[packet loss|dropping the packet]]. This act is referred to as "marking" and its purpose is to inform the receiving endpoint of impending [[network congestion|congestion]]. 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 as [[Transmission Control Protocol|TCP]], that support congestion control and have a method for echoing the CE indication to the transmitting endpoint.

===Operation of ECN with TCP===
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 the ''Congestion 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 with [[tcpdump]], use the filter predicate <code>(tcp[13] & 0xc0 != 0)</code>.

====ECN and TCP control packets====
Since the [[Transmission 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{{Ref RFC|5562}} 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.<ref name="kuzmanovic">Aleksandar Kuzmanovic.  The power of explicit congestion notification. In ''Proceedings of the 2005 conference on Applications, technologies, architectures, and protocols for computer communications''. 2005.</ref>

===Operation of ECN with other transport protocols===
ECN is also defined for other transport layer protocols that perform congestion control, notably [[Datagram Congestion Control Protocol|DCCP]] and [[Stream 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 above [[User Datagram Protocol|UDP]]. However, UDP requires that congestion control be performed by the application, and early UDP based protocols such as [[Domain Name Services|DNS]] did not use ECN. More recent UDP based protocols such as [[QUIC]] are using ECN for congestion control.