Abstract. This paper proposes a novel fast backward congestion notification mechanism for TCP congestion control. The proposed method uses a simple.
Fast Backward Congestion Notification Mechanism for TCP Congestion Control Fei Peng and Victor C.M. Leung Department of Electrical and Computer Engineering The University of British Columbia 2356 Main Mall, Vancouver B.C., Canada V6T 1Z4 E-Mail: {feip, vleung}@ece.ubc.ca Abstract This paper proposes a novel fast backward congestion notification mechanism for TCP congestion control. The proposed method uses a simple implementation to inform the traffic source at a very early stage that the network is becoming overloaded or congested and ask the source to slow down its transmission rate. Since TCP uses acknowledgments (ACKs) to adjust the number of packets sent over the network, the basic idea of our scheme is to control (or delay) TCP ACKs in the access node where its forward connection through the network is congested. To shorten the control loop, the congested network node generates ICMP Source Quench to initiate ACK control at the access node at the onset of congestion. The mechanism is proven very effective to improve TCP throughput and fairness performance and reduce buffer occupancy, by theoretical analysis and simulations. In particular, formulae for buffer occupancy and average throughput are derived relative to the distance between the congested node and the source terminal. It is important to note that TCP behavior does not have to be amended in any way.
1.
Background and Motivations
TCP is one of the few transport protocols that have their own congestion control mechanisms. The TCP flow control mechanism is meant to slow down the source rate when the network becomes congested. It has no direct way of knowing when the network is congested and can only indirectly detect congestion by keeping track of packet loss. This reliance on packet drops as an indication of congestion causes congestion control to be initiated after congestion losses have already happened. Because retransmissions of lost packets are scheduled with a backoff delay equal to twice the current
(estimated) round trip time (RTT), throughput decreases as the end-to-end delay increases. Besides, depending on when congestion hits, packet dropping may come too late if the source has already sent out all the data it intended to. To avoid unnecessary packet drops and therefore avoid unnecessary delays for packets from lowbandwidth delay-sensitive TCP connections, an Explicit Congestion Notification (ECN) mechanism is being considered by IETF [3]. When the buffer of a router’s outgoing link is about to overflow, it sets the ECN bits in the forwarded packets as an indication of congestion. When each packet reaches its destination, the congestion indication is turned around by the receiving terminal and returned to the source by setting the ECN bit in the next outgoing ACK packet. In this way, it can avoid congestion in asymmetric networks. However, the source has to wait one RTT before responding to an ECN indication as it has the same control loop as TCP. Implementing the congestion control algorithm at the source and processing congestion-related notifications at the receiver clearly need modifications of TCP behavior at end systems. Compared to ECN, mechanisms based on the idea of delaying reverse ACKs have been proposed to reduce the sending rates of TCP sources in case of congestion. Generally, the delayed ACK algorithm is implemented in TCP receivers [4]. This requires a round-trip control time and the TCP behavior at receiver has to be modified. In addition, without any knowledge of network conditions, it is difficult to determine when the receiver should send ACKs. Fast-TCP (FTCP) proposed by Nokia requires no TCP modifications since it executes ACK control in the network node where the forwarding data buffer becomes congested. However, it requires that ACKs be routed through the same nodes as their corresponding forward packets. Except the access nodes, the backward ACK’s are often routed through
different intermediate nodes than its corresponding forward packet. This limits the usefulness of FTCP even though it has been proven to work well in access nodes [5, 6]. Another mechanism called TCP rate control was proposed to employ ACK control at intermediate nodes to smooth the traffic flow without incurring retransmission timeouts [9]. However, different from FTCP, it does not rely on monitoring queue status and manages the TCP transmitter directly by taking over TCP flow control. By optimally pacing transmissions of ACKs, TCP rate control provides direct feedback to the transmitter by detecting a remote user’s access speed and the network’s latency. In this way, it can maintain flow and connection status, monitor a connection’s speed and adjust bandwidth allocation as the connection speed changes. However, TCP rate control is a proprietary solution that is not compatible with standard TCP behavior and is complex to implement. From the above, we see that it is advantageous to develop a congestion control mechanism with a shortened control loop that requires no modifications of TCP loop (>100's ms)
ECN path
FBCN Control Loop (>=ms,
