CSC 458/2209 – Computer Networking Systems
Lecture 8: TCP Congstion Control
Peter Marbach & Sajad Shirali-Shahreza
Department of Computer Science
University of Toronto
TCP Congestion Control
TCP implements host-based, feedback-based,
window-based congestion control.
TCP sources attempts to determine how much
capacity is available
TCP sends packets, then reacts to observable events
(loss).
CSC 458/CSC 2209 – Computer Networks University of Toronto – Fall 2019
Idea of TCP Congestion Control
Each source determines the available capacity
… so it knows how many packets to have in transit
Congestion window
Maximum # of unacknowledged bytes to have in transit
Flow control uses receiver window
MaxWindow = min{congestion window, receiver window}
Send at the rate of the slowest component: receiver or
network
Adapting the congestion window
Decrease upon losing a packet: backing off
Increase upon success: optimistically exploring
CSC 458/CSC 2209 – Computer Networks University of Toronto – Fall 2019
Additive Increase, Multiplicative Decrease
How much to increase and decrease?
Increase linearly, decrease multiplicatively
A necessary condition for stability of TCP
Consequences of over-sized window are much worse
than having an under-sized window
Over-sizedwindow: packets dropped and retransmitted
Under-sized window: somewhat lower throughput
Multiplicative decrease
On loss of packet, divide congestion window in half
Additive increase
On success for last window of data, increase linearly
CSC 458/CSC 2209 – Computer Networks University of Toronto – Fall 2019
Additive Increase
Src
D A D D A A D D D A A A
Dest
Actually, TCP uses bytes, not segments to count:
When ACK is received:
MSS
cwnd MSS
cwnd
CSC 458/CSC 2209 – Computer Networks University of Toronto – Fall 2019
Leads to the TCP “Sawtooth”
Window
Loss
halved
CSC 458/CSC 2209 – Computer Networks University of Toronto – Fall 2019
Practical Details
Congestion window
Represented in bytes, not in packets (Why?)
Packets have MSS (Maximum Segment Size) bytes
Increasing the congestion window
Increase by MSS on success for last window of data
In practice, increase a fraction of MSS per received
ACK
# packets per window: CWND / MSS
Increment per ACK: MSS * (MSS / CWND)
Decreasing the congestion window
Never drop congestion window below 1 MSS
CSC 458/CSC 2209 – Computer Networks University of Toronto – Fall 2019
TCP Sending Rate
What is the sending rate of TCP?
Acknowledgement for sent packet is received after
one RTT
Amount of data sent until ACK is received is the
current window size W
Therefore sending rate is R = W/RTT
Is the TCP sending rate saw tooth shaped as well?
CSC 458/CSC 2209 – Computer Networks University of Toronto – Fall 2019
TCP Sending Rate and Buffers
CSC 458/CSC 2209 – Computer Networks University of Toronto – Fall 2019
Getting Started
Need to start with a small CWND to avoid overloading the network.
Window
But, could take a long
time to get started! t
CSC 458/CSC 2209 – Computer Networks University of Toronto – Fall 2019
“Slow Start” Phase
Start with a small congestion window
Initially, CWND is 1 MSS
So, initial sending rate is MSS/RTT
That could be pretty wasteful
Might be much less than the actual bandwidth
Linear increase takes a long time to accelerate
Slow-start phase (really “fast start”)
Sender starts at a slow rate (hence the name)
… but increases the rate exponentially
… until the first loss event
CSC 458/CSC 2209 – Computer Networks University of Toronto – Fall 2019
Slow Start in Action
Double CWND per round-trip time
=
Increase CWND by 1 for each ACK received
1 2 4 8
Src
D D D A A D D D D
A
A A A A
Dest
CSC 458/CSC 2209 – Computer Networks University of Toronto – Fall 2019
Slow Start and the TCP Sawtooth
Window
Loss
Exponential “slow start” t
Why is it called slow-start? Because TCP originally had
no congestion control mechanism. The source would just
start by sending a whole window’s worth of data.
CSC 458/CSC 2209 – Computer Networks University of Toronto – Fall 2019
Two Kinds of Loss in TCP
Triple duplicate ACK
Packet n is lost, but packets n+1, n+2, etc. arrive
Receiver sends duplicate acknowledgments
… and the sender retransmits packet n quickly
Do a multiplicative decrease and keep going
Timeout
Packet n is lost and detected via a timeout
E.g., because all packets in flight were lost
After the timeout, blasting away for the entire CWND
… would trigger a very large burst in traffic
So, better to start over with a low CWND
CSC 458/CSC 2209 – Computer Networks University of Toronto – Fall 2019
Repeating Slow Start After Timeout
Window
timeout
Slow start in operation until
it reaches half of previous
tcwnd.
Slow-start restart: Go back to CWND of 1, but take advantage
of knowing the previous value of CWND.
CSC 458/CSC 2209 – Computer Networks University of Toronto – Fall 2019
Repeating Slow Start After Idle Period
Suppose a TCP connection goes idle for a while
E.g., Telnet session where you don’t type for an hour
Eventually, the network conditions change
Maybe many more flows are traversing the link
E.g., maybe everybody has come back from lunch!
Dangerous to start transmitting at the old rate
Previously-idle TCP sender might blast the network
… causing excessive congestion and packet loss
So, some TCP implementations repeat slow start
Slow-start restart after an idle period
CSC 458/CSC 2209 – Computer Networks University of Toronto – Fall 2019
Conclusions
Congestion is inevitable
Internet does not reserve resources in advance
TCP actively tries to push the envelope
Congestion can be handled
Additive increase, multiplicative decrease
Slow start, and slow-start restart
Active Queue Management can help
Random Early Detection (RED)
Explicit Congestion Notification (ECN)
CSC 458/CSC 2209 – Computer Networks University of Toronto – Fall 2019
