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.

  • Packet loss (router cache overflow)
  • Excessive grouping latency (queuing in the router cache)

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

Causes and costs of congestion

We progressively analyze the causes and costs of congestion by assuming different scenarios

Scene 1

We assume that

  • Two senders, two receivers
  • One Router, Unlimited Cache
  • No retransmission


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


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.

  • Too much packet delay during congestion
  • reach maximum throughput

Scenario 2

We assume that

  • A router, limited buffers
  • Sender retransmission group


It can be discussed in the following categories

  • Case a: The Sender is able to know the router buffer information through some mechanism and sends it only when it is free


  • Case b: retransmitted only after loss, which obviously reduces the arrival speed


  • Case c: retransmission after both packet loss and timer timeout, with apparent further reduction in arrival speed


The cost of congestion :

  • For a given "goodput", do more work (retransmission)
  • Resulting in waste of resources

Scenario 3

  • Four senders
  • hopping
  • Timeout/retransmission


As congestion becomes severe, the entire network may go down and the arrival speed converges to zero, similar to a deadlocked state


Another cost of congestion :

  • When a packet is dropped, any "upstream" transmission capacity used for that packet is wasted, which is equivalent to a wasted transmission, wasting resources and transmission capacity

Methods of congestion control

End-to-end congestion control.

  • The network layer does not need to explicitly provide support
  • end system by observing the loss, delay, etc. Network behavior to determine if congestion is occurring
  • TCP takes this approach *Network-assisted congestion control. *The router explicitly feeds the network to the sender congestion message *Simple congestion indication (1bit): SNA, DECbit, TCP/IP ECN, ATM) *Indicate what speed the sender should take

Case: ATM ABR Congestion Control

  • ABR:available bit rate "Flexible services" If the sender path is "underloaded" Use of available bandwidth If the sender path is congested Reducing the sending rate to the minimum guaranteed rate
  • RM(resource management)cells transmitter (computing) Switch setup RM cell bit (network assist) - NI bit: rate not allowed to grow - CI bit: Congestion indication RM cell is returned by the receiver to the sender

TCP congestion control

Fundamentals of TCP congestion control

Sender limits the sending rate


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.

  • Loss event = timeout or 3 duplicate ACKs
  • After a loss event, the sender reduces the rate

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.

  • Additive additive - multiplicative subtractive: AIMD
  • Slow start: SS

Additive additive - multiplicative subtractive: AIMD

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


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.

TCP Slow Start: SS

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.


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.


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.

  • 3 duplicate ACKs: CongWin cuts to half, then grows linearly
  • Timeout event: CongWin is directly set to 1 MSS, then grows exponentially, reaches threshold, then grows linearly

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

1、Tesla vs Cadillac vs MercedesBenz the three biggest car autopilot systems compete
2、 NetRemoting Basic OperationPart2
3、Microsofts Cheng Horses Challenges and solutions for the industrial application of intelligent healthcare
4、iOSRunTime no longer just heard
5、Documentation for adding static routes temporary and permanent under Centos

    已推荐到看一看 和朋友分享想法
    最多200字,当前共 发送