Subject: [PMOL] FW: [xrblock] WGLC for Packet Delay Variation Metric Reporting

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 2 May 2012 10:56:21 +0200

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Shida Schubert
Sent: Wednesday, May 02, 2012 8:02 AM
To: xrblock
Subject: [xrblock] WGLC for Packet Delay Variation Metric Reporting

This is an announcement of a 2 weeks XRBLOCK WG last call on 
"Report Block for Packet Delay Variation Metric Reporting" prior
to requesting publication of the document as a proposed standard. 

Please send your comments, including nits, to the list by the

  17th of May

If you read the draft and you see no issues, concerns, or nits, please
express the fact that you have no issue progressing the draft on the
list as well. 

The latest version can be found here:
http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-pdv-02

Regards

 Shida as co-chair
 
_______________________________________________
xrblock mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/xrblock

---

From: Al Morton <[email-masked]>
Date: Wed, 16 May 2012 10:51:13 -0400

PM Directorate,

Dan sent this a few weeks back, did anyone review it?
If not, would anyone like to review it fairly soon?
(we could probably get some extra time for a PMdir review
from the chairs...)

let me know,
Al
PMdir admin

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 16 May 2012 18:22:53 +0200

Hi Al,

I reviewed it and sent my comments a few days ago to the XRBLOCK list -
http://www.ietf.org/mail-archive/web/xrblock/current/msg00511.html, I
apologize for not copying PMOL. Note that this I-D refers only to
reporting formats, while for metrics definition they are referring
http://tools.ietf.org/html/draft-ietf-avtcore-monarch-04. 

Regards,

Dan

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Al Morton
> Sent: Wednesday, May 16, 2012 5:51 PM
> To: [email-masked]
> Subject: Re: [PMOL] FW: [xrblock] WGLC for Packet Delay Variation
> Metric Reporting
> 
> PM Directorate,
> 
> PMOL mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pmol

---

From: Al Morton <[email-masked]>
Date: Wed, 16 May 2012 20:44:02 -0400

At 12:22 PM 5/16/2012, Romascanu, Dan (Dan) wrote:
>apologize for not copying PMOL.

Thanks Dan, no need to apologize, just trying to keep track.

>Note that this I-D refers only to

Anyone volunteer to review this one?

Al

---

From: Carlos Pignataro <[email-masked]>
Date: Sat, 19 May 2012 18:01:52 -0400

> Anyone volunteer to review this one?

I cannot volunteer to review this one this next two weeks. However I wanted to point out that, when the XRBLOCK refers to rev -04 of the Monitoring Architecture document, the current rev is -13.
These are the changes, non trivial amount:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-monarch-13.txt&url1=draft-ietf-avtcore-monarch-04.txt

Thanks,

-- Carlos.

---

From: Al Morton <[email-masked]>
Date: Sun, 20 May 2012 08:57:28 -0400

Charles and Shida,

Dan Romascanu suggested that the Performance Metrics Directorate

take a look at this draft, in addition to his WGLC review.

Carlos' comment is below (Thanks for your comment, Carlos).

Al

PMDir admin

At 06:01 PM 5/19/2012, Carlos Pignataro wrote:

On May 16, 2012, at 8:44 PM, Al
Morton wrote:

At 12:22 PM 5/16/2012,
Romascanu, Dan (Dan) wrote:

I reviewed it and sent my
comments a few days ago to the XRBLOCK list -

http://www.ietf.org/mail-archive/web/xrblock/current/msg00511.html,
I

Note that this I-D refers only
to

I cannot volunteer to review this one this next two weeks. However I
wanted to point out that, when the XRBLOCK refers to rev -04 of the
Monitoring Architecture document, the current rev is -13.

Thanks,

-- Carlos.

Al

PMOL mailing list

[email-masked]

---

From: Al Morton <[email-masked]>
Date: Sun, 20 May 2012 09:21:42 -0400

Charles and Shida,

I gave this a brief look myself, and add the following comment:

3.3. Guidance on use of PDV metrics

This subsection provides informative guidance on when it
might be

appropriate to use each of the PDV metric types.

...

2-point PDV (Clause 6.2.4 of [Y.1540]) reports absolute
packet delay

variation with respect to the time of arrival of the
first packet of

the connection.  In an RTP context, the two
"points" are at the

sender (the synchronization source which applies RTP
timestamps) and

at the receiver.  The value of this metric for the
packet with index

j is identical to the quantity D(i,j) defined in Section
6.4.1 of

[RFC3550] if the packet index i is set equal to 1, that
is, the

reference packet for the metric is the first packet of
the

connection.  The metric includes the effect of the
frequency offsets

of clocks in both the sender and receiver end systems,
so it is

useful mainly in network where synchronisation is
distributed.  As

well as measuring packet delay variation in such
networks, it may be

used to ensure that synchronisation is effective, for
example where

the network carries ISDN data traffic over RTP
[RFC4040].  The metric

is likely to be useful in networks which use fixed
de-jitter

buffering, because it may be used to determine the
length of the

required de-jitter buffer, or to determine if network
performance has

deteriorated such that existing de-jitter buffers are
too small to

accommodate the observed delay variation.
While

"...The value of this metric for the packet with
index

j is identical to the quantity D(i,j) defined in Section
6.4.1 of

[RFC3550] if the packet index i is set equal to 1, that is,
the

reference packet for the metric is the first packet of
the

connection."

is true, it's not a particularly relevant comparison.

The reference packet "i" is not the first packet in either

the 3550 or the Y.1540 definition - this should be noted,

at least. Also, the reference to Y.1540 is not up to date,

a newer version is available.

This section should probably reference

http://tools.ietf.org/html/rfc5481

which includes all the metrics mentioned in section 3.3

and provides more complete guidance.

Al

At 08:57 AM 5/20/2012, Al Morton wrote:

Charles and Shida,

Al

PMDir admin

At 12:22 PM 5/16/2012,

Thanks,

-- Carlos.

Al

PMOL mailing list

[email-masked]

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 23 May 2012 10:08:54 -0700

Hi Al,

Thank you for your comments. I have added the XRBLOCK alias so folks
there can benefit from them.
Carlos, thanks for volunteering to review as well. When you do, please
include [email-masked] in your list of recipients.

Cheers,
Charles

> From: Al Morton [mailto:[email-masked]]
> Sent: Sunday, May 20, 2012 6:22 AM
> To: Carlos Pignataro (cpignata); Charles Eckel (eckelcu); shida@ntt-
> at.com
> Cc: Romascanu, Dan (Dan); [email-masked]
> Subject: Re: [PMOL] [xrblock] WGLC for Packet Delay Variation Metric
> Reporting
> 
> Charles and Shida,
> 
might
> be
packet
> delay
> 	   variation with respect to the time of arrival of the first
> packet of
> 	   the connection.  In an RTP context, the two "points" are at
> the
> 	   at the receiver.  The value of this metric for the packet
with
> 	   j is identical to the quantity D(i,j) defined in Section
6.4.1
> of
> 	   reference packet for the metric is the first packet of the
> 	   connection.  The metric includes the effect of the frequency
> offsets
> 	   of clocks in both the sender and receiver end systems, so it
> is
distributed.
> As
> 	   well as measuring packet delay variation in such networks, it
> may be
> 	   used to ensure that synchronisation is effective, for example
> where
> 	   the network carries ISDN data traffic over RTP [RFC4040].
The
> metric
> 	   is likely to be useful in networks which use fixed de-jitter
> 	   buffering, because it may be used to determine the length of
> the
> 	   deteriorated such that existing de-jitter buffers are too
> small to
>    "...The value of this metric for the packet with index
>    j is identical to the quantity D(i,j) defined in Section 6.4.1 of
>    [RFC3550] if the packet index i is set equal to 1, that is, the
>    reference packet for the metric is the first packet of the
>    connection."
<http://tools.ietf.org/html/rfc5481>
> 				I reviewed it and sent my comments a few
days
> ago to the XRBLOCK list -
> 				http://www.ietf.org/mail-
> archive/web/xrblock/current/msg00511.html <http://www.ietf.org/mail-
> archive/web/xrblock/current/msg00511.html> , I
> 			Thanks Dan, no need to apologize, just trying to
keep
> track.
> 				reporting formats, while for metrics
definition
> they are referring
http://tools.ietf.org/html/draft-ietf-avtcore-
> monarch-04 <http://tools.ietf.org/html/draft-ietf-avtcore-monarch-04>
.
> 		I cannot volunteer to review this one this next two
weeks.
> However I wanted to point out that, when the XRBLOCK refers to rev -04
> of the Monitoring Architecture document, the current rev is -13.
> 		http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-
> monarch-13.txt&url1=draft-ietf-avtcore-monarch-04.txt
> <http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-monarch-
> 13.txt&url1=draft-ietf-avtcore-monarch-04.txt>
> 
> 		Thanks,
> 
> 		-- Carlos.
> 
> 
> 
> 			Al
> 
> <https://www.ietf.org/mailman/listinfo/pmol>

---

From: Qin Wu <[email-masked]>
Date: Thu, 24 May 2012 12:59:32 +0800

Hi, Al:
I agree with your comments. Based on RFC5481 and the newly updated Y.1541 in March,2011,
the reference packet transfer delay should be chosen as the delay of the reference packet with minimum
delay.
Therefore I proposed the following change in the section 3.3, 3rd paragraph to get consistent with RFC5481 and Y.1541.
OLD TEXT:
"
   2-point PDV (Clause 6.2.4 of [Y.1540]) reports absolute packet delay
   variation with respect to the time of arrival of the first packet of
   the connection.  In an RTP context, the two "points" are at the
   sender (the synchronization source which applies RTP timestamps) and
   at the receiver.  The value of this metric for the packet with index
   j is identical to the quantity D(i,j) defined in Section 6.4.1 of
   [RFC3550] if the packet index i is set equal to 1, that is, the
   reference packet for the metric is the first packet of the
   connection. ...
"
NEW TEXT:
"
   2-point PDV (Clause 6.2.4 of [Y.1540]) reports absolute packet delay
   variation with respect to a defined reference packet transfer delay
    . One example of such reference packet is the first packet of the connection.
    Note that the reference IP packet transfer delay is the delay of the 
    reference packet with minimum
    delay [RFC5481] and  may be not the first packet delay of 
    the connection.
 In an RTP context, the two "points" are at the
   sender (the synchronization source which applies RTP timestamps) and
   at the receiver.  The value of this metric for the packet with index
   j is identical to the quantity D(i,j) defined in Section 6.4.1 of
   [RFC3550]. If the packet index i is set equal to 1, that is, the
   reference packet for the metric is the first packet of the
   connection.  ....
"
Also the reference to Y.1541 will be updated.

Regards!
-Qin

---

From: Al Morton <[email-masked]>
Date: Thu, 24 May 2012 08:31:02 -0400

Qin,

I'm sorry, but it's still completely misleading to talk about
the first packet as a reference packet in your text,
(even though you say mention it may not be the reference).
The first packet is not used as a reference because it sets an arbitrary
delay as the reference for the delay variation distribution,
and other problems follow.

I suggest that you make a stronger reference to RFC 5481
in this section, and remove the confusing text.

Al

At 12:59 AM 5/24/2012, Qin Wu wrote:
>Therefore I proposed the following change in the section 3.3, 3rd 
>paragraph to get consistent with RFC5481 and Y.1541.
>OLD TEXT:
>"
> >> archive/web/xrblock/current/msg00511.html 
> <http://www.ietf.org/mail->> archive/web/xrblock/current/msg00511.html> , I
> <http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-monarch->>

---

From: Qin Wu <[email-masked]>
Date: Fri, 25 May 2012 11:32:36 +0800

Hi, Al:
You are right, the Y.1540 has already got alignment with RFC5481 in the update.
and use RFC5481 as the reference.
So I propose the following change to the section 3.3, 3rd paragraph
OLD TEXT:
"
2-point PDV (Clause 6.2.4 of [Y.1540]) reports absolute packet delay
variation with respect to the time of arrival of the first packet of
the connection.  In an RTP context, the two "points" are at the
sender (the synchronization source which applies RTP timestamps) and
at the receiver.  The value of this metric for the packet with index
j is identical to the quantity D(i,j) defined in Section 6.4.1 of
[RFC3550] if the packet index i is set equal to 1, that is, the
reference packet for the metric is the first packet of the connection. ...
"
NEW TEXT:
"
2-point PDV (Clause 6.2.4 of [Y.1540]) reports absolute packet delay
variation with respect to a defined reference packet transfer delay
. Note that the reference packet is generally selected as the
packet with minimum delay based on the most common criterion (See section 1 and 
section 5.1 of [RFC5481]). In an RTP context, the two "points" are at the sender (the synchronization 
source which applies RTP timestamps) and at the receiver.  The value of 
this metric for the packet with index j is identical to the quantity 
D(i,j) defined in Section 6.4.1 of [RFC3550] and he packet index i should be 
set equal to the index of the reference packet for the metric in practice.  ....
"

Regards!
-Qin

---

From: Al Morton <[email-masked]>
Date: Fri, 25 May 2012 07:43:40 -0400

Thanks Qin, that should do it.
Al