Resolution of Explicit Congestion announcement in TCP/IP Networks

Overview of TCP/IP network congestion

The current TCP implementation regards the intermediate network between TCP end nodes as an opaque "black box ". The TCP packet enters and flows out of this box. Sometimes the bags that enter the box are lost. Because there are few opportunities for bit-level errors in digital and optical media today, the designers of TCP assume that packet loss is largely due to the congestion of routers, that is, the buffer used by the router to hold the incoming packet has been filled up, so that the router will silently discard the next incoming packet.

Although TCP can detect the loss of TCP packets and re-transmits the packets, the re-transmission process will consume a lot in terms of TCP processing process, retransmission process and throughput reduction.

When a sent TCP node detects a packet loss, you can perform a fast retransmission or the packet retransmission timer times out and re-transmits the packet. Then, the TCP node reduces the sending window (the number of packets that can be sent before waiting for a response), and implements slow start and congestion avoidance algorithms (RFC 2001 ). This immediately reduces the sending rate of the sender so that the router can reduce the congestion. The sender gradually restores the size of the sending window before the congestion occurs.

Although packet loss due to router congestion is an accidental event, it does not negatively affect block data transmission, but it only increases the time for re-transmitting data packets and restoring the sending rate. Slow Start and congestion avoid time-sensitive algorithms, and the effect of block data stream control is very good. However, TCP's packet loss processing method is not very effective for interactive, time-sensitive, and loss-sensitive traffic.

Another problem about router congestion is the impact of congestion on multiple data streams. When a router begins to discard incoming data packets, it generally does not distinguish between different data streams. When multiple TCP data streams cause packet loss, all data streams must reduce their transmission rate. Depending on the degree of router congestion reduction, multiple TCP data streams will gradually restore their transmission rate. This reduces the usage of routers and related links until all TCP data streams are sent at a rate prior to congestion. The router enters the low-usage status again from the congestion status.

The throughput problem caused by retransmission and low link usage after congestion is the result of managing congestion only through the sending end. To avoid a series of problems caused by packet loss caused by router congestion, TCP/IP designers have created some standards for host and router. These standards describe the active queue management algorithm (AQM) (RFC 2309) on the IP router, enabling the router to monitor the status of the forwarding queue, to provide a mechanism for a router to report congestion to the sender, so that the sender can reduce the transmission rate before the router starts packet loss. This router report and host response mechanism are called Explicit Congestion Notification (ECN) (RFC 3168 ).

When congestion occurs, the sending host must still reduce their transmission rate. However, to avoid packet loss, the sender does not need to re-transmit the packet, and the loss of sensitive data packet streams will not be greatly affected by congestion.

Explicit Congestion Notification

The unused fields in the IP and TCP headers support ECN. At the network layer (IP), a sender must be able to indicate that ECN can be performed, and the router must be able to indicate that it is experiencing congestion during forwarding.

On the transport layer (TCP), the TCP End must indicate to the other party that it can perform ECN operations. The receiving end must be able to notify the sender that it has received a congestion notice from the router. The sender must be able to notify the receiver that it has been notified by the receiver and has reduced the sending rate.

The eight-bit service type domain (TOS) in the IP packet header was originally defined in RFC791 to indicate the packet sending priority, latency, throughput, reliability, consumption, and other features. RFC2474 is redefined as including a 6-bit Differentiated Service Code Point (DSCP) and two unused bits. The DSCP value indicates the sending priority associated with the queue configured on the vro. IP support for ECN uses the remaining two in the TOS domain. 1.

Two unused TOS fields in RFC2474 are defined as ECN fields in rfc00008 and include the following values:

00: The sending host does not support ECN.

01 or 10: sending host supports ECN

11: The router is experiencing congestion

When a host that supports ECN sends data packets, set ECN to 01 or 10. For packets sent from hosts that support ECN, if the vro on the path supports ECN and suffers congestion, it sets the ECN domain to 11. If this value has been set to 11, the vro on the downstream path does not change this value.

This article describes how to display ECN in TCP/IP networks. The principles of this article are many, but the description is more detailed. I hope you can master it.