When Average Loss Numbers Miss the Failure That Actually Happens

An average packet loss figure tells you very little about whether an application will survive that much loss. What decides the outcome is how the loss arrives, so a test setup has to be configured for the pattern, not just the percentage.

Spread evenly, 5% loss is fairly mild. The odd packet goes missing with healthy traffic either side of it, and recovery deals with it before anyone notices. Bunch that same 5% into bursts and you get stretches where nothing arrives at all. The figure on the report doesn’t change, but what the receiver experiences is something else altogether.

Bursts remove the signal recovery depends on

The reason comes down to how classic loss recovery finds out something’s gone wrong. It depends on the packets after the lost one turning up. Each of those arrivals prompts a duplicate acknowledgement, and once the sender has seen three, it retransmits straight away rather than waiting. It’s a bit like noticing a missing page in a book because the page numbers jump. A burst takes out the very pages that would have shown the jump. The sender hears nothing, falls back to a full retransmission timeout, and the connection’s sending rate collapses while it rebuilds from the bottom.

None of this is a fringe idea. The Gilbert-Elliott two-state model goes back to the early 1960s, and it exists because uniform random loss didn’t match how real channels behaved. It flips between a good state and a bad one, so losses cluster the way they do on a congested or noisy link. It’s still a model, mind. A two-state chain tuned to resemble a wireless hop isn’t a recording of that hop on its worst afternoon. But it gets the shape of the failure roughly right, which a flat percentage never does. The same clustering is why redundancy often disappoints, since a backup copy sent close behind the original tends to land in the same bad patch.

Protocols adapted. Test plans mostly didn’t

Protocol designers took this on board a while ago. RACK and Tail Loss Probe moved TCP towards time-based detection, and QUIC handles loss on timers as well, because waiting for duplicate acknowledgements during a burst means waiting for a signal the burst has already removed. It’s a real improvement, though it has a ceiling. A burst long enough to wipe out everything in flight leaves nothing to detect, so the stall still happens, just with better bookkeeping. Satellite links go further and interleave data deliberately, turning one long physical burst into scattered single losses that error correction can repair, and some real-time media schemes do something similar with their forward error correction. Most ordinary application traffic gets none of that.

What I find odd is that testing hasn’t followed. The people building protocols have designed around clustered loss for years, while plenty of the people checking whether an application survives real conditions still set one percentage and call it done. Fair enough, a single dial is quick to set and easy to explain to whoever signs off. That convenience is the problem, though, because it quietly picks the gentlest version of the loss you claimed to have tested.

Burst-aware testing won’t predict the exact bad day your users have. What it does is put the application through the kind of loss that breaks recovery, rather than the kind recovery was always going to absorb. A pass against evenly spread loss mostly tells you the average was survivable, and I’d want to know a fair bit more than that before signing anything off.