1. CSS432 Congestion Control Textbook Ch6.1 – 6.4
Instructor: Joe McCarthy (based on Prof. Fukuda’s slides)
CSS432: Congestion Control

2. CSS432: Congestion Control
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. CSS432: Congestion Control
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. CSS432: Congestion Control
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-robin
service
[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 times
are 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:
= Min( CongestionWindow, AdvertisedWindow )
– (LastByteSent – LastByteAcked)
Idea:
Increase CongestionWindow when congestion deceases
Decrease CongestionWindow when congestion increases
Sending application
LastByteWritten
TCP
LastByteSent
LastByteAcked
LastByteSent – LastByteAcked ≤ AdvertisedWindow
EffectiveWindow
= AdvertisedWindow – (LastByteSent – LastByteAcked) y
CSS432: Congestion Control

9. CSS432: Congestion Control
AIMD (cont)
Question: how does the source determine whether or not the network is congested?
CSS432: Congestion Control

10. CSS432: Congestion Control
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. CSS432: Congestion Control
AIMD (cont)
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 T
ime (seconds) 70 30 40 50 10
10.0
CongestionWindow Size
In practice: increment a little for each ACK
Increment = MSS * (MSS/CongestionWindow)
CongestionWindow += Increment
CSS432: Congestion Control

12. CSS432: Congestion Control
Slow Start
Source
Destination …
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.
CSS432: Congestion Control

13. CSS432: Congestion Control
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 = INF
while (true) {
CongestionWindow = 1
while ( 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 / 2
Continue }
CSS432: Congestion Control

14. CSS432: Congestion Control
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 30 40 50 10
CSS432: Congestion Control

15. CSS432: Congestion Control
Slow Start
CSS432: Congestion Control

16. CSS432: Congestion Control
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 30 40 50 10
Timeout
Packets lost
The actual congestion threshold
Congestion window
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
Retransmit
packet 3
ACK 1
ACK 2
ACK 6
Sender
Receiver
Duplicate ACK 1
Duplicate ACK 2
Duplicate ACK 3
CSS432: Congestion Control

18. Effect of Fast Retransmit60 20
1.0
2.0
3.0
4.0
5.0
6.0
7.0
8.0
9.0 KB 70 30 40 50 10 70 60 50 40 KB 30 20 10
1.0
2.0
3.0
4.0
5.0
6.0
7.0
CSS432: Congestion Control

19. Effect of Fast Retransmit
Too many packets sent
A half of them dropped off
No ACKs returned
CongestionWindow stays flat (no increase)
Coarse-grained timeouts
A packet lost
Duplicate ACKs allow transmission of more packets
CongestionWindow is divided in a half upon retransmits rather than timeouts 70 60 50 40 KB 30 20 10
1.0
2.0
3.0
4.0
5.0
6.0
7.0
CSS432: Congestion Control

20. Fast Recovery (TCP Reno)
skip the slow start phase
go directly to half the last successful CongestionWindow (ssthresh)
CSS432: Congestion Control

21. CSS432: Congestion Control

22. CSS432: Congestion Control
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 Versions
RFC 1122
TCP Tahoe
TCP Reno
TCP Vegas
RTT Estimation X
Karn’s Algorithm
Slow Start
AIMD
Fast Retransmit
Fast Recovery
Throughput-rate congestion control
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 drop
rather 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. CSS432: Congestion Control
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. CSS432: Congestion Control
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. CSS432: Congestion Control
RED Details (cont)
Computing probability P
TempP = MaxP * (AvgLen - MinThreshold) / (MaxThreshold - MinThreshold)
P = TempP / (1 - count * TempP)
Drop Probability Curve
Typically 0.02
Keep track of how many newly arriving
packets have been queued while AvgLen
has remained between the 2 thresholds
Typically:
MaxThreshold = MinThreshold * 2
MaxThreshold < MaxBuffer
CSS432: Congestion Control

28. CSS432: Congestion Control
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)
CSS432: Congestion Control

29. CSS432: Congestion Control
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

30. CSS432: Congestion Control
Exercise 6
Consider the arrangement of hosts H and routers R and R1 in Figure 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

31. CSS432: Congestion Control
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

32. CSS432: Congestion Control
27. Consider the TCP trace in Figure 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 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
CSS432: Congestion Control

33. CSS432: Congestion Control
Exercise 34
Consider a RED gateway with MaxP = 0.01 and with an average queue length halfway between the two thresholds
Find the drop probability Pcount for count = 1 and count = 100
Calculate the probability that none of the first 50 packets is dropped. Note that this is (1 – P1) * … * (1 – P50)
CSS432: Congestion Control