Networking · Network Performance
Decomposing Path Latency into Propagation, Serialization, and Queueing
The four terms that sum to the delay across a network path, how each scales with distance, link rate, and load, and which ones a sender can actually influence.
A single number describes the delay between two hosts badly. The same 40 ms path can be a transcontinental fibre span carrying an idle 100 Gbit/s link, or a metropolitan path through six congested routers, and the engineering response to each is different. The number that matters is a sum of four terms, each with its own dependence on distance, packet size, link rate, and traffic. Separating them identifies which term dominates a given measurement and which term a sender can do anything about.
The decomposition is standard in performance work and is formalised in the IP Performance Metrics framework, which distinguishes delay from loss and from variation, and defines one-way delay as the difference between the timestamps of two corresponding packets at two observation points. Every practical measurement is a noisy estimate of that quantity.
Four terms, one sum
For a packet crossing one store-and-forward hop, the delay contributed by that hop is
$$d = \frac{L}{C} + \frac{q}{C} + \tau + p$$
where $L$ is the packet length in bits, $C$ the link capacity in bits per second, $q$ the number of bits already queued ahead of the packet, $\tau$ the propagation time across the medium, and $p$ the time the device spends deciding where to send the packet. The first term is serialization, the second is queueing, the third is propagation, and the fourth is processing. Across a path of $n$ hops the terms add, with one subtlety: a store-and-forward device cannot begin transmitting until the last bit has arrived, so its serialization delay is charged to the packet in full at every hop it passes through.
The four terms differ in character. Propagation depends only on geography and medium, and nothing a host does changes it. Serialization depends on packet size and link rate, and a host controls one of those two. Queueing depends on the load offered to the link at that instant, and is the term that produces the long tail of observed latencies. Processing is a per-device constant, small on modern hardware and large on anything that forwards in software with an unoptimised path.
Propagation is set by distance and medium
Light in a vacuum travels at $3 \times 10^8$ m/s. In an optical fibre the group velocity is lower because the refractive index of silica is around 1.47, which puts the signal at roughly $2 \times 10^8$ m/s, or about 5 microseconds per kilometre. Copper twisted pair is comparable, with a velocity factor typically between 0.6 and 0.7 of $c$, so a metre of cable costs a few nanoseconds.
Those constants give the floor under every wide-area measurement. A 6,000 km fibre run has a one-way propagation delay near 30 ms and therefore a round trip near 60 ms, before any router has been traversed. A geostationary satellite sits at 35,786 km altitude, so the ground-to-satellite leg is about 120 ms at the speed of light, the up-and-down hop between two ground stations is about 240 ms, and a round trip through the satellite is close to half a second. No amount of link capacity reduces either figure: upgrading a transatlantic path from 10 to 100 Gbit/s leaves the propagation term untouched.
Radio is the exception worth noting. A terrestrial microwave link travels through air at very nearly $c$, so over the same distance its propagation delay is about two thirds of the fibre figure, a reduction of roughly a third. That is the entire reason some trading and backhaul paths use radio where geography permits.
Propagation is also the term that makes round-trip measurements asymmetric. The forward and reverse directions of a path rarely have the same length, and the difference shows up as an error when a round-trip figure is halved to estimate a one-way delay, a problem taken up in one-way delay and the clock offset problem.
Serialization is bytes divided by rate
A link cannot place a packet on the medium faster than its bit rate allows. A 1,500-byte packet is 12,000 bits; at 1 Gbit/s it occupies the link for 12 microseconds, at 10 Gbit/s for 1.2 microseconds, and at 100 Mbit/s for 120 microseconds. Serialization is the only one of the four terms that a sender can compute exactly before transmitting anything, because it needs only the packet size and the bottleneck rate.
Per hop the cost repeats. A packet crossing ten store-and-forward hops at 1 Gbit/s accumulates 120 microseconds of serialization even if every link is idle, while the same path at 100 Mbit/s accumulates 1.2 milliseconds. On low-rate access links this term is not a rounding error: a 100 Mbit/s uplink costs 120 microseconds per full-size packet, so a burst of fifty packets back to back holds the link for 6 milliseconds and forces every later packet to wait behind them.
Packet size is the half of the ratio a sender controls, and the trade is not free. Smaller packets reduce the time a packet occupies a link and reduce the delay suffered by whatever is queued behind it, but they raise the fraction of the link spent on headers and the per-packet work done by every device on the path. The consequences of that trade, including the packet-rate ceilings that switches quote, are worked through in serialization delay and the latency cost of small packets.
Queueing is the term that moves
Queueing delay is whatever the packet has to wait for behind traffic already scheduled. In an empty queue it is zero; in a queue holding one full-size packet on a 1 Gbit/s link it is 12 microseconds; in a queue holding a megabyte it is 8 milliseconds. Because the queue depth is a function of arrival patterns, this term is the one that turns a stable latency measurement into a distribution with a long right tail.
Two properties of queueing matter for interpretation. First, it is not additive in the same way as the other terms: a packet that queues at one hop is likely to arrive at the next hop later and more bunched, so congestion at consecutive hops compounds rather than merely summing. Second, queueing delay rises without bound as the arrival rate approaches the service rate, which is why a link at 50 percent utilisation can be nearly as fast as an idle one while a link at 95 percent is not. The shape of that curve, and the utilisation levels at which it becomes visible, is the subject of why queueing delay rises sharply near link utilisation.
A persistent queue is a different phenomenon from a transient one. If the arrival rate exceeds the drain rate for a sustained period, the queue settles at a depth that stays roughly constant, and every packet crossing that link pays a fixed extra delay for as long as the condition lasts. That standing queue is the mechanism behind bufferbloat, and its magnitude is set by buffer size rather than by traffic burstiness, as described in standing queues and buffer sizing.
Processing and the store-and-forward penalty
The fourth term covers everything a device does between receiving a packet and forwarding it: parsing headers, looking up a route or a flow entry, applying filters, decrementing a time-to-live, rewriting a checksum, and scheduling the packet onto an output queue. On a fixed-function switch this is pipelined hardware and lands in the low hundreds of nanoseconds. On a general-purpose machine running a software dataplane it can be tens of microseconds, and it varies with cache state, which is why software forwarding produces a wider latency distribution than an ASIC.
Store-and-forward adds a specific and often overlooked cost: the device must receive the entire packet before it can forward it, so the packet’s own serialization delay is paid at every hop, not only at the bottleneck. Cut-through forwarding, which begins transmitting as soon as the header has been parsed, removes that accumulation and is what keeps multi-hop switch fabrics in the microsecond range. The catch is that cut-through cannot check the frame check sequence before forwarding, so a corrupted frame propagates one hop further before being discarded.
Processing is also where routers implement control-plane protections that distort measurements. A device may generate an Internet Control Message Protocol reply, or expire a packet’s time-to-live, on a path that is deliberately rate-limited and lower priority than forwarding. The measured delay to such a device then reflects the control-plane queue, not the data path, which makes a hop-by-hop probe read high on the hops that answer it and low on the hops that do not.
What a sender can and cannot change
Of the four terms, propagation is fixed by physics and geography. Serialization is fixed by packet size and the bottleneck rate, and only the first is under the sender’s control. Processing is fixed by the equipment on the path. Queueing is the only term with real leverage, and the leverage is indirect: a sender changes queueing delay by changing how much it offers, how fast it offers it, and how it reacts when the path signals that a queue is building.
This is why latency work divides cleanly into two activities. One is removing round trips and bytes, which attacks serialization and the fixed costs of protocol exchanges; the counting of those fixed costs is covered in counting round trips in connection setup. The other is keeping queues short, which attacks the only term that varies by orders of magnitude on a path whose distance and rate never changed.
A useful discipline follows from the decomposition. When a measurement is worse than expected, the first question is which term could possibly explain the gap. A 30 ms path showing 200 ms of round-trip time has 170 ms of queueing, processing, or measurement error, and no amount of application tuning will remove it. A 30 ms path showing 32 ms is close to its floor, and the remaining work is protocol round trips and server-side time, not the network.
References
- RFC 2330: Framework for IP Performance Metrics — IETF
- RFC 7679: A One-way Delay Metric for IPPM — IETF
- Queueing Systems, Volume 1: Theory — Leonard Kleinrock, Wiley, 1975