A skilled physician can diagnose many conditions by taking a patient's pulse—subtle variations in rhythm, strength, and timing reveal underlying pathology. Similarly, TCP must diagnose network health using only the "pulse" of acknowledgments and timing patterns.

Unlike a physician who can order tests and examination, TCP cannot probe the network directly. It can only observe symptoms: packets that don't arrive, packets that arrive late, and occasionally, explicit markers left by routers along the way.

The art of congestion control lies in correctly interpreting these symptoms. Treat every slight delay as congestion, and TCP starves itself of bandwidth. Ignore clear warning signs, and TCP drives the network into collapse. Finding the right balance requires understanding what each signal means, how reliable it is, and when it might be misleading.

Packet loss is the most fundamental and historically primary congestion signal in TCP. When routers become overloaded and their buffers fill, they have no choice but to discard incoming packets. This drop is the network's way of saying "I cannot handle this load."

The Logic:

In a properly designed network:

1. Normal operation → buffers mostly empty → no drops
2. High load → buffers fill → occasional drops as indicator
3. Congestion → persistent buffer overflow → frequent drops

By treating drops as congestion, TCP can adapt: detect loss, reduce sending rate, allow the network to recover.

Timeout-Based Detection:

If no acknowledgment arrives within the Retransmission Timeout (RTO) period, TCP assumes the segment was lost. The RTO is calculated from measured RTT with safety margins:

RTO = SRTT + 4 × RTTVAR

Where:

• SRTT = Smoothed RTT (running average)
• RTTVAR = RTT variance (running average of deviation)

Timeout is the "last resort" detection method—reliable but slow. Modern TCP uses faster mechanisms when possible.

Triple Duplicate ACK Detection:

When a receiver gets out-of-order data, it immediately ACKs the last in-order byte. If segment 5 is lost but 6, 7, 8 arrive, the receiver sends:

• ACK for segment 4 (upon receiving 6)
• ACK for segment 4 again (upon receiving 7)
• ACK for segment 4 again (upon receiving 8)

These are "duplicate ACKs." Three duplicates strongly suggest loss (not just reordering), triggering fast retransmit without waiting for timeout.

While packet loss is an unambiguous signal that something happened, interpreting it correctly poses several challenges:

Problem 1: Loss Happens After Congestion

By the time a packet is dropped:

1. The router's buffer filled (queuing delay increased)
2. Many packets waited in that buffer
3. The system was already congested for a full buffer's worth of traffic

Dropping is a lagging indicator. The network was already stressed before the drop occurred, and significant data has already queued up.

Problem 2: Multiple Causes

Packet loss can result from:

• Buffer overflow (congestion) ✓ Proper to reduce rate
• Bit errors (transmission) ✗ Wrong to reduce rate
• Link failures (transient) ✗ Wrong to reduce rate
• Firewall drops (policy) ✗ Rate change won't help
• Routing loops (configuration) ✗ Rate change won't help

TCP cannot distinguish these causes from observation alone.

Problem 3: The Sensitivity Trade-off

How should TCP respond to a single loss event?

Conservative interpretation: One loss = mild congestion. Reduce rate moderately. Risk: If it WAS serious congestion, this under-reacts, causing more drops.

Aggressive interpretation: One loss = serious congestion. Cut rate dramatically. Risk: If it was random loss, this over-reacts, wasting capacity.

Classic TCP takes the aggressive approach (halve cwnd), which works well in wired networks where nearly all loss IS congestion. But it performs poorly where random loss is common.

Problem 4: Burst Losses

When a router's buffer overflows, multiple consecutive packets may be lost (a "burst" or "cluster"). This creates challenges:

• Multiple losses in one window vs. separate loss events—how to count?
• Head-of-line blocking if early segment lost but later segments arrive
• SACK helps but not universally deployed

Delay (specifically, delay increase) provides an earlier congestion indicator than loss. When traffic approaches capacity, queues build at bottlenecks, increasing packet delay. This queuing happens before buffers overflow—potentially well before.

The Principle:

Consider a path with some minimum delay (propagation + minimum processing). When congestion develops:

Stage 1: Light Load

• Packets traverse quickly
• Minimal queuing delay
• RTT ≈ minimum RTT (RTT_min)

Stage 2: Increasing Load

• Queues start to form at bottleneck
• RTT increases above RTT_min
• No loss yet—buffer has room

Stage 3: Heavy Load

• Queues deep, RTT significantly elevated
• Approaching buffer capacity
• Loss imminent

Stage 4: Overload

• Buffer full, packets dropped
• Loss-based TCP finally reacts

Delay-based approaches detect Stage 2 or 3, reacting before Stage 4.

Measuring Delay:

TCP tracks RTT through various mechanisms:

Without Timestamps: Measure time from sending a segment to receiving its ACK. Limited by:

• Can only sample one packet per RTT (oldest unACKed)
• Ambiguity when retransmitting (is ACK for original or retransmit?)

With TCP Timestamps (RFC 1323):

• Sender includes timestamp in each segment
• Receiver echoes it in ACK
• Sender computes RTT for every ACK
• Eliminates retransmission ambiguity
• Provides fine-grained RTT history

Delay Variation:

Beyond absolute delay, the variation in delay carries information:

• Stable, low delay: path is uncongested
• Increasing delay over time: queue building
• High, stable delay: persistent queue (buffer may be large)
• Jittery delay: variable cross-traffic or wireless

Several TCP variants and congestion control algorithms use delay as their primary or a contributing congestion signal.

TCP Vegas (1994):

The first major delay-based TCP variant. Vegas compares actual throughput to expected throughput:

Expected = cwnd / RTT_min Actual = cwnd / RTT_current Diff = Expected - Actual

• If Diff < α: increase cwnd (underutilizing path)
• If Diff > β: decrease cwnd (building queue)
• If α ≤ Diff ≤ β: maintain cwnd (sweet spot)

Interpretation: If actual throughput is close to expected (based on minimum RTT), the queue is empty. If actual is notably lower, packets are waiting in queues.

BBR's Approach (2016):

Google's BBR represents a sophisticated evolution of delay-based thinking:

1. Model the network: Estimate bottleneck bandwidth (max delivery rate) and minimum RTT (when path is empty)

2. Target optimal operating point: BDP = BW_max × RTT_min. Keep exactly this much data in flight.

3. Probe periodically: Occasionally increase rate to check if capacity increased (BW probing) or decrease rate to let queue drain and measure true RTT_min (RTT probing)

4. Control via pacing rate: Rather than just cwnd, pace packets at the estimated bottleneck rate

BBR aims to operate at the inflection point—high throughput with minimal queuing. It largely ignores loss as a congestion signal (within limits), making it robust to non-congestion losses.

The Delay-Based Challenge:

The fundamental issue: delay-based algorithms back off when queues build. But loss-based algorithms keep pushing until drops occur. When they compete:

• Delay-based flow senses queue building, reduces rate
• Loss-based flow doesn't see loss yet, takes the freed capacity
• Delay-based flow sees MORE delay (from loss-based traffic), reduces more
• Result: loss-based flows capture most bandwidth

This "compete against loss-based flows" problem has hindered pure delay-based adoption.

Explicit Congestion Notification (ECN) represents a paradigm shift: rather than inferring congestion from its symptoms, have routers explicitly signal when congestion is developing.

The Problem ECN Solves:

With loss-based signaling:

1. Router buffer fills completely
2. Router drops packet
3. Sender detects loss (after RTT)
4. Sender reduces rate (another RTT to take effect)
5. Packet must be retransmitted (more traffic on congested path)

With ECN:

1. Router buffer starts filling (threshold, not full)
2. Router marks packet (modifies header, doesn't drop)
3. Packet arrives at receiver with mark
4. Receiver echoes mark to sender in ACK
5. Sender reduces rate based on marks
6. No packet lost, no retransmission needed

ECN Mechanics:

ECN uses bits in the IP header (IP ECN field) and TCP header (ECN flags):

IP Header (2 bits):

• 00: Not-ECT (transport not capable)
• 10 or 01: ECT (ECN-Capable Transport)
• 11: CE (Congestion Experienced)

TCP Header (2 flags):

• ECE (ECN-Echo): Receiver saw CE marking, telling sender
• CWR (Congestion Window Reduced): Sender confirms it reduced cwnd

Process:

1. Negotiation: During handshake, peers agree on ECN capability
2. Sender marking: Sender sets ECT on outgoing packets
3. Router marking: Router changes ECT → CE when queue exceeds threshold
4. Receiver echo: Receiver sets ECE in ACK upon receiving CE-marked packet
5. Sender response: Sender treats ECE like loss, reduces cwnd
6. Confirmation: Sender sets CWR to acknowledge the reduction

Modern congestion control increasingly recognizes that no single signal is perfect. The best approaches combine multiple signals, using each where it's most informative.

The Signal Spectrum:

Hybrid Examples:

CUBIC + HyStart: CUBIC is loss-based but uses HyStart (Hybrid Slow Start) for early phases:

• During slow start, monitors RTT and ACK train
• Exits slow start early if delay increases (before loss)
• Then uses loss-based CUBIC for steady state

BBR's Multi-Signal Approach:

• Primarily delay-based (model RTT_min and BW_max)
• Uses loss as a bound (if loss rate high, something is wrong)
• Ignores random loss below threshold, responds to persistent loss
• Can integrate ECN for earlier/more precise signals

L4S: The Future Direction

Low Latency, Low Loss, Scalable throughput (L4S) is an emerging architecture that uses ECN as the primary signal:

1. Routers mark packets at much lower queue thresholds than classic ECN
2. Senders reduce rate proportionally to marking frequency (not binary response)
3. Result: very low queuing delay (~1ms) while maintaining full utilization

L4S requires:

• Scalable congestion control at endpoints (DCTCP, Prague, BBRv2 with L4S)
• Dual-queue or fair-queue AQM at bottlenecks
• Coexistence mechanisms to not harm classic TCP

This represents the trajectory of congestion signaling: from occasional binary signals (drop/don't drop) to continuous, proportional feedback (marking rate ∝ congestion level).

Even with good signals, correct interpretation is challenging. TCP must make decisions under uncertainty, balancing responsiveness against stability.

Challenge 1: Distinguishing Cause from Effect

If RTT increases, is it because:

• Queuing at a bottleneck you're causing? → Reduce rate
• Queuing from other traffic? → Uncertain, maybe wait
• Path change to longer route? → No rate change needed
• Receiver processing delay? → No rate change needed

TCP cannot directly distinguish these. It must use heuristics (did my rate recently increase? did loss accompany the delay?).

Challenge 2: How Much to React

Upon detecting congestion, by how much should cwnd decrease?

• Too little: congestion persists, more losses
• Too much: underutilizes capacity, wastes bandwidth
• Right amount: depends on severity, which is uncertain

Classic TCP uses "multiplicative decrease" (halve cwnd)—a conservative choice that may over-react to mild congestion but safely addresses severe congestion.

Challenge 3: Noise and Variability

Real network measurements are noisy:

• RTT varies due to load, OS scheduling, NIC batching
• Loss is stochastic even under congestion
• ECN marking has threshold effects

Algorithms must filter noise from signal:

• Smoothing: SRTT uses exponential moving average
• Windowing: BBR uses max BW over 10 RTTs, min RTT over 10s
• Thresholds: Vegas uses α/β bands, not exact values
• Hysteresis: Don't react to every small change

Challenge 4: Competing Flows

Congestion signals reflect aggregate network state, not just your flow. If RTT increases:

• Is YOUR traffic causing it, or OTHER flows?
• If others, should you reduce rate (polite) or not (competitive)?

The AIMD approach (we'll see on Page 5) elegantly handles this by having all flows reduce multiplicatively upon any congestion signal, naturally leading to fair convergence.

We've developed a comprehensive understanding of how TCP detects congestion. Let's consolidate the key insights:

What's Next:

With signals in hand, TCP must decide how to respond. The next page explores the AIMD principle—Additive Increase, Multiplicative Decrease—the foundation of TCP's response strategy and the key to distributed fairness.