chapter 6 tcp congestion control - uni department of...
Post on 22-May-2020
9 Views
Preview:
TRANSCRIPT
Chapter 6 TCP Congestion Control
Networking CS 3470, Section 1
TCP Congestion Control
TCP congestion control introduced into the Internet in the late 1980s Roughly eight years after the TCP/IP protocol stack
had become operational
TCP Congestion Control
Immediately preceding late 1980s, the Internet was suffering from congestion collapse— hosts would send their packets into the Internet as fast
as the advertised window would allow congestion would occur at some router (causing
drops) and the hosts would time out and retransmit their
packets, resulting in even more congestion
3
TCP Congestion Control
Congestion: Informally: “too many sources sending too much
data too fast for network to handle” Different from flow control! Manifestations:
Lost packets (buffer overflow at routers) Long delays (queueing in router buffers)
a top-10 problem!
TCP Congestion Control
A Congestion Window called CongWin is used by the source to limit how much data it is allowed to have in transit at a given time. The congestion window is congestion control’s
counterpart to flow control’s advertised window.
TCP Congestion Control
Once a given source has CongWin packets in transit, an ACK arrival signals that one of its packets has left the network
Then it is safe to insert a new packet into the network without adding to the level of congestion
By using ACKs to pace the transmission of packets, TCP is said to be self-clocking.
TCP Congestion Control
We now modify TCP’s effective window MaxWindow = MIN(CongestionWindow, AdvertisedWindow) EffectiveWindow = MaxWindow − (LastByteSent − LastByteAcked)
That is, MaxWindow replaces AdvertisedWindow in the calculation of EffectiveWindow.
7
TCP Congestion Control
If CongWin < AdvertisedWindow, then the rate of the connection is
CongWin is dynamic, function of perceived network congestion
8
rate = CongWin
RTT Bytes/sec
TCP Congestion Control
Great, so how does the sender perceive congestion? Loss event = timeout or 3 duplicate ACKs TCP sender reduces rate (CongWin) after loss
event
9
TCP Congestion Control
Three mechanisms make up TCP congestion control: Additive Increase/Multiplicative Decrease
(AIMD) Slow Start Fast Retransmit and Fast Recovery
10
TCP AIMD
Multiplicative Decrease: Cut CongWin in half after loss
event
Additive increase: Increase CongWin by 1
MSS every RTT in the absence of loss events: probing
8 Kbytes
16 Kbytes
24 Kbytes
time
congestionwindow
Long-lived TCP connection
TCP AIMD
Packets in transit during additive increase, with one packet being added each RTT.
TCP Slow Start
When connection begins, CongWin = 1MSS Example: MSS=500 bytes and RTT = 200 msec Initial rate = 20 Kbps
Available bandwidth may be much greater than MSS/RTT Desirable to quickly ramp up to respectable rate
When connection begins, increase rate exponentially fast until first loss event
13
TCP Slow Start (more)
When connection begins, increase rate exponentially until first loss event: double CongWin every
RTT done by incrementing
CongWin for every ACK received
Summary: initial rate is slow but ramps up exponentially fast
Host A
RTT
Host B
time
Fast Recovery
After 3 dup ACKs: CongWin is cut in half window then grows
linearly But after timeout
event: CongWin instead set to
1 MSS; window then grows
exponentially to a threshold, then
grows linearly
• 3 dup ACKs indicates network capable of delivering some segments • timeout before 3 dup ACKs is “more alarming”
Philosophy:
Fast Recovery
Q: When should the exponential increase switch to linear?
A: When CongWin gets to 1/2 of its value before timeout.
Implementation: Variable Threshold At loss event, Threshold
is set to 1/2 of CongWin just before loss event
Cong
estio
n wi
ndow
Summary: TCP Congestion Control
When CongWin is below Threshold, sender in slow-start phase, window grows exponentially.
When CongWin is above Threshold, sender is in congestion-avoidance phase, window grows linearly.
When a triple duplicate ACK occurs, Threshold set to CongWin/2 and CongWin set to Threshold.
When timeout occurs, Threshold set to CongWin/2 and CongWin is set to 1 MSS.
TCP sender congestion control
CongWin and Threshold not changed
Increment duplicate ACK count for segment being acked
SS or CA Duplicate ACK
Enter slow start Threshold = CongWin/2, CongWin = 1 MSS, Set state to “Slow Start”
SS or CA Timeout
Fast recovery, implementing multiplicative decrease. CongWin will not drop below 1 MSS.
Threshold = CongWin/2, CongWin = Threshold, Set state to “Congestion Avoidance”
SS or CA Loss event detected by triple duplicate ACK
Additive increase, resulting in increase of CongWin by 1 MSS every RTT
CongWin = CongWin+MSS * (MSS/CongWin)
Congestion Avoidance (CA)
ACK receipt for previously unacked data
Resulting in a doubling of CongWin every RTT
CongWin = CongWin + MSS, If (CongWin > Threshold) set state to “Congestion Avoidance”
Slow Start (SS)
ACK receipt for previously unacked data
Commentary TCP Sender Action State Event
TCP throughput
What’s the average throughput of TCP as a function of window size and RTT? Ignore slow start – these phases are typically short
Let W be the window size right before loss occurs.
When window is W, throughput is W/RTT So fast, but cannot last
Just after loss, window drops to W/2, throughput to W/2RTT.
Average throughput: .75 W/RTT
TCP Fairness
Fairness goal: if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/K
TCP connection 1
bottleneck router
capacity R
TCP connection 2
Why is TCP fair?
Two competing sessions: Additive increase gives slope of 1, as throughput increases multiplicative decrease decreases throughput proportionally
R
R
equal bandwidth share
Connection 1 throughput
Connection 2 throughput
congestion avoidance: additive increase loss: decrease window by factor of 2
congestion avoidance: additive increase loss: decrease window by factor of 2
Assumptions: same MSS and RTT, nothing else using link
Fairness (more)
Fairness and UDP Multimedia apps often do
not use TCP do not want rate throttled by
congestion control Instead use UDP:
pump audio/video at constant rate, tolerate packet loss
Research area: congestion control for UDP
Fairness and parallel TCP connections nothing prevents app
from opening parallel connections between 2 hosts.
Web browsers do this Example: link of rate R
supporting 9 connections; new app asks for 1 TCP,
gets rate R/10 new app asks for 11 TCPs,
gets R/2 !
top related