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

On Apr 1, 2:43 am, use...@oakseed.demon.co.uk.invalid (James Taylor)
wrote:
> 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 find wireshark's time/sequence graphs really difficult to interpret.

The combination of tcptrace and xplot is far easier for me to read.
The documentation explaining time/sequence graphs is here:

http://tcptrace.org/manual/node12_mn.html

A quick glance at your usenet posting history suggests you're a mac
user. You'll need to install and run X11 from your install disks
before you can run xplot.

Then it's just a matter of:

1) capture your problem incident with wireshark (as you've done), save
it to a file
2) in the terminal: 'tcptrace -S <filename>
3) observe the tcptrace output, and the files it has created
4) xplot ?2?_tsg.xpl

alternatively, you could just upload the capture so we can all have a
look at it.

/chris

chris <googlegroups@marget.com> wrote:

> James Taylor wrote:
>
> > 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/>

I'd still like to know if my speculations in my initial post are likely
to be anywhere near the mark. Can anyone me understand?

> I find wireshark's time/sequence graphs really difficult to interpret.
>
> The combination of tcptrace and xplot is far easier for me to read.
> The documentation explaining time/sequence graphs is here:
>
> http://tcptrace.org/manual/node12_mn.html

That's much nicer visualisation, I agree, and now I've read that page I
can now understand how to interpret a very similar tcptrace-style graph
drawn by WireShark. Thanks.

> A quick glance at your usenet posting history suggests you're a mac user.

Yes, amongst others.

> You'll need to install and run X11 from your install disks
> before you can run xplot.

Yes, WireShark for Mac also requires X11, so this is already installed.

> Then it's just a matter of:
>
> 1) capture your problem incident with wireshark (as you've done), save
> it to a file
> 2) in the terminal: 'tcptrace -S <filename>
> 3) observe the tcptrace output, and the files it has created
> 4) xplot ?2?_tsg.xpl

You make it sound very easy. I've installed tcptrace and xplot, now I
just need to familiarise myself with their usage. Thanks for the tip.

> alternatively, you could just upload the capture so we can all have a
> look at it.


Yes, I'd like to do that, but the captures contain data that is private
to my users. Do you know of an easy way to sanitise the capture files?

Thanks again.

--
James Taylor

On Apr 1, 1:42 pm, use...@oakseed.demon.co.uk.invalid (James Taylor)
wrote:
> chris <googlegro...@marget.com> wrote:

> > alternatively, you could just upload the capture so we can all have a
> > look at it.
>
> Yes, I'd like to do that, but the captures contain data that is private
> to my users. Do you know of an easy way to sanitise the capture files?

tcpurify

/chris