Packet loss occurs when one or more packets transmitted across a network fail to reach their intended destination successfully. In packet-switched networks, information is divided into packets that travel through network infrastructure, and individual packets can be lost because of congestion, damaged links, wireless interference, device failures, routing problems, software faults or other conditions. Packet loss is normally expressed as a percentage or count over a defined measurement period.
A measured loss rate of 1 percent, for example, means that approximately one packet out of every hundred tested packets failed to produce the expected result, although the exact meaning depends on the measurement methodology. Packet loss is important because applications often rely on timely and complete delivery, and lost packets may need to be retransmitted or may simply be unavailable to the receiving application.
Congestion is one of the most common causes of packet loss. Network links and device interfaces have finite capacity, and routers and switches use buffers to temporarily hold packets waiting for transmission. When packets arrive faster than they can be forwarded, queues grow. If a buffer becomes full, newly arriving packets may be discarded. This is commonly called tail drop when packets are discarded after the queue reaches its configured limit.
Active queue management mechanisms can deliberately drop or mark packets earlier to control queue growth and congestion. Packet loss can therefore be a deliberate network-control mechanism as well as the result of an unexpected fault. TCP interprets loss as a signal of congestion or transmission problems and generally reduces its sending rate, which can reduce throughput.
Wireless networks experience packet loss for additional reasons. Radio signals can be weakened by distance, walls, interference and obstacles, while competing transmissions can corrupt or prevent successful frame delivery. Wi-Fi devices use link-layer acknowledgements and retransmissions to recover from many transmission failures before an application sees a lost IP packet. Consequently, a noisy wireless environment may cause significant radio-level retransmissions without producing an equivalent level of application-visible packet loss.
If repeated attempts fail or timeouts occur, however, packets can ultimately be discarded. Mobile and other wireless technologies use their own error-correction and retransmission mechanisms, so the point at which a loss becomes visible to higher layers varies according to the technology and protocol stack.
Packet loss has different effects depending on the transport and application protocol. TCP is designed to provide reliable, ordered delivery, so it retransmits missing data and adjusts its congestion-control behaviour when loss is detected. The user may therefore experience slower transfers rather than missing file contents. UDP does not itself guarantee delivery, ordering or retransmission, so an application using UDP must decide how to handle missing packets.
Real-time voice and video systems may prefer to continue playing with a small amount of missing data rather than waiting for retransmissions that arrive too late to be useful. Some applications use forward error correction, interpolation or redundant information to mitigate loss. The practical impact of a given loss percentage therefore depends heavily on the application and whether the missing information can be recovered or tolerated.
Packet loss is closely related to latency and jitter. Congestion can cause packets to spend longer in queues, increasing latency, and if queues overflow, packets may subsequently be dropped. Retransmissions caused by loss can add additional delay to reliable protocols, making an application appear slower even if the underlying physical path is unchanged. Variable queueing and retransmission times can also increase jitter.
A network with zero measured loss but extremely high latency can still perform poorly for interactive applications, while a network with small intermittent loss may be acceptable for some resilient applications. Network diagnostics therefore examine loss alongside RTT, jitter, throughput and application-level response times rather than interpreting packet loss in isolation.
Packet-loss measurements must also account for where the test is performed. If a diagnostic packet is sent from a computer to an intermediate router and that router deprioritises diagnostic traffic, the router may fail to respond even though it forwards normal transit traffic successfully. This can create apparent loss at one hop that does not continue to the final destination. Similarly, some network devices rate-limit ICMP responses without dropping transit packets.
A meaningful diagnosis therefore looks for loss that persists to the destination and correlates with application behaviour. Tools such as ping, traceroute variants and continuous monitoring can help identify patterns, but their results need to be interpreted in the context of the protocols and devices involved.
Packet loss can occur at many points in the path. A damaged Ethernet cable, failing optical transceiver, overloaded interface, duplex mismatch in older Ethernet environments, faulty network device, wireless interference, congested ISP link, routing problem or destination overload can all contribute. Error counters on network interfaces can reveal physical-layer or link-layer problems, while switch and router statistics can identify discarded packets caused by congestion or policy.
Monitoring systems can record loss over time and correlate it with interface utilisation, errors, queue depth and other events. Intermittent loss can be more difficult to diagnose than continuous loss because it may occur only during peak utilisation, particular radio conditions or specific routing paths. Effective troubleshooting therefore considers timing, location and correlation rather than simply repeating a single test.
Packet loss is not necessarily evidence that the entire network is malfunctioning, and a small amount of loss does not have a universal significance independent of application and measurement conditions. Some network protocols intentionally discard packets during congestion because controlled loss can help prevent congestion from becoming worse. On the other hand, persistent loss on a stable wired connection can indicate a configuration, physical or capacity problem that warrants investigation.
The important questions are where the loss occurs, whether it reaches the final destination, how frequently it occurs, whether it is correlated with congestion or physical errors, and what effect it has on the application. Packet loss is therefore best understood as a measurable characteristic of packet delivery whose significance depends on its magnitude, persistence, location, cause and interaction with the protocols using the network.
