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

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

> -----Original Message-----
> 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,
> 
> 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
<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,
> 
> 	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 <http://www.ietf.org/mail-
> archive/web/xrblock/current/msg00511.html> , I
> 				apologize for not copying PMOL.
> 
> 
> 			Thanks Dan, no need to apologize, just trying to
keep
> track.
> 
> 
> 
> 				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 <http://tools.ietf.org/html/draft-ietf-avtcore-monarch-04>
.
> 
> 
> 			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
> <http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-monarch-
> 13.txt&url1=draft-ietf-avtcore-monarch-04.txt>
> 
> 		Thanks,
> 
> 		-- Carlos.
> 
> 
> 
> 			Al
> 
> 			_______________________________________________
> 			PMOL mailing list
> 			[email-masked]
> 			https://www.ietf.org/mailman/listinfo/pmol
> <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
----- Original Message ----- 
From: "Charles Eckel (eckelcu)" <[email-masked]>
To: "Al Morton" <[email-masked]>; "Carlos Pignataro (cpignata)" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, May 24, 2012 1:08 AM
Subject: Re: [xrblock] [PMOL] WGLC for Packet Delay Variation MetricReporting

> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock

---

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
----- Original Message ----- 
From: "Al Morton" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Charles Eckel (eckelcu)" <[email-masked]>; "Carlos Pignataro (cpignata)" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, May 24, 2012 8:31 PM
Subject: Re: [xrblock] [PMOL] WGLC for Packet Delay Variation MetricReporting

> 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:
>>Hi, Al:
>>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->>