Transport-Layer Congestion Control, and Leaky Bucket vs Token Bucket

1. How the transport layer provides congestion control

Congestion means the network's routers/links are carrying more traffic than their buffers and bandwidth can absorb, causing queueing delay, packet loss and throughput collapse. IP itself has no congestion control, so the end hosts — specifically TCP at the transport layer — control the rate at which they inject data, treating losses and delay as feedback signals.

1. Window-based rate control. The sender may have at most $\min(\text{cwnd}, \text{rwnd})$ unacknowledged bytes in flight; increasing cwnd increases the injection rate.
2. Slow start. cwnd starts at 1 MSS and doubles once per RTT (exponential growth) until it reaches the slow-start threshold $ssthresh$ or a loss occurs.
3. Congestion avoidance. Beyond $ssthresh$, cwnd grows additively (+1 MSS per RTT) — probing cautiously for spare capacity (AIMD).
4. Loss as congestion signal (multiplicative decrease).
   • 3 duplicate ACKs → fast retransmit + fast recovery: $ssthresh = \text{cwnd}/2$, $\text{cwnd} = ssthresh + 3$, then additive increase.
   • Timeout (severe congestion): $ssthresh = \text{cwnd}/2$, $\text{cwnd} = 1$ MSS, back to slow start.
5. Explicit signals: ECN marks IP headers (CE bit) and the receiver echoes ECE so the sender reduces cwnd without loss; a receiver can also reduce its advertised rwnd, throttling the sender (receiver flow control).
6. Retransmission timers with RTT estimation keep the in-flight data bounded so buffers upstream are not overrun.

 cwnd  |        additive increase (+1/RTT)
 (MSS) |      ______________/
       |     /      × loss → half (multiplicative decrease)
 ssth. |/____/ 
       | slow start (exponential)
       +---------------------------→ time/RTT

2. Leaky bucket vs Token bucket

Both are traffic-shaping (policing) algorithms that convert bursty input into a smoother, rate-limited output.

Basis	Leaky bucket	Token bucket
Working idea	Packets enter a bucket (queue) and drain at a constant fixed rate; if full, arriving packets are dropped/rejected	Tokens are generated at a fixed rate; a packet may be sent only if it grabs enough tokens, otherwise it waits
Empty bucket	Bucket empty ⇒ nothing to output	Bucket empty ⇒ new packets may still be sent if burst capacity is available — the bucket accumulates surplus
Burst tolerance	No bursts — output is strictly uniform (any burst is delayed/dropped)	Allows bursts up to the bucket's token capacity
Output rate	Always exactly the leak rate	Average = token rate, but instantaneous bursts are permitted
Implementation	Simple FIFO queue with a timer	Counter of tokens + queue
Typical use	Constant bit-rate shaping, hard policing	Limiting average rate while permitting bursts (e.g. network access rate policing)
Analogy	Water leaks out of a punctured bucket at a fixed rate	Coins are minted at a fixed rate; spending them authorises sending
Burst after idle	Cannot send a burst immediately	Idle time accumulates tokens → burst up to bucket size can be sent instantly

Essence: the leaky bucket enforces a rigid, smooth output rate and treats any excess as error, while the token bucket enforces a long-term average rate but deliberately allows bursts up to the accumulated token count — which is why it is preferred for real, bursty application traffic.

Conclusion: congestion control is achieved end-to-end by TCP's AIMD window algorithms (slow start, congestion avoidance, fast recovery, ECN), and routers additionally police/shape traffic at entry points using leaky or token bucket algorithms.