interpacket arrival times and jitter reporting values

Carter Bullard carter at qosient.com
Mon Mar 26 12:29:36 EDT 2007


Gentle people,
I'm putting the final touches on the jitter reporting schemes, and  
wanted some feedback.

Our approach to interpacket arrival and jitter is very simple.  We  
are reporting sample
size (N), the max, min and mean inter-packet arrival times and the  
std deviation around
that mean, in microseconds.   The inter-packet arrival time is the  
number of microseconds
between packets that 'belong' to the argus flow, measured  
independently for each
direction observed, at the argus.

Now, these are numbers  that real statisticians can actually use ;o)   
The only really
debatable issue is whether to report standard deviation or variance  
of the inter-packet
arrival times.  A statistical definition of jitter suggests that  
variance is the right metric
here, but I think that most statisticians will ask for std dev, as it  
is a number that can
be eyeballed (same units, simple rules for use, familiarity).  If you  
want the variance,
you just square the standard deviation.

I know that this approach is much different than that seen in most  
places in the industry,
which are trying to do either "cheap" metrics or they are trying to  
be relevant for some
weird use, like on the wire correlation to stuff like VoIP jitter  
buffer performance,
or trying to recover metrics like RTP/RTCP.  These approaches are  
dubious, and
are difficult to use in other statistical methodologies/systems.    
Wireshark has fallen
down into this abyss with their jitter metric for RTP.   My concern  
has been that I can't
do an ANOVA of the variances reported using these schemes, cause I  
don't know
what the numbers really mean, since they are poor approximations or  
weighted series.

We don't have any assumptions on our data, so that's why we take a  
literal statistical
approach.  With our strategy, you can aggregate multiple records  
together and use
real statistics to merge the interpacket arrival data and jitter  
values to get understandable
results.  And, more importantly, you can use real statistics to  
compare jitter data,
like an ANOVA test.  Wow!!!!

We measure everything as microseconds, to get the scale to a decent  
target
for the high speed stuff (HDTV video transmission), and we store and  
report the values
as C floats, as a result, we can report the numbers anyway we want.

So my question is, would you like your interpacket arrivals reported  
in seconds, milliseconds
or the current microseconds?

Does anyone have any questions themselves?   Any opinions/suggestions/ 
comments/
whatever would be really welcome, especially now before we release  
argus-3.0.  Great
opportunity to change it now!!!!!!

Hope all is most excellent,


Carter



More information about the argus mailing list