Why can a high-bandwidth link deliver low throughput?

Because the sender may not be allowed to keep enough bytes in flight. If its effective window is smaller than the bandwidth-delay product, it sends a burst, waits for acknowledgements, then sends again. The link is capable of more, but the connection’s control loop cannot feed it continuously.

Does poor throughput require packet loss?

No. Loss makes things worse, but it is not required. A perfectly clean long-distance path can still underperform if the RTT is high and the connection window is small. The cap comes from window divided by RTT, so delay alone can limit a single flow.

Do multiple connections fix the problem?

They can help because each connection has its own effective window, so the total in-flight data can increase. That is why large uploads and downloads often use parallel parts. It is not a universal fix: it adds coordination, retry complexity, memory use, and can behave badly when the network is already congested.

Where should I look when diagnosing this?

Measure RTT to the real destination, not localhost or the same rack. Then compare the path’s bandwidth-delay product with the effective TCP, HTTP/2, gRPC, or application flow-control windows. Also check whether window scaling is enabled, whether buffers are being capped, and whether the workload uses one stream or many.

Connections Cost Something

Connections Cost Something means a network connection’s throughput is limited not just by link bandwidth, but by how much data the protocol is allowed to keep in flight while waiting for acknowledgements. On long RTT paths, a small window leaves the pipe empty, so a fast link can behave like a slow one.

The problem is that bandwidth is often bought, monitored, and advertised as if it were the same as throughput. It is not. A connection that must wait for acknowledgements can only send a window’s worth of data per round trip. As distance, queuing, or processing delay increases, each acknowledgement arrives later, and the sender spends more time unable to use the available capacity.

The mechanism is the bandwidth-delay product: bandwidth multiplied by RTT. That product is the amount of data that must be in flight to keep the path full. Separately, actual throughput is bounded by window divided by RTT. If the send or receive window is smaller than the bandwidth-delay product, packets drain from the path before more can be sent, even when there is no packet loss.

The trade-off is that larger windows and more parallel connections are not free. They consume buffer memory, can increase burstiness, may worsen queueing under congestion, and make loss recovery more expensive because more data may need retransmission. Parallel flows can raise aggregate throughput by adding their windows together, but they also compete less politely and complicate fairness, retries, and observability.

Engineers meet this in cross-region replication, object storage uploads, gRPC and HTTP/2 services, CDN acceleration, database backup restore jobs, and Kubernetes traffic between cloud regions. It is commonly misunderstood as a server CPU problem or a bad provider link. The honest answer depends on RTT, effective flow-control windows, TCP window scaling, loss, application framing, and how many connections are active.

Go deeper

DeploymentConnections Cost SomethingUse the bandwidth-delay product to explain why a fat pipe underperforms over distance, and why throughput is window divided by RTT.Open the lesson

Common questions

Why can a high-bandwidth link deliver low throughput?: Because the sender may not be allowed to keep enough bytes in flight. If its effective window is smaller than the bandwidth-delay product, it sends a burst, waits for acknowledgements, then sends again. The link is capable of more, but the connection’s control loop cannot feed it continuously.
Does poor throughput require packet loss?: No. Loss makes things worse, but it is not required. A perfectly clean long-distance path can still underperform if the RTT is high and the connection window is small. The cap comes from window divided by RTT, so delay alone can limit a single flow.
Do multiple connections fix the problem?: They can help because each connection has its own effective window, so the total in-flight data can increase. That is why large uploads and downloads often use parallel parts. It is not a universal fix: it adds coordination, retry complexity, memory use, and can behave badly when the network is already congested.
Where should I look when diagnosing this?: Measure RTT to the real destination, not localhost or the same rack. Then compare the path’s bandwidth-delay product with the effective TCP, HTTP/2, gRPC, or application flow-control windows. Also check whether window scaling is enabled, whether buffers are being capped, and whether the workload uses one stream or many.

Every term