Subject: Re: [IPFIX] RFC 3550 jitter

From: Andrew Feren <[email-masked]>
Date: Mon, 03 Dec 2012 22:59:49 -0500

Hi Paul,

Is it necessary to have an IE each possible jitter calculation and the
document where that calculation is defined?  Seems like we could end up
with a huge pile of jitter IEs.  Are there other calculated values that
have need to specify how they were calculated?  PSAMP has
selectorAlgorithm etc., applicationId has an embedded Classification
Engine ID, do we need some sort of calculationTypeId for calculated values
like jitter?

-Andrew

On 11/28/12 12:30 PM, "Paul Aitken" <[email-masked]> wrote:

>Dear all,
>
>I received feedback that the name should include "mean" and 'rfc3550',
>since there are other jitter metrics which take into account all samples
>rather than running average based last 16 samples as done by RFC3550.
>
>So the proposed names could be rfc3550JitterMeanMilliseconds,
>rfc3550JitterMeanMicroseconds, and rfc3550JitterMeanNanoseconds.
>
>P.
>
>
>On 28/11/12 15:25, Paul Aitken wrote:
>> Dear IPFIX experts,
>>
>> I'd like to request an IPFIX IE for jitter from IANA. RFC 3550 defines
>> a suitable "interarrival jitter". Unfortunately it's measured in
>> "timestamp units":
>>
>>       An estimate of the statistical variance of the RTP data packet
>>       interarrival time, measured in timestamp units and expressed as an
>>       unsigned integer.
>>
>>
>> Therefore it seems we may need multiple IEs: one for units of
>> milliseconds, one for microseconds, one for nanoseconds...
>> Else comparison of two jitter values would be meaningless.
>>
>> So I request your feedback on the following:
>>
>> Name: interarrivalJitterMilliseconds
>> Type: unsigned32
>> Semantic: quantity
>> Description: interarrival jitter as defined in section 6.4.1 of RFC
>> 3550, measured in milliseconds.
>> Units: milliseconds
>> References: [RFC3550]
>>
>> Name: interarrivalJitterMicroseconds
>> Type: unsigned32
>> Semantic: quantity
>> Description: interarrival jitter as defined in section 6.4.1 of RFC
>> 3550, measured in microseconds.
>> Units: microseconds
>> References: [RFC3550]
>>
>> Name: interarrivalJitterNanoseconds
>> Type: unsigned32
>> Semantic: quantity
>> Description: interarrival jitter as defined in section 6.4.1 of RFC
>> 3550, measured in nanoseconds.
>> Units: nanoseconds
>> References: [RFC3550]
>>
>> Thanks,
>> P.
>> _______________________________________________
>> IPFIX mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ipfix
>
>_______________________________________________
>IPFIX mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ipfix

---

From: Paul Aitken <[email-masked]>
Date: Tue, 04 Dec 2012 12:01:14 +0000

Andrew,

This is a great point. It was also raised privately (off list) by one 
other responder.

Cisco already has a large number of jitter metrics which we export in 
enterprise-specific fields. RFC 3550 jitter was the only one we thought 
standardisable. I expect others have similar ES fields for their own 
jitter metrics.

One solution would be to use the same mechanism that I proposed for MIB 
export, ie Extended Field Specifiers.

ie, we'd have a single export ID for "jitter", to which an extension can 
be applied indicating which jitter it is, which implies how it's calculated.

See slide 7 here: 
http://tools.ietf.org/agenda/85/slides/slides-85-ipfix-2.pdf

P.

---

From: Andrew Feren <[email-masked]>
Date: Fri, 07 Dec 2012 12:10:00 -0500

Hi Paul, all,

I've been giving this a bit of thought.  I think your suggestion to use 
Extended Field Specifiers is absolutely the direction that we need to 
head in.  I'm pretty sure jitter won't be the only IE that would benefit 
from some additional detail.

For example it would be fantastic if IEs (any IEs, but particularly 
Enterprise specific IEs) came with type and semantic information. 
Currently I can decode new IEs, but then have to discard them as useless 
until I get additional information out of band.  Being able to have 
users send new IEs and immediately be able to create useful reports 
would be great.

I suspect that this opens up a number of other possibilities that I 
haven't considered yet.

-Andrew

PS in addition to jitter, something for latency would probably be useful.

On 12/04/2012 07:01 AM, Paul Aitken wrote:
> enterprise-specific fields. RFC 3550 jitter was the only one we 
> thought standardisable. I expect others have similar ES fields for 
> their own jitter metrics.
>
> One solution would be to use the same mechanism that I proposed for 
> MIB export, ie Extended Field Specifiers.
>
> ie, we'd have a single export ID for "jitter", to which an extension 
> can be applied indicating which jitter it is, which implies how it's 
> calculated.
>
> See slide 7 here: