Transport Layer Congestion Control
Tom Kelliher, CS 325
Mar. 30, 2011
- Congestion control principles.
- TCP congestion control.
Network layer introduction.
- Assume no segments are dropped and senders don't time-out any
segments -- no retransmits.
- The network load generated by each sender's application layer is
Assume the senders equally share the available bandwidth.
- The router's outgoing link has capacity R bps.
- The network load seen by the receiver's application layer is
until we hit the bandwidth limit --
can't exceed this.
approaches , the router's segment queue's
length -- and delay -- increases.
- Now, segments will be be dropped and retransmits will occur.
is the offered load of the transport layer.
Due to retransmits,
- Due to finite buffers,
can't exceed -- shared
The graph on the left assumes the sender is omniscient and knows when the
router has free buffers and only transmits segments then, avoiding dropped
segments. -- unrealistic.
- Dropped segments mean duplicate, redundant data sent across a link
-- wasting bandwidth.
The middle graph shows what could happen if the sender retransmits only segments known to be lost -- again, unrealistic. Here, we assume
17% of segments are retransmits.
- Realistically, delays will cause some non-dropped segments to be
retransmitted, further wasting bandwidth with redundant segments.
The graph on the right shows this realistic scenario, assuming each segment
is retransmitted once.
- Consider what could happen if R2 becomes congested due to B-D
- R2 begins dropping segments from A-C, wasting bandwidth at R1.
- A's offered load increases, to handle retransmits.
- R1 could become congested, affecting the (initially free) D-B
Worst case, B-D traffic could completely lock-out A-C traffic beyond the
point at which
saturates the routers' transmit
- End-to-end control:
- No help from network layer --sender/receiver have to intuit
congestion on their own.
- TCP intuits congestion through fast retransmits (triple ACKs),
not too bad -- some bandwidth still available; timeout transmits,
really bad -- no bandwidth available.
Third idea for TCP: increased RTTs mean congestion is beginning to
become a problem.
- Network assisted. Two approaches here:
- Direct feedback with choke packet -- router sends choke command
directly to sender.
- Indirect feedback with congestion indication bit in segment --
router sets this, when congested, as it forwards a segment to
Receiver responsible for getting the indication back to the sender.
- Recall receive window for flow control:
- Recall our transmit model: sender sends segments each RTT with
We therefore have
So, RcvWindow, controlled by receiver, can be used to throttle sender
- TCP itself defines CongWindow, maintained by sender, to
throttle sender rate in face of congestion.
We then have:
Sender rate controlled by both RcvWindow and CongWindow.
TCP congestion control algorithm:
- Multiplicative decrease:
- After triple duplicate ACK, cut CongWindow in half. CongWindow never drops below 1 MSS.
Not as bad as a timeout.
- After a timeout, cut CongWindow down to 1 MSS.
- Additive increase:
- Increase CongWindow by 1 MSS each RTT.
Increase rate is controlled by RTT -- a lower RTT results in faster
CongWindow increase rate.
Often implemented by increasing CongWindow by
for each new ACK.
- Actually, CongWindow increase is multiplicative until Threshold is reached.
- Additive increase; multiplicative decrease:
- Slow start:
- CongWindow is set to 1 MSS for a new connection.
- CongWindow is increased by 1 MSS for each ACK received,
until Threshold is reached.
Exponential increase in CongWindow during SS phase:
- Additive increase, once Threshold reached:
TCP Reno = current algorithm. Is decrease from timeout or fast
- Actual timeout events behavior:
|| Sender Action
Slow Start (SS)
|| New ACK received
|| CongWin = CongWin + MSS. if
(CongWin Threshold) set state to CA.
|| CongWin doubles every
Congestion Avoidance (CA)
|| New ACK received
|| CongWin = CongWin +
|| CongWin increases by 1 MSS every RTT.
SS or CA
|| Triple Dup ACK
|| Threshold = CongWin/2. CongWin = Threshold.
set state to CA.
|| Fast recover; multiplicative decrease.
SS or CA
|| Threshold = CongWin/2. CongWin = 1 MSS. Set state to
SS or CA
|| Duplicate ACK received
|| Increment duplicate ACK count for
- Is TCP's AIMD algorithm fair? Consider this situation:
Suppose, initially, connection 1 has a higher throughput (CongWindow)
than connection 2:
This shows what happens during 3DupACK events -- multiplicative decrease.
Eventually, we converge to equal throughput.
On timeout, both connections will end up with a CongWindow of
- But, UDP doesn't implement congestion control, which can bring a
- Also, what about parallel TCP connections -- they allow a connection
to grab more bandwidth. Fair?
Thomas P. Kelliher