How does Argus measure jitter?

Carter Bullard carter at qosient.com
Mon Oct 31 14:11:54 EDT 2011


Hey Nik,
Not sure that I understand your comment:
   "Although Argus has the disadvantage that it does not have an instance at
    the source and destination of a probe,"

Argus can be deployed in most sources and destinations, that is one of the big differences
between argus and other flow / performance sensors.  And because it can be
deployed multiple points along the path, you can compare the offered metrics and
observed metrics from multiple points, and realize where modifications to performance
are occurring, specifically path utilization, loss and shaping (queuing).

One of the interesting things about Argus, is that it understands many VoIP codecs,
and adjusts its packet jitter calculation to deal with issues like silence suppression.
I didn't want to get into too much detail in the first email.   Argus tracks 2 packet jitter
measurements, for each flow, both "active" and "idle" packet inter-packet arrivals, and jitter.
All flows have these metrics, for VoIP, and some codecs, the idle time is the time in between
packets during silent suppression, and the active time is when silent suppression is not on.

In the early days, many commercial VoIP end systems would shape traffic in the worst way.
The mean arrival times were great, but the packet jitter was terrible.  Some were 2 packets
at line rate, then idle, and then 2 packets at line rate.  So, argus has been very helpful for
some to measure the offered load and jitter for VoIP, and to compare that with received
load and jitter by using argus within matching sets of equipment.  Argus has been used for
many years by companies like Nortel (not so anymore) and Ericsonn, to measure video
conferencing terminal performance.  For video, unexpected issues like fragmentation really
cause performance problems, as the fragments are written at line rate, which of course,
can create problems for long haul and satellite video conferencing.

I would try to get argus into the phone, thats what most of them do.  The SPAN port
shapes the traffic and can introduce loss that is not there.  Of course the impact is
not infinitely huge if you're tracking voice, not the best if you're tracking HD video,
as it does introduce queuing issues that the user traffic doesn't experience.  Taps do
a much better job, and companies like Endace really shine here, as they can provide
the time sync needed to do short segment one-way delay (sub uSec), as they can be
sync'd up using GPS equipment.

So, an argus flow status record, collected from two argus probes, trivial algorithm goes:
   1. Compare records from different probes to find match.
      With matching records:
   2. S to D One-way delay
           abs(ArgusRecord1.sstime - ArgusRecord2.sstime);
           abs(ArgusRecord1.sltime - ArgusRecord2.sltime);
   3. D to S One-way delay
           abs(ArgusRecord1.sltime - ArgusRecord2.sltime);
           abs(ArgusRecord1.dstime - ArgusRecord2.dstime); 
   4. NTT
           abs(ArgusRecord1.dur - ArgusRecord2.dur);

Pretty trivial.  Argus self-synchronization is kinda complicated, another email perhaps,
but you have to turn it on, so its not a default behavior.  Without the option, traffic
sessions that are shorter than the flow status interval, are inherently self-synchronized.
So many use the short traffic, like DNS and web traffic, to do the one-way delay metric estimates.

Carter


On Oct 28, 2011, at 4:59 AM, Nik Mitev wrote:

> Thanks Carter - for a useful, short and to the point reply. Things look
> promising, so I will elaborate on my targets.
> 
> I am looking at using Argus for monitoring the QoS the network provides
> for voice traffic. This includes network jitter as described in your
> reply, packet loss and one-way delay.
> Cisco IP SLA is an obvious candidate for the job, but it is currently
> buggy and not working on our 2960S switches, plus it monitors switch to
> switch connections rather than server to endpoint and generates extra
> traffic.
> Although Argus has the disadvantage that it does not have an instance at
> the source and destination of a probe, it analyses actual production
> traffic and not an artificial sample which hopefully offsets any
> inaccuracy introduced by the fact that it views flows from outside.
> 
> 
>> However, because each argus record has 4 microSecond timestamps, one for the first and last observed packet in either direction, Argus data can be used to generate sampled network jitter.  This is done through differencing matching flow records from two independant probes that are deployed near or in the end systems of interest.  A good one-way delay measurement requires that the two probes be time synchronized, but formulating a decent estimate of the variance of the delay ( network jitter ) doesn't require synchronization, as long as the two sensors clocks are not drifting.
>> 
>> Argus data can also be used to calculate network transit time (NTT) which is ( RTT - Host Delay ), because argus is a bi-directional flow monitor.  This is also done through differencing matching flow data from two independant probes, deployed in the end systems, in this case time synchronization is not needed.  This generates a very good metric for bi-directional network jitter, as the host component is removed.
>> 
>> Argus is designed specifcially to enable these types of metrics, as the probe is self-synchronizing.  The two independent sensors, looking at the same packet stream, will generate network flow data that is packet aligned.
> 
> Could you put this in an example, hopefully with some formulae for the
> calculations? The best way to describe our topology would be two
> hub-and-spoke networks linked together at the hubs with our own fibre.
> If the stream to be analysed is a call segment from an IP phone at a
> spoke location to a server in a data centre at the hub and Argus is fed
> data from a SPAN port on the hub switch how would the network jitter
> calculation look? All endpoints are synchronised to the same set of ntp
> servers on site.
> 
> Thanks
> Nik
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20111031/150b6716/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4367 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20111031/150b6716/attachment.bin>


More information about the argus mailing list