Explicit Congestion Notification (ECN) is a TCP/IP extension that allows end-to-end notification of network congestion without dropping packets. When ECN is enabled between two endpoints and supported by the network, congested routers can set a mark in the IP header instead of dropping packets to signal impending congestion. The receiver echoes this back to the sender, which reduces its transmission rate as if it had detected dropped packets. However, some outdated network equipment improperly handles packets with ECN bits set and drops them instead.

1. ExplicitCongestionNotification
From Wikipedia, the free encyclopedia
Explicit Congestion Notification (ECN) is an extension to the Internet Protocol and to
the Transmission Control Protocoland is defined in RFC 3168 (2001). ECN allows end-to-end
notification of network 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 though it detected a dropped packet.
Rather than responding properly or ignoring the bits, some outdated or faulty network equipment
drop packets that have ECN bits set.[1][2][3]
Internet protocol suite
Application layer
 BGP
 DHCP
 DNS
 FTP
 HTTP
 IMAP
 LDAP
 MGCP
 NNTP
 NTP
 POP
 ONC/RPC
 RTP
 RTSP
 RIP
 SIP
 SMTP
 SNMP
 SSH
 Telnet
 TLS/SSL
 XMPP
 more...
Transport layer
 TCP
 UDP
 DCCP
 SCTP
 RSVP
 more...

2. Internet layer
 IP
 IPv4
 IPv6
 ICMP
 ICMPv6
 ECN
 IGMP
 IPsec
 more...
Link layer
 ARP
 NDP
 OSPF
 Tunnels
 L2TP
 PPP
 MAC
 Ethernet
 DSL
 ISDN
 FDDI
 more...
 V
 T
 E
Contents
[hide]
 1 Operation
o 1.1 Operation of ECN with IP
o 1.2 Operation of ECN with TCP
 1.2.1 ECN and TCP control packets
o 1.3 Operation of ECN with other transport protocols
 2 Effects on performance
 3 Implementations
o 3.1 ECN support in TCP by hosts
 3.1.1 Microsoft Windows
 3.1.2 Unix-like
 3.1.2.1 BSD
 3.1.2.2 Linux
 3.1.2.3 Mac OS X
 3.1.2.4 Solaris
o 3.2 ECN support in IP by routers
o 3.3 Data Center TCP
 4 See also

3.  5 References
 6 External links
Operation[edit]
ECN requires specific support at 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 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[edit]
ECN uses the two least significant (right-most) bits of the DiffServ field in the IPv4 or IPv6 header to
encode four different codepoints:
 00 – Non ECN-Capable Transport, Non-ECT
 10 – ECN Capable Transport, ECT(0)
 01 – ECN Capable Transport, ECT(1)
 11 – Congestion Encountered, CE.
When both endpoints support ECN they mark their packets with ECT(0) or ECT(1). 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 supports ECN, it may
change the codepoint to CE instead of dropping the packet. This act is referred to as “marking” and
its purpose is to inform the receiving endpoint of impending 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 TCP, that support congestion
control and have a method for echoing the CE indication to the transmitting endpoint.
Operation of ECN with TCP[edit]
TCP supports ECN using three flags in the TCP header. The first one, the Nonce Sum (NS), is used
to protect against accidental or malicious concealment of marked packets from the TCP
sender.[4]
The other two bits are used to echo back the congestion indication (i.e. signal the sender to
reduce the amount of information it sends) and to acknowledge that the congestion-indication
echoing was received. These are the ECN-Echo (ECE) and Congestion Window Reduced (CWR)
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 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 codepoint. This allows intermediate routers that support ECN to mark

4. those IP packets with the CE codepoint instead of dropping them in order to signal impending
congestion.
Upon receiving an IP packet with the Congestion Experienced codepoint, 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 (tcp[13] & 0xc0 != 0).
ECN and TCP control packets[edit]
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 recent proposal[5]
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.[6]
Operation of ECN with other transport protocols[edit]
ECN is also defined for other transport layer protocols that perform congestion control,
notably 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 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[edit]
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,[7]
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[8]
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[edit]
Many modern implementations of the TCP/IP protocol suite have some support for ECN; however,
they usually ship with ECN disabled.[citation needed]
ECN support in TCP by hosts[edit]
Microsoft Windows[edit]

5. Windows versions since Windows Server 2008 and Windows Vista support ECN for TCP.[9]
Since
Windows Server 2012, it is enabled by default in Windows Server versions, because Data Center
Transmission Control Protocol (DCTCP) is used.[10]
In previous Windows versions and non-server
versions it is disabled by default.
ECN support can be enabled with the following shell command:
Random early detection
From Wikipedia, the free encyclopedia
Random early detection (RED), also known as random early discard or random early drop is
a queueing discipline for anetwork scheduler suited for congestion avoidance.[1]
In the conventional tail drop algorithm, a router or other network component buffers as many packets
as it can, and simply drops the ones it cannot buffer. If buffers are constantly full, the network
iscongested. Tail drop distributes buffer space unfairly among traffic flows. Tail drop can also lead
to TCP global synchronization as allTCP connections "hold back" simultaneously, and then step
forward simultaneously. Networks become under-utilized and flooded by turns. RED addresses
these issues.
Contents
[hide]
 1 Operation
 2 Problems with Classic RED
 3 Other variants
o 3.1 WRED
o 3.2 ARED

6. o 3.3 RRED
 4 See also
 5 References
 6 External links
Operation[edit]
RED monitors the average queue size and drops (or marks when used in conjunction with ECN)
packets based on statisticalprobabilities. If the buffer is almost empty, all incoming packets are
accepted. As the queue grows, the probability for dropping an incoming packet grows too. When the
buffer is full, the probability has reached 1 and all incoming packets are dropped.
RED is more fair than tail drop, in the sense that it does not possess a bias against bursty traffic that
uses only a small portion of the bandwidth. The more a host transmits, the more likely it is that its
packets are dropped as the probability of a host's packet being dropped is proportional to the
amount of data it has in a queue. Early detection helps avoid TCP global synchronization.
Problems with Classic RED[edit]
According to Van Jacobson, "there are not one, but two bugs in classic RED."[2]
Improvements to the
algorithm were developed, and a draft paper[3]
was prepared, but the paper was never published,
and the improvements were not widely disseminated or implemented. There has been some work in
trying to finish off the research and fix the bugs.[2]
Pure RED does not accommodate quality of service (QoS) differentiation. Weighted RED (WRED)
and RED with In and Out (RIO)[4]
provide early detection with QoS considerations.
Other variants[edit]
WRED[edit]
Main article: Weighted random early detection
In weighted RED you can have different probabilities for different priorities (IP precedence, DSCP)
and/or queues.[5]
ARED[edit]
The adaptive RED or active RED (ARED) algorithm[6]
infers whether to make RED more or less
aggressive based on the observation of the average queue length. If the average queue length
oscillates around min threshold then early detection is too aggressive. On the other hand if the
average queue length oscillates around max threshold then early detection is being too
conservative. The algorithm changes the probability according to how aggressively it senses it has
been discarding traffic.