Subject: Re: [ippm] New ipdv draft (attached)

From: [email-masked]
Date: Fri, 9 Feb 2001 17:59:36 EST

Phil,

Thanks for the update to ipdv. Attached as a Word file with comments. I will 
also paste the comments into the body of this e-mail for those who would 
rather have it that way.

First some editorial or minor wording (to prove I read it):

3.1 2nd para: after MP2 should be "as" not "is"
3.2 2nd para: add "to" after "respect"
4.2 definition of I1, I2: "that" should be "the"
4.4 3rd para: this seems to be extra, was already said in previous.
4.5 2nd para, 2nd bullet (beginning "A given methodology ...") add 
"[RFC2678]"after "Mahdavi and Paxson" 
4.5 2nd para: spelling of "assumes"
5.5 3rd para: spelling of "specific"
6.2 4th para: need to add meaning of "pdf" and "cdf"
6.6 title is the same as 6.5. This needs a different name
6.6 1st para: change "each" at end of 1st sentence to "the same"
7.1 3rd para (after formula): "change is skew" should be "in"

Next some technical issues:

3.1 2nd para: This says it is the difference between the first and the 
second. If the second is greater, this would yield a negative number. The 
definition should be second minus first, therefore it might be better to say 
"difference between the second and the first".

3.3 This whole issue of the definition of "skew" and "drift" and the dual 
meanings of "clock" has been confused in other references. This RFC doesn't 
need to repeat all this, other than to say that offset between the source and 
destination real time clocks is not important and that changes in the offset 
between the clocks has an effect and needs to be controlled. It is clear that 
the possible variation due to changes in the frequency of crystals is 
insignificant and should not be mentioned. I suggest deleting everything 
after the first sentence. In fact, the only concern should be if procedures 
used to update a clock (like when an operator finds it is wrong) cause 
discontinuities, but this is a common, well-known problem and doesn't need to 
be dealt with in detail.

5. This presumes that a Poisson distribution (of generation times) is 
required. This is one possibility, but when a real distribution of all 
differences is taken, it is less important for the generation to be Poisson. 
If the service being measured is one that uses periodic packets, then the 
measurement of "delay variation" can use the same periodic packets.

6.2 This discussion of the finite distribution of values still presumes that 
we are looking at a sample in which the first packet of each pair is the 
second packet of the previous. I really don't know what the significance of 
this is. Since  it is always possible that a packet is delayed any length, 
there is no bound on the ipdv-value. In looking at any sample, the 
distribution is whatever it is.

6.3 and 6.4 These refer to a "Type-P-One-way sample" but not as a defined 
metric name. (Note that there is no hyphen between ipdv and sample.)

6.5 I would suggest not referring to the "jitter" definition in RFC 2598. I 
think they used the term in a very general sense, and defined it as "absolute 
value of the difference between ... adjacent packets". Their definition 
didn't talk about samples of multiple values.

6.6 This seems like an awful complicated way to describe the derivation of 
"peak-to-peak" jitter. The same was already implied by the description in 6.5 
(same title). (Should 6.5 and 6.6 simply be combined?) In fact, the 
derivation is based on a multiple step process which needs to be detailed. It 
requires calculating a statistic for each sub-interval, forming a sample of 
many of these, and then calculating a statistic based on the sample of the 
whole measurement period (see below).

The description assumes that there is a sample of delay values for all 
packets in each sub-interval. To be complete, that sample metric should be 
defined first.
As in other sections, this should be "the first packet of each pair is the 
minimum and the second is the maximum" so that a positive value means that 
the second is larger. Or just eliminate this concept or "first" and "second" 
and "pairs" and say that "the peak-to-peak delay variation for each 
sub-interval of the measurement period is the difference between the maximum 
Type-P-One-way-Delay and the minimum Type-P-One-way-delay".

The metric described in 6.6 is a "sample" based on the definition in RFC 
2330, not a "Statistic" (title of section 6).

I would suggest the following:

Change the title and beginning text of 6 as follows
6. Statistic and Sample Metrics for One-way-ipdv"
Some samples and statistics ...

Add new section between 6.2 and 6.3
6.3 Type-P-One-way-Delay-Sample
This sample consists of a sequence of Type-P-One-way-Delay values (as defined 
in RFC 2679) for a stream of packets. This stream may be either a Poisson 
distribution or a periodic stream, depending on the type of packets being 
considered.

Correct references in the current 6.3 and 6.4 to refer to the above defined 
metric (and renumber 6.4 and 6.5).

Combine the current Section 6.5 and 6.5 as follows to describe a statistic 
for each individual interval:
6.6 Type-P-One-way-Peak-to-peak-ipdv
This statistic metric is based on the definition of "jitter" and the analysis 
of delay variations found in [7]. In that document, consecutive packets of 
the Type-P stream are selected for the packet pairs used in the delay 
variation computation. The maximum value of the absolute value of the 
individual delay variation values in the sample is then used for the analysis.
The Type-P-One-way-Peak-to-peak ipdv statistic metric is computed for a 
specified interval by determining the difference between the maximum and 
minimum values in Type-P-One-way-Delay-Sample during that interval.

Add a new sample metric to contain peak-to-peak ipdv values for multiple 
intervals:
6.7 Type-P-One-way-Peak-to-peak-ipdv-Sample
This sample metric is formed by taking a sequence of 
Type-P-One-way-Peak-to-peak-ipdv values for a series of sub-intervals which 
make up a larger measurement interval. The sub-intervals may be contiguous or 
discontiguous. They shall not overlap.

Add a new statistic metric to show one possible derivation of information 
from the above defined sample and a section to indicate that there are others:
6.8 Type-P-One-way-Peak-to-peak-ipdv-Percentile
For all sub-intervals in the measurement period and for a given percentage X, 
this statistic metric indicates the peak-to-peak delay variation which 
represents the X-percentile of the sample. For example, 
Type-P-One-way-Peak-to-peak-ipdv-Percentile-90% = 50ms means that 90% of the 
sub-intervals had a peak-to-peak delay variation less than or equal to 50ms.

6.9 Other Statistic Metrics
Other statistics may be derived from the Type-P-One-way-Delay-Sample and the 
Type-P-One-way-Peak-to-peak-ipdv-Sample metrics.

See you in Minneapolis.

Mike