A content platform finds that transfers to distant clients achieve far less throughput than the available bandwidth. What are the causes and what tuning applies?

The primary cause

The bandwidth-delay product exceeds the receive window. Throughput over a reliable transport is bounded by window / round-trip-time. Over a 200 ms path, a 64 KB window caps throughput at about 2.6 Mbps regardless of how much bandwidth exists.

This is the classic long-fat-network problem, and its signature is unmistakable: throughput inversely proportional to distance, with local clients fast and distant ones slow, on the same servers and the same content.

The contributing causes

1. Loss-based congestion control over long paths. Classic algorithms interpret any loss as congestion and reduce the sending rate. On a long path, recovery from a reduction is slow because it takes many round trips, so occasional non-congestive loss has an outsized effect on average throughput.

2. Slow start. Every new connection begins conservatively and takes several round trips to reach full rate. For short transfers on a long path, the connection may finish before ever reaching it — so for many workloads the transfer is entirely in slow start.

3. Bufferbloat. Oversized buffers in intermediate equipment mean loss-based control keeps increasing the rate until buffers fill, adding latency without adding throughput.

4. Small initial congestion window, which compounds the slow-start problem for small responses.

The tuning

• Window scaling enabled and buffers sized to the bandwidth-delay product. Autotuning handles this on modern stacks, but maximum buffer limits are frequently set too low by default.
• A congestion control algorithm that models bandwidth and round-trip time rather than treating loss as the only signal. This behaves far better on long or lossy paths and avoids filling buffers, and it is usually the highest-return change because it is a configuration rather than an architectural one.
• A larger initial congestion window, so small responses complete in fewer round trips.
• Connection reuse, so the cost of slow start is paid once rather than per request.
• A transport with faster connection establishment, combining transport and cryptographic handshakes into a single round trip.

The architectural answer that beats all tuning

Reduce the round-trip time. Every mechanism above is a workaround for distance. Serving from a location near the client makes the window sufficient, slow start brief, and loss recovery fast — and it improves every metric simultaneously.

This is why content delivery is a network-performance strategy rather than merely a caching strategy: the latency reduction improves throughput non-linearly, because throughput is inversely proportional to round-trip time.

The measurement requirement

None of this is visible from the server. Server-side metrics show the bytes were written promptly. Client-side timing segmented by region and network is the only way to see the problem, which is why platforms serving distant clients invest in client telemetry rather than in more server dashboards.