Help Interpreting traceroute output

[dsr at tao.merseine.nu (dsr at tao.merseine.nu)]

On Mon, Oct 18, 2004 at 02:27:29PM -0400, trlists at clayst.com wrote:
> On 18 Oct 2004 dsr at tao.merseine.nu wrote:
> 
> > Remember that traceroute is not a performance measurement tool.
> > It's a connectivity checker. 
> 
> Fair enough.  But it is sometimes a simple way to get a rough idea of 
> where a performance problem lies, no?

Welll.... no. It's great at some things -- discovering a
routing loop, or that your ISP likes to send packets through
Chicago even when the destination is across town... but it's
not a reliable indicator for most things people try to do with
it.

> OK.  But we are looking for a serious bottleneck here that is breaking 
> an application.  I'm guessing that the differences in performance 
> within a normal range of packet sizes will not be so great that the 
> traceroute output is for that reason alone useless in finding an 
> obvious bottleneck.  And the routing is usually the same from try to 
> try.

Suppose that your app occasionally sends data that is just larger than
one packet-payload, requiring a second packet. And suppose that
there is a router somewhere in the middle which always drops
that second packet. But a single packet from traceroute always
gets through...

> I hadn't thought about the differences in packet types -- and I'm not a 
> router expert so please bear with me.  Are the routing algorithms 
> typically different for the different packet types, such that a notable 
> bottleneck found via traceroute for UDP would routinely not apply to 
> ICMP or TCP packets?
> 
> > routers may handle traceroutes and/or pings preferentially, may
> > artificially restrict them, may route them differently, store
> > them in different buffers, all sorts of things.
> 
> Again, fair enough, but will this affect the gross results or just less 
> important details?

I don't know what your app is doing. It might be that traceroute
is handled exactly the same as your app's packets. (I doubt
this.) It may be that the two are reasonably close, and a
traceroute anomaly will correspond directly to a problem for
your protocol. (Possible.) It may be that the two are quite
dissimilar, and traceroute won't be of much help in diagnosing
the app's problems.

> > Performance testing is best done between the points in question
> > with the protocol in question using a payload as similar to
> > "typical" as possible.
> 
> In this case we are trying to get a rough feel for why an installer 
> can't retrieve data from a mirror at any reasonable rate.  The data is 
> sent via HTTP POST and hence is coming as TCP packets.  I don't know 
> the packet size (I didn't write the installer, I'm just looking for 
> what's slowing it down) but I can probably find out.  Beyond that, what 
> is a good method for doing this kind of basic performance testing 
> without overdoing the level of precision?

Now, this is useful information.

httperf is a good tool for testing HTTP connectivity and
performance.
www.hpl.hp.com/personal/David_Mosberger/httperf.html

> More to the point, we are pretty sure we already know what end-to-end 
> testing will tell us -- the link is slow.  The question is why and 
> where.  Is there something other than tranceroute that can be helpful 
> in answering questions like that?


Well, you might as well ping as traceroute if you just want an
idea of end-to-end times.

But your best bet is to talk to your ISP and their upstream (if
any) and see what they say.

-dsr-