Packet loss is the failure of one or more data packets to reach their destination, usually expressed as a percentage of packets sent over a measurement interval. In networking and network monitoring, it is one of the core health metrics alongside latency and jitter, because even a small loss rate can sharply reduce throughput and degrade voice and video quality.
Loss happens when a device drops a packet deliberately, for example because a queue is full, or when a packet is corrupted in transit and discarded after a failed checksum. Monitoring therefore aims not only to measure loss, but to locate where and why it occurs.
Why packets are lost
Most packet loss in wired networks comes from congestion: a router or switch receives traffic faster than it can forward it, its buffer fills, and new packets are dropped. The remaining causes are physical errors, configuration faults and deliberate policy decisions.
| Cause | Mechanism | Typical evidence |
|---|---|---|
| Congestion | Queue overflow on a busy link | Output drops, loss rising with utilization |
| Physical errors | Bit errors from cabling, optics or interference | CRC and FCS errors on interface counters |
| Duplex mismatch | One side half duplex, the other full | Late collisions, heavy loss under load |
| Wireless interference | Collisions and weak signal on radio links | Retries, low data rates, high noise floor |
| Policing and rate limits | Traffic above a contracted rate is discarded | Drops at a fixed throughput ceiling |
| MTU problems | Oversized packets dropped when fragmentation is blocked | Small packets work, large transfers stall |
Some loss is normal and intentional. TCP congestion control probes for available bandwidth until a queue overflows, and active queue management such as RED or CoDel drops packets early on purpose to keep queues short.
How much packet loss is acceptable
Acceptable loss depends on the application and its transport. TCP traffic recovers by retransmission but slows down, while real-time media over UDP simply loses the missing audio or video data.
| Traffic type | Generally good | Noticeable degradation |
|---|---|---|
| Voice over IP | Below 0.5 percent | Above about 1 percent |
| Video conferencing | Below 0.5 percent | Above 1 to 2 percent |
| Online gaming | Close to 0 percent | Above about 1 percent |
| Bulk TCP transfers | Below 0.1 percent on long paths | Throughput collapse even near 1 percent |
| Backbone and data center links | Effectively 0 percent | Any sustained loss |
The impact on TCP grows with distance. The well-known Mathis approximation states that TCP throughput is roughly proportional to MSS divided by round-trip time times the square root of the loss rate. In practice, 0.1 percent loss on a 100 ms path can limit a single connection to a few tens of megabits per second, regardless of link capacity.
Burst loss matters more than average loss. Ten consecutive lost packets hurt a voice call far more than ten isolated losses spread across a minute, so good monitoring records loss patterns, not only percentages.
Measuring and monitoring packet loss
Loss can be measured actively, by sending test traffic, or passively, by reading device counters and observing real traffic. Each approach sees a different part of the picture.
| Method | What it measures | Limitation |
|---|---|---|
| Ping | Loss of ICMP echo along one path | Routers often deprioritize ICMP replies |
| MTR or pathping | Loss per hop over many probes | Intermediate hop loss is often misleading |
| SNMP interface counters | Discards and errors per interface | Polling intervals hide short bursts |
| Packet capture | Retransmissions and gaps in real flows | Requires capture at the right point |
| TWAMP or synthetic probes | One-way loss, latency and jitter | Needs agents or supported devices |
| RTP statistics | Loss and jitter in media streams | Applies only to real-time traffic |
In Wireshark and other packet capture tools, loss appears indirectly as TCP retransmissions, duplicate acknowledgments and selective acknowledgment blocks. A high retransmission rate on the server side of a capture usually confirms loss somewhere along the path.
Packet loss compared with latency and jitter
Packet loss, latency and jitter are closely linked symptoms of the same underlying conditions. Growing queues first raise latency and jitter, and only when buffers overflow does loss appear.
- Latency is the time a packet needs to cross the network; congestion increases it before packets are dropped.
- Jitter is the variation in latency; large jitter can cause late packets to be discarded by a receiver buffer, which counts as effective loss for voice.
- Packet loss is the final outcome when buffers, links or devices cannot deliver the packet at all.
A path with low loss but very high latency under load often suffers from bufferbloat: oversized buffers avoid drops but add hundreds of milliseconds of delay.
Common diagnostic mistakes
Packet loss is easy to misdiagnose, because the place where it is observed is rarely the place where it happens. A few rules prevent most false conclusions.
- Loss at an intermediate hop in MTR that does not continue to later hops is control-plane rate limiting, not real loss.
- Check both directions, because routing is often asymmetric and loss may exist only on the return path.
- Compare error counters before and after a test window; old totals since the last reboot say little about current conditions.
- Test with realistic packet sizes, since small ICMP probes may pass while full-size packets fail on an MTU problem.
- Correlate with utilization: loss that rises with traffic points to congestion, while constant loss points to a physical fault.
Understanding it simply
Data travels across a network in many small envelopes called packets. Packet loss means some envelopes never arrive. Most often, a busy point along the way gets more mail than it can handle and throws some away.
For a file download, the missing envelopes are sent again, so the file arrives complete but more slowly. For a phone or video call, there is no time to resend. The listener hears gaps or robotic sound instead. That is why even a small share of lost packets matters.
Applied in practice
A company with two offices complains about choppy video calls every afternoon. The network team sets up synthetic probes every 10 seconds between the sites and graphs loss, latency and jitter together with link utilization from SNMP.
The graphs show 2 to 3 percent loss only between 2 p.m. and 5 p.m., exactly when the 100 Mbit/s inter-office link reaches full utilization during daily backups. Interface counters confirm output drops on the router, and error counters stay at zero, which rules out cabling. The team moves the backup to the night and adds a quality of service policy that prioritizes voice and video. Afternoon loss for calls falls below 0.1 percent, and the complaints stop.