What Is Packet Loss? – Definition and How It Works
Learn what packet loss is, how it degrades throughput far more than latency, and how to measure and mitigate it.
Packet loss is data that never reaches its destination. TCP retransmits lost segments, so a connection still works — but the retransmission and the congestion response cost far more than the lost bytes.
1. Why a Small Loss Rate Hurts a Lot
The damage is not the lost data. It is TCP's reaction to it.
TCP treats loss as a congestion signal and reduces its sending rate. Repeated loss keeps the window small, so throughput collapses well out of proportion to the loss rate. A few percent loss can cut effective throughput dramatically, and the effect worsens with distance because each recovery takes a round trip.
That is the counter-intuitive part worth remembering: 2% loss is not a 2% problem.
2. Where It Comes From
| Cause | Character |
|---|---|
| Congestion | Queues overflow, packets dropped |
| Wireless interference | Radio errors on Wi-Fi and cellular |
| Faulty hardware | A bad cable, port, or transceiver |
| Overloaded middlebox | A saturated firewall or proxy |
| Rate limiting by policing | Deliberate drops above a rate |
| Routing changes | Brief loss during reconvergence |
The last two matter in collection work: a policer drops packets rather than rejecting requests, so deliberate throttling appears as loss.
3. Measuring It
ping -c 100 example.com # loss percentage over 100 probes
mtr --report --report-cycles 100 example.com # per-hop loss along the path
mtr is the more useful of the two because it localises the problem. One caveat that causes constant misdiagnosis: loss shown at an intermediate hop is often not real. Routers deprioritise ICMP responses to themselves, so a middle hop can show loss while traffic passes through it fine.
The rule: only loss at the final hop, or loss that persists at every hop after a point, indicates a genuine problem.
4. What It Looks Like From an Application
Packet loss rarely announces itself. It presents as:
- Slow transfers with no error, since TCP recovers but slowly.
- Timeouts on large responses while small ones succeed.
- Inconsistent performance — the same request fast then slow.
- Truncated bodies where a client accepts a partial read after a stalled connection.
- TLS handshake failures, when a handshake packet is lost and the retry exceeds a timeout.
Small responses often complete within a single window and are unaffected, which is why the symptom looks size-dependent.
5. Loss Versus Bandwidth Throttling
Both slow large transfers. The discriminator:
- Throttling produces a steady, often round-numbered rate ceiling.
- Loss produces a sawtooth — bursts of speed interrupted by stalls, with high variance.
A capture showing retransmissions confirms loss; a smooth constant rate with no retransmissions indicates a policy limit.
6. Mitigation
Fix the cause where you can. A bad cable, a saturated uplink, or an overloaded proxy is fixable, and no amount of client tuning substitutes.
Reduce concurrency. If you are the congestion, fewer connections means less loss and higher total throughput — which is the case where slowing down makes you faster.
Shorten the path. Fewer hops and less distance means less exposure and faster recovery. Proxy geography matters here as much as it does for latency.
Prefer fewer, larger connections over many small ones, so recovery costs are paid less often.
Consider QUIC. Per-stream loss recovery means one lost packet does not stall every multiplexed stream, which is a genuine improvement on a lossy path.
Set read timeouts, not total timeouts, so a slow-but-progressing transfer is not killed while a stalled one is.
7. Verify Completeness
Because loss can produce truncation behind a successful status, transport health is not enough. Check the content: byte count against Content-Length, a JSON parse, a closing tag, a plausible record count.
This is the same discipline that catches bandwidth throttling and chunked-stream truncation, and it is the only thing that turns a silent data-quality failure into a caught error.
8. Summary
Packet loss is data that never arrives, and its cost is TCP's congestion response rather than the lost bytes — so a few percent loss can cut throughput far out of proportion, especially over long paths.
Measure it with mtr while ignoring apparent loss at intermediate hops, distinguish its sawtooth pattern from throttling's steady ceiling, reduce concurrency when you are the congestion, shorten the path, and verify response completeness because loss can truncate a body behind a 200.