What is packet loss and how do you diagnose it?

Packet loss is when packets sent across a network fail to arrive, usually because a link is congested, a device drops them or a transmission error corrupts them. TCP hides some of it by resending, which costs speed. Voice and video do not resend, so you hear or see it.

How is it defined?

The IETF's IP Performance Metrics work defines it precisely. RFC 2680 specifies a one-way packet loss metric: for a packet sent from a source to a destination at a given time, the value is zero if the packet was received and one if it was lost. Measurement takes a sample of such observations, taken at times drawn from a random (Poisson) process so the sampling does not line up with periodic network behavior, and then reports statistics, usually the fraction lost. The RFC's structure is a single observation, a sample, then statistics, with clear separation between them.

That definition is useful in practice. Loss is a rate over time and over a path, in one direction. A single dropped ping tells you little.

Why does it happen?

• Congestion. A link or queue is full, so the router drops packets.
• Faulty hardware or media. A bad cable, connector, optic or wireless interference corrupts packets.
• Misconfiguration. Duplex mismatches, wrong maximum transmission unit settings or rate limits.
• Overloaded devices. A firewall or router that runs out of CPU or memory.
• Wireless conditions. Distance, interference and busy channels.
• Deliberate dropping. Policies that rate limit or discard certain traffic, including during denial of service attacks.

What does it do to applications?

The internet design anticipates loss. RFC 1122 lists packet loss, delay, reordering and packet size limits among the variations a host must tolerate. TCP recovers by retransmitting. RFC 5681 defines TCP's congestion control algorithms: slow start, congestion avoidance, fast retransmit and fast recovery. In general, TCP treats loss as a sign of congestion and slows its sending rate. So modest loss can cut throughput sharply on a long path even when the link has spare capacity. Real time traffic over UDP, such as voice, has no built-in resend, so lost packets become gaps.

How do you diagnose it?

Work from the whole path to the specific hop.

1. Measure end to end. Send a steady stream of probes in both directions over several minutes and record the loss rate. One direction may be bad while the other is clean.
2. Compare times. If loss peaks at certain hours, suspect congestion. If constant, suspect hardware or configuration.
3. Walk the path. Use per-hop tools that report loss at each router. Be careful: some routers deprioritize replies to probes, so loss shown only at one intermediate hop and not later hops is often harmless.
4. Check interface counters. Errors, discards and drops on switch and router ports point at the faulty link or full queue.
5. Swap and isolate. Replace the cable, move to another port, or test from a wired connection to rule out wireless.
6. Check device load. Look at CPU, memory and connection table use on firewalls and routers.

A constructed example

A branch office complains that video calls are choppy every afternoon, but file downloads are fine. A two-minute probe stream from the branch to head office shows 0.1 percent loss in the morning and 4 percent from 2 to 5 pm, always in the branch to head office direction. Interface counters on the branch router show output drops on the uplink at those times. The uplink is saturated by a nightly backup that was rescheduled into the afternoon. Moving the backup, and putting voice traffic in a priority queue, clears the problem. A cable swap would have changed nothing.

How does this relate to security?

Sudden loss can be a symptom of attack, such as flooding, or of a failing security device in the path. Include network performance data in your monitoring. NIST SP 800-53's SI-4 control on system monitoring includes analyzing communications traffic anomalies.

How to check or apply this

1. Define acceptable loss for each application, for example near zero for voice and a little higher for bulk transfer.
2. Run continuous probes between key sites and alert on sustained loss.
3. Record interface errors and drops and review them weekly.
4. When loss appears, test both directions and several times of day before changing anything.
5. Treat unexplained loss on a security device as a possible capacity or attack issue.

Quick check

Sources

• RFC 2680, A One-way Packet Loss Metric for IPPM
• RFC 1122, Requirements for Internet Hosts: Communication Layers
• RFC 5681, TCP Congestion Control
• NIST SP 800-53 Rev. 5, SI-4 System Monitoring

Last reviewed: 18 October 2026.