Congestion Control
This work is licensed under a Creative Commons Attribution 4.0 License.
Congestion Control and Resource Allocation
1. Resource Allocation
■ How the network distributes available resources among users.
■ Resources include:
Bandwidth
Buffers
Processing power
2. Congestion Control
■ Managing traffic to prevent network overload.
■ Typically reactive:
Responds to packet loss or delay.
3. Proactive Resource Management
■ If the network manages resources upfront, congestion can be minimized.
■ Techniques include:
Admission Control: Allow only traffic that fits available capacity.
QoS Guarantees / Traffic Shaping: Prioritize and smooth traffic.
Dynamic Bandwidth Reservation: Allocate bandwidth based on demand.
■ Challenges in Precise Resource Allocation
Resources (bandwidth, buffer space) are spread across multiple links and routers.
Network conditions change dynamically, making prediction difficult.
Centralized coordination can be complex or slow in large, heterogeneous networks.
Congestion Control and Resource Allocation
Two broad strategies:
1. Proactive resource allocation (hard but clean):
Network tries to control how much data each source can send before congestion happens.
Examples: RSVP (Resource Reservation Protocol), QoS-based scheduling, traffic policing.
Pros: Congestion is avoided or minimized, smoother performance, fewer packet drops.
Cons: Complex to implement, requires network support and signaling, less flexible, possibly under-utilized resources.
2. Reactive congestion control (easy but rough):
Sources send as much as they want, and network drops or delays packets when overloaded.
Endpoints detect congestion signals (packet loss, ECN marks) and back off.
Examples: TCP congestion control, AIMD algorithms.
Pros: Simple, scalable, works over existing best-effort networks, no need for complex signaling.
Cons: Congestion happens first, causing packet loss and retransmissions, which wastes resources and increases delay.
■ When the network just drops packets as a reaction, it’s like applying the brakes after the car has
already hit the wall. It’s less elegant, and can cause:
■ Packet loss bursts, hurting real-time applications
■ Retransmission overheads
■ Increased jitter and latency
In practice:
■ Many networks rely primarily on reactive congestion control because it’s simpler and
more flexible, while gradually introducing resource allocation mechanisms in critical or
controlled environments (like data centers or telecom networks).
Congestion Control and Resource Allocation
At the Hosts (Endpoints):
■ Congestion control mechanisms are implemented in the transport protocols (e.g.,
TCP, QUIC):
■ They pace how fast the sender injects packets into the network.
■ Use feedback signals like packet loss, delay, or explicit congestion notifications (ECN) to
adjust sending rate.
■ Goal: Avoid overwhelming the network by backing off when congestion is detected and
cautiously increasing sending rate when the path is clear.
■ Together:
■ Routers handle real-time allocation and management of scarce network resources,
deciding which packets to forward or drop.
■ Hosts adapt their sending behavior based on network signals to prevent congestion
from building up.
■ This combined approach helps the network operate efficiently and fairly.
TCP Congestion Control
■ Introduced by Van Jacobson in the late 1980s, ~8 years after TCP/IP
became operational.
■ Motivation: Congestion collapse in the early Internet.
■ Hosts sent packets as fast as the advertised window allowed.
■ Routers became overloaded, dropped packets.
■ Hosts retransmitted, worsening congestion.
■ Core Idea
■ Each source estimates available network capacity.
■ Sends only as many packets as the network can handle safely.
■ Uses ACKs as signals:
■ Arrival of an ACK = one packet left the network.
■ Safe to send a new packet without increasing congestion.
■ Self-Clocking
■ TCP paces packet transmission based on ACKs.
■ This mechanism is called self-clocking, preventing excessive congestion.
TCP Congestion Control
■ Congestion Window (CongestionWindow)
■ Limits the amount of data a source can have in transit.
■ Works alongside the advertised window from flow control:
MaxWindow = MIN(CongestionWindow, AdvertisedWindow)
EffectiveWindow = MaxWindow − (LastByteSent − LastByteAcked)
■ Ensures the sender does not exceed what the network or receiver can handle.
■ How CongestionWindow is Managed
■ Unlike AdvertisedWindow, there’s no receiver to tell the sender the congestion window.
■ TCP infers congestion from the network:
■ Packet drops and timeouts indicate congestion.
■ Mechanism: Additive Increase / Multiplicative Decrease (AIMD)
■ Multiplicative Decrease ■ Additive Increase
■ On detecting congestion (timeout or packet
loss): ■ When network is clear and ACKs are received for
■ CongestionWindow = CongestionWindow all packets in the window:
/2 ■ Increase CongestionWindow by 1 packet per RTT
■ Example:
■ Allows TCP to gradually probe for available
■ 16 → 8 → 4 → 2 → 1 packet
■ Minimum limit: 1 packet (MSS) bandwidth without causing congestion
Key Idea of AIMD
■ Decrease multiplicatively on congestion → prevents collapse
■ Increase additively when network permits → utilizes available capacity
TCP Congestion Control
■ Additive Increase Multiplicative Decrease
Packets in transit during additive increase, with one packet being
added each RTT.
TCP Congestion Control
■ Incremental Increase
■ TCP does not wait for a full window of ACKs to increase the congestion window.
■ Instead, it increments the CongestionWindow slightly for each ACK received.
■ Increment Formula
■ MSS: Maximum Segment Size (size of one packet)
■ Each ACK adds a fraction of MSS to the congestion window.
■ Key Idea
■ Smooth, continuous growth of the congestion window
■ Allows TCP to probe for available bandwidth gradually, avoiding sudden congestion
TCP Congestion Control
■ Slow Start
■ The additive increase mechanism just described is the
right approach to use when the source is operating
close to the available capacity of the network, but it
takes too long to ramp up a connection when it is
starting from scratch.
■ TCP therefore provides a second mechanism,
ironically called slow start, that is used to increase the
congestion window rapidly from a cold start.
■ Slow start effectively increases the congestion
windowexponentially, rather than linearly.
TCP Congestion Control
■ Slow Start
■ Specifically, the source starts out by setting
CongestionWindow to one packet.
■ When the ACK for this packet arrives, TCP adds 1 to
CongestionWindow and then sends two packets.
■ Upon receiving the corresponding two ACKs, TCP
increments CongestionWindow by 2—one for each
ACK—and next sends four packets.
■ The end result is that TCP effectively doubles the
number of packets it has in transit every RTT.
TCP Congestion Control
■ Slow Start
Packets in transit during slow start.
TCP Congestion Control
■ Slow Start
■ There are actually two different situations in which
slow start runs.
■ The first is at the very beginning of a connection, at which
time the source has no idea how many packets it is going to
be able to have in transit at a given time.
■ In this situation, slow start continues to double CongestionWindow each
RTT until there is a loss, at which time a timeout causes multiplicative
decrease to divide CongestionWindow by 2.
TCP Congestion Control
■ Slow Start
■ There are actually two different situations in which
slow start runs.
■ The second situation in which slow start is used is a bit more
subtle; it occurs when the connection goes dead while waiting
for a timeout to occur.
■ Recall how TCP’s sliding window algorithm works—when a packet is
lost, the source eventually reaches a point where it has sent as much
data as the advertised window allows, and so it blocks while waiting for
an ACK that will not arrive.
■ Eventually, a timeout happens, but by this time there are no packets in
transit, meaning that the source will receive no ACKs to “clock” the
transmission of new packets.
■ The source will instead receive a single cumulative ACK that reopens
the entire advertised window, but as explained above, the source then
uses slow start to restart the flow of data rather than dumping a whole
window’s worth of data on the network all at once.
TCP Congestion Control
■ Slow Start
■ Although the source is using slow start again, it now
knows more information than it did at the beginning of
a connection.
■ Specifically, the source has a current (and useful)
value of CongestionWindow; this is the value of
CongestionWindow that existed prior to the last packet
loss, divided by 2 as a result of the loss.
■ We can think of this as the “target” congestion
window.
■ Slow start is used to rapidly increase the sending rate
up to this value, and then additive increase is used
beyond this point.
TCP Congestion Control
■ Slow Start
■ Notice that we have a small bookkeeping problem to
take care of, in that we want to remember the “target”
congestion window resulting from multiplicative
decrease as well as the “actual” congestion window
being used by slow start.
■ To address this problem, TCP introduces a temporary
variable to store the target window, typically called
CongestionThreshold, that is set equal to the
CongestionWindow value that results from
multiplicative decrease.
TCP Congestion Control
■ Slow Start
■ The variable CongestionWindow is then reset to one
packet, and it is incremented by one packet for every
ACK that is received until it reaches.
■ CongestionThreshold, at which point it is incremented
by one packet per RTT.
TCP Congestion Control
■ Slow Start
■ In other words, TCP increases the congestion window
as defined by the following code fragment:
{
u_int cw = state->CongestionWindow;
u_int incr = state->maxseg;
if (cw > state->CongestionThreshold)
incr = incr * incr / cw;
state->CongestionWindow = MIN(cw + incr,
TCP_MAXWIN);
}
■ where state represents the state of a particular TCP
connection and TCP MAXWIN defines an upper bound on
how large the congestion window is allowed to grow.
TCP Congestion Control
■ Slow Start
Behavior of TCP congestion control. Colored line = value of
CongestionWindow over time; solid bullets at top of graph =
timeouts; hash marks at top of graph = time when each packet is
transmitted; vertical bars = time when a packet that was
eventually retransmitted was first transmitted.
TCP Congestion Control
■ Fast Retransmit and Fast Recovery
■ The mechanisms described so far were part of the
original proposal to add congestion control to TCP.
■ It was soon discovered, however, that the
coarse-grained implementation of TCP timeouts led to
long periods of time during which the connection went
dead while waiting for a timer to expire.
■ Because of this, a new mechanism called fast
retransmit was added to TCP.
■ Fast retransmit is a heuristic that sometimes triggers
the retransmission of a dropped packet sooner than
the regular timeout mechanism.
TCP Congestion Control
■ Fast Retransmit and Fast Recovery
■ The idea of fast retransmit is straightforward. Every
time a data packet arrives at the receiving side, the
receiver responds with an acknowledgment, even if
this sequence number has already been
acknowledged.
■ Thus, when a packet arrives out of order— that is,
TCP cannot yet acknowledge the data the packet
contains because earlier data has not yet
arrived—TCP resends the same acknowledgment it
sent the last time.
TCP Congestion Control
■ Fast Retransmit and Fast Recovery
■ This second transmission of the same
acknowledgment is called a duplicate ACK.
■ When the sending side sees a duplicate ACK, it knows
that the other side must have received a packet out of
order, which suggests that an earlier packet might
have been lost.
■ Since it is also possible that the earlier packet has
only been delayed rather than lost, the sender waits
until it sees some number of duplicate ACKs and then
retransmits the missing packet. In practice, TCP waits
until it has seen three duplicate ACKs before
retransmitting the packet.
TCP Congestion Control
■ Fast Retransmit and Fast Recovery
■ When the fast retransmit mechanism signals
congestion, rather than drop the congestion window
all the way back to one packet and run slow start, it is
possible to use the ACKs that are still in the pipe to
clock the sending of packets.
■ This mechanism, which is called fast recovery,
effectively removes the slow start phase that happens
between when fast retransmit detects a lost packet
and additive increase begins.
TCP Congestion Control
■ Fast Retransmit and Fast Recovery
Trace of TCP with fast retransmit. Colored line = CongestionWindow;
solid bullet = timeout; hash marks = time when each packet is transmitted;
vertical bars = time when a packet that was eventually retransmitted was
first transmitted.
