Re: comments on draft-dcbench-def-00 (part 1)

On 7/29/13 9:14 AM, Lucien Avramov (lavramov) wrote:

>> 3 Jitter
>>
>> 3.1 Definition
>>
>>     The definition of Jitter is covered extensively in RFC 3393. This
>>     definition is not meant to replace that definition, but it is meant
>>     to provide guidance of use for data center network devices.
>>
>>     The use of Jitter is in according with the variation delay definition
>>     from RFC 3393:
>>
>>     The second meaning has to do with the variation of a metric (e.g.,
>>     delay) with respect to some reference metric (e.g., average delay or
>>     minimum delay).  This meaning is frequently used by computer
>>     scientists and frequently (but not always) refers to variation in
>>     delay.
>>
>> Comment:  Even with the reference to RFC 3393, there are many definitions
>> of "jitter" possible. Fortunately this is not the first draft to examine
>> the possibilities :-)
>>
>> I find that a comment I made on the Traffic Management draft is
>> applicable here:
>>> ...
>>>    - Packet Delay Variation (PDV): the Packet Delay Variation metric is
>>>    the variation between the timestamp of the received egress port
>>>    packets and specified in RFC 1889.
>>>
>>> Comment: since you have One-way Delay (PD defined above PDV), why
>>> resort to the RFC 1889 definition?
>>> What does this give you?
>>> Suggest: Specify PDV as defined in
>>> http://tools.ietf.org/html/rfc5481#section-4.2 instead, for the many
>>> reasons given in http://tools.ietf.org/html/rfc5481#page-27
>>> (or call this IPDV to avoid confusion).
>>
>> In the Isolated test lab environment, we don't have time clock drift
>> issues that
>> we can't solve, in many cases the same clock is used for ingress and
>> egress timestamps.
>> So, we are free to choose the delay variation metric(s) that serve our
>> audience best.
>>
>>>>>> I think "Jitter" is another topic that we can advance through
>>>>>> face2face discussion.
>>       What do we really want to learn from the "jitter" metric?
>>       How will these results be used? (in network design, application
>> planning, etc.)
> 
> For the Data Center benchmarking, we found that the rfc 3393 definition
> was the easiest to consume for its applicability to the data center. we
> wanted to add to this that what is key is to have packets of the same
> size when jitter is measured. It's mentioned in the RFC 3393 but in a
> more complex method as follows:
> 
> '‘+ L, a packet length in bits. The packets of a Type P packet stream
> from which the singleton ipdv metric is taken MUST all be of the same
> length.’’
> 
> We want to make this simpler to the end data center user by calling it
> packets of the same size.
> 
> Also we add to this definition, by explaining the necessity for a
> histogram with latency buckets, this will help understand where there is
> higher jitter for instance.

RFC 4689, approved by this wg a few years ago, provides a simpler
definition of jitter:

http://tools.ietf.org/html/rfc4689#section-3.2.5

|D(i) - D(i-1)|, where D equals the Forwarding Delay
      and i is the order the packets were received.

This paragraph compares the RFC 3393 and 4689 definitions:

"Jitter is related to the IPDV (IP Delay Variation) taking the absolute
value of the ipdv. The two metrics will produce different mean values.
Mean Jitter will produce a positive value, where the mean ipdv is
typically zero. Also, IPDV is undefined when one packet from a pair is
lost."

The RFC 4689 definition may be more applicable here.

dn