Packet Loss

Packet loss occurs when data packets sent across a network fail to reach their destination. It is expressed as a percentage. Even 1% packet loss causes TCP to slow down dramatically (the protocol halves its transmission rate on each lost packet). For real-time applications like gaming and VoIP, any packet loss is immediately noticeable.

How packet loss happens

Packets are dropped at specific points in the network path for specific reasons:

• Congestion and buffer overflow — when a router or switch receives more traffic than it can forward, it buffers packets in a queue. When the queue fills completely, new arriving packets are dropped. This is the most common cause of packet loss on ISP networks during peak hours.
• Physical layer errors — a faulty coaxial cable connector, a damaged Ethernet cable with a broken pair, or a corroded splice introduces bit errors that cause the receiving device to discard the corrupted packet.
• Wi-Fi interference — 2.4 GHz and 5 GHz bands share spectrum with neighbouring networks, microwave ovens, Bluetooth devices, and cordless phones. Collisions and retransmissions at the wireless layer appear as packet loss at the IP layer.
• Faulty network hardware — an overheating router, an aging cable modem, or a failing NIC can silently drop packets under load.
• ISP or transit congestion — oversubscribed nodes, peering point congestion, or undersized backhaul links drop packets at the ISP level, beyond your local network.

TCP behaviour under packet loss

TCP treats a lost packet as a congestion signal. When a packet is not acknowledged within the retransmission timeout, TCP enters a slow-start phase — it halves its congestion window and begins rebuilding throughput from scratch. Modern TCP variants like CUBIC and BBR handle this differently: CUBIC uses a cubic function to recover bandwidth aggressively after loss, while BBR uses bandwidth and round-trip time measurements to avoid loss-based congestion control entirely. Under sustained 1–2% loss, CUBIC TCP throughput can fall to 10–20% of the available bandwidth. BBR is more resilient but still degrades under persistent loss. The practical result: packet loss hurts download speeds far more than raw bandwidth numbers suggest.

How UDP applications handle packet loss

UDP has no built-in recovery mechanism — lost packets are simply gone. Applications built on UDP implement their own strategies:

• VoIP uses a jitter buffer to smooth delivery timing and Forward Error Correction (FEC) — sending redundant data so that a lost packet can be reconstructed from surrounding packets without retransmission.
• Online games accept some loss for movement updates (dead reckoning interpolates the missing position) but retransmit reliable game events like player actions using their own application-layer acknowledgement.
• Video streaming over UDP (RTP/RTSP) uses redundant streams, error concealment, and adaptive bitrate to hide loss from the viewer.

Acceptable packet loss thresholds

How to measure packet loss

A standard speed test samples packet loss over only a few seconds and may miss intermittent loss. Better methods:

• ping -c 100 8.8.8.8 (Linux/macOS) or ping -n 100 8.8.8.8 (Windows) — sends 100 ICMP packets and reports the percentage lost. Run for several minutes to catch intermittent loss.
• MTR (Matt's Traceroute) — combines traceroute and continuous ping, showing packet loss at every hop between you and a destination. Useful for pinpointing where in the path loss occurs.
• iperf3 -u -b 10M -t 60 — sends UDP traffic at a specified rate and reports the exact loss percentage. More accurate than ICMP because it generates real traffic load.

Wi-Fi loss vs WAN loss

Diagnosing the location of packet loss matters because the fix is different. To distinguish Wi-Fi loss from WAN (ISP) loss, connect your device directly to the router via Ethernet and run the same packet loss test. If loss disappears on wired, the problem is in the wireless segment — channel congestion, interference, or weak signal. If loss persists on wired Ethernet, the problem is between your router and the internet — likely the ISP's network, the cable modem, or the physical drop cable from the street.

Common home causes and fixes

• Bad coaxial connector — a loose or corroded coax F-connector between the wall and cable modem introduces signal noise that causes upstream packet loss. Replace the connector or the entire coax run.
• Overloaded router — consumer routers have limited CPU and memory. Under load from many simultaneous connections (especially with QoS or VPN enabled), they drop packets. A reboot may help temporarily; upgrading the router is the permanent fix.
• ISP congestion — if loss only occurs during evening peak hours and resolves overnight, the ISP's node is oversubscribed. Document the loss with MTR reports and contact the ISP.
• Split coax splitter — each splitter on a coax run reduces signal level by 3.5 dB. Excessive splitting weakens the cable modem's signal to the point where upstream packets are corrupted.

Frequently Asked Questions

Does packet loss affect streaming?

Buffered streaming (Netflix, YouTube) absorbs occasional packet loss by buffering ahead. You may see a quality drop but rarely a full stall unless loss exceeds 3–5%. Real-time streaming (Twitch, Zoom) has no buffer — packet loss immediately degrades quality.

How do I fix packet loss?

Check physical cables first — replace any coax or Ethernet cable that is kinked, damaged, or older than 10 years. Then test on wired Ethernet to rule out Wi-Fi. If packet loss persists on wired, contact your ISP — the problem is likely at the node or in your drop cable.

Can a VPN cause packet loss?

A VPN adds encryption overhead and routes through an extra server, which can introduce small amounts of packet loss (0.1–0.5%) if the VPN server is under load. If you have packet loss, test with and without the VPN to isolate the cause.