2

I'm seeing similar output to that on the traceroute manpage, but I've always been curious on why ping times go down between hops? I.e., I'd always expect values to increment from hop to hop like:

 [yak 71]% traceroute nis.nsf.net.
 traceroute to nis.nsf.net (35.1.1.48), 64 hops max, 38 byte packet
 1  helios.ee.lbl.gov (128.3.112.1)  19 ms  19 ms  0 ms
 2  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  39 ms  19 ms
 3  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  39 ms  19 ms
 4  ccngw-ner-cc.Berkeley.EDU (128.32.136.23)  39 ms  40 ms  39 ms
 5  ccn-nerif22.Berkeley.EDU (128.32.168.22)  39 ms  39 ms  39 ms
 6  128.32.197.4 (128.32.197.4)  40 ms  59 ms  59 ms
 7  131.119.2.5 (131.119.2.5)  59 ms  59 ms  59 ms
 8  129.140.70.13 (129.140.70.13)  99 ms  99 ms  80 ms
 9  129.140.71.6 (129.140.71.6)  139 ms  239 ms  319 ms
 10  129.140.81.7 (129.140.81.7)  220 ms  199 ms  199 ms
 11  nic.merit.edu (35.1.1.48)  239 ms  239 ms  239 ms

But what is the reasoning for:

 [yak 72]% traceroute allspice.lcs.mit.edu.
 traceroute to allspice.lcs.mit.edu (18.26.0.115), 64 hops max
 1  helios.ee.lbl.gov (128.3.112.1)  0 ms  0 ms  0 ms
 2  lilac-dmc.Berkeley.EDU (128.32.216.1)  19 ms  19 ms  19 ms
 3  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  19 ms  19 ms
 4  ccngw-ner-cc.Berkeley.EDU (128.32.136.23)  19 ms  39 ms  39 ms
 5  ccn-nerif22.Berkeley.EDU (128.32.168.22)  20 ms  39 ms  39 ms
 6  128.32.197.4 (128.32.197.4)  59 ms  119 ms  39 ms
 7  131.119.2.5 (131.119.2.5)  59 ms  59 ms  39 ms
 8  129.140.70.13 (129.140.70.13)  80 ms  79 ms  99 ms
 9  129.140.71.6 (129.140.71.6)  139 ms  139 ms  159 ms
 10  129.140.81.7 (129.140.81.7)  199 ms  180 ms  300 ms
 11  129.140.72.17 (129.140.72.17)  300 ms  239 ms  239 ms
 12  * * *
 13  128.121.54.72 (128.121.54.72)  259 ms  499 ms  279 ms
 14  * * *
 15  * * *
 16  * * *
 17  * * *
 18  ALLSPICE.LCS.MIT.EDU (18.26.0.115)  339 ms  279 ms  279 ms

Why is the time from hops 3 to 4 go from 39ms to 19ms?

Colby Blair
  • 396
  • 4
  • 15

3 Answers3

9

They are not just different "hops" but indeed totally different events, at different times, and possibly under different conditions.

The way traceroute works is, it sends a packet with at TTL of 1 and sees how long it takes for an answer to arrive. The program repeats this three times to account for some variation that is possible and normal (note that even the three numbers in "the same hop" are sometimes very different, since they are totally separate things, too).

Then, traceroute sends a packet with a TTL of 2 (and then 3, and 4, etc.) and sees how long it takes for an answer to arrive. In the mean time, the load on the first router may have lowered, so your packets are actually forwarded faster. Or, the physical cable where your packets go out may not be busy because your roommate just finished downloading his porn (whereas before your network card would have to wait for the cable to get idle). This is something that happens all the time, and you have no way of knowing or controlling that.
There is no way of going back in time, so you can't change the fact that a second ago it took a bit longer for your packets to make it through. You're probing at two different times, so all you can get is a reasonable guestimate. Yes, generally, the time from hop to hop should gradually increase, but it needs not.

That doesn't mean that the round trip time is really going down between hops 3 and 4. It only means that it went down in the meantime while you you independently tried to get an estimate of how long 3 hops and 4 hops might take.

Damon
  • 67,688
  • 20
  • 135
  • 185
  • 1
    Awesome detailed explanation, this was what I was looking for! I suspected generally something like this, but the details were good. Thanks! I wish traceroute would send packets to every hop for the first test/column, then packets to every hop on the second test for column 2, etc, so the time decreasing goofs between hops would be more apparent. Not that this common utility will ever change. – Colby Blair Oct 08 '14 at 21:09
2

Most likely random delays between the lines. Note that on both the second and third packet sent for hops 3-4 go from 19ms to 39ms. They're all on the same network anyway, so most delays would be due to processing/congestion.

Although, another case that you occasionally see is that some servers provide higher QoS to ICMP messages, superficially giving the appearance of better performance.

fruglemonkey
  • 131
  • 3
  • 1
    Odd - in my (extensive) experience most servers / routers give far _lower_ priority to IMCP messages. – Alnitak Oct 06 '14 at 15:23
  • 1
    I heard of a case where a dodgy ISP/server host was giving higher priority to ICMP messages to make their service look better – fruglemonkey Oct 07 '14 at 01:16
2

On a packet-switched networks packet delays are not deterministic, particularly if there's congestion in the network. Each hop of the traceroute test is a separate test, so varying network conditions can easily cause later tests to have better latency than the nearer hops.

That is to say, traceroute doesn't just send out three packets and then somehow figure out what the time was at each hop. It sends out packets deliberately designed to timeout after n hops and measures the time as n increases.

Alnitak
  • 334,560
  • 70
  • 407
  • 495