What is packet loss?
Packet loss is data packets that fail to reach their destination. We cover causes, the impact on TCP and real-time traffic, and how to diagnose it with MTR.
Last updated:
Packet loss is when one or more IP packets sent across a network fail to reach their destination. It is measured as the percentage of packets lost relative to packets sent, so 2% loss means two out of every hundred packets disappeared in transit. Loss is a normal part of how the IP-based internet works, since it delivers packets on a best-effort basis with no guarantee of delivery, but above a certain threshold it clearly degrades service quality and needs to be diagnosed.
How packet loss affects traffic
The impact of loss depends on the protocol. TCP detects missing segments and retransmits them, so the data eventually arrives, but at the cost of added delay and reduced throughput, because the congestion-control mechanism shrinks the window on every loss. UDP and real-time traffic do not retransmit, so loss translates directly into distortion.
- TCP: retransmissions, a smaller congestion window and lower effective throughput, especially on high-RTT links.
- VoIP and video conferencing: choppy audio and visual artifacts; even 1% loss is usually audible.
- Online gaming and live streaming: latency spikes, desynchronization and stalled video.
- DNS over UDP: timeouts and repeated queries that lengthen name-resolution time.
Common causes of packet loss
Packet loss usually has one of a few recurring causes, and telling them apart decides whether you fix it effectively. The most common reason is link congestion: when the queue on an interface overflows, the router discards the excess packets (tail drop). On top of that come physical-layer problems, configuration errors and deliberate traffic limiting.
- Congestion and queue overflow on a saturated link or peering port.
- Layer-1 faults: a damaged cable, a dirty or failing optical module, CRC errors on the interface.
- MTU mismatch and fragmentation, causing large packets to be dropped (PMTUD black holes).
- Overloaded or misconfigured hardware, router CPU exhaustion, a faulty QoS policy.
- Policing and rate-limiting that intentionally drop traffic above a configured threshold.
Diagnosing it with MTR
MTR (My Traceroute) combines traceroute with ping and sends a continuous stream of probes to every hop on the path, showing latency and loss percentage per hop in real time. This lets you locate where packets start to disappear. The output still needs careful reading. Loss seen only at a single intermediate hop that does not propagate further almost always comes from that router rate-limiting ICMP (deprioritizing probes aimed at its control plane), not from real loss of transit traffic. A genuine problem is loss that appears at a hop and persists across all subsequent hops through to the destination. Run MTR in both directions, because internet paths are often asymmetric and loss in one direction does not imply loss in the other.
A clean path across the AS202520 SkyPass network
Low packet loss follows directly from a well-engineered, uncongested network. AS202520 SkyPass keeps capacity headroom on its transit and peering links and peers at Polish internet exchanges (THINX, TPIX, WRIX, 1-IX), so domestic traffic stays short and stable. Our public looking glass lets you verify BGP paths and run ping and traceroute from our PoPs in Warsaw and Wrocław, while IP transit and DDoS protection shield you from loss caused by congestion during volumetric attacks.
Frequently asked questions
What level of packet loss is acceptable?
On a backbone and transit link you expect loss close to 0%. For TCP a noticeable throughput drop begins at a few tenths of a percent, and for VoIP and video even 1% loss is usually audible. Sustained loss above 1% warrants investigation.
Why does MTR show loss at an intermediate hop but not the final one?
This is almost always an artifact: that router rate-limits ICMP replies aimed at its control plane and deprioritizes MTR probes. Since the loss does not propagate to later hops through to the destination, transit traffic is not being lost and there is no real problem.
How is packet loss different from jitter and latency?
Latency is how long a packet takes to arrive, jitter is the variation in that latency, and packet loss is packets that never arrive at all. All three can be symptoms of the same cause, such as queue congestion, but they are distinct metrics.
Does packet loss always mean a fault?
No. Occasional, isolated loss is inherent to a best-effort network and is masked by TCP retransmission. The problem is loss that is sustained, high or localized to a specific link, which degrades services.