Bandwidth, Latency, and Throughput

Three numbers describe how a link performs, and people collapse them into the single word "fast" at the cost of every performance argument that follows. Bandwidth is capacity — the bits per second the pipe can carry. Latency is delay — the time for one bit to travel from end to end. Throughput is what you actually achieve, which is bounded by both and often by neither alone.

They are independent, and the independence has a sharp consequence: a fat transcontinental link can be slow to finish a small transfer because latency, not bandwidth, dominates it. Adding capacity to a latency-bound workload does nothing. Most "the network is slow" complaints are really a confusion between these three, and sorting them out is the difference between fixing a problem and spending money on the wrong one.

Bandwidth, Latency, and Throughput Are Three Things

Bandwidth is the width of the pipe: a 10 Gbps link can put ten billion bits on the wire each second. It says nothing about how long any one bit takes to arrive. Latency is the length of the pipe in time: a packet to a server 3000 km away cannot arrive in under about 15 milliseconds one way, no matter how wide the link.

Throughput is the rate you actually get, and it is capped by whichever limit binds first — bandwidth on a large bulk transfer, latency on a small request-response, and loss or a too-small window on a long-distance flow. The analogy that holds: bandwidth is how many lanes the highway has, latency is how long the highway is, and throughput is how fast your particular trip actually completes.

The Components of Latency

End-to-end latency is the sum of four delays, and knowing which one dominates tells you whether anything can be done about it. Propagation delay is distance divided by the speed of signal in the medium — fixed by geography. Transmission delay is the time to clock the bits onto the wire, set by bandwidth and packet size. Queuing delay is time spent waiting in buffers behind other packets, which rises with congestion. Processing delay is the small time each node spends making a forwarding decision.

On a long-distance path, propagation dominates and you cannot reduce it without moving the endpoints closer. On a congested link, queuing dominates and you fix it by relieving congestion, not by adding bandwidth that fills right back up. Diagnosing latency starts with deciding which of the four components is the bottleneck, because three of them have completely different cures.

The Speed of Light Floor

Signal in fiber travels at roughly two-thirds the speed of light in vacuum, about 200,000 km/s, which works out to near 5 milliseconds of one-way delay per 1000 km. New York to London is about 5500 km, so the round trip cannot beat roughly 55 milliseconds even on a perfectly straight, empty fiber — and real paths are neither straight nor empty.

This is a hard floor, not an engineering target. No amount of bandwidth, no faster router, no protocol tweak moves it, because it is physics. It is why content delivery networks push data to the edge near users, why a chatty protocol that makes ten sequential round trips across an ocean feels sluggish regardless of the link speed, and why the only way to cut propagation latency is to shorten the distance.

# ping measures round-trip latency; the floor is geography, not bandwidth
ping -c 3 lon.example.com
# time=72.4 ms   <- ~55 ms is light over fiber; the rest is path + queuing
# a 10x faster link would not lower this number at all

The Bandwidth-Delay Product

To keep a pipe full, a sender must have enough data in flight to cover the entire round trip before the first acknowledgment comes back. That amount is the bandwidth-delay product: bandwidth multiplied by round-trip time. A 1 Gbps link with an 80 ms RTT has a BDP of about 10 megabytes — meaning 10 MB must be unacknowledged and in flight at once to use the link fully.

If the protocol's window is smaller than the BDP, the sender stalls waiting for acknowledgments and throughput falls far below the available bandwidth, even with zero loss. This is why a single TCP connection often gets a fraction of a fast long-distance link until its window is tuned, and the BDP is the number that quantifies exactly how much data must be in flight. The transport chapter returns to this; here it is enough to know that bandwidth and latency together set the window you need.