Congestion Control at the Transport Layer

Congestion occurs when too many hosts inject traffic into a part of the network faster than its links/routers can drain it — queues overflow, packets are dropped, delays rise and throughput can collapse. Detecting congestion and curing it are two different things: routers can detect it, but only the end hosts can reduce the offered load, which is why the transport layer must participate.

Why transport-layer control is necessary even though congestion is a network-layer problem

Aspect	Network layer	Transport layer
View	Local — one router's queue	End-to-end across the whole path
Can detect congestion?	Yes (buffer overflow, ECN bits, queue delay)	Yes (loss, RTT growth, duplicate ACKs)
Can throttle traffic?	Only per-packet (drop/mark/ECN) — cannot tell the source to slow down persistently	Yes — the sender controls its own sending rate
State kept	Ideally stateless (no per-flow state)	Per-connection state (cwnd, ssthresh)
Scope	Works only while packet is in that router	Adapts to route changes, cross traffic anywhere on path

• The network layer sees only a local snapshot; congestion is an aggregate, end-to-end phenomenon, so only an end-to-end mechanism can react correctly to it.
• IP routers are designed to be stateless and forward packets fast; holding per-connection rate information for millions of flows at every router is impractical (scaling, memory, processing).
• Cross traffic appears/disappears constantly and routes change — the sender must continuously adapt its rate, which only the source can do.
• Modern IP offers ECN: routers mark packets instead of dropping them, but the reaction (slowing down) still happens in TCP.

Why TCP has congestion control and UDP does not

TCP maintains a congestion window (cwnd); the effective sending window is min(cwnd, rwnd). It starts with slow start (exponential growth of cwnd from 1 MSS until ssthresh), then switches to congestion avoidance (linear +1 MSS/RTT). On 3 duplicate ACKs it does fast retransmit/fast recovery (halve cwnd); on RTO it resets cwnd to 1 MSS and doubles ssthresh — the classic AIMD (additive-increase/multiplicative-decrease) behaviour that keeps the network stable and fairly shared.

UDP has no congestion control because it is connectionless: there is no connection setup, no sequence numbers/ACKs, no retransmission and therefore no feedback signal to tell it that congestion occurred. It also keeps no per-connection state to hold a cwnd. UDP apps (DNS queries, RTP streaming) are typically short, delay-sensitive, or handle quality at the application layer (e.g. RTP/RTCP); if a UDP datagram is lost to congestion, it is simply dropped rather than retransmitted.

(Note: because uncontrolled UDP harms everyone, mechanisms like LEDBAT and QUIC-over-UDP implement congestion control above the transport — confirming that the control itself must exist somewhere, but not in connectionless UDP itself.)