Some providers rate limit how often they respond with the TTL-exceeded ICMP packets used by traceroute and PING. This is done to prevent attacks against their routers, since responding to these packets requires much more CPU time than simply forwarding the packet does. If the router is set up to ratelimit, it will respond to a certain number of traceroute packets per second, and once that many have been received, it will stop responding to them for that second, which will appears as packet loss. In other words, you are not losing any "real" traffic.

ICMP ping is not typically the best indicator of packet loss for these following reasons:

1. Interpreting where the packet was lost. Because you have no idea whether the request ever made it to the host, or the reply got lost on the return, it is hard to pinpoint where on the network the packet loss occurred. You only know that the ping failed to get a response.

2. Network queueing. ICMP pings usually have the lowest priority across a network end-to-end. Therefore, if any router along the path is saturated with packets, then the ICMP ping is likely to be the first to get dropped by that router. Regular applications may exhibit no packet loss; yet, the ping tests will show packet loss.

3. ICMP filtering. Pings are often used as a method for producing denial of service (DoS) attacks or attempts to discover a network topology. For this reason, many firewalls are configured to block ICMP pings. Additionally, many desktop operating systems and routers have mechanisms for minimizing the number of ICMP pings they will respond to in a given time frame. Therefore, it's possible to get failures when, in fact, there is connectivity, leading to false positives with regards to packet loss.