122 TCP Congestion Control Ion Stoica TAs Junda Liu DK Moon David Zats http insteecsberkeleyeduee122 Materials with thanks to Vern Paxson Jennifer Rexford and colleagues at UC Berkeley ID: 532765
Download Presentation The PPT/PDF document "1 EE" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
1
EE 122:TCP Congestion Control
Ion StoicaTAs: Junda Liu, DK Moon, David Zatshttp://inst.eecs.berkeley.edu/~ee122/(Materials with thanks to Vern Paxson, Jennifer Rexford,and colleagues at UC Berkeley)Slide2
2
Goals of Today’s LecturePrinciples of congestion control
Learning that congestion is occurringAdapting to alleviate the congestionTCP congestion controlAdditive-increase, multiplicative-decrease (AIMD)How to begin transmitting: Slow StartSlide3
3
What We KnowWe know:
How to process packets in a switchHow to route packets in the networkHow to send packets reliablyWe don’t know:How fast to sendSlide4
4
It’s Not Just The Sender & ReceiverFlow control
keeps one fast sender from overwhelming a slow receiverCongestion control keeps a set of senders from overloading the networkThree congestion control problems:Adjusting to bottleneck bandwidthWithout any a priori knowledgeCould be a Gbps link; could be a modemAdjusting to variations in bandwidthSharing bandwidth between flowsSlide5
5
Congestion is Unavoidable
Two packets arrive at the same timeThe node can only transmit one… and either buffers or drops the otherIf many packets arrive in a short period of timeThe node cannot keep up with the arriving traffic… and the buffer may eventually overflowSlide6
6
Congestion Collapse
Definition: Increase in network load results in a decrease of useful work doneDue to:Undelivered packetsPackets consume resources and are dropped later in networkSpurious retransmissions of packets still in flightUnnecessary retransmissions lead to more load!Pouring gasoline on a fireMid-1980s: Internet grinds to a haltUntil Jacobson/Karels (Berkeley!) devise TCP congestion controlSlide7
7
View from a Single Flow
Knee – point after which Throughput increases very slowlyDelay increases quicklyCliff – point after whichThroughput starts to decrease very fast to zero (congestion collapse)Delay approaches infinity
Load
Load
Throughput
Delay
knee
cliff
congestion
collapse
packet
lossSlide8
8
General ApproachesSend without care
Many packet drops(1) ReservationsPre-arrange bandwidth allocationsRequires negotiation before sending packetsLow utilization(2) PricingDon’t drop packets for the high-biddersRequires payment modelSlide9
9
General Approaches (cont’d)(3) Dynamic Adjustment
Probe network to test level of congestionSpeed up when no congestionSlow down when congestionSuboptimal, messy dynamics, simple to implementAll three techniques have their placeBut for generic Internet usage, dynamic adjustment is the most appropriateDue to pricing structure, traffic characteristics, and good citizenshipSlide10
10
TCP Congestion ControlTCP connection has window
Controls number of unacknowledged packetsSending rate: ~Window/RTTVary window size to control sending rateSlide11
11
Sizing the Windows
cwnd (Congestion Windows) How many bytes can be sent without overflowing routersComputed by congestion control algorithmAdvertisedWindow How many bytes can be sent without overflowing the senderDetermined by the receiverSlide12
12
EffectiveWindow
Limits how much data can be in transitImplemented as # of bytesDescribed as # packets (segments) in this lecture
EffectiveWindow
= MaxWindow – (LastByteSent – LastByteAcked)
MaxWindow = min(cwnd, AdvertisedWindow)
LastByteAcked
LastByteSent
sequence number increases
MaxWindow
EffectiveWindowSlide13
13
Two Basic ComponentsDetecting congestion
Rate adjustment algorithmDepends on congestion or notThree subproblems within adjustment problemFinding fixed bandwidthAdjusting to bandwidth variationsSharing bandwidthSlide14
14
Detecting CongestionPacket dropping is best sign of congestion
Delay-based methods are hard and riskyHow do you detect packet drops? ACKsTCP uses ACKs to signal receipt of dataACK denotes last contiguous byte receivedActually, ACKs indicate next segment expectedTwo signs of packet dropsNo ACK after certain time interval: time-outSeveral duplicate ACKs (ignore for now)Slide15
15
Rate AdjustmentBasic structure:
Upon receipt of ACK (of new data): increase rateUpon detection of loss: decrease rateBut what increase/decrease functions should we use?Depends on what problem we are solvingSlide16
16
Problem #1: Single Flow, Fixed BW
Want to get a first-order estimate of the available bandwidthAssume bandwidth is fixedIgnore presence of other flowsWant to start slow, but rapidly increase rate until packet drop occurs (“slow-start”)Adjustment: cwnd initially set to 1cwnd++ upon receipt of ACK Slide17
17
Slow-Start
cwnd increases exponentially: cwnd doubles every time a full cwnd of packets has been sentEach ACK releases two packetsSlow-start is called “slow” because of starting point
segment 1
cwnd = 1
cwnd = 2
segment 2
segment 3
cwnd = 4
segment 4
segment 5
segment 6
segment 7
cwnd = 8
cwnd = 3Slide18
18
5 Minute BreakQuestions Before We Proceed?Slide19
19
Problems with Slow-StartSlow-start can result in many losses
Roughly the size of cwnd ~ BW*RTTExample:At some point, cwnd is enough to fill “pipe”After another RTT, cwnd is double its previous valueAll the excess packets are dropped!Need a more gentle adjustment algorithm once have rough estimate of bandwidthSlide20
20
Problem #2: Single Flow, Varying BW
Want to be able to track available bandwidth, oscillating around its current valuePossible variations: (in terms of RTTs)Multiplicative increase or decrease: cwnd a*cwndAdditive increase or decrease: cwnd cwnd + bFour alternatives:AIAD: gentle increase, gentle decreaseAIMD: gentle increase, drastic decreaseMIAD: drastic increase, gentle decrease (too many losses)MIMD: drastic increase and decreaseSlide21
21
Problem #3: Multiple FlowsWant steady state to be “fair”
Many notions of fairness, but here all we require is that two identical flows end up with the same bandwidthThis eliminates MIMD and AIADAIMD is the only remaining solution!Slide22
22
Buffer and Window Dynamics
No congestion x increases by one packet/RTT every RTTCongestion decrease x by factor 2A
B
C = 50 pkts/RTT
xSlide23
23
AIMD Sharing Dynamics
AB
x
1
D
E
No congestion
rate increases by one packet/RTT every RTT
Congestion
decrease rate by factor 2
Rates equalize
fair share
x
2Slide24
24
AIAD Sharing Dynamics
AB
x
1
D
E
No congestion
x increases by one packet/RTT every RTT
Congestion
decrease x by 1
x
2Slide25
25
Efficient Allocation: Challenges of Congestion Control
Too slowFail to take advantage of available bandwidth underloadToo fastOvershoot knee overload, high delay, lossEveryone’s doing itMay all under/over shoot large oscillationsOptimal:xi=
X
goal
Efficiency = 1 - distance from efficiency line
User 1: x
1
User 2: x
2
Efficiency
line
2 user example
overload
underloadSlide26
26
Example
User 1: x1User 2: x2
fairness
line
efficiency
line
1
1
Total bandwidth 1
Inefficient:
x
1
+x
2
=0.7
(0.2, 0.5)
Congested:
x
1
+x
2
=1.2
(0.7, 0.5)
Efficient
:
x
1
+x
2
=1
Not fair
(0.7, 0.3)
Efficient
:
x
1
+x
2
=1
Fair
(0.5, 0.5)Slide27
27
MIAD
User 1: x1User 2: x2
fairness
line
efficiency
line
(x
1h
,x
2h
)
(x
1h
-a
D
,x
2h
-a
D
)
(b
I
(x
1h
-a
D
), b
I
(x
2h
-a
D
))
Increase:
x*b
I
Decrease:
x - a
D
Does not converge to fairness
Does not converges to efficiencySlide28
28
AIAD
User 1: x1User 2: x2
fairness
line
efficiency
line
(x
1h
,x
2h
)
(x
1h
-a
D
,x
2h
-a
D
)
(x
1h
-a
D
+a
I
),
x
2h
-a
D
+a
I
))
Increase:
x + a
I
Decrease:
x - a
D
Does not converge to fairness
Does not converge to efficiencySlide29
29
MIMD
User 1: x1User 2: x2
fairness
line
efficiency
line
(x
1h
,x
2h
)
(b
d
x
1h
,b
d
x
2h
)
(b
I
b
D
x
1h
,
b
I
b
D
x
2h
)
Increase:
x*b
I
Decrease:
x*b
D
Does not converge to fairness
Converges to efficiency iffSlide30
30
(b
Dx1h+aI
,
b
D
x
2h
+a
I
)
AIMD
User 1: x
1
User 2: x
2
fairness
line
efficiency
line
(x
1h
,x
2h
)
(b
D
x
1h
,b
D
x
2h
)
Increase:
x+a
D
Decrease:
x*b
D
Converges to fairness
Converges to efficiency
Increments smaller as fairness increasesSlide31
31
Implementing AIMDAfter each ACK
Increment cwnd by 1/cwnd (cwnd += 1/cwnd)As a result, cwnd is increased by one only if all segments in a cwnd have been acknowledged But need to decide when to leave slow-start and enter AIMDUse ssthresh variable Slide32
32
Slow Start/AIMD Pseudocode
Initially: cwnd = 1; ssthresh = infinite;New ack received: if (cwnd < ssthresh)
/* Slow Start*/
cwnd = cwnd + 1;
else
/* Congestion Avoidance */
cwnd = cwnd + 1/cwnd;
Timeout:
/* Multiplicative decrease */
ssthresh = cwnd/2;
cwnd = 1;Slide33
33
The big picture (with timeouts)
Time
cwnd
Timeout
Slow
Start
AIMD
ssthresh
Timeout
Slow
Start
Slow
Start
AIMDSlide34
34
SummaryCongestion is inevitable
Internet does not reserve resources in advanceTCP actively tries to grab capacityCongestion control critical for avoiding collapseAIMD: Additive Increase, Multiplicative DecreaseCongestion detected via packet loss (fail-safe)Slow start to find initial sending rate & to restart after timeoutNext classAdvanced congestion control