Here is the result of two mtr
reports on ipv4 and ipv6 to google.com
I had very consistent lag spikes when ipv6 was enabled. I disabled ipv6 and all my lag spikes disappeared. I concluded the problem was the node that had 80% loss on the ipv6 report.
I showed this graph to a very experienced network engineer, and he told me that this did not indicate a problem. He said it was likely but not certain that the node with 80% loss was a result of the router dropping the ping when the TTL was 0 because the offloading of the packet from the optimized network ASIC to the CPU was full.
Is it true that this report does not indicate a problem.
(sorry for the screen shot, I no longer have it in text form)
Like ping and traceroute, mtr relies on intermediate hops returning an ICMP time exceeded for the probe packets.
ICMP processing is very low priority though and commonly limited in frequency. That means that you can not reliably deduce there's general packet loss on a certain hop when you see ICMP message loss indicated. In contrast, if subsequent hops show no packet loss at all, it's ICMP handling or rate limiting you see, not actual packet loss.
It is a rate limiting on those nodes.
If the packet loss was caused by congestion all next hops until destination would observe some packet loss.
Just try to use:
mtr -i 20 www.google.com