Delay, Loss and Throughput

Two questions decide whether a network feels good: how long does a packet take to get there, and how many bits per second can I actually push? The first is delay (latency); the second is throughput. They sound like the same thing — "fast" — but they are almost independent, and confusing them is the root of more bad networking intuitions than anything else. A transatlantic fibre link can have enormous throughput and still make a video call laggy; a satellite link can have huge capacity and feel unusable for a phone call. This page pins down exactly where the time goes and exactly what limits the rate.

The plan: dissect the delay a single packet suffers at one router (four distinct sources), settle the classic transmission-vs-propagation confusion once and for all, watch queues fill and packets drop, and then switch from one packet to a stream — where throughput, the bottleneck link, and the "bits in flight" of the bandwidth–delay product take over.

The four sources of nodal delay

Follow one packet as it passes through one router on its journey. The total time it spends there — the nodal delay — is the sum of four separate contributions, and it pays to keep them strictly apart because they scale with completely different things.

d_{\text{nodal}} = d_{\text{proc}} + d_{\text{queue}} + d_{\text{trans}} + d_{\text{prop}}

Processing delay d_{\text{proc}} — the time the router spends examining the packet header, checking for bit errors, and deciding which outbound link to send it on. Typically microseconds. Depends on the router's speed, not on the packet or the network load.
Queuing delay d_{\text{queue}} — the time the packet waits in the outbound buffer behind other packets already lined up for the same link. This one is highly variable: on an idle link it is zero; on a congested link it can dwarf everything else. It is the only term that depends on how busy the network is.
Transmission delay d_{\text{trans}} = L / R — the time to push all the packet's bits onto the wire, where L is the packet length in bits and R is the link's transmission rate in bits/second. This is a property of the link's speed and the packet's size — not the distance.
Propagation delay d_{\text{prop}} = d / s — the time for a bit, once on the wire, to travel the physical distance d to the next router at the signal's propagation speed s (roughly 2\times10^8 m/s in fibre, about two-thirds the speed of light). This depends on distance only — not on the link's bit-rate.

The two that people conflate are the middle pair, transmission and propagation. They deserve their own section — but first, an analogy that makes all four click.

The caravan analogy

Picture a caravan of ten cars (a packet of ten bits) driving down a motorway with a toll booth every so often (a router). Each toll booth takes 12 seconds to service one car — that is the transmission of one bit onto the road: the booth must "push" each car through before the next can go. Servicing all ten cars takes 120 seconds. The cars then drive the 100 km to the next booth at 100 km/h, taking one hour — that is propagation: pure travel time over distance, independent of how fast the booth works.

Speed up the toll booth (a faster link, bigger R) and transmission shrinks — but the drive is unchanged.
Move the booths closer together (less distance d) and propagation shrinks — but each car still takes 12 seconds to be serviced.
Add a queue of caravans ahead of you at the booth and you wait — that is queuing delay, and it depends on traffic, not on the road or the booth alone.

The analogy nails the key asymmetry: transmission is "how fast can I get the bits onto the road", propagation is "how long is the road." A short fat road and a long thin road behave completely differently, even at the same "speed."

Transmission vs propagation — the number that settles it

Nothing dissolves this confusion like plugging in numbers. Send one 8,000-bit packet (1 KB) two ways: over a short, slow link and over a long, fast one. Run it and read the two breakdowns.

// Delay of a single packet across a chain of links. // Each link: rate R (bits/s), distance d (metres). Signal speed in fibre ~2e8 m/s. const S = 2e8; // propagation speed (m/s) interface Link { name: string; R: number; d: number; } function linkDelays(L: number, link: Link) { const dTrans = L / link.R; // time to push L bits onto the wire const dProp = link.d / S; // time for a bit to travel the distance return { dTrans, dProp, total: dTrans + dProp }; } const L = 8000; // packet length: 8000 bits (1 KB) // (A) short but SLOW link: 1 Mb/s over 10 km const slow: Link = { name: "slow+short (1 Mb/s, 10 km)", R: 1e6, d: 10_000 }; // (B) long but FAST link: 1 Gb/s over 5000 km const fast: Link = { name: "fast+long (1 Gb/s, 5000 km)", R: 1e9, d: 5_000_000 }; for (const link of [slow, fast]) { const d = linkDelays(L, link); console.log(`${link.name}:`); console.log(` transmission = ${(d.dTrans * 1000).toFixed(3)} ms (L/R, depends on RATE)`); console.log(` propagation = ${(d.dProp * 1000).toFixed(3)} ms (d/s, depends on DISTANCE)`); console.log(` total = ${(d.total * 1000).toFixed(3)} ms`); console.log(""); } // On (A) transmission dominates; on (B) propagation dominates — same packet!

On the slow-short link, transmission (8 ms) dwarfs propagation (0.05 ms): the bottleneck is pushing bits onto a thin pipe. On the fast-long link the picture flips completely — propagation (25 ms) dwarfs transmission (0.008 ms): the pipe is fat, but the ocean is wide and light is not instantaneous. Same packet, opposite stories. That is why "just buy a faster link" often does nothing for latency: if you are propagation-bound, a bigger R changes almost nothing.

The single most common delay mistake: assuming that a "faster" link (higher bit-rate R) means lower latency. It does not, necessarily. Increasing R only shrinks the transmission term L/R — the time to clock the bits onto the wire. It does nothing to the propagation term d/s — the time for those bits to physically travel the distance, which is fixed by the speed of light and the length of the cable.

Concretely: a 1 Gb/s and a 100 Gb/s link across the Atlantic have essentially the same one-way delay for a small packet, because both are dominated by the ~30 ms it takes light to cross the ocean. Bandwidth buys you throughput (bits per second), not latency (time for one bit to arrive). A gamer on a fibre line in Sydney playing on a European server will never get below the round-trip light-speed floor, no matter how many gigabits they pay for. Keep the two terms in separate mental boxes: rate fixes transmission, distance fixes propagation.

Queues, traffic intensity, and packet loss

Queuing delay is the wild card. It depends on the traffic intensity at the link, the dimensionless ratio

\rho = \frac{L a}{R}

where a is the average packet arrival rate (packets/second), L the bits per packet, and R the link rate. The numerator La is the average rate at which bits arrive; the denominator R is the rate at which the link can drain them. So \rho is simply arrival rate ÷ service rate.

\rho \approx 0 — packets arrive rarely; the queue is almost always empty; queuing delay ≈ 0.
\rho \to 1 — bits arrive almost as fast as the link can send them; small bursts pile up faster than they drain; average queuing delay shoots toward infinity.
\rho > 1 — bits arrive faster than the link can ever send them. The queue grows without bound. This is overload, and it is unsustainable.

The curve below is the shape every network engineer carries in their head: queuing delay stays flat and boring until traffic intensity nears 1, then explodes. This is why a link that is "80% utilised" can feel fine and the same link at "98% utilised" feels broken — you are riding up the knee of this curve.

And when the queue is full? A router's buffer is finite. A packet that arrives to find no free buffer space has nowhere to go — the router simply drops it. That is packet loss: not corruption, not a wrong turn, just a full waiting room and no seat. The lost packet must be detected and retransmitted by a higher layer (TCP), which costs a whole round trip. Loss, then, is the direct consequence of pushing traffic intensity too close to 1 for too long.

From one packet to a stream: throughput and the bottleneck

Delay describes one packet. When you download a file you care about a stream of them, and the right measure is throughput: the rate, in bits/second, at which bits actually arrive at the receiver. It is tempting to equate this with "bandwidth," but they differ:

Bandwidth (capacity) is what a link could carry — its rated bits/second.
Throughput is what you actually achieve end-to-end, which is usually less.

Why less? Because a path is a chain of links, and a chain is only as fast as its weakest link. If bits flow from server to you through links of rates R_1, R_2, \dots, R_n, the end-to-end throughput can be no more than the slowest one:

\text{throughput} = \min(R_1, R_2, \dots, R_n)

That slowest link is the bottleneck. A gigabit server link and a gigabit backbone are wasted if your home link is 50 Mb/s — you will get about 50 Mb/s, and the fat links upstream sit idle. This is why upgrading a fast part of the path changes nothing: you have to find and widen the bottleneck. (It is also why one heavy user can starve a shared bottleneck for everyone behind it.)

Several culprits, all of which the "min of the links" rule hides at first glance. The bottleneck might not be your link — the server, or some congested link in the middle, may be slower right now. Throughput is also shared: if the bottleneck carries N connections at once, each gets roughly its 1/N slice. And protocol overhead eats into it — headers, acknowledgements, and TCP's slow ramp-up mean the goodput (useful application bytes) is always a little below the raw link rate. "100 Mb/s" is a ceiling on the last hop, not a promise about the whole path.

Round-trip time and the bandwidth–delay product

One more quantity ties delay and throughput together, and it is the one that governs how fast protocols can actually go: the bandwidth–delay product (BDP). First, the round-trip time (RTT) is the time for a small packet to travel from sender to receiver and back — dominated by propagation, so it is essentially fixed by distance. A ping across a city might be 5 ms; across an ocean, 150 ms; via a geostationary satellite, ~500 ms.

Now multiply a link's bandwidth by the connection's RTT:

\text{BDP} = \text{bandwidth} \times \text{RTT}

This is the number of bits "in flight" — the amount of data that can be travelling down the pipe at any instant before the first bit's acknowledgement can possibly come back. Picture the link as a physical pipe: bandwidth is its cross-section (how many bits fit per metre), RTT stands in for its length, and the BDP is the pipe's volume — how many bits it holds when completely full.

The consequence is profound: to keep a link busy, a sender must have at least a whole BDP of unacknowledged data outstanding. Send less and the pipe runs half-empty — you waste capacity waiting for ACKs. This is exactly why a protocol's window size must be at least the BDP to reach full throughput, and why "long fat networks" (high bandwidth × high RTT — think transcontinental gigabit links) demand large windows. Compute one to feel the size:

// Bandwidth-delay product: how many bits can be "in flight" at once. function bdp(bandwidthBps: number, rttSeconds: number) { const bits = bandwidthBps * rttSeconds; return { bits, bytes: bits / 8, kilobytes: bits / 8 / 1024 }; } const cases = [ { name: "home, same city: 100 Mb/s x 10 ms RTT", R: 100e6, rtt: 0.010 }, { name: "transatlantic: 1 Gb/s x 150 ms RTT", R: 1e9, rtt: 0.150 }, { name: "geo-satellite: 50 Mb/s x 500 ms RTT", R: 50e6, rtt: 0.500 }, ]; for (const c of cases) { const p = bdp(c.R, c.rtt); console.log(`${c.name}`); console.log(` in-flight = ${Math.round(p.bits).toLocaleString()} bits` + ` = ${p.kilobytes.toFixed(1)} KB`); console.log(` -> the sender's window must hold >= ${Math.ceil(p.kilobytes)} KB to keep the pipe full`); console.log(""); }

Notice the transatlantic gigabit link needs nearly 19 MB of data in flight to stay full — far more than a default TCP window, which is why bulk transfers over long fast paths need window scaling. The BDP is the bridge between our two headline quantities: it is literally bandwidth (throughput) multiplied by delay.