![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...](https://image.slidesharecdn.com/explicitcongestionnotification-150322235401-conversion-gate01/85/Explicit-congestion-notification-1-320.jpg)
![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](https://image.slidesharecdn.com/explicitcongestionnotification-150322235401-conversion-gate01/85/Explicit-congestion-notification-2-320.jpg)
![ 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](https://image.slidesharecdn.com/explicitcongestionnotification-150322235401-conversion-gate01/85/Explicit-congestion-notification-3-320.jpg)
![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]](https://image.slidesharecdn.com/explicitcongestionnotification-150322235401-conversion-gate01/85/Explicit-congestion-notification-4-320.jpg)
![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](https://image.slidesharecdn.com/explicitcongestionnotification-150322235401-conversion-gate01/85/Explicit-congestion-notification-5-320.jpg)
![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.](https://image.slidesharecdn.com/explicitcongestionnotification-150322235401-conversion-gate01/85/Explicit-congestion-notification-6-320.jpg)
Explicit congestion notification
- 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.