As commonly known, TCP is the most popular transport layer protocol for data transfer. It provides connection-oriented reliable transfer of data between two communicating hosts, wherein a host refers to a network-connected computer, or to any system which can be connected to a network for offering services to another host connected to the same network. TCP uses several techniques to maximize the performance of the connection by monitoring different variables relating to the connection. For example, TCP includes an internal algorithm for avoiding congestion.
ATM (Asynchronous Transfer Mode), in turn, is a connection-oriented packet-switching technique which the internal telecommunication standardization organization ITU-T has chosen as the target solution of a broadband Integrated Services Digital Network (B-ISDN). The problems of conventional packet networks have been eliminated in the ATM network by using short packets of a standard length (53 bytes), known as cells. ATM networks are quickly being adopted as backbones for the various parts of TCP/IP networks such as the Internet.
Although ATM has been designed to provide an end-to-end transport level service, it is very likely that, also in the future, networks will be implemented in such a way that TCP/IP remains the de-facto standard of the networks and only a part of the end-to-end path of a connection is implemented using ATM. Thus, even though ATM will continue to be utilized, TCP will still be needed to provide the end-to-end transport functions.
The introduction of ATM also means that implementations must be able to support the huge legacy of existing data applications, in which TCP is widely used as transport layer protocol. To migrate the existing upper layer protocols to ATM networks, several approaches to congestion control in ATM networks have been considered in the past.
Congestion control relates to the general problem of traffic management for packet-switched networks. Congestion means a situation in which the number of transmission requests at a specific time exceeds the transmission capacity at a certain network point (called a bottle-neck resource). Congestion usually results in overload conditions. As a result, the buffers overflow, for instance, so that packets are retransmitted either by the network or by the subscriber. In general, congestion arises when the incoming traffic to a specific link is more than the outgoing link capacity. The primary function of congestion control is to ensure good throughput and delay performance while maintaining a fair allocation of network resources to users. For the TCP traffic, whose traffic patterns are often highly bursty, congestion control poses a challenging problem. It is known that packet losses result in a significant degradation in TCP throughput. Thus, for the best possible throughput, a minimum number of packet losses should occur.
For the above mentioned reasons, most of such networks are TCP networks or TCP over ATM networks, i.e. networks in which TCP provides the end-to-end transport function and the ATM network provides the underlying “bit pipes”.
In the article “Improving TCP performance over ATM by the fast TCP flow control” by Jing Wu, Peng Zhang and Jian Ma, ICCT'98, Beijing, China, October 1998, fast-TCP (FTCP) is described, which is readily to be used in intermediate nodes aiming to improve the TCP throughput by quickly relieving congestion. The mechanisms of FTCP can be divided into three parts: congestion detection, identification of acknowledgments (ACKs) and delay of ACKs. The basic idea is to delay the acknowledgments being transferred from a destination to a source of a data packet. This can be done at the same network point where congestion has been detected, or, alternatively, a network point detecting overload or congestion can direct another network point to delay the acknowledgments. Thus, congestion control is performed on the return path of the connection. Instead of discarding packets or cells on the forward path, the network delays acknowledgments on the return path and thus causes the TCP source to reduce its output rate. A congestion detection is used to notify congestion before a buffer overflow occurs. Furthermore, an identification of data packets including ACKs is required to extract the ACK flow from the normal data traffic. The rate of ACKs is adjusted by delaying the ACKs.
In particular, a fixed threshold for the forward buffer occupancy is said, so that congestion is notified once the buffer occupancy exceeds the threshold. ACKs flows are delayed according to the congestion state, i.e. congestion or no congestion. That is, when no congestion occurs, ACKs leak by a normal rate, otherwise, by a fraction of the normal rate. The normal rate is set equal to the rate of the data packets in the forward path. If the rate is to be halved when a congestion is detected, the fraction is set to a half.
Thus, the transport protocol TCP itself does not have to be amended in any way.
However, it is difficult to set a reasonable threshold in order to meet the desired efficiency of the network resource without degrading validity of FTCP. To avoid congestion, a small threshold might be preferred so as to notify the congestion in an early state. However, in this case, the forward buffer capacity might be largely underutilized. On the contrary, if a large threshold is chosen, buffer overflow is likely to happen.
Furthermore, the termination of the delay rate of the ACKs also leads to a problem. For FTCP, the ACKs should be delayed according to the network traffic conditions. However, in real networks, traffic changes so quickly and frequently that it is difficult to provide a well-adapted delay rate.