How to Read Packet Loss Before Blaming the Cable

Two percent loss across a long ping run feels like a number you can act on, and it rarely is. It does not say where the replies went missing, whether they went missing together, or how any particular application experienced that interval. Loss spread evenly across a minute and loss clustered inside one exchange produce very different outcomes for the same percentage.

Compare three measures instead of trusting one: what the probe saw, what the interface counters did, and what the application actually waited for.

What a Ping Percentage Actually Measures

An echo probe tests one direction of one protocol with one packet size, at whatever rate you chose. A tunnel carrying a large upload is doing something else entirely, and a link that drops small probes is not necessarily the link that is hurting the transfer. The percentage also collapses the timing information that matters most, because ten lost replies in a burst are not the same as ten lost replies an hour apart. It cannot tell you which side of the tunnel dropped anything either.

Keep the probe result as a hint about the path. Then go looking for the timing and the boundary that produced it.

Compare Counter Deltas, Not Lifetime Totals

Take timestamped readings before and after the window in which the symptom appeared, at both endpoints and at any switch port you control. Record traffic volume alongside errors, discards and link-state changes, because a nonzero total that accumulated over months describes history rather than this incident. A counter that moved by three during the stall is a different observation from a counter that reads three thousand and never changed.

ip -s link show dev eth0
nstat -az TcpRetransSegs TcpExtTCPTimeouts
date -u +%Y-%m-%dT%H:%M:%SZ

Packets discarded because of receive errors and packets discarded for other reasons live in separate counters, and the distinction changes the follow-up. Error counters point at the physical or driver layer, while queue pressure and policy discards point somewhere above it. Preserve the direction and the interface name as well, since an uplink receive-error increase and a tunnel packet counter are not interchangeable.

If a driver exposes detailed physical counters, read them through that adapter's documentation. Assigning one meaning to every field named "drop" across two vendors is how a normal accounting quirk becomes a hardware diagnosis.

How a Lost Segment Becomes a Long Wait

An application can wait far longer than one round trip after losing a segment. TCP estimates the round-trip time, computes a retransmission timer from that estimate and backs off when a retransmission also fails, so a single lost segment at the wrong moment can stall a request for a noticeable interval. That mechanism is specified in RFC 6298, and it explains why a loss rate that looks trivial can still be felt.

Not every pause is a retransmission timeout, though. The same waiting can come from name resolution, a slow server, or an application retrying its own request after a failure. Separate those cases by aligning the failed operation with transport observations and with the tunnel's own session events. An interruption on the data path with no reconnect is a different event from a fresh handshake and credential exchange.

Where capture is permitted, keep it narrow. What you need is whether the expected packets or acknowledgements stop at a specific boundary, not the fact that some retransmission exists somewhere in a busy trace.

Change One Boundary Without Moving the Others

If the evidence points at a local link, substitute an approved cable or port as a controlled comparison and leave everything else alone. Keep the endpoint, the application and the workload comparable, and change exactly one boundary per attempt. Comparing a wired laptop against a wireless one while also switching exits and protocols tells you nothing you can attribute.

Clean local counters do not certify the rest of the path. They bound the part you can see, and the honest report says which boundaries were observed and which were not. What you want at the end is a statement that one observation changed when one intervention happened, not an anecdote about a bad cable promoted into a universal rule.