EMZETT.Data Loss
In short: The state in which data packets don’t arrive on their way from sender to recipient — e.g. due to overloaded lines, interference or defective hardware.
In more detail: With TCP, data loss is detected and the packet is automatically resent; with UDP it isn’t — there the application itself has to decide whether and how to deal with it (e.g. a brief picture dropout in streaming instead of waiting for a redelivery). Often stated as a percentage of the packets sent (“packet loss”).
In Depth
The three main causes
The most common causes of data loss in a network can be roughly divided into three groups. Congestion is the most common: a router or switch receives more packets than it can hold or forward in its limited buffer and discards excess packets (“congestion drop” or “tail drop”) — this typically happens at bottlenecks where a fast line feeds into a slower one. Physical interference is the second group: defective or poorly shielded cables, electromagnetic interference with Wi-Fi (e.g. from other radio sources in the same frequency band), or simply faulty hardware such as an ageing switch port. The third group is deliberate dropping by firewalls or quality-of-service (QoS) rules, which deliberately give certain traffic lower priority during bottlenecks or even block it completely, for example to give critical applications such as video calls priority over less time-critical traffic such as software updates.
Reaction depending on the transport protocol
How strongly data loss has an effect depends crucially on the transport protocol. TCP detects missing packets through missing ACKs (or duplicate ACKs) and resends them automatically — the loss therefore basically stays invisible to the application, but costs time (retransmission delay) and, at a high loss rate, can make the entire throughput collapse drastically, because TCP’s flow control mechanism (more precisely: congestion control algorithms such as CUBIC or BBR) interprets packet loss as a congestion signal and throttles the sending rate significantly so as not to overload the network further. Beyond a certain loss rate (often from just a few percent), TCP throughput drops disproportionately, because sender and receiver are constantly in a cycle of speeding up and throttling again.
UDP, on the other hand, doesn’t care about lost packets at all — there’s neither acknowledgement nor automatic retransmission. In video streaming this shows up as a brief picture glitch or stutter instead of a noticeable delay, which for real-time applications (VoIP, online gaming, live streaming) is often the better compromise than TCP’s waiting for a redelivery that would arrive too late to be useful anyway — an outdated, belatedly delivered video frame is of no use to anyone.
Metrics and typical thresholds
Packet loss is usually stated as a percentage of the total packets sent. As rough guidelines: below 1% usually goes unnoticed, 1–2.5% is already noticeable in real-time applications (slight dropouts in video calls), above 5% makes video calls or online gaming practically unusable. Pure web/streaming use tolerates comparatively more loss, because TCP and buffering can compensate for much of it.
Diagnostic tools
In practice, packet loss can be diagnosed with tools such as ping (shows the loss rate over several requests, but only for ICMP traffic, which firewalls may treat differently from the actual application traffic) or mtr/traceroute — the latter additionally show on which specific hop in the multi-stage transmission path the loss actually occurs, which makes narrowing down the problem (your own network, ISP or target server) much easier.
See also: Flow control, TCP, UDP, Latency