Date post: | 19-Dec-2015 |
Category: |
Documents |
Upload: | camron-elliott |
View: | 221 times |
Download: | 2 times |
CSS432: Congestion Control 1
CSS432 Congestion ControlTextbook Ch6.1 – 6.4
Professor: Munehiro Fukuda
(Augmented by Rob Nash)
CSS432: Congestion Control 2
Taxonomy Resource in network systems
Link bandwidth Buffer size in routers or switches
Two sides of the same coin Pre-allocate resources so as to avoid congestion Control congestion that leads to resource restrictions
Flow control versus congestion control Flow control: to keep a fast sender from overrunning a slow receiver Congestion control: to keep a set of senders from sending two much data into the
network. Two points of implementation
Router Centric QoS-based service Reservation-based Rate-based
Host Centric Best-effort service Feedback-based Window-based
CSS432: Congestion Control 3
Connectionless Flow Datagrams
Switched independently Flowing through a particular set of routers if transmitted from the same source/destination pair
Connectionless Flows Routers
No state if they follow purely connectionless service Hard state if they follow purely connection-oriented service Soft state used to make resource allocation decision for each flow – How?
Router
Source2
Source1
Source3
Router
Router
Destination2
Destination1
CSS432: Congestion Control 4
Congestion in Packet-Switched Network
Source cannot directly observe the traffic on the slow network
A congested link could be assigned a large edge weight by the route propagation protocol
All packets may have to flow through the same (bottleneck) router to the destination.
Destination1.5-Mbps T1 link
Router
Source2
Source1
100-Mbps FDDI
10-Mbps Ethernet
drops off overflowed packets.
CSS432: Congestion Control 5
TCP Congestion Control
Idea Assumes best-effort network (FIFO or FQ routers) Determines network capacity at each source host Uses implicit feedback Uses ACKs to pace packet transmission (self-clocking)
Challenge Determining the available capacity in the first place Adjusting # in-transit packets in response to dynamic
changes in the available capacity
CSS432: Congestion Control 6
Additive Increase/Multiplicative Decrease (AIMD)
New state variable per connection: CongestionWindow Limits how much data source can send: Previously:
EffectiveWindow= AdvertisedWindow – (LastbyteSent - LastByteAcked)
Now:EffectiveWindow= Min( CongestionWindow, AdvertisedWindow) – (LastByteSent – LastByteAcked)
Idea: Increase CongestionWindow when
congestion goes down Decrease CongestionWindow when
congestion goes up
Sending application
LastByteWritten
TCP
LastByteSentLastByteAcked
LastByteSent – LastByteAcked ≤ AdvertisedWindow
EffectiveWindow= AdvertisedWindow – (LastByteSent – LastByteAcked)
y
CSS432: Congestion Control 7
AIMD (cont)
Question: how does the source determine whether or not the network is congested?
Answer: a timeout occurs Timeout signals that a packet was lost Packets are seldom lost due to transmission error Lost packet implies congestion
CSS432: Congestion Control 8
AIMD (cont)
In practice: increment a little for each ACK
Increment = MSS * (MSS/CongestionWindow)CongestionWindow += Increment
Algorithm Increment CongestionWindow by one packet per CW (linear increase) Divide CongestionWindow by two whenever a timeout occurs
(multiplicative decrease)
60
20
1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0
KB
Time (seconds)
70
304050
10
10.0
AI in AIMD too Slow?
Connections just starting up ramp up too slowly and waste resourcesNot doing effective probing, either
We need something faster, that sounds faster:Quick Ramp Up?Fast Start?
CSS432: Congestion Control 9
Slow Start Overview (p481)
Avoids “out of the gate” bursts of windowSize Quicker than a linear increase Begin with CongestionWindow = 1 On timeout, set a threshold == CW/2
This is the multiplicative decrease Set CongestionWindow to 1 and slow start
Then switch to linear once CW >= threshold
CSS432: Congestion Control 10
CSS432: Congestion Control 11
Slow Start
Objective: reach the available capacity as fast as possible
Idea: Begin with CongestionWindow = 1 packet Double CongestionWindow each RTT
(increment by 1 packet for each ACK) When timeout occurs:
Set congestionThreashold to CongestionWindow / 2
Begin with CongestionWindow = 1 packet again Observe slow start with tcpdump in
assignment 3.
Source Destination
…
CSS432: Congestion Control 12
Slow Start (cont) Exponential growth, but slower than all at once Used…
when first starting connection When Nagle’s algorithm is used and packets are lost, (timeout occurs and
the congestion window is already 0) Final Algorithm:
CongestionThreshold = INF While (true) {
CongestionWindow = 1 While ( congestionWindow < congestionThreshold )
CongestionWindow *= 2 (based on slow start, exponential growth) While ( ACK returned )
CongestionWindow++ (based on additive lincrease, linear growth) If timeout occurs,
CongestionThreshold = CongestionWindow / 2 Continue
}
CSS432: Congestion Control 13
Slow Start (cont) Trace:
Problem: lose up to half a CongestionWindow’s worth of data
60
20
1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0
KB
70
304050
10
The actual congestion threshold Congestion windowPackets lost
Timeout
Slow Start Notes Only used at the beginning of a connection or
whenever a timeout occurs Slow Start augments the AI in AIMD
Less time to use more bandwidth after a course-grained timeout
So, our ramp up is steeper Fast Retransmit deals with cumulative ACKS
Avoid waiting for long timeouts
Fast Recovery skips Slow Start avoids “resetting to 1” (the slow start approach) and
just uses CW/2CSS432: Congestion Control 14
CSS432: Congestion Control 15
Fast Retransmit Problem: coarse-grain TCP timeouts
lead to idle periods
Fast retransmit: use duplicate ACKs to trigger retransmission The receiver sends back the same
ACK as the last packet received in the correct sequential order.
The sender retransmits the packet whose ID is one larger than this duplicate ACK, upon receiving three ACKs.
Packet 1
Packet 2
Packet 3
Packet 4
Packet 5
Packet 6
Retransmitpacket 3
ACK 1
ACK 2
ACK 2
ACK 2
ACK 6
ACK 2
Sender Receiver
Duplicate ACK 1
Duplicate ACK 2
Duplicate ACK 3
CSS432: Congestion Control 16
Results
60
20
1.0 2.0 3.0 4.0 5.0 6.0 7.0
KB
70
304050
10
A packet lost
Duplicate Acks allowing to keep transmitting more packet
CongestionWindow is divided in a half upon retransmits rather than timeouts
Too many packets sent
A half of them dropped off
No ACKs returned
CongestionWindow stays in flat
Coarse-grained timeouts
Implications
Congestion Threshold is divided in a half upon retransmits and timeoutsCW = 1We use ACKS and DUP ACKS as our timers
Since these move faster than our internal clocks
A retransmission indicates congestion and we don’t need to wait forever (course timeout) to notice this
CSS432: Congestion Control 17
CSS432: Congestion Control 18
Fast Recovery
Fast recovery skip the slow start phasego directly to half the last successful CongestionWindow (ssthresh)
Below lacks the initial slow start & cg timeouts60
20
1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0
KB
Time (seconds)
70
304050
10
10.0
Chapter 6, Problem 27
Consider the TCP traces…
CSS432: Congestion Control 19
CSS432: Congestion Control 20
Congestion Avoidance TCP’s strategy is Congestion Control, not Avoidance
control congestion once it happens repeatedly increase load in an effort to find the point at which
congestion occurs, and then back off TCP needs to observe losses to find the sweet spot in the bandwidth
Alternative strategy predict when congestion is about to happen reduce rate before packets start being discarded call this congestion avoidance, instead of congestion control
Two possibilities router-centric: RED Gateways
Explanation in the following slides host-centric: TCP Vegas (guess who?)
Compare measured and expected throughput rate, and shrink congestion window if the measured rate is smaller.
CSS432: Congestion Control 21
Summary of TCP VersionsRFC 1122 TCP Tahoe TCP Reno TCP Vegas
RTT Estimation X X X X
Karn’s Algorithm X X X X
Slow Start X X X X
AIMD X X X X
Fast Retransmit X X X
Fast Recovery X X
Throughput-rate congestion control
X
CSS432: Congestion Control 22
Random Early Detection (RED)
Notification is implicit just drop the packet (TCP will timeout)could make explicit by marking the packet
Early random droprather than wait for queue to become full, drop
each arriving packet with some drop probability whenever the queue length exceeds some drop level
Congestion avoidance Global synchronization avoidance
CSS432: Congestion Control 23
RED Details Compute average queue length
AvgLen = (1 - Weight) * AvgLen + Weight * SampleLen
0 < Weight < 1 (usually 0.002)SampleLen is queue length each time a packet arrives
MaxThreshold MinThreshold
AvgLen
CSS432: Congestion Control 24
RED Details (cont) Two queue length thresholds
if AvgLen <= MinThreshold then
enqueue the packet
if MinThreshold < AvgLen < MaxThreshold then
calculate probability P
drop arriving packet with probability P
if MaxThreshold <= AvgLen then
drop arriving packet
CSS432: Congestion Control 25
RED Details (cont) Computing probability P
TempP = MaxP * (AvgLen - MinThreshold)/ (MaxThreshold - MinThreshold)
P = TempP/(1 - count * TempP)
Drop Probability CurveP(drop)
1.0
MaxP
MinThresh MaxThresh
AvgLen
Keep track of how many newly arrivingpackets have been queued while AveLenhas been between the two thresholds
Typically 0.02
Chapter 6, Problem 33
DECbit V.S. RED
Explicit Congestion Avoidance V.S. Implicit Congestion Avoidance
CSS432: Congestion Control 26
CSS432: Congestion Control 27
Reviews Queuing disciplines: FIFO FQ TCP congestion control: AIMD, cold/slow start, and fast
retransmit/fast recovery Congestion avoidance: RED and TCP vegas
Exercises in Chapter 6 Ex. 2 (Avoidance) Ex. 6 (Router congestions) Ex. 25(Slow start) Ex. 27 (AIMD, slow start) Ex. 34 (RED)