All IP packets are initially sent with a Time-To-Live (TTL) field set to a suitable number. Each time an IP packet passes through an IP router, its TTL is reduced by one. When the TTL reaches zero, the packet is discarded. This strategy is to prevent IP packets circulating endlessly on the internet in the event of a router
misconfiguration leading to a circular route.

Each traceroute query is sent with a very small TTL. When the query's TTL reaches zero, instead of being totally discarded, an ICMP TTL-exceeded warning packet is returned to the sending address, where the traceroute program is waiting to time its return. For the first hop, the TTL is initialised to one, three
queries are sent and timed. Then the initial TTL is increased by one, three queries sent and timed, and so on. This repeats until the IP number that replies to the query does so with an echo instead of an ICMP TTL-exceeded. This indicates that it is the sought host, rather than an intermediate router.

How traceroute can mislead
Windows PCs have poor clocks, and are incapable of measuring with a resolution of a millisecond. Study of the RTTs above will show they are strongly quantised to be close to multiples of 6.8 ms. This means that slight differences in RTTs can either (a) show an apparent 7 ms jump, or (b) show no change at all.

But nothing inbetween. Windows 2000 appears to have an even worse resolution of 10 ms. The route displayed is only the outward route taken by the probes. It is impossible to infer by what route the replies came back. It is possible for the return route to be different to the outward route, and involve a different number of hops. It is possible for every router shown to have a different return path to the sender. Those different return routes will add their own different contributions to the RTTs shown.

This can lead to sudden steps in RTT up or down compared with the previous hop or the next hop. Modern routers give priority to real data packets, and very low priority to returning TTL-exceeded ICMP packets. So RTTs on intermediate routers can be anomalously high, such as those shown on hop 3 above. Routers
can drop these packets altogether, as in hop 4. In both cases, reasonable RTTs and lack of packet loss on all the subsequent queries which must have passed through these routers in order to produce results for later hops show that the routers at hops 3 and 4 are in reasonable working order.

The RTTs on the final line will be more reliable, because they are echoes from the traced host, rather than a router. The RTT on the final line is the only one that matters when checking lag times to game servers etc.