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

From: Victor Reijs <[email-masked]>
Date: Thu, 01 Feb 2001 13:54:00 +0000

Hello Phil,

Because I am quiet new to this subject just an issue that still pops in
my writings/thoughts:
'Accuracy' seems to be a defined term in RFC2679 (has to do with the
clock)
Sometimes I want to talk about the accuracy of the result of a
measurement (like you also do on page 7), but is that the correct
wording because of this 'reservation' of the term? Perhaps I should use
'error' or 'standard variation' or ???

Hoep you can help me with this basic naive question.

All the best,

Victor

"P.F. Chimento" wrote:
> 
> Hello all:
> 
> I have attached a new ipdv draft which has been modified according to
> many of the comments that I received on the mailing list in November. I
> did not submit it as an ID yet, because I wanted to get comments from
> the mailing list before officially submitting it as a new draft.
>
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: Victor Reijs <[email-masked]>
Date: Thu, 01 Feb 2001 16:36:55 +0000

Hello Phil,

One addition perhaps. There are now One-way-ipdv statistics defined
(section 6). Is it not good also define in this section the statistics
used within the RTP protocol (RFC1889, section 6.3.1)?
Looking at RTP; it uses at least the same method of determining some
sort of 'Type-P-One-way-ipdv' -> (D(i-1,i))
The 'Type-P-One-way-ipdv-interarrival-rtp???' (J) is determined by:
  J=J+(|D(i-1,i)|-J)/16

What do you think? This provides links between RFC...

All the best,

Victor

---

From: Al Morton <[email-masked]>
Date: Tue, 20 Feb 2001 20:10:08 -0500

Phil and all,

Here's a few more comments on the "ippm-list-only" draft, you sent
At 07:25 PM 01/31/2001 -0500:

*  Section 4.4 Definition (of singleton metric)
The first paragraph is new.  It's not clear why an
index number should be assigned at the Dst (MP2).
The Dst/MP2 index would not increment when a packet is lost.
Perhaps you meant MP1?
The ipdv definition is based on sending times (T1 and T2) and the
need to track sending sequence is clear.
Also, Mike Pierce noted that the third paragraph (a single line)
is redundant. It appears to be the last line fragment of a NOTE
that you deleted, and should go too.

* Section 4.5 Discussion
In the last paragraph, you give the assumption of Poisson sampling
described in the Framework RFC. Given the development of the npmps
draft, would it be appropriate to allow for alternative sampling
methods here (and in Section 5, as Mike suggested)?
I also want to be sure that ipdv is applicable to passive measurement,
e.g., on a stream of RTP/UDP/IP packets conveying constant bit rate media.

* Section 5.5 Discussion (of Samples)
The third paragraph gives two examples of the selection function.
The 2nd example gives the triple:
<T(i), T(i+1), D(i)-D(i+1)>
where D(i) denotes the one-way delay of the ith packet of a stream.
If ipdv is reported, should the triple be
<T(i), T(i+1), D(i+1)-D(i)>
to be consistent with the definition in section 4.4?
The last paragraph in Sec 5.5 gives two references (both to [9]),
and one of them should probably be [3] or [8].
(the latest draft of [8] is dated 11/2000).

* Section 6 Statistics for One-way-ipdv
Mike had substantial comments here.  I would like to see the
jitter definition [RFC 2598] in current section 6.5 preserved.
This is a good spot to mention similarities to the computation of
smoothed jitter in RTP [RFC 1889 section 6.3.1].  It should be
valuable to include a statistic that can be related to measurements
made by user's endpoints.

Thanks for your efforts, Phil. The flexibility you've built into
this draft accommodates a range of opinions on delay variation.

Al

---

From: "Matthew J Zekauskas" <[email-masked]>
Date: Thu, 22 Feb 2001 02:20:13 -0500

In addition to the comments already received...

Perhaps we can change the name in section 5.1 from
Type-P-One-way-ipdv-stream to Type-P-One-way-ipdv-Poisson-stream;
we did this in drafts for RFC 2679 and RFC 2680 to allow for the
possibility of other types.

A nit: In the last sentence of 5.5, you say 
"proposed in [9] and the one proposed in [9]."

7 and 9?

--Matt