Skip to content

Latency vs Bandwidth

"Our connection is 1 Gbps, why is this transfer only getting 40 Mbps?" is one of the most common confused tickets a network engineer ever receives, and the honest answer is almost always: bandwidth was never the constraint. This article is about the difference between two numbers that get casually lumped together as "speed," and the specific arithmetic that explains why a fast link and a slow transfer aren't a contradiction.

Two different physical properties, not two names for the same thing

Bandwidth is a link's carrying capacity — how many bits per second it can physically move, the way a pipe's diameter determines how much water can flow through it per second. Latency, as the ping article already established precisely, is one-way delay: how long a single bit takes to travel from one end of that link to the other, the way a pipe's length determines how long it takes one drop of water to travel from one end to the other, independent of how wide the pipe is.

A wide, short pipe and a wide, long pipe carry the same volume per second once full — bandwidth is identical — but a drop entering the long pipe takes far longer to come out the other end. That's the entire relationship in one image: bandwidth is about volume over time, latency is about delay over distance, and a link can be excellent at one while being poor at the other, in either direction.

A gigabit link with 200ms latency can carry enormous data. It just can't deliver it fast. A single packet is not "delivered faster" by having more bandwidth available — bandwidth only helps once you're sending enough data, over enough time, that the pipe's width actually becomes the limiting factor rather than its length.

Why a single request never benefits from more bandwidth

Consider one HTTP request for a tiny response — a health-check endpoint returning {"status":"ok"}, a few dozen bytes. That request has to complete TCP's three-way handshake — one round trip — before a single byte of actual data can be sent, and then the request and response themselves cost at least one more round trip. Whether the link between client and server is 10 Mbps or 10 Gbps makes essentially no difference to how long this takes, because the total data involved is a few hundred bytes at most — nowhere near enough to fill even a slow link for any measurable fraction of a second. What dominates the total time is purely how many round trips are needed, multiplied by how long each round trip takes — which is to say, purely latency.

Small request over a 10 Mbps link, 50ms latency:   ~2 round trips × 50ms  = ~100ms
Same request over a 10 Gbps link, 50ms latency:    ~2 round trips × 50ms  = ~100ms
(bandwidth changed by 1000x; total time didn't move)

This is exactly the situation the TCP use-cases article's satellite office scenario diagnosed: a 220ms round-trip time made ordinary API calls feel slow no matter how much bandwidth the office's link actually had, because each request was small enough that latency, not throughput, was the entire cost. Upgrading that office's bandwidth would have changed nothing; the fix there had to address the round trips themselves.

Why a large transfer does care about bandwidth — and why it also needs enough window

A large file transfer is the opposite case: with enough data to send continuously, the connection can genuinely fill the pipe, and bandwidth becomes the real ceiling — but only if the sender is actually allowed to have enough data in flight at once to keep that pipe full. This is where latency comes back in in a way that's easy to miss the first time you see it.

The sliding window article already established that TCP can only have so much unacknowledged data in flight at once, bounded by the smaller of the receive window and the congestion window. Combine that limit with a round trip that takes real time to complete, and a hard ceiling on throughput falls out directly — a relationship worth deriving explicitly rather than taking on faith:

Maximum possible throughput = Window size ÷ Round-trip time

Example: a 64 KB TCP window, 100ms round-trip time

Maximum throughput = 64 KB ÷ 0.1s = 640 KB/s ≈ 5.12 Mbit/s

No matter how much raw bandwidth the underlying link actually has — 100 Mbps, 10 Gbps, doesn't matter — a connection stuck with a 64 KB window and a 100ms round trip physically cannot exceed roughly 5 Mbit/s, because the sender has to stop and wait for an acknowledgment once that 64 KB of unacknowledged data is outstanding, and waiting for that acknowledgment costs one full round trip every time. This product — the amount of data that can be "in flight" filling the pipe at any given moment for a link of a given capacity and delay — is called the bandwidth-delay product, and it's the number that actually determines how large a TCP window needs to be to use a given link's full capacity:

Bandwidth-delay product = Bandwidth × Round-trip time

Example: a 1 Gbps link, 100ms round-trip time

BDP = 1,000,000,000 bits/s × 0.1s = 100,000,000 bits = 12.5 MB

A connection on this 1 Gbps, 100ms path needs roughly 12.5 MB of data in flight at once to actually use the full gigabit — a single-digit-kilobyte window, the kind an unoptimized older TCP stack might default to, would leave the vast majority of that link's real capacity sitting idle no matter how fast the link itself is. This is precisely the physical reality BBR is built to estimate directly — its BtlBw (bottleneck bandwidth) and RTprop (round-trip propagation time) are exactly the two quantities this product multiplies together, and a modern congestion-control algorithm's whole job on a high-bandwidth, high-latency path is keeping enough data in flight to actually saturate that product instead of leaving capacity unused while waiting on acknowledgments that haven't arrived yet.

Tip

The bandwidth-delay product is why a transcontinental or satellite link — exactly the kind of path TCP Reno already flagged as struggling to recover its window after loss — needs a deliberately large TCP window to perform well, and why simply "upgrading the link's bandwidth" without also making sure the window can grow to match does nothing: the link was never the bottleneck, the window was.

The GEO satellite case, worked already, applies directly here

This course's landing page already worked out a GEO satellite link's round-trip time explicitly — four hops of roughly 36,000 km each at close to the speed of light, totaling a bit over 480 milliseconds before any processing delay. That number is exactly the round-trip time half of this article's bandwidth-delay product formula, and it explains why satellite internet, despite often advertising respectable bandwidth figures, still feels sluggish for anything involving many small round trips (loading a page with dozens of separate resources, for instance) even when a single large download over that same link can eventually reach close to its rated bandwidth, given a large enough window to keep that ~480ms-wide pipe full.

A company sets up nightly backups from an on-premises server to cloud storage over a dedicated 500 Mbps link, confirmed with a same-network file copy to be genuinely capable of that rate locally. The backup job to the cloud consistently caps out around 40 Mbps, with no errors and no packet loss reported anywhere.

ping -c 5 <cloud-storage-endpoint>

rtt min/avg/max/mdev = 118.203/119.847/121.502/1.104 ms

ss -ti dst <cloud-storage-endpoint>

ESTAB 0 0 10.0.5.12:51422 203.0.113.44:443
     cubic rto:340 rtt:119.8/1.1 mss:1448 cwnd:10 ssthresh:20 bytes_sent:1847302 bytes_acked:1847302

The rtt:119.8 confirms a genuine ~120ms round trip to the cloud endpoint — nowhere near as extreme as a satellite link, but far higher than the sub-millisecond RTT the same-network test enjoyed, and cwnd:10 shows the connection's congestion window sitting at only 10 segments (roughly 14.5 KB at a 1448-byte MSS). Plugging those numbers into the throughput ceiling from earlier: 14.5 KB ÷ 0.12s works out to roughly 120 KB/s, or just under 1 Mbit/s per TCP connection — nowhere near 40 Mbps on its own, which tells you the backup software is running several parallel connections, and the aggregate of all of them is landing around 40 Mbps rather than any single stream hitting bandwidth's actual ceiling.

The fix isn't the network link at all — it's the software's connection strategy and the OS's window-scaling configuration. Increasing the number of parallel streams the backup job opens gives more independent windows all filling the same underlying pipe simultaneously; separately, confirming the OS has TCP window scaling enabled (sysctl net.ipv4.tcp_window_scaling, which should read 1 on any current Linux distribution) ensures a single stream isn't artificially capped by TCP's original 16-bit window field, a limitation the sliding window article covers as a scaling extension rather than a design flaw that got fixed. Either approach addresses the actual constraint — not enough data in flight to fill a ~120ms-wide pipe — instead of chasing a bandwidth ceiling the connection was never actually reaching.

Practice exercises

  1. A team doubles their office internet plan's advertised bandwidth from 500 Mbps to 1 Gbps and finds that loading their internal dashboard — which makes 40 small sequential API calls before rendering — feels exactly as slow as before. Using the small-request reasoning above, explain why.
  2. Calculate the bandwidth-delay product for a 200 Mbps link with a 150ms round-trip time, in both bits and bytes, and state what TCP window size would be needed to fully utilize that link with a single connection.
  3. Using the diagnostic scenario above, explain specifically what about the ss -ti output — not just the ping result — confirmed that the congestion window, not the physical link, was the limiting factor.

Every calculation in this article assumed there was exactly one path between sender and receiver, with one latency and one bandwidth to reason about. Real internet paths are rarely that simple — a packet crosses several independently operated networks to get anywhere, and which specific path it takes, and how quickly the internet reroutes around a failure on that path, is a decision made by a protocol this course has referenced constantly without yet explaining.

Sources