Packet loss

Data crosses a network in packets, and some go missing: a congested router drops them, a weak Wi-Fi signal corrupts them, or a faulty cable or port damages them. RFC 7680, the IETF's one-way loss metric, counts a packet as lost when the destination does not receive it within a set waiting time, so a packet that arrives far too late is lost for practical purposes too.

What loss does depends on the application. A download over TCP retransmits each missing packet, so loss shows up as lower speed rather than missing data. A call or a game uses packets that are worthless once late, so loss shows as dropped words, frozen video, or a character that jumps and rubber-bands. In a live call even a small share of lost packets can be heard.

Not measured: a loss test needs a relay server at the other end, and we do not run one. A browser can only send ordinary web requests, which the transport retransmits, so the page never sees the loss itself. The jitter and bufferbloat tests do measure the delay that usually travels with it: a line that queues badly under load is also the line most likely to drop packets when the queue overflows. For loss itself, a native tool that sends its own probes, or a game's network statistics overlay, reads it.