EECS 122: Introduction to Computer Networks Congestion Control

1
EECS 122 Introduction to Computer Networks
Congestion Control

• Computer Science Division
• Department of Electrical Engineering and Computer
  Sciences
• University of California, Berkeley
• Berkeley, CA 94720-1776

2
What We Know

• We know
• How to process packets in a switch
• How to route packets in the network
• How to send packets reliably
• We dont know
• How fast to send

"As we know, there are known knowns. There are
things we know we know. We also know there are
known unknowns. That is to say, we know there are
some things we do not know. But there are also
unknown unknowns, the ones we don't know we
don't know." The Zen of Donald Rumsfeld.
3
Implications

• Send too slow link is not fully utilized
• Wastes time
• Send too fast link is fully utilized but....
• Queue builds up in router buffer (delay)
• Overflow buffers in routers
• Overflow buffers in receiving host (ignore)
• Why are buffer overflows a problem?
• Packet drops (mine and others)
• Interesting history....(Van Jacobson rides to the
  rescue)

4
Abstract View

• Ignore internal structure of router and model it
  as having a single queue for a particular
  input-output pair

Receiving Host
Sending Host
Buffer in Router
5
Three Congestion Control Problems

• Adjusting to bottleneck bandwidth
• Adjusting to variations in bandwidth
• Sharing bandwidth between flows

6
Single Flow, Fixed Bandwidth

• Adjust rate to match bottleneck bandwidth
• Without any a priori knowledge
• Could be gigabit link, could be a modem

100 Mbps
7
Single Flow, Varying Bandwidth

• Adjust rate to match instantaneous bandwidth
• Assuming you have rough idea of bandwidth

BW(t)
8
Multiple Flows

• Two Issues
• Adjust total sending rate to match bandwidth
• Allocation of bandwidth between flows

9
Reality
Congestion control is a resource allocation
problem involving many flows, many links, and
complicated global dynamics
10
Whats Really Happening?View from a Single Flow
packet loss
knee
cliff

• Knee point after which
• Throughput increases very slow
• Delay increases fast
• Cliff point after which
• Throughput starts to decrease very fast to zero
  (congestion collapse)
• Delay approaches infinity
• Note (in an M/M/1 queue)
• Delay 1/(1 utilization)

Throughput
congestion collapse
Load
Delay
Load
11
General Approaches

• Send without care
• Many packet drops
• Not as stupid as it seems
• Reservations
• Pre-arrange bandwidth allocations
• Requires negotiation before sending packets
• Low utilization
• Pricing
• Dont drop packets for the high-bidders
• Requires payment model

12
General Approaches (contd)

• Dynamic Adjustment
• Probe network to test level of congestion
• Speed up when no congestion
• Slow down when congestion
• Suboptimal, messy dynamics, simple to implement
• All three techniques have their place
• But for generic Internet usage, dynamic
  adjustment is the most appropriate
• Due to pricing structure, traffic
  characteristics, and good citizenship

13
TCP Congestion Control

• TCP connection has window
• Controls number of unacknowledged packets
• Sending rate Window/RTT
• Vary window size to control sending rate

14
Congestion Window (cwnd)

• Limits how much data can be in transit
• Implemented as of bytes
• Described as packets in this lecture

MaxWindow min(cwnd, AdvertisedWindow)
EffectiveWindow MaxWindow (LastByteSent
LastByteAcked)
MaxWindow
LastByteAcked
EffectiveWindow
LastByteSent
sequence number increases
15
Two Basic Components

• Detecting congestion
• Rate adjustment algorithm
• Depends on congestion or not
• Three subproblems within adjustment problem
• Finding fixed bandwidth
• Adjusting to bandwidth variations
• Sharing bandwidth

16
Detecting Congestion

• Packet dropping is best sign of congestion
• Delay-based methods are hard and risky
• How do you detect packet drops? ACKs
• TCP uses ACKs to signal receipt of data
• ACK denotes last contiguous byte received
• Actually, ACKs indicate next segment expected
• Two signs of packet drops
• No ACK after certain time interval time-out
• Several duplicate ACKs (ignore for now)

17
Rate Adjustment

• Basic structure
• Upon receipt of ACK (of new data) increase rate
• Upon detection of loss decrease rate
• But what increase/decrease functions should we
  use?
• Depends on what problem we are solving

18
Problem 1 Single Flow, Fixed BW

• Want to get a first-order estimate of the
  available bandwidth
• Assume bandwidth is fixed
• Ignore presence of other flows
• Want to start slow, but rapidly increase rate
  until packet drop occurs (slow-start)
• Adjustment
• cwnd initially set to 1
• cwnd upon receipt of ACK

19
Slow-Start

• cwnd increases exponentially cwnd doubles every
  time a full cwnd of packets has been sent
• Each ACK releases two packets
• Slow-start is called slow because of starting
  point

segment 1
cwnd 1
cwnd 2
segment 2
segment 3
cwnd 3
cwnd 4
segment 4
segment 5
segment 6
segment 7
cwnd 8
20
Problems with Slow-Start

• Slow-start can result in many losses
• Roughly the size of cwnd BWRTT
• Example
• At some point, cwnd is enough to fill pipe
• After another RTT, cwnd is double its previous
  value
• All the excess packets are dropped!
• Need a more gentle adjustment algorithm once have
  rough estimate of bandwidth

21
Problem 2 Single Flow, Varying BW

• Want to be able to track available bandwidth,
  oscillating around its current value
• Possible variations (in terms of RTTs)
• Multiplicative increase or decrease cwnd? acwnd
• Additive increase or decrease cwnd? cwnd b
• Four alternatives
• AIAD gentle increase, gentle decrease
• AIMD gentle increase, drastic decrease
• MIAD drastic increase, gentle decrease (too many
  losses)
• MIMD drastic increase and decrease

22
Problem 3 Multiple Flows

• Want steady state to be fair
• Many notions of fairness, but here all we require
  is that two identical flows end up with the same
  bandwidth
• This eliminates MIMD and AIAD
• AIMD is the only remaining solution!

23
Buffer and Window Dynamics
x
C 50 pkts/RTT

• No congestion ? x increases by one packet/RTT
  every RTT
• Congestion ? decrease x by factor 2

24
AIMD Sharing Dynamics
x
A
B
y
D
E

• No congestion ? rate increases by one packet/RTT
  every RTT
• Congestion ? decrease rate by factor 2

Rates equalize ? fair share
25
AIAD Sharing Dynamics
x
A
B
y
D
E

• No congestion ? x increases by one packet/RTT
  every RTT
• Congestion ? decrease x by 1

26
Efficient Allocation

• Too slow
• Fail to take advantage of available bandwidth ?
  underload
• Too fast
• Overshoot knee ? overload, high delay, loss
• Everyones doing it
• May all under/over shoot ? large oscillations
• Optimal
• ?xiXgoal
• Efficiency 1 - distance from efficiency line

2 user example
overload
User 2 x2
Efficiency line
underload
User 1 x1
27
AIMD
28
AIAD
29
Multiplicative Increase, Additive Decrease
fairness line

• Does not converge to fairness
• Not stable at all
• Does not converges to efficiency
• Stable iff

(x1h,x2h)
User 2 x2
efficiency line
User 1 x1
30
Additive Increase, Additive Decrease
fairness line

• Does not converge to fairness
• Stable
• Does not converge to efficiency
• Stable iff

(x1h,x2h)
User 2 x2
efficiency line
User 1 x1
31
Multiplicative Increase, Multiplicative Decrease
fairness line

• Does not converge to fairness
• Stable
• Converges to efficiency iff

(x1h,x2h)
User 2 x2
efficiency line
User 1 x1
32
Additive Increase, Multiplicative Decrease
fairness line
(x1h,x2h)

• Converges to fairness
• Converges to efficiency
• Increments smaller as fairness increases
• effect on metrics?

User 2 x2
efficiency line
User 1 x1
33
Implementing AIMD

• After 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 AIMD
• Use ssthresh variable

34
Slow Start/AIMD Pseudocode

• Initially
• cwnd 1
• ssthresh infinite
• New ack received
• if (cwnd lt ssthresh)
• / Slow Start/
• cwnd cwnd 1
• else
• / Congestion Avoidance /
• cwnd cwnd 1/cwnd
• Timeout
• / Multiplicative decrease /
• ssthresh cwnd/2
• cwnd 1

35
The big picture (with timeouts)
cwnd
Timeout
Timeout
AIMD
AIMD
ssthresh
SlowStart
SlowStart
SlowStart
Time
36
Congestion Detection Revisited

• Wait for Retransmission Time Out (RTO)
• RTO kills throughput
• In BSD TCP implementations, RTO is usually more
  than 500ms
• The granularity of RTT estimate is 500 ms
• Retransmission timeout is RTT 4
  mean_deviation
• Solution Dont wait for RTO to expire

37
Fast Retransmits

• Resend a segment after 3 duplicate ACKs
• Duplicate ACK means that an out-of sequence
  segment was received
• Notes
• ACKs are for next expected packet
• Packet reordering can cause duplicate ACKs
• Window may be too small to get enough duplicate
  ACKs

ACK 2
cwnd 2
segment 2
segment 3
ACK 3
ACK 4
cwnd 4
segment 4
segment 5
segment 6
segment 7
ACK 4
3 duplicate ACKs
ACK 4
ACK 4
38
Fast Recovery After a Fast Retransmit

• ssthresh cwnd / 2
• cwnd ssthresh
• instead of setting cwnd to 1, cut cwnd in half
  (multiplicative decrease)
• For each dup ack arrival
• dupack
• MaxWindow min(cwnd dupack, AdvWin)
• indicates packet left network, so we may be able
  to send more
• Receive ack for new data (beyond initial dup ack)
• dupack 0
• exit fast recovery
• But when RTO expires still do cwnd 1

39
Fast Retransmit and Fast Recovery
cwnd
AI/MD
Slow Start
Fast retransmit
Time

• Retransmit after 3 duplicated acks
• Prevent expensive timeouts
• Reduce slow starts
• At steady state, cwnd oscillates around the
  optimal window size

40
TCP Congestion Control Summary

• Measure available bandwidth
• Slow start fast, hard on network
• AIMD slow, gentle on network
• Detecting congestion
• Timeout based on RTT
• robust, causes low throughput
• Fast Retransmit avoids timeouts when few packets
  lost
• can be fooled, maintains high throughput
• Recovering from loss
• Fast recovery dont set cwnd1 with fast
  retransmits

41
Issues to Think About

• What about short flows? (setting initial cwnd)
• most flows are short
• most bytes are in long flows
• How does this work over wireless links?
• packet reordering fools fast retransmit
• loss not always congestion related
• High speeds?
• to reach 10gbps, packet losses occur every 90
  minutes!
• Why are losses bad?
• Tornado codes can reconstruct data proportional
  to packets that get through. Why not send at
  maximal rate?
• Fairness how do flows with different RTTs share
  link?

42
Bonus Question

• Why is TCP like Blanche Dubois?
• Because it relies on the kindness of
  strangers...
• What happens if not everyone cooperates?