Summary

  • TCP can be throttled by delayed, lost or compressed acknowledgments on a narrow reverse path even when the forward data link has ample capacity.
  • Techniques that reduce ACK load can restore one resource while changing sender burst, congestion-window growth and loss-recovery evidence; the final application result needs its own receipt.

The sales figure was 10 Mbps downstream. The return channel had 50 Kbps. Data packets were large, acknowledgments small, so the two numbers looked compatible.

RFC 3449 demonstrated the missing calculation. With 1,000-byte data packets and 40-byte ACKs, the packet-size ratio was 25. The raw capacity ratio was 200. Normalized, the asymmetry ratio k was eight. If the receiver acknowledged more frequently than the upstream could carry, the reverse path saturated before the forward path. The 10 Mbps pipe waited for a feedback clock it did not own.

Published in December 2002 as Best Current Practice 69, TCP Performance Implications of Network Path Asymmetry surveyed a range of access-network conditions and mitigations. Its figures and deployment examples are historical. Its lasting lesson is evidentiary: TCP delivery is a control loop, not a one-way capacity test.

An ACK is small in bytes and large in authority

A cumulative ACK tells the sender that the receiver's TCP has advanced to a sequence point. It opens the sliding window and participates in congestion-control growth and recovery. It is not proof that an application persisted, processed or usefully acted on the data.

On a normal path, ACK arrival spacing helps self-clock new data. Forward packets become spaced by the forward bottleneck; acknowledgments generated from that arrival pattern return to the sender; new packets are released accordingly. An asymmetric reverse bottleneck can rewrite that timing.

The reverse path may be narrow in capacity. It may also make every packet expensive because the MAC requires contention, grants, guard time or a radio turnaround. In that case the cost of a 40-byte ACK is not proportional to forty bytes. Counting bandwidth without counting transmission events misses the control surface.

The correct record therefore starts with two paths, not one throughput number. It includes direction, route, capacity, packet-event overhead, queueing, cross traffic and the receiver's ACK policy.

A deep queue slows the clock without losing it

If the upstream queue is deep enough, ACKs accumulate rather than drop. They leave the bottleneck farther apart than the receiver produced them. The sender observes ACK dilation and clocks out data at the return link's rate.

The forward link can be visibly idle while no forward loss is present. Congestion-window growth also slows because feedback arrives less often. Persistent reverse queuing raises RTT for every control loop sharing that bottleneck, and variability can distort retransmission timing.

That failure is easy to misclassify. A downstream utilization chart suggests unused capacity. A round-trip chart reports latency. Neither alone identifies the reverse ACK queue as the causal bridge. Directional queue and packet observations are required.

A shallow queue preserves bytes and loses recovery evidence

With a small reverse buffer, ACKs may be dropped. Because acknowledgments are cumulative, one surviving ACK can still confirm receipt of many data segments. No byte-level contradiction appears: data arrived and later progress covers the gap.

The control evidence is different. Infrequent ACKs can release a large burst because one message advances the send window by many segments. Implementations that grow the congestion window per ACK grow more slowly. During forward loss, duplicate ACKs or SACK information may fail to reach the sender in the pattern needed for prompt Fast Retransmit and Fast Recovery.

“The receiver acknowledged all bytes” is therefore compatible with “the sender lost the timing and duplicate evidence needed to recover efficiently”. A transport audit must preserve both facts.

Compression turns waiting into a burst

Bidirectional traffic intensifies the problem. Large upstream data packets can occupy the queue that forward-flow ACKs need. A group of ACKs may wait, then emerge close together. This is ACK compression: the sender receives a cluster that no longer represents the receiver's original spacing and responds with a concentrated data burst.

The burst can overflow forward queues and create loss on a path that looked underused moments earlier. The reverse queue has not merely delayed evidence; it has reshaped the sender's actuation.

ACK dilation and ACK compression are opposite timing distortions. Both make raw ACK arrival an unreliable copy of receiver progress. A useful incident record compares receiver emission, pre-bottleneck arrival, post-bottleneck departure and sender receipt.

Reducing ACK volume moves the risk

RFC 3449 carefully avoids presenting one fix. Its summary labels techniques recommended, experimental or not recommended, often with conditions.

A larger MSS without router fragmentation can reduce ACKs per byte when path MTU allows it. Creating a larger TCP segment that routers fragment was not recommended because the unit of recovery becomes larger than the unit of transmission and loss.

Relaxing delayed-ACK rules beyond the standard bound was also not recommended for general use. The receiver usually lacks enough knowledge of the reverse path to choose a safe factor. Fewer ACKs reduce load while increasing RTT, window-opening time and sender burst size.

ACK Filtering removes redundant cumulative ACKs before the bottleneck. That can reclaim upstream capacity, but the surviving stretch ACKs may trigger large bursts. RFC 3449 treated filtering as experimental and conditioned it on burst mitigation. ACK Decimation uses queue and drop policy to constrain feedback, but its crude selection can impair recovery; the RFC preferred filtering where possible.

The lesson is not that filtering is wrong. It is that a mitigation changes the evidence surface. A lower ACK packet rate does not prove less congestion. It may reflect deliberate suppression, loss or receiver behavior.

Reconstructing the clock creates a new speaker

ACK Reconstruction attempts to insert replacement ACKs after the reverse bottleneck, smoothing feedback for the sender. The reconstructed messages do not come from fresh receiver observations. They are produced from soft state by an intermediary trying to approximate the stream that filtering removed.

RFC 3449 classified the technique not recommended. It also identified an amplification risk: an attacker able to inject suitable stretch ACKs could trigger generated traffic unless endpoints and rates were bounded.

The governance point is sharper than the classification. Once an intermediary speaks ACK timing on behalf of the receiver, the record needs its identity, state generation, rate bounds and failure behavior. A smooth sender clock can coexist with stale or forged reconstruction state.

Pacing separates acknowledged progress from immediate release

Sender pacing addresses the burst that infrequent ACKs can create. Instead of transmitting every newly permitted segment immediately, the sender spreads packets over an estimated interval. RFC 3449 treated pacing as experimental, noting implementation cost and the need for a rate prediction.

Pacing does not add receiver evidence. It changes how the sender acts on evidence it already received. Byte counting similarly changes window growth according to bytes acknowledged, but unlimited counting can turn a large cumulative ACK into an excessive release. Later Appropriate Byte Counting supplies bounds; it does not make application outcome part of the ACK.

This distinction matters when reporting success. A smoother queue after pacing proves an actuation change. It does not prove the reverse path stopped dropping ACKs or that recovery under loss improved.

Priority can cure latency and starve data

Giving ACKs strict priority at an upstream bottleneck can shorten feedback delay. Without a mechanism controlling ACK volume, the same priority can starve upstream data. RFC 3449 therefore did not recommend ACKs-first scheduling for the Internet.

Fair queuing was the more balanced recommendation because it can separate flows and keep ACKs from being trapped indefinitely without granting them unlimited authority. Again, the outcome depends on workload. A scheduler that helps a forward download can harm an upstream application if the measurement excludes it.

Encryption removes some transparent powers

Several transparent mechanisms assume that an intermediary can find, read or modify the TCP header. RFC 3449's historical IPsec analysis made the dependency explicit: payload encryption that hides the header can rule out compression, filtering, reconstruction and compaction, while integrity protection can allow observation but prevent modification.

The inability to modify a protected header is not a failure of encryption. It is a boundary on the intermediary's authority. A design that depends on transparent manipulation must disclose that it competes with end-to-end confidentiality and integrity properties.

Twelve receipts for one throughput claim

First identify both routes and the observation interval. Record capacity, MAC event cost, cross traffic, queue policy and buffer depth in each direction. Preserve the receiver's ACK policy and actual emission timing.

Then document every change before the sender: loss, filtering, decimation, compression, reconstruction or scheduling. At the sender, record ACK spacing, cumulative progress, duplicate/SACK evidence, congestion-window change, pacing and burst distribution.

Forward loss and recovery form a separate receipt. Transport goodput must be tied to offered load and fairness. Authenticated application completion and the user-visible result come afterward. Finally, reproduce the mechanism under rollback and an alternate path.

One green throughput number cannot replace the chain. It can be accurate within its test and still conceal who set the clock.

Evidence boundary

RFC 3449 does not prove current behavior for any named access network, satellite, cable system, radio, TCP stack, congestion controller or operator. Its k = 8 example illustrates normalization; it is not a measurement of a live service. CUBIC and later TCP work change window dynamics without eliminating dependence on acknowledgments and recovery evidence.

Heng Lu's minimum-initial-specification and running-code principles are disclosed editorial lenses. They favour bounded, locally chosen mitigations and observed directional receipts over a universal rule derived from one access architecture. They do not supply deployment facts.

The narrow conclusion is sufficient: TCP's forward capacity is exercised by a loop. If only the wide half is measured, the advertised rate describes a pipe and not the delivery system.

Sources