congestion control
TRANSCRIPT
CSS432: Congestion Control 1
CSS432 Congestion ControlTextbook Ch6.1 – 6.4
Instructor: Joe McCarthy(based on Prof. Fukuda’s slides)
CSS432: Congestion Control 2
Taxonomy Limited resources in network systems
Link bandwidth Buffer size in routers or switches
Resource allocation & congestion control: 2 sides of same coin Pre-allocate resources so as to avoid congestion Control congestion only when it occurs
Flow control vs. 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 Typically flow through same set of routers if transmitted from the same source to the same
destination Connectionless Flows
Routers & states: No state: purely connectionless service Hard state: purely connection-oriented service Soft state: allocate resources on a per-flow basis
CSS432: Congestion Control 4
Queuing Discipline First-In-First-Out (FIFO) w/ Tail Drop
Does not discriminate between traffic sources (flows) Fair Queuing (FQ)
Work conserving: link is never left idle (if data to be sent) Explicitly segregates traffic based on flows Ensures no flow captures more than its share of capacity
If there are n flows sending data, each is allocated 1/n bandwidth Variation: weighted fair queuing (WFQ)
Problem: Variable packet length
Flow 1
Flow 2
Flow 3
Flow 4
Round-robinservice
H1 R1 R2 R3 H8
ETH IP (1400) FDDI IP (1400) PPP IP (512)
PPP IP (376)
PPP IP (512)
ETH IP (512)
ETH IP (376)
ETH IP (512)
[Section 3.2]
CSS432: Congestion Control 5
Bit-Round Fair Queuing (BRFQ) Algorithm
For each queue, compute the virtual finish time (F) upon arrival of a new packet. Choose a packet with the lowest virtual finish time. No preemption
Pros and Cons Emulates bit-by-bit fair queuing Not perfect: can’t preempt a large packet currently being transmitted
Example of fair queuing in action: (a) packets with earlier finishing timesare sent first; (b) sending of a packet already in progress is completed
CSS432: Congestion Control 6
TCP Congestion Control Created by Van Jacobson, 1980s,
~8 years after TCP/IP protocol stack became operational
Immediately preceding this time, 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 packets
to be dropped), and the hosts would time out hosts retransmit their packets, resulting in even more
congestion
CSS432: Congestion Control 7
TCP Congestion Control
Concept: 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 # of in-transit packets in response to dynamic
changes in the available capacity
CSS432: Congestion Control 8
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 deceases Decrease CongestionWindow when
congestion increases
Sending application
LastByteWritten
TCP
LastByteSentLastByteAcked
LastByteSent – LastByteAcked ≤ AdvertisedWindow
EffectiveWindow= AdvertisedWindow – (LastByteSent – LastByteAcked)
y
Options (variable)
Data
Checksum
SrcPort DstPort
HdrLen 0 Flags
UrgPtr
AdvertisedWindow
SequenceNum
Acknowledgment
0 4 10 16 31
CSS432: Congestion Control 9
AIMD (cont)
Question: how does the source determine whether or not the network is congested?
CSS432: Congestion Control 10
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 11
AIMD (cont)
In practice: increment a little for each ACK
Increment = MSS * (MSS/CongestionWindow)CongestionWindow += Increment
Algorithm Increment CongestionWindow by 1 packet per RTT (additive increase) Divide CongestionWindow by 2 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
Co
ng
est
ion
Win
do
w S
ize
CSS432: Congestion Control 12
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 13
Slow Start 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 = INFwhile (true) {
CongestionWindow = 1while ( CongestionWindow < CongestionThreshold )
CongestionWindow *= 2 (based on slow start, exponential growth)while ( ACK returned )
CongestionWindow++ (based on additive increase, linear growth)if timeout occurs,
CongestionThreshold = CongestionWindow / 2Continue
}
CSS432: Congestion Control 14
Slow Start Trace:
Where: Colored line = value of CongestionWindow Solid bullets at top = timeouts Hash marks = time when each packet is transmitted Vertical bars = time when a packet that was eventually retransmitted (i.e.,
was lost) was first transmitted
60
20
1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0
KB
70
304050
10
CSS432: Congestion Control 15
Slow Start
http://www.6test.edu.cn/~lujx/linux_networking/0131777203_ch24lev1sec4.html
CSS432: Congestion Control 16
Slow Start 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
CSS432: Congestion Control 17
Fast Retransmit (TCP Tahoe) Problem: coarse-grained 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 3 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 18
Effect of Fast Retransmit
60
20
1.0 2.0 3.0 4.0 5.0 6.0 7.0
KB
70
304050
10
60
20
1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0
KB
70
304050
10
CSS432: Congestion Control 19
Effect of Fast Retransmit
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 allow transmission of more packets
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 flat (no increase)
Coarse-grained timeouts
CSS432: Congestion Control 20
Fast Recovery (TCP Reno)
Fast recoveryskip the slow start phasego directly to half the last successful CongestionWindow (ssthresh)
CSS432: Congestion Control 21
Congestion
CSS432: Congestion Control 22
Congestion Avoidance TCP’s strategy: congestion control
control congestion after it happens repeatedly increase load in an effort to find the point at which
congestion occurs, and then back off
Alternative strategy: congestion avoidance predict when congestion is about to happen reduce rate before packets start being discarded
Two possibilities router-centric: RED Gateways
Explanation in the following slides host-centric: TCP Vegas
Compare measured and expected throughput rate, and shrink congestion window if the measured rate is smaller.
CSS432: Congestion Control 23
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 24
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 25
RED Details Detect / respond to long-lived congestion (vs. short bursts)
Low-pass filter 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
CSS432: Congestion Control 26
RED Details (cont) Two queue length thresholds
if AvgLen <= MinThreshold then
enqueue the packet
else if AvgLen >= MaxThreshold then
drop arriving packet
else // MinThreshold < AvgLen < MaxThreshold
calculate probability P
drop arriving pack with probability P
CSS432: Congestion Control 27
RED Details (cont) Computing probability P
TempP = MaxP * (AvgLen - MinThreshold) / (MaxThreshold - MinThreshold)
P = TempP / (1 - count * TempP)
Drop Probability CurveKeep track of how many newly arrivingpackets have been queued while AvgLenhas remained between the 2 thresholds
Typically 0.02
Typically:• MaxThreshold = MinThreshold * 2• MaxThreshold < MaxBuffer
CSS432: Congestion Control 28
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)
Exercise 2
TCP uses a host-centric, feedback-based, window-based resource allocation model. How might TCP have been designed to use instead the following models:(a) Host-centric, feedback-based and rate-
based.(b) Router-centric and feedback-based.
CSS432: Congestion Control 29
Exercise 6
Consider the arrangement of hosts H and routers R and R1 in Figure 6.27. All links are full-duplex, and all routers are faster than their links. Show that R1 cannot become congested and for any other router R, we can find a traffic pattern that congests that router alone.
CSS432: Congestion Control 30
Exercise 25
You are an Internet Service Provider; your client hosts connect directly to your routers. You know some hosts are using experimental TCPs and suspect some may be using a “greedy” TCP with no congestion control.
What measurements might you make at your router to establish that a client was not using a slow start at all?
If a client used slow start on startup but not after a timeout, could you detect that?
CSS432: Congestion Control 31
CSS432: Congestion Control 32
27. Consider the TCP trace in Figure 6.28. Identify time intervals representing slow start on startup, slow start after timeout, and linear-increase congestion avoidance. Explain what is going on from T=0.5 to T=1.9. The TCP version that generated this trace includes a feature absent from the TCP that generated Figure 6.11. What is this feature? This trace and the one in Figure 6.13 both lack a feature. What is it?
Figure 6.28
Figure 6.11
Figure 6.13
Exercise 34
Consider a RED gateway with MaxP = 0.01 and with an average queue length halfway between the two thresholdsFind the drop probability Pcount for count = 1
and count = 100Calculate the probability that none of the first
50 packets is dropped. Note that this is (1 – P1) * … * (1 – P50)
CSS432: Congestion Control 33