Re: [IPFIX] RFC 3550 jitter

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:
> 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.
>
>> 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 protected]> 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 protected]
>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>> _______________________________________________
>>> IPFIX mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/ipfix
>

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix