Talking about TCP Global synchronization and TCP Hunger

TCP global synchronization

As shown above:

When the network is normal, PC1,PC2,PC3 establishes a TCP link with PC4, and the window size of TCP is the largest. When there is a congestion tail loss on the interface of R1 and PC4, the TCP senses link congestion. The window size is changed to the original 1ax 2, and the rate of AR1 interface decreases obviously when it is changed. The link is back to normal. TCP sensed that the link was not congested and immediately restored the window size, so it is conceivable that the link would be congested. It just goes over and over again.

This phenomenon is called TCP global synchronization.

TCP starvation

As shown above:

Like TCP synchronization, congestion occurs when the link between AR1 and PC4 is congested. The window of TCP changes to the size of the original window, but then the message of PC5 UDP comes in. UDP does not have the same window mechanism as TCP. When the link is not congested, UDP immediately fills up the link. TCP still feels link congestion and shrinks the window again. If UDP messages are sent continuously (at a high rate), the TCP will be squeezed out and unable to get the bandwidth.

This phenomenon is called TCP hunger.

The reasons for the above two cases are that when congestion occurs, congestion avoids tail discarding. Using WRED weighted random early detection mechanism to avoid the above situation.