TCP Reliability Transport
We are all familiar with TCP protocol as a reliable transport protocol, but how does it ensure the reliability of transport?
To achieve reliable transmission, many factors need to be considered, such as data corruption, loss, duplication, and out-of-order shards. If these problems cannot be solved, reliable transmission cannot be achieved.
Therefore, TCP employs mechanisms such as sequence number, acknowledgement reply, resend control, connection management, and window control to achieve reliable transmission.
In this paper, we will focus on the sliding window, flow control and congestion control of TCP. The retransmission mechanism is covered separately in the next section.
Network Flow Control
Network Flow Control or know as Network Traffic Control is actually a manifestation of the subtle relationship between producers and consumers. You've probably come across this scenario a lot at work or in interviews. If the producer's capacity to produce greatly exceeds the consumer's capacity to consume, it will cause the queue to grow indefinitely. In a more serious case, you may know that when RabbitMQ messages pile up too much, it can cause performance degradation of the entire MQ server. The same is true for TCP; if left unchecked, too many messages will be put into the network, and the consumers will have exceeded their capacity, while the producers will continue to send duplicate messages, which will greatly affect the performance of the network.
To address this phenomenon, TCP provides a mechanism for the sender to control the amount of data sent based on the actual reception capacity of the receiver, which is known as flow control. The receiver maintains a receive window, while the sender maintains a send window. It should be noted that these Windows are only for a single TCP connection and not all connections share a window.
TCP provides flow control by using a variable for a receive window. The receive window gives the sender an indication of how much cache space is still available. The sender controls the amount of data sent according to the actual acceptance capacity of the receiver.
The receiver host notifies the sender of the size of the data it can receive, and the sender sends up to this limit. This limit is the window size, remember the TCP header? There is a receive window field, which is used to indicate the number of bytes the receiver is able or willing to receive.
The sender host will periodically send a window probe packet, which is used to detect whether the receiver host is still able to accept data. When the receiver's buffer is in danger of overflowing, the window size is set to a smaller value to instruct the sender to control the amount of data sent.
Here is a Network Flow Control diagram:
Network Congestion Control
Before introducing congestion control, we need to understand that in addition to the receive window and the send window, there is also a congestion window, which is mainly used to solve the problem of at what rate the sender starts sending data to the receive window. Therefore, the congestion window is also maintained by the TCP sender. We need an algorithm to decide how much data is appropriate to send, since sending too little or too much data is not ideal, hence the concept of a congestion window.
In the previous network flow control, what we avoided was the sender filling the receiver's cache with data, but we didn't know what was happening in the network. Typically, computer networks are in a shared environment. As a result, there may be network congestion due to communication between other hosts.
When the network is congested, if a large number of packets are continued to be sent, it may cause problems such as delay and loss of packets. At this point, TCP will retransmit the data, but the retransmission will increase the burden on the network, resulting in larger delays and more packet losses. This can get into a vicious cycle and keep getting bigger.
Thus, TCP cannot ignore what is happening on the network. When the network is congested, TCP sacrifices itself by reducing the amount of data it sends.
Therefore, congestion control is proposed, which aims to avoid filling the whole network with data from the sender. To regulate the amount of data the sender should send, TCP defines a concept called the congestion window. The congestion control algorithm will adjust the size of the congestion window according to the congestion degree of the network, so as to control the amount of data sent by the sender.
What is a congestion window? What does this have to do with the send window?
The Congestion Window is a state variable maintained by the sender that determines the amount of data the sender can send. The congestion window changes dynamically according to the congestion level of the network.
The Sending Window is an agreed upon window size between the sender and receiver that indicates the amount of data the receiver can receive. The congestion window and the sending window are related; the sending window is usually equal to the minimum of the congestion and receiving Windows, that is, swnd = min(cwnd, rwnd).
The congestion window cwnd changes as follows:
If there is no congestion in the network, i.e., no retransmission timeout occurs, the congestion window increases.
If there is congestion in the network, the congestion window decreases.
The sender determines whether the network is congested by observing whether the ACK acknowledgement packet is received within the specified time. If the sender does not receive the ACK acknowledgement packet within the specified time, it is considered that the network is congested.
In addition to the congestion window, it is time to discuss the TCP congestion control algorithm. TCP congestion control algorithm consists of three main parts:
Slow Start: Initially, the cwnd congestion window is relatively small, and the sender increases the congestion window exponentially to quickly adapt to the capacity of the network.
Congestion Avoidance: After the congestion window exceeds a certain threshold, the sender increases the congestion window in a linear manner to slow down the growth rate of the congestion window and avoid overloading the network.
Fast Recovery: If congestion occurs, the sender halves the congestion window and enters the fast recovery state to determine the location of the network recovery through the received duplicate acks, and then continues to increase the congestion window.
Slow Start
When a TCP connection is established, the congestion window cwnd is initially set to a minimum MSS (maximum segment size) value. This way, the initial sending rate is about MSS/RTT bytes/second. The actual available bandwidth is usually much larger than MSS/RTT, so TCP wants to find the optimal sending rate, which can be achieved by means of slow-start.
In the slow-start process, the value of the congestion window cwnd will be initialized to 1 MSS, and each time the transmitted packet segment is acknowledged, the value of cwnd will be increased by one MSS, that is, the value of cwnd will become 2 MSS. After that, the value of cwnd is doubled for each successful transmission of a packet segment, and so on. The specific growth process is shown in the following figure.
However, the sending rate can't always grow; the growth has to end sometime. So, when does the sending rate increase end? Slow-start typically ends the increase in the sending rate in one of several ways:
The first way is the case of packet loss during the sending process of slow start. When a packet loss occurs, TCP sets the sender's congestion window cwnd to 1 and restarts the slow-start process. At this point, a concept of slow start threshold ssthresh is introduced, whose initial value is half of the value of cwnd that generates packet loss. That is, when congestion is detected, the value of ssthresh is half of the window value.
The second way is to directly correlate with the value of the slow-start threshold ssthresh. Since the value of ssthresh is half of the window value when congestion is detected, packet loss may occur with each doubling when cwnd is larger than ssthresh. Therefore, it is best to set cwnd to ssthresh, which will cause TCP to switch to congestion control mode and end slow-start.
The last way that slow start can end is if three redundant acks are detected, TCP performs a fast retransmission and enters the recovery state. (If it is not clear why there are three ACK packets, it will be explained separately in the retransmission mechanism.)
Congestion Avoidance
When TCP enters the congestion control state, cwnd is set to half the congestion threshold ssthresh. This means that the value of cwnd cannot be doubled every time a packet segment is received. Instead, a relatively conservative approach is adopted in which the value of cwnd is increased by only one MSS (maximum packet segment length) after each transmission is completed. For example, even if 10 packet segments are acknowledged, the value of cwnd will only increase by one MSS. This is a linear growth model and it also has an upper bound on growth. When packet loss occurs, the value of cwnd is changed to an MSS, and the value of ssthresh is set to half of cwnd. Or it will also stop the growth of MSS when 3 redundant ACK responses are received. If three redundant acks are still received after halving the value of cwnd, the value of ssthresh is recorded as half the value of cwnd and the fast recovery state is entered.
Fast Recovery
In the Fast Recovery state, the value of the congestion window cwnd is increased by one MSS for each received redundant ACK, that is, ACK that does not arrive in sequence. This is to make use of the packet segments that have been successfully transmitted in the network to improve the transmission efficiency as much as possible.
When an ACK of the lost packet segment arrives, TCP decreases the value of cwnd and then enters the congestion avoidance state. This is to control the size of the congestion window and avoid further increasing the network congestion.
If a timeout occurs after the congestion control state, the network condition becomes more serious and TCP migrates from the congestion avoidance state to the slow-start state. In this case, the value of the congestion window cwnd is set to 1 MSS, the maximum packet segment length, and the value of the slow-start threshold ssthresh is set to half of cwnd. The purpose of this is to re-gradually increase the size of the congestion window after the network recovers to balance the transmission rate and the degree of network congestion.
Summary
As a reliable transport protocol, TCP implements reliable transport by sequence number, acknowledgement, retransmission control, connection management and window control. Among them, the flow control mechanism controls the amount of data sent by the sender according to the actual receiving capacity of the receiver, which avoids the problems of network congestion and performance degradation. The congestion control mechanism avoids the occurrence of network congestion by adjusting the amount of data sent by the sender. The concepts of congestion window and sending window are related to each other, and the amount of data at the sender is controlled by dynamically adjusting the size of the congestion window. Slow start, congestion avoidance and fast recovery are the three main parts of TCP congestion control algorithm, which adjust the size of the congestion window through different strategies to adapt to the capacity and congestion degree of the network.
In the next section, we will examine TCP's retransmission mechanism in detail. Retransmission mechanism is an important part of TCP to achieve reliable transmission. It ensures the reliable transmission of data by retransmitting lost, corrupted or delayed data. The implementation principle and strategy of the retransmission mechanism will be introduced and analyzed in detail in the next section. Stay tuned!
Post time: Feb-24-2025
