[ARGUS] QoS Analysis with Argus

[James Lever]

Hi Carter/list,

I'm finally trying to get further on this issue...

How is the new argus tarball looking?

On 09/07/2004, at 4:48 AM, Carter Bullard wrote:

> I suspect that in your situation, packet loss is the biggest
> concern.  You've got some periods of saturation on your graphs,
> and you can expect a high level of loss at that time.  A PC with
> a 10meg ethernet card can overrun your ISDN link very easily,
> and if the router/modem doesn't buffer the packets, you could
> be losing a significant number, especially with TCP based traffic.

I agreee with this statement.

> TCP will burst out traffic (up to its available window size) and
> then wait for a response.  If it senses that there is trouble
> (ie. there is packet loss), it will lower its window, unfortunately
> once it does this, it doesn't ever recover, and so in some
> situations, a transient packet loss can cause a TCP connection
> to be persistently slow.

Is this the window size a tcp stack variable or a session/tcp 
connection variable?  (ie, will it cause all applications to slow down 
or just the one that had the transient loss)

> Argus provides loss/retransmission statistics for TCP traffic,
> and you can look to see if there is a significant number of packets
> being retransmitted there (assume that every retransmission is the
> result of a packet being dropped), and of course you can graph
> the retransmission by replacing 'bytes' with 'retrans' using ragraph.

I've done that and it's actually a really slow process to try to get 
anything meaningful out of it even with lots of pretty graphs.  Is 
there a way to graph all packets, loss and retransmit (or at least 
all+retrans) on the same graph:?

> Also if your performance is bad because the TCP window size is
> poorly chosen, argus data has the window sizes, so you can check
> it out.

Is there a way to graph the size of the data window so as to make it 
easy to identify where the change in window size is occurring?

Lots of questions today... ;)

cheers,
James