Imagine trying to control traffic flow on a highway network where you can only see the cars at the entrance ramps and exit ramps—never the highway itself. You don't know how congested any segment is. You can't see the accidents or the volume of traffic from other entrances. All you can observe is: how long before cars you sent reach their destination.

This is precisely the challenge TCP faces. A TCP sender sits at the edge of the network with no visibility into routers, no knowledge of other connections, and no authority to request special treatment. Yet it must somehow regulate its transmission rate to be:

• Fast enough to fully utilize available bandwidth
• Slow enough to avoid causing or worsening congestion
• Fair enough to share capacity reasonably with other flows

This is the essence of sender-based congestion control: making optimal decisions using only end-host observations.

Congestion control could, in principle, be implemented by the network itself. Routers could allocate bandwidth, schedule packets fairly, and reject traffic that exceeds capacity. This network-assisted approach exists in some networks (ATM, MPLS traffic engineering, Software-Defined Networks).

So why does the Internet use sender-based control? The answer lies in the Internet's end-to-end design philosophy.

The End-to-End Argument:

First articulated by Saltzer, Reed, and Clark in 1984, the end-to-end principle holds that functions should be implemented at the endpoints rather than in the network when:

• The function can only be completely implemented with endpoint knowledge
• Implementing in the network would burden all traffic for functions needed by few
• Keeping the network simple improves reliability and enables innovation

The Trade-off:

Sender-based control pays for these advantages with significant limitations:

Information asymmetry — The sender doesn't know the network state. It must infer congestion from indirect signals (loss, delay) that arrive delayed by one RTT.

Delayed feedback — By the time a congestion signal reaches the sender, the congestion has existed for at least one RTT. Any response takes another RTT to reach the congestion point.

Limited coordination — Each sender operates independently. There's no mechanism to ensure fair allocation except the emergent behavior of compatible algorithms.

Conservative approach required — Unable to detect network state precisely, TCP must err on the side of caution, potentially underutilizing capacity.

To implement congestion control, TCP senders must extract meaningful signals from limited observations. Understanding what information is available—and what isn't—clarifies why congestion control algorithms work the way they do.

Direct Observations:

The sender can directly observe:

1. Segment Transmission Times When each segment was sent (local timestamp)

2. ACK Arrival Times When acknowledgments arrive (local timestamp)

3. ACK Contents

• Acknowledgment number (cumulative bytes received)
• Receiver window (advertised receive buffer space)
• Timestamp echo (if TCP timestamps enabled)
• SACK blocks (if SACK enabled, indicating out-of-order segments)
• ECN flags (if ECN enabled)

4. Timeout Events When expected ACKs don't arrive within the expected time

What's NOT Available:

Critically, the sender cannot directly observe:

• Router queue depths — No visibility into intermediate buffers
• Link utilization — Unknown whether bottleneck is at 50% or 95%
• Other flows' traffic — No coordination with competing connections
• Cause of loss — Cannot distinguish congestion from bit errors
• Forward path vs. return path — ACK delay mixes both directions
• Where congestion is — Only that it exists somewhere on path

This information gap is the fundamental challenge. TCP must infer network state from noisy, delayed signals that mix multiple causes together.

TCP's primary mechanism for controlling transmission rate is the congestion window (cwnd). This variable, maintained at the sender, limits how much data can be in flight at any time.

The Relationship:

Effective Window = min(cwnd, receiver_window)

The sender can have at most Effective Window bytes unacknowledged at any time.

Sending Rate = Effective Window / RTT

By adjusting cwnd, TCP indirectly controls its sending rate without explicit rate specification.

Why a Window Rather Than a Rate?

Defining rate directly (e.g., "send at 100 Mbps") would require:

• Accurate clock at the sender
• Precise packet scheduling
• Knowledge of current capacity

The window approach is self-regulating: new packets are sent only when ACKs arrive, naturally adapting to network conditions. If the network is fast, ACKs return quickly, enabling fast transmission. If the network is slow, ACKs are delayed, automatically slowing transmission.

The cwnd Lifecycle:

1. Initialization: cwnd starts "conservatively" small (typically 1-10 segments)
2. Growth: As ACKs confirm successful delivery, cwnd increases
3. Reduction: When loss or ECN signals congestion, cwnd decreases sharply
4. Steady State: cwnd oscillates around the network's capacity

Units:

cwnd is typically measured in bytes, though algorithms often think in terms of segments (MSS). A cwnd of 64 KB with MSS of 1460 bytes allows ~44 segments in flight.

State Tracking:

Beyond cwnd, TCP tracks:

• ssthresh (slow start threshold): The cwnd level above which slow start ends
• bytes_in_flight: Currently unacknowledged bytes
• bytes_newly_acked: Used for window updates
• delivered: Total bytes acknowledged (BBR)
• rtt_min, rtt_max: Historical RTT bounds (BBR, Vegas)

One of TCP's most elegant properties is ACK clocking (also called self-clocking). When the network is properly loaded, the rate at which ACKs return naturally matches the rate at which the sender can safely transmit.

How ACK Clocking Works:

Consider a fully loaded connection:

1. Sender transmits segments at some rate
2. Segments traverse the network, potentially queuing at the bottleneck
3. Receiver sends ACKs as data arrives
4. ACKs traverse the return path
5. ACKs arrive at the sender paced by the bottleneck's service rate

The key insight: The bottleneck link serializes segments at its capacity. The spacing between segment arrivals at the receiver (and thus ACK departures) reflects the bottleneck bandwidth. These inter-ACK spacings are preserved on the return path. When ACKs arrive at the sender, they're naturally spaced at the bottleneck rate.

Consequence: If the sender transmits one new segment for each ACK received, it automatically sends at the bottleneck rate—no explicit rate calculation needed!

Benefits of ACK Clocking:

1. Rate adaptation: Sending rate naturally matches available capacity
2. Burstiness reduction: Segments are paced by ACK arrival, not sent in bursts
3. No clock required: Rate emerges from network feedback, not sender timing
4. Self-correction: Temporary slowdowns reduce ACK rate, which reduces sending rate

Breaking ACK Clocking:

Several situations disrupt ACK clocking:

ACK compression: Multiple ACKs arrive together due to queuing on return path Delayed ACKs: Receiver waits before ACKing, bunching acknowledgments Packet loss: Lost packets break the ACK stream, requiring retransmissions Path changes: New routes have different timing characteristics Application stalls: Sender runs out of data, breaking the continuous flow

After disruption, TCP must re-establish proper clocking through slow start or careful probing.

TCP's traditional window-based control is not the only approach. Modern systems often combine windows with explicit pacing to better regulate transmission patterns.

Window-Only Control (Traditional):

The sender transmits immediately whenever:

• The window allows (cwnd > bytes_in_flight)
• Data is available
• No other limit (receiver window, SWS avoidance) applies

Problem: This can create bursts. If 10 ACKs arrive nearly simultaneously (delayed ACKs, ACK compression), the sender may immediately transmit 10 segments back-to-back. These bursts can:

• Overflow router buffers (causing loss)
• Create micro-congestion (temporary queue buildup)
• Trigger unfair interactions with competing flows

Pacing Implementation:

The basic pacing approach:

Pacing Rate = cwnd / RTT

Packets are spaced at intervals of MSS / Pacing Rate.

Example: cwnd = 1 MB, RTT = 100 ms, MSS = 1500 bytes

• Rate = 1 MB / 100 ms = 80 Mbps
• Inter-packet gap = 1500 bytes / 80 Mbps = 150 microseconds

A packet is transmitted every 150 μs, smoothing the transmission pattern.

Modern Usage:

Google's BBR uses pacing extensively. QUIC (which rebuilds congestion control from scratch) includes pacing as a core mechanism. Linux TCP also supports pacing through the FQ (Fair Queue) packet scheduler.

Trade-offs:

Pacing helps at high speeds but adds overhead at low speeds (more timer events). It also requires kernel support for fine-grained packet scheduling. Modern systems typically enable pacing above a certain threshold rate.

TCP congestion control can be analyzed as a feedback control system. Understanding control loop dynamics explains why TCP behaves as it does and why certain parameter choices are made.

The Control Loop:

           ┌─────────────────────────────────┐
           │          Network                │
           │   (Unknown, time-varying)       │
           └─────────────────────────────────┘
                      ▲         │
                      │         │ Feedback (ACKs,
              Packets │         │ losses, delay)
                      │         ▼
           ┌─────────────────────────────────┐
           │         TCP Sender              │
           │                                 │
           │  cwnd = f(feedback signals)     │
           │  rate ≈ cwnd / RTT              │
           └─────────────────────────────────┘

Key Control Theory Concepts:

The Stability Challenge:

TCP must respond to congestion without overreacting:

Too aggressive increase: Multiple flows simultaneously increase, causing oscillation and repeated congestion events.

Too aggressive decrease: Minor congestion triggers severe rate cuts, leaving capacity unused.

Too slow increase: After congestion, recovery takes too long, wasting capacity.

Too slow decrease: Congestion persists because flows don't reduce rate fast enough.

The AIMD (Additive Increase, Multiplicative Decrease) approach—which we'll explore in detail on Page 5—was specifically designed to provide stability and fairness in this control loop.

RTT Sensitivity:

The control loop's stability depends on RTT:

• Low RTT = fast feedback = can adapt quickly = more aggressive OK
• High RTT = slow feedback = must be conservative = slower adaptation

This creates inherent challenges for flows with very different RTTs sharing a bottleneck.

Despite its elegance, sender-based control has inherent limitations that drive ongoing research and algorithm development.

Challenge 1: Limited Visibility

The sender sees only end-to-end behavior. If performance degrades, it cannot determine:

• Which link is congested
• Whether congestion is on forward or return path
• What share of bottleneck other flows consume
• Whether losses are random or congestion-induced

Challenge 2: Delayed Response

All feedback arrives at least 1 RTT after the event occurred. For a flow with 200 ms RTT, congestion that started 200 ms ago is just now being signaled. The response won't affect the congestion point until another 200 ms passes.

Challenge 3: Fairness Depends on Cooperation

Sender-based control relies on all senders implementing compatible algorithms. An aggressive sender ignoring congestion signals gains unfair bandwidth share. This led to the concept of TCP-friendliness: new algorithms should achieve similar throughput to standard TCP under the same conditions.

The Alternatives:

Recognizing these limitations, various approaches augment or partially replace pure sender-based control:

ECN (Explicit Congestion Notification): Routers mark packets (rather than dropping) when queues build. Senders respond before loss occurs. Reduces delay and loss variability.

Active Queue Management (AQM): Routers (RED, CoDel, PIE) actively manage queues, providing earlier and clearer congestion signals to senders.

Network-Assisted CC: In controlled environments (data centers), network information can be exposed to endpoints (DCQCN, HPCC).

Receiver-Side Modifications: Receivers can help by providing more information (accurate timestamps, congestion indicators) or by pacing ACKs.

Despite these enhancements, the sender remains the decision-maker. These approaches provide better information, but the fundamental architecture remains sender-based.

We've established a comprehensive understanding of how TCP controls congestion from the sender. Let's consolidate the key insights:

What's Next:

Sender-based control needs signals to know when congestion is occurring. The next page explores congestion signals—how TCP interprets packet loss, delay changes, and explicit marks to infer network state and react appropriately.