Interpreting WireShark TCP time/seq graphs
In the last few days my ADSL Internet connection has exhibited very poor
performance and by capturing the traffic in Ethereal/WireShark I can see
that there are many dropped or out of order packets. I'm certain the
problem is not with my internal network, or with my ADSL modem/router,
and now suspect that the local ISP is doing something badly wrong. I'm
based in Thailand where strangely incompetent things like this happen
regularly and, this being Asia, "loss of face" is something I must avoid
causing. I therefore need to track down as precisely as possible what
the nature of the problem is so that I can steer an ISP technician
directly to the problem in their network so it can be discretely fixed
without embarrassing anyone. The performance problems are causing my
users misery and reflecting badly on me, so I would be *hugely* grateful
for any .
I've taken one typical HTTP stream and used WireShark's time/sequence
graphing function in order to understand why so many packets arrive out
of order. However, I'm not at all familiar with this kind of TCP
performance analysis and I would love someone to me interpret the
graph. I've (very temporarily) uploaded two views of the graph here:
<http://www.hackershack.co.uk/usenet/tcpgraphs/>
The stream pictured is the download-only side of the conversation. It
contains firstly a 64K HTML page and then and a number of smallish
images and other resources. The close-up view of the graph corresponds
to the latter 48K of the HTML page. I would love to know why this latter
48K of the page seems to arrive faster than the rest of the resources.
It's not like a transparent caching proxy could deliver only part of a
page ...or could it?
The other thing I noticed in the close-up portion is that there appear
to be three separate lines of timing, as illustrated by the coloured
lines that I have drawn over the graph. What does this mean?
Could it be that there are three different routes from the web server
across the Internet to the browser, with the packets getting
load-balanced out along the different routes at some point? Or could
there be a routing misconfiguration causing this?
Why is the blue line so different from the red and green ones? Could the
blue line be a caching proxy that first stores all the packets before
releasing them on their journey?
Is it possible that something much worse than I can see is happening but
then some kind of reassembly and/or duplicate removal is taking place
before the traffic arrives?
I'd really appreciate everyone's ideas about what's going on here, and
whether I have sufficient cause to approach the ISP with a fault report.
Thanks.
--
James Taylor
|