TCP/IP's Congestion Control Causes and Costs of Congestion Congestion Control Methods TCP Congestion Control
Congestion An informal definition would be "too many sending hosts are sending too much data or sending it too fast for the network to handle" If congestion occurs in the network, the following manifestations will occur.
is as much a top-10 problem in networking as reliable data transmission.
Congestion phenomenon refers to the phenomenon that the number of packets arriving at a certain part of the [communication subnet] is too large for that part of the network to process, thus causing a degradation in the performance of that part or even the whole network, and in serious cases, even causing the network communication service to come to a halt, i.e., the phenomenon of [deadlock]. This phenomenon is similar to the traffic congestion often seen on the road network, when there is a large increase in the number of vehicles on the road network during the holidays, and traffic of various directions interferes with each other, causing a relative increase in the time it takes for each vehicle to reach its destination (i.e., an increase in delay), and sometimes even in the blockage of vehicles on a particular section of the road (i.e., a local [deadlock] occurs)
We begin by discussing the causes and costs of congestion
We progressively analyze the causes and costs of congestion by assuming different scenarios
We assume that
image.png
We assume that the original data is sent at a speed of in, and reaches the receiver at a speed of out. Due to the speed limit of the router, the maximum speed of arrival cannot exceed the speed of the router even with infinite caching
image.png
Even if the sending speed is fast, the arrival speed cannot exceed the speed of the router, so the latency increases infinitely when congestion occurs.
We assume that
image.png
It can be discussed in the following categories
image.png
image.png
image.png
The cost of congestion :
image.png
As congestion becomes severe, the entire network may go down and the arrival speed converges to zero, similar to a deadlocked state
image.png
Another cost of congestion :
End-to-end congestion control.
Sender limits the sending rate
image.png
CongWin can be dynamically adjusted to change the sending rate and to reflect perceived network congestion.
So the question arises as to how to sense network congestion.
After sensing network congestion, the sending rate needs to be dynamically adjusted to alleviate the congestion in the network, and there are two general methods on how to adjust the sending rate.
As the name implies, this method is to simply increase first and multiply the decrease when congestion is encountered. Principle: Gradually increase the sending rate and carefully probe the available bandwidth until a loss occurs. Additive Increase: Each RTT increases CongWin by one MSS - Congestion Avoidance Multiplicative Decrease: Halves CongWin after a loss occurs. The AIMD method causes congwin to fluctuate in a jagged fashion
image.png
It first increases slowly, decreases to half when congestion is encountered, then continues to increase slowly again until it decreases to half again after congestion is encountered, and so on and so forth with jagged fluctuations.
We consider the following scenario. When a TCP connection is established, the CongWin=1 Example: MSS=500 byte, RTT=200msec Initial rate = 20k bps We find that in this case, the available bandwidth may be much higher than the initial rate, and it would be too slow if we used additive augmentation, and we want to grow to the available bandwidth quickly. This gives the idea of the slow-start algorithm. Exponential growth when the connection starts. Exponential growth. Each RTT doubles CongWin. Each ACK is received for operation. The initial rate is slow, but climbs quickly.
image.png
So the question arises, when do we do linear growth to avoid congestion control? We do this by setting a variable Threshold, which is set to 1/2 of the pre-Loss event CongWin value when the Loss event occurs. Then if the cogwin reaches Threshold, it starts to grow linearly.
image.png
As shown, the initial Threshold variable is 8, so when the exponential growth is greater than or equal to 8, it begins to grow linearly, then until a loss event occurs, the Threshold becomes half of what it was when the loss event occurred, which is 6, and then continues to grow exponentially to the Threshold, which begins to grow linearly again.
So how do we tell when a LOSS event has occurred? We deal with it in two ways.
Let's think about the reason for this, since 3 duplicate ACKs indicate that the network is still capable of transmitting some segments , timeout events indicate more severe congestion.
Slow start algorithm.
Th = ? CongWin = 1 MSS /* slow start or exponential increase */ While (No Packet Loss and CongWin < Th) { send CongWin TCP segments for each ACK increase CongWin by 1 } /* congestion avoidance or linear increase */ While (No Packet Loss) { send CongWin TCP segments for CongWin ACKs, increase CongWin by 1 } Th = CongWin/2 If (3 Dup ACKs) CongWin = Th; If (timeout) CongWin=1;
A TCP connection always sends TCP segments at a maximum segment length of 1 KB, and the sender has enough data to send Delivery. A timeout occurs when the congestion window is 16 KB, and if the next 4 RTTs (round-trip times) when The transmission of TCP segments during the interval is successful, then when all TCP segments sent during the 4th RTT time What is the size of the congestion window when both get an affirmative answer? Solution: threshold=16/2=8 KB, CongWin=1 KB, 1 RTT later, CongWin=2 KB , 2 After 3 RTTs, CongWin=4 KB , after 3 RTTs, CongWin=8 KB , Slowstart is Over; After 4 RTTs, CongWin=9 KB