Latency, Jitter, Loss, and Bufferbloat

Three numbers describe the quality of a path, and conflating them is the single most common reason an engineer tunes the wrong thing. Latency is delay — how long one packet takes to cross. Jitter is the variation in that delay from packet to packet. Loss is the fraction of packets that never arrive. They are independent: a link can have low latency and high jitter, or zero loss and terrible latency, and each one breaks a different class of application.

The trap that wastes the most time is bufferbloat — oversized router queues that hoard packets rather than dropping them, so latency stays low at idle and explodes the instant the link is loaded. It looks like a fast connection that mysteriously goes slow under use, and it is invisible to any test run on an idle link. Measuring the right number, under load, against the application that actually hurts, is what this topic is about.

Latency, Jitter, and Loss

Latency has a floor set by physics — roughly 5 ms per 1000 km of fiber each way — plus queuing and processing delay on top. It bounds anything chatty: a protocol that does ten sequential round trips pays the RTT ten times, so a 100 ms RTT turns a "fast" operation into a one-second one regardless of bandwidth. Jitter is the standard deviation of latency; a path averaging 30 ms with 2 ms jitter is smooth, the same average with 40 ms jitter is unusable for anything real-time.

Loss is the cruelest of the three for bulk transfers, because TCP reads loss as congestion and slows down hard. A path with 1% loss does not lose 1% of throughput — it can lose half or more, because every dropped packet triggers a retransmit and a congestion-window cut. Map each metric to its victim: latency hurts chatty request/response protocols, jitter wrecks real-time media, and loss strangles bulk throughput.

How Loss Crushes TCP Throughput

The relationship is mathematical, not vague. For a TCP flow, throughput is bounded roughly by MSS divided by RTT times the square root of the loss rate — the Mathis formula. The square root is the sting: dropping the loss rate by a factor of four only doubles throughput, and raising loss from 0.01% to 1% cuts the ceiling by a factor of ten. Worse, the formula has RTT in the denominator, so the same loss rate hurts a long-distance link far more than a local one.

# iperf3 over a path with mild loss — note the retransmits
iperf3 -c host -t 10
# [ID] Interval        Transfer   Bitrate        Retr  Cwnd
# [ 5] 0.00-10.0 sec   112 MBytes  94.1 Mbits/sec  318  1.41 MBytes
# 318 retransmits = loss capping the window; bandwidth is not the limit

This is why "add more bandwidth" so often fails to fix a slow transfer. If the bottleneck is loss, a fatter pipe does nothing — the window keeps collapsing on every drop, and the average sits well below the link rate. The fix is to find and fix the loss, or switch to a congestion-control algorithm like BBR that does not treat every drop as a stop sign. Chasing bandwidth for a loss problem is throwing money at the wrong number.

Jitter and Real-Time Media

Real-time media — voice, video, gaming — cares more about jitter than raw latency. A VoIP call at a steady 120 ms one-way delay is perfectly usable; the same call averaging 60 ms but swinging between 20 ms and 180 ms is choppy and broken. The reason is the jitter buffer: the receiver holds arriving packets briefly to smooth out variation, and high jitter forces a deeper buffer that adds delay, or a shallow one that drops late packets as if they were lost.

So jitter converts into either added latency or effective loss, whichever the buffer is tuned to trade. This is why a connection that benchmarks well on average bandwidth and average ping can still sound terrible on a call — the average hides the variation, and the variation is exactly what the application cannot absorb. For real-time workloads, measure the spread, not the mean.

Bufferbloat and Active Queue Management

Bufferbloat is what happens when network gear ships with queues sized for throughput instead of latency. When the link saturates, packets pile into a giant buffer instead of being dropped, and TCP — which relies on loss as its congestion signal — never gets told to slow down until the buffer is enormous and full. The result is latency that climbs from 20 ms idle to 500 ms or more under load, while a naive idle ping test shows everything is fine.

The fix is active queue management: algorithms like CoDel and fq_codel that watch how long packets sit in the queue and drop or mark them early, signaling TCP to back off before the buffer bloats. CoDel targets a standing queue delay of about 5 ms; fq_codel adds fair queuing so one bulk flow cannot starve an interactive one. The way to catch bufferbloat is to ping continuously while running a heavy download — if the RTT jumps by hundreds of milliseconds under load, the queue is bloated and AQM is the cure.