Network Congestion Control (5) defects of traditional TCP

This world is constantly changing. If everything stays in the same place, it will eventually be eliminated. TCP congestion controlAlgorithmThis is also true.

Since the mid-to-late s and the 21st century, the Internet has developed rapidly. First, congestion has become increasingly serious. Second, the emergence of high-bandwidth networks, from Mbps to 1 Gbps to 10 Gbps, more and more data-sensitive applications, such as audio and video applications, pose a huge challenge to the traditional TCP congestion control algorithm.

First, let's look at the high-bandwidth and high-latency networks. This type of network is usually called long fat Network (LFN), or high-bandwidth latency product network (high-bandwidth-delay-product network, BDP ). The bandwidth latency product (BDP) usually represents the capacity of the network channel, that is, the amount of data that can be buffered in the network. Obviously, increasing the bandwidth or latency will double the capacity of the channel. When the product is getting bigger and bigger, the limitations of TCP and begin to be exposed. For a 100 Mbps network, if the latency is 100,000,000 ms, BDP is 0.1*1,250,000/8 = 1220.7 bytes = 100 K. If the network latency is Ms for 1 Gbps, the BDP is about K. If TCP runs on this network, the efficiency is very low. From the TCP Header, we can see that TCP uses 16 bits to indicate the rwnd size of the receiving window, the maximum value of a 16-bit value is 65535, because the TCP sending window is the minimum value between the cwnd window of the congestion window and the rwnd window of the receiving end, obviously, the maximum sending window can only reach 65535 (in bytes). Obviously, this value is too far different from the above-mentioned network BDP, so TCP can only send a burst of data and then wait for ACK. In extreme cases, it is a bit like a "stop protocol. In this way, TCP will not be able to fully utilize the network bandwidth, resulting in a serious waste of bandwidth.

Window expansion option: to solve the problem of window size being too small, TCP uses its option function. From the TCP Header, we can see that TCP reserves a certain option function for expansion and other purposes. The window expansion option adds an additional 16 bits to indicate the window size. The window value consists of the 16 bits of the header and the 16 bits of the option, but is not composed of addition, it is expressed by the power of the shift window value. That is to say, if the shift window value is 10, the maximum value of the window is 65535*2.10, This value is relatively large, enough to indicate the size of the window.

Well, the window is too small to solve the problem. Let's look at the problem of the window growth mechanism. Through the preceding TCP congestion control mechanism, we can see that the TCP growth mode is based on the AIMD principle, that is, the addition increases. In the congestion avoidance phase, 1 is added each time, according to the network environment we calculated above, the latency is 1 Gbps and 12,500,000 ms, and the window size is 1500. If the size of each packet is bytes, so we need 8333 congestion windows, that is, 8333 RTTs, to increase to this value. This time also increases with the increase of RTT and bandwidth, in addition, if packet loss occurs during the growth process, the window will be halved immediately. At this time, we have to start to grow again. Obviously, this growth function cannot meet the needs of the current network.

Second, the traditional TCP always interprets packet loss as network congestion, and assumes that packet loss caused by Link errors is negligible.V. Jacob observed that the probability of Link errors is too low to be ignored. However, in high-speed networks, such assumptions are not true,When the data transmission rate is high, the Link error cannot be ignored. In wireless networks, the Link error rate is higher. Therefore, if we generally think that packet loss is caused by congestion and thus reduce the speed by half, this is a great waste of network resources. Congestion determination requires two consecutive groups to be lost.

The last step is the diversity of network applications and the increasing number of audio and video applications. In most cases, UDP is used to transmit data. UDP does not provide data reliability assurance, and there is no congestion control or flow control, therefore, when UDP and TCP compete together, if packet loss is caused, TCP will return and avoid them, while UDP transmission will obviously cause the TCP application to become odd and slow, of course, this is not a problem of TCP, but it brings problems to TCP.

In response to the above problems, TCP congestion control has entered a new stage, with many research hotspots emerging. The concentrated aspects include the improvement of the "slow start" process, speed-based congestion control, ECN, and congestion control for special networks (wireless networks and satellite networks. Initially proposed hstcp, and later appeared in the BI-TCP, cubic TCP, fasttcp, TCP-Westwood and a series of improvement, UDP application began TCP-friendly congestion control, the emergence of TFRC, DCCP has been launched recently.

Next section: hstcp and bi-TCP.