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