[ARGUS] QoS Analysis with Argus

Carter Bullard carter at qosient.com
Thu Jul 8 14:48:34 EDT 2004


Hey James,
Sorry for the delayed response.  Been busy.   Hey, nice graphs, they
look like ragraph() graphs, hope its working for you well.

You have a number of questions, I'd like to take a stab at most if
possible.  First is what level of loss on a given link can generate
noticeable degradation of service.  Well the real answer to this
question is any level of loss generates noticeable effects, depending
on the application.  A single DNS request or response being lost
can cause a 1-2 second delay in say a web page completing, and that
is really noticeable.  Of course the more loss, the more applications
will be affected, until everything is significantly slow.

What is jitter?  Jitter is the variance of the interpacket arrival
times for a given flow/link/virtual circuit/whatever.  The network
has the ability to 'shape' traffic, either because its 'rate limiting'
i.e. 'slow', or because it is busy and possibly introducing queuing
artifacts, or its congested and it drops packets, or packets are
taking differing paths in the network and arriving in different burst
patterns or in different order.  With your 'rate limited' link,
you will get all kinds of jitter issues, depending on the size of
the packets and the contention for the single link.  Jitter is
normally of interest for voice and video traffic, which has
pretty stringent jitter tolerances if they are real time, but
there are a lot of high performance applications, like remote
file sharing, where jitter impacts peak performance.  I don't
think issues in jitter are a real problem for you.

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.
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.

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.

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.

Hopefully this will help.   If anything comes up, don't hesitate
to send mail to the list.

Carter



-----Original Message-----
From: owner-argus-info at lists.andrew.cmu.edu
[mailto:owner-argus-info at lists.andrew.cmu.edu] On Behalf Of James Lever
Sent: Wednesday, July 07, 2004 8:34 AM
To: Argus Info List; Argus Info List
Subject: [ARGUS] QoS Analysis with Argus

Hi All,

I'm trying to perform some quality of service analysis with Argus to
determine true cause of network slow-downs.

I've so far determined times/dates of high traffic
(bytes+daddr/saddr/dport) and have also used the packets metric to
cross-check.

The link I am concerned with is a single/dual channel ISDN (2x 64kBps B
channels) running single channel most of the time and bursting up to
dual channels in times of high demand.

Can somebody give me an idea of what loss could be expected on such a
link before a noticeable degredation of service was noticed?

Also, what is jitter?  My best guess is time between an outgoing packet
and an incoming packet.  What should be expected?  How many orders of
magnitude difference would be required to have a perceived massive
degredation of service?

Some graphs of interest are currently available at
http://jamver.id.au/argus/ if anybody is willing to have a look and
give me some ideas on directions to look.

How would you try to analyse QoS using Argus?  Would you use other
tools too?

cheers,
James







More information about the argus mailing list