1. CSS432 Congestion Control Textbook Ch6.1 – 6.4
Prof. Athirai Irissappane
CSS432: Congestion Control

2. CSS432: Congestion Control
Taxonomy
Network Congestion:
Too many packets in the network (more than its capacity)
Too many packets in the switch/router buffer
Congestion control is closely related to resource allocation
How many packets can be sent in the network at a time
Can the switch handle requests from many hosts
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.
CSS432: Congestion Control

3. Taxonomy of resource allocation mechanisms
Router Centric:
Router makes decisions about resource allocation
When to forward, drop packets
Inform hosts how many packets can be sent to them
Host Centric:
Host makes decisions
Observe network conditions and adjust
E.g., advertised window
Reservation-based
Reserve necessary resources prior to transmission
Host can reserve capacity in the network for transmission
Feedback-based
No prior reservation
Host send data without reserving then adjust sending rate based on observation
Rate Based Limit Transmission rate
Window Based Advertised Window
Router Centric
QoS-based service
(guarantees QOS)
Reservation-based
Rate-based
Host Centric
Best-effort service
(no QOS guarantee)
Feedback-based
Window-based
CSS432: Congestion Control

4. CSS432: Congestion Control
Connectionless Flow
Datagrams
No connection
Switched independently
Flowing through a particular set of routers if transmitted from the same source/destination pair
Connectionless Flows
maintain state information of each flow at router for better resource allocation decisions: e.g., what should be done to the packets of the same flow
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
Source 2 1 3
Destination
CSS432: Congestion Control

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

6. 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 – Cannot interrupt a transmitting packet
A new packet with shorter F than a waiting (large) packet will be transmitted first
F = S (Start time) + P (Packet length)
StartTime = Max(F_prev, Arrival Time)
Clock ticks for one bit transmitted
Pros and Cons
Emulates bit-by-bit fair queuing
Not perfect: can’t preempt a large packet currently being transmitted
Virtual finish time: router finishes transmitting the packet
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

7. 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.
Destination
1.5-Mbps T1 link
Router
Source 2 1
100-Mbps FDDI
10-Mbps Ethernet
FQ or BRFQ drops off overflowed packets.
CSS432: Congestion Control

8. 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

9. TCP Congestion Control
Idea
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
Increase in capacity?
CSS432: Congestion Control

10. Additive Increase/Multiplicative Decrease (AIMD)
New state variable per TCP 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 goes down
Decrease CongestionWindow when congestion goes up
Sending application
LastByteWritten
TCP
LastByteSent
LastByteAcked
LastByteSent – LastByteAcked ≤ AdvertisedWindow
EffectiveWindow
= AdvertisedWindow – (LastByteSent – LastByteAcked) y
CSS432: Congestion Control

11. 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

12. AIMD (cont) Algorithm Divide CongestionWindow by 2 whenever
a timeout occurs(halved) (multiplicative decrease)
Increment CongestionWindow by
1 packet per RTT (linear increase)
If all packets (of congestion window) sent are ACKed increment window by 1
In practice: increment a little for each ACK
Increment = MSS * (MSS/CongestionWindow)
CongestionWindow += Increment
Source
Destination …

13. AIMD (cont)
Congestion
Window 60 20
1.0
2.0
3.0
4.0
5.0
6.0
7.0
8.0
9.0 KB
Time (seconds) 70 30 40 50 10
10.0
Saw Tooth
Window increases at slower rate and decreases at a faster rate

14. 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/packet loss:
Set congestionThreashold to CongestionWindow / 2
Begin with CongestionWindow = 1 packet again
CSS432: Congestion Control

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

16. CSS432: Congestion Control
Slow Start
Exponential growth, but slower than all at once
Used…
when first starting connection (do not know anything about network)
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

17. CSS432: Congestion Control
Slow Start (cont) 60 20
1.0
2.0
3.0
4.0
5.0
6.0
7.0
8.0
9.0
Congestion Window KB 70 30 40 50 10
congestion
Multiplicative decrement
Multiplicative decrement
congestion
Additive increase
Slow start
on startup
Additive increase
Slow start after timeout
CSS432: Congestion Control

18. CSS432: Congestion Control
Slow Start (cont)
Trace:
Flat out: Packets lost and no ACKs arrive (Timer running)
Problem: lose up to half a CongestionWindow’s worth of data
Capacity 16packets, first time send 16packets and receive ACK
Double congestion window (drop 16 packets) 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

19. CSS432: Congestion Control
Fast Retransmit
Sender
Receiver
Packet 1
Packet 2
Problem: coarse-grain TCP timeouts lead to idle periods
If no retransmit:
Say window full after Packet 6, When ACK 2 arrives, no action is taken, wait for time out and retransmit Packet 3 (idle period)
ACK for 1
Packet 3
Packet 4
ACK for 2
Duplicate
Packet 5
ACK for 2
Packet 6
Duplicate
ACK for 2
ACK for 2
Duplicate
Time Out
Retransmit
packet 3
ACK for 6
CSS432: Congestion Control

20. CSS432: Congestion Control
Fast Retransmit
Sender
Receiver
Packet 1
Packet 2
Problem: coarse-grain (use timer) 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.
ACK 1
Packet 3
Packet 4
ACK 2
Duplicate ACK 1
Packet 5
ACK 2
Packet 6
ACK 2
Duplicate ACK 2
ACK 2
Duplicate ACK 3
Time Out
Retransmit
packet 3
Since TCP does not know whether a duplicate ACK is caused by a lost segment or just a reordering of segments, it waits for a small number of duplicate ACKs to be received. It is assumed that if there is just a reordering of the segments, there will be only one or two duplicate ACKs before the reordered segment is processed, which will then generate a new ACK. If three or more duplicate ACKs are received in a row, it is a strong indication that a segment has been lost.
ACK 6
CSS432: Congestion Control

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

22. CSS432: Congestion Control
Fast Recovery
Fast recovery
skip the slow start phase
go directly to half the last successful CongestionWindow (threshold)
Slow start
Only at beginning
Coarse timeout occurs
CSS432: Congestion Control

23. CSS432: Congestion Control
Congestion Avoidance
TCP’s strategy
control congestion once it happens
repeatedly increase load in an effort to find the point at which congestion occurs, and then back off
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
Compare measured and expected throughput rate, and shrink congestion window if the measured rate is smaller.
Throughput = number of bytes outstanding in the network/RTT, as packets queue up before causing congestion, RTT is going to increase and throughput is going to decrease
CSS432: Congestion Control

24. Random Early Detection (RED)
Job of congestion control - router
Router notifies host
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
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 A
vgLen
CSS432: Congestion Control

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

27. RED Details (cont) Computing probability P Drop Probability Curve
TempP = MaxP * (AvgLen - MinThreshold)/ (MaxThreshold - MinThreshold)
P = TempP/(1 - count * TempP)
Drop Probability Curve
P increases between min thresholg and max Threshold
Sharply increases to 1 for MaxThreshold
Typically 0.02
Keep track of how many newly arriving
packets have been queued while AveLen
has been between the two thresholds
P(drop)
1.0
MaxP
MinThresh
MaxThresh A
vgLen

28. 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
Linux – TCP cubic
CSS432: Congestion Control

29. 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