Explicit Congestion Notification
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 buggy network equipment drop packets which have ECN bits set.
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 Transport Layer's protocol header. For example, when using TCP, the congestion indication is echoed back by setting the ECE bit.
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.
TCP supports ECN using three flags in the TCP header. The 1st one, the Nonce Sum, is used to protect against accidental or malicious concealment of marked packets from the TCP sender. 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 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.
Since TCP does not perform congestion control on control packets, control packets are usually not marked as ECN-capable.
A recent proposal 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.
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 don't give access to the ECN bits.
Since ECN is only effective in combination with an Active Queue Management 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, when it is able to avoid an RTO timeout; this is often the case for interactive connections and transactional protocols (such as HTTP requests, the conversational phase of SMTP, or SQL requests).
Effects of ECN on bulk throughput are less clear 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. 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.
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.
Related Sites for Explicit Congestion Notification
- ECN (Explicit Congestion Notification) in TCP/IP read Explicit Congestion Notification
- TheFreeDictionary.com - explicit - definition of explicit by the ... read Explicit Congestion Notification
- Explicit | Easy to understand definition of explicit by Your ... read Explicit Congestion Notification
0 Response to "Explicit Congestion Notification is ..."
Post a Comment