Transport Layer Congestion Control and Leaky Bucket vs Token Bucket

Transport-layer congestion control prevents a sender from injecting traffic faster than the network can handle. In practice, transport protocols accomplish this via a feedback loop that uses loss and delay/ACK behavior as congestion signals, then adjusts the sending rate by changing the sender’s control variables (e.g., TCP’s congestion window).

Transport-layer congestion control and congestion window (cwnd) are tightly linked: TCP grows $cwnd$ when the network appears healthy, and reduces it when congestion is inferred.

A key idea is that TCP uses:

• slow start
• congestion avoidance
• fast retransmit
• fast recovery

Important note (scope): There are multiple congestion-control designs across protocols. The most widely taught mechanism in textbooks is TCP Reno-style behavior. Other TCP variants (CUBIC, BBR) and QUIC congestion control differ in details, but the feedback-and-rate-adjustment principle remains the same.

1) How transport-layer congestion control provides stability

At a high level, congestion control aims to keep the network in a regime where queues remain bounded and packet loss (or ECN marks) is rare.

TCP-style closed-loop control (conceptual)

1. Start conservatively with a small $cwnd$ to avoid overwhelming routers.
2. Probe for capacity:
   • If ACKs arrive without congestion indications, increase $cwnd$.
3. React to congestion:
   • Loss / timeout suggests queues are overflowing; reduce $cwnd$ sharply.
   • Duplicate ACKs suggest segment loss but route is still delivering other segments; reduce $cwnd$ less drastically and recover faster.

This yields a control law that alternates between probing and backing off, preventing persistent overload.

Relationship to reliability mechanisms

TCP also has reliability mechanisms (ACKs and retransmissions). Congestion control is different: retransmissions can occur due to link errors, but congestion control treats certain retransmission patterns as congestion evidence and reduces future sending rate accordingly.

Duplicate ACK is therefore central: it provides earlier, finer-grained feedback than waiting for a timeout.

2) Leaky Bucket vs Token Bucket: definitions and differentiation

Both leaky bucket and token bucket are classic traffic shaping and rate limiting algorithms used in the data plane (often implemented in routers/switches). They control how bursts are handled while enforcing a long-term average rate.

Key parameters:

• For token bucket: token generation rate and bucket capacity (burst size).
• For leaky bucket: drain rate and queue/buffer capacity.

Traffic shaping and rate limiting are the general goals.

Leaky bucket (queue that “leaks” at constant rate)

• Concept: A bucket holds up to $B$ bytes (or tokens representing bytes).
• A constant rate process removes (“leaks”) one unit per time interval.
• If packets arrive faster than the leak rate:
  • buffer fills up to $B$
  • once full, arrivals are dropped (or delayed if implemented with queueing semantics).

This tends to create a smoother, more regular output stream.

Token bucket (bucket fills with tokens; sending consumes tokens)

• Tokens are generated at a fixed average rate $r$ up to a maximum capacity $B$.
• To send/forward $1$ unit of data, you must “spend” (consume) $1$ token.
• If a packet arrives and tokens are available, it is forwarded immediately.
• If tokens are insufficient:
  • the packet is typically delayed until enough tokens accumulate, or dropped depending on the implementation policy.

This allows bursty traffic up to the capacity $B$ while still enforcing the average rate $r$ over time.

3) Direct comparison table