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

From: Shida Schubert <[email-masked]>
Date: Wed, 2 May 2012 14:02:18 +0900

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

---

From: Alan Clark <[email-masked]>
Date: Wed, 2 May 2012 17:13:39 -0400

Shida

The draft looks good for progression with one minor correction. MAPDV2 is a
comparison of instantaneous delay with a short term moving average delay.

Change

   MAPDV2 (Clause 6.2.3.2 of [G.1020])compares instantaneous (per-
   packet) delay variation against a moving average delay variation.

to

   MAPDV2 (Clause 6.2.3.2 of [G.1020]) is the envelope of instantaneous
  (per-packet) delay when compared to the short term moving average delay.

Best Regards

Alan

On 5/2/12 1:02 AM, "Shida Schubert" <[email-masked]> wrote:

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

---

From: Qin Wu <[email-masked]>
Date: Thu, 3 May 2012 13:52:01 +0800

----- Original Message ----- 
From: "Alan Clark" <[email-masked]>
To: "Shida Schubert" <[email-masked]>
Cc: "xrblock" <[email-masked]>
Sent: Thursday, May 03, 2012 5:13 AM
Subject: Re: [xrblock] WGLC for Packet Delay Variation Metric Reporting

>  (per-packet) delay when compared to the short term moving average delay.

[Qin]: Agree, the proposed change removes ambiguity the existing description has and 
looks reasonable to me.

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Thu, 3 May 2012 05:52:20 +0000

Hi Shida,

I think this draft is in good shape. I only have 3 minor comments.

1. The definition of Interval Metric flag (I):

   Sample values are not always sampled at the end of the interval. It is possible to sample them in middle of the interval. 

    change 

    "or to the
      value of a continuously measured or calculated that has been
      sampled at end of the interval (I=01) (Sampled Value)."

   to
   
   " or to the
      value of a continuously measured or calculated that has been
      sampled at any given instance of the interval (I=01) (Sampled Value)."

2. Block Length: 16 bits

  " The length of this report block in 32-bit words, minus one.  For
      the Packet Delay Variation Metrics block, the block length is
      equal to 3. "

  This definition should be compliant with RFC3611. In RFC3611, the definition of Block Length includes the header of the block. So I think the block length is equal to 4, not 3.

3. Packet Delay Variation Metric Type (pdvtyp): 4 bits

   What's the meaning of " bits 014-017 "? If it is the bits position of the field "pdvtyp", I think it should be corrected. 

Others 

Best Regards!
Rachel

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

  17th of May

Regards

 Shida as co-chair

---

From: Qin Wu <[email-masked]>
Date: Thu, 3 May 2012 16:03:07 +0800

Hi,Rachel:
Thank for your comments. Please see my replies inline.

Regards!
-Qin
----- Original Message ----- 
From: "Huangyihong (Rachel)" <[email-masked]>
To: "Shida Schubert" <[email-masked]>
Cc: "xrblock" <[email-masked]>
Sent: Thursday, May 03, 2012 1:52 PM
Subject: Re: [xrblock] WGLC for Packet Delay Variation Metric Reporting

>      sampled at any given instance of the interval (I=01) (Sampled Value)."

[Qin]: Good catch.
To get consistent with sample metric definition in the Monarch draft, I agree with your proposed change. 
and this comment also applies to other new XR Block drafts we are working on in the XRBLOCK WG
, which should be updated synchronously.

>  This definition should be compliant with RFC3611. In RFC3611, the definition of Block Length includes the header of the block. So I think the block length is equal to 4, not 3.

[Qin]: Agree and will fix this.

>   What's the meaning of " bits 014-017 "? If it is the bits position of the field "pdvtyp", I think it should be corrected. 

[Qin]: That's a good question. "bits014-017" represents four bits allocated from Block header for "pdvtyp" field.
That is to say, bit 014 is the last bit of 14 leftmost bits in the block header. bit 015 is the last bit of 15 leftmost bits in the block header ,and so on.
So I think you are right, the "bits 014~017" should be fixed as "bits 014~011"

---

From: "Roni Even" <[email-masked]>
Date: Thu, 3 May 2012 13:08:47 +0300

Hi,
I think the draft is in good shape, I have some comments

1. This is editorial, in section 1.1 I am not sure that saying(work in
progress) is required, can be deleted.

2. In section 3.2 - Interval Metric flag says that is indicates whether the
Basic Loss/discard metrics are sampled ...
I think it should say the Packet Delay variation metrics.

3. I am not sure what bits 014-017 are in the pdvtype definition.

4. About Positive PDV Threshold/Peak, I understand that it is usually
threshold, I did not see when it is used as peak value, can we have some
text about the usage as peak. This is the same for the Negative PDV
Threshold/Peak

5. For the Positive PDV Threshold/Peak, I was wondering if the Threshold can
be a negative value, same for the Negative PDV Threshold. I am asking since
this is the threshold value that is used to calculate the percentage of
packets above or bellow.

Roni Even

> Sent: Wednesday, May 02, 2012 8:02 AM
> To: xrblock
> 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.
>

---

From: Qin Wu <[email-masked]>
Date: Fri, 4 May 2012 10:48:56 +0800

Hi, Roni:
Thank for your valuable review. please see my replies inline below.

Regards!
-Qin
----- Original Message ----- 
From: "Roni Even" <[email-masked]>
To: "'Shida Schubert'" <[email-masked]>; "'xrblock'" <[email-masked]>
Sent: Thursday, May 03, 2012 6:08 PM
Subject: Re: [xrblock] WGLC for Packet Delay Variation Metric Reporting

> progress) is required, can be deleted.

[Qin]: Okay.

> I think it should say the Packet Delay variation metrics.

[Qin]: Good catch and will fix this typo in the update.

> 3. I am not sure what bits 014-017 are in the pdvtype definition.

[Qin]: Bits 014~017 means the fourteenth bit from the left to seventeenth bit from the left.
As I explained to Rachel for this similar issue, I think bits 014~017 in the current version should
be corrected as "bits 014~011".

> text about the usage as peak. This is the same for the Negative PDV

[Qin]:Just to clarify, the usage of PDV metric has already been discussed in the section 3.3 and 3.4, especially in section 3.4, second paragraph.
Regarding usage as peak, my understanding is this usage has already been covered by section 3.4. 
You are right, the Threshold may not be the peak value or maximum value, otherwise, the Pos PDV Percentile and Negative PDV Percentile 
should always been 100.

Take MAPDV2 as an example, if we fixed Pos PDV Threshold = 50.0 (note this implies 50ms) and Neg PDV
Threshold = 50.0 (note this implies -50ms);  we have gathered 100 measured value, in 200 measured value,
10 measured values are greater than 50 ms, 90 measured values are less than 50 ms and greater than 0 ms.
20 measured values are less than -50 ms, 80 measured values are less than 0 ms and greater than -50 ms.
Then the Pos PDV Percentile = (90/90+10)*100=90, the negative PDV Percentile  = (80/80+20)*100=80;

> this is the threshold value that is used to calculate the percentage of

[Qin]: See above, the answer is no. The Threshold correspond to Postive PDV Threshold/Peak should
be positive. The Threshold corresponding to Negative PDV Threshold/Peak should be negative.
Otherwise, PDV Threshold/Peak will not be separated into two kinds: i.e.,
Postive PDV Threshold and Negative PDV Threshold.

---

From: Colin Perkins <[email-masked]>
Date: Fri, 4 May 2012 12:37:08 +0100

> http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-pdv-02

I have three small comments:

- As with the xr-delay metric draft, this draft should clarify that the measurement information block should be sent in the same compound RTCP packet as the PDV report. This issue should be checked across all the draft that reference the measurement information block.

- One field is marked as "reserved" while another is "unused". Is there a difference in meaning intended? If not, I suggest using a common label.

- Inter-arrival jitter is defined as a 32 bit value in RFC3550 section 6.4.1. How is it to be reported in 16 bit fields? Also, in Section 3.4 it suggests that some fields should be reported as “undefined” when using RTP jitter, but this is not specified in the definition of those fields.

-- 
Colin Perkins
http://csperkins.org/

---

From: Qin Wu <[email-masked]>
Date: Mon, 7 May 2012 10:40:21 +0800

Hi:
----- Original Message ----- 
From: "Colin Perkins" <[email-masked]>
To: "Shida Schubert" <[email-masked]>
Cc: "xrblock" <[email-masked]>
Sent: Friday, May 04, 2012 7:37 PM
Subject: Re: [xrblock] WGLC for Packet Delay Variation Metric Reporting

[Qin]: Agree, in the section 3, 1st paragraph, we have already clarify with the following text:
"
  Instances of this Metrics Block refer by
   SSRC to the separate auxiliary Measurement Information block [MEASI]
   which contains measurement intervals.  This metric block relies on
   the measurement interval in the Measurement Information block
   indicating the span of the report.  If the measurement interval is
   not received for this metric block, this metric block should be
   discarded.
"
For better understanding, I propose to change the above text as following:
NEW Text
"
  Instances of this Metrics Block refer by
   SSRC to the separate auxiliary Measurement Information block [MEASI]
   which contains measurement intervals.  This metric block relies on
   the measurement interval in the Measurement Information block
   indicating the span of the report and should be sent in the same 
  compound RTCP packet as the measurement information block.  If the measurement interval is
   not received for this metric block, this metric block should be
   discarded.
"
Does this address your comment?

[Qin]: I think they are same and can replace "unused" with "reserved" for consistency.

- Inter-arrival jitter is defined as a 32 bit value in RFC3550 section 6.4.1. How is it to be reported in 16 bit fields? 

[Qin]: That's a good question. But it seems a little bit tough to fix since the basic idea to use 16 bit value is to use one common 
block format to report each PDV metric type including inter-arrival jitter, MAPDV, 2-point PDV.
For MAPDV, 2-point PDV, I think 16 bit value, expressed with numeric format S11:4 is more than enough.

However for Inter-arrival Jitter, 16bit value with numeric format S11:4 is not consistent with 32 bit Inter-arrival Jitter in timestamp units defined in RFC3550
and only can report the value between -2047.9375ms~+2047.9375ms. However 32 bit Inter-arrival Jitter defined in RFC3550 can report the value range from
0~65536 seconds.
 So my counter question is do we really need to report PDV value more than 2 or 3 seconds?
If the answer is yes, we can change 16 bit value into 32 bit value, remove 16 bit unused field  and update the 1st paragraph of the  "Mean PDV" definition as follows:
OLD Text:
"
   Mean PDV: 16 bits

      The mean PDV value of data packets is expressed in milliseconds
      with Numeric format S11:4 format.

"
NEW Text:
"
   Mean PDV: 32 bits

      For MAPDV2 and 2-point PDV, the least significant 16bit of the mean PDV value of data packets is expressed in milliseconds
      with Numeric format S11:4 format. The most significant 16bit should be set to 0x0000.
      For interarrival jitter, the mean PDV value of data packets is expressed in units of 1/65536 seconds.
"
If the answer is no, we'd better keep the existing text unchanged.
Colin, What do you think of it?

-Also, in Section 3.4 it suggests that some fields should be reported as “undefined” when using RTP jitter, but this is not specified in the definition of those fields.

[Qin]: That's a good point, just to clarify, those fields you mentioned have already specified the value to report "unavailable measurement". I think "unavailable" and "undefined"
are the same things. Therefore I suggest to fix this issue by changing "undefined" in the section 3.4 into "unavailable". 
-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Mon, 7 May 2012 11:37:21 +0100

> Does this address your comment?

Yes.

> [Qin]: I think they are same and can replace "unused" with "reserved" for consistency.

Ok.

> and only can report the value between -2047.9375ms~+2047.9375ms. However 32 bit Inter-arrival Jitter defined in RFC3550 can report the value range from

The RTP jitter value is in RTP timestamp units, and potentially has a much wider range than that.

> Colin, What do you think of it?

I don't think the current text is sufficient, since it does not clearly define how to convey the inter-arrival jitter, and your new text doesn't fit the definition of the inter-arrival jitter.

Perhaps a better question would be to ask why another way of carrying the inter-arrival jitter is needed, or if it can be removed, since it doesn't seem to fit with the definitions of the other metrics.

> are the same things. Therefore I suggest to fix this issue by changing "undefined" in the section 3.4 into "unavailable". 

This doesn't address my comment. For each of the fields in Section 3.2, I think you need to specify how they are used with each type of PDV metric, and which are unavailable.

-- 
Colin Perkins
http://csperkins.org/

---

From: Qin Wu <[email-masked]>
Date: Tue, 8 May 2012 11:58:10 +0800

[Qin]: Agree.

[Qin]: Since all compound RTCP packets begin with an SR or RR packet, if we assume the metric block should be sent in the compound RTCP packet,
I see no reason to recapitulates inter-arrival jitter field from SR or RR packet and put it into a new XR Block.

[Qin]: You are right.
However if we agree to remove inter-arrival jitter part in this draft, I think it is not neccessary to specify "undefined" and distinguish the useage of each type of PDV metric anymore.
am I right?

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Tue, 8 May 2012 11:24:19 +0100

On 8 May 2012, at 04:58, Qin Wu wrote:
...
> However if we agree to remove inter-arrival jitter part in this draft, I think it is not neccessary to specify "undefined" and distinguish the useage of each type of PDV metric anymore.

Yes: if you decide that it's appropriate to remove inter-arrival jitter as a metric, then you don't need to specify how the fields in Section 3.2 are used with inter-arrival jitter.

-- 
Colin Perkins
http://csperkins.org/

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 13 May 2012 22:06:22 +0200

Hi,

Please find below my comments and questions related to this I-D. 

1. Section 1.3: 

   Metrics
   described in this draft either reference external definitions or
   define metrics generally in accordance with the guidelines in
   [RFC6390].

Why 'generally'? 

2. Section 1.4 says nothing as it stands. Maybe it should refer RFC
5481? Or maybe refer of some of the applicability stuff described in
Section 3.3? 

3. Section 2 - should not it be called 'Notations' rather than
'Definitions'? 

4. Expand SSRC at first occurrence

5. Reference [MEASI] does not exist

6.  Section 3.2 -  definition of Packet Delay Variation Metric Type
(pdvtyp) is not well in synch with the IANA considerations in Section
5.4. It does not say that the value of the field is to be interpreted as
Integer, and mentioning of bits 014-017 further enhances the confusion.
It does not mention this is an initial allocation for an IANA registry.
The three values allocated are 0,1,2 in 3.2 and 1,2,3 in 5.4 (0,1,2 is
better IMO as 0 has no special meaning, and this field allows for a max
of 16 values)

7. Section 3.2 - why are the recommendations for unavailable values
SHOULD and not MUST? For example ' If the measurement is unavailable,
the value 0x7FFF SHOULD be reported.' for Positive PDV Threshold/Peak.
Or ' If the measurement is unavailable, the value 0xFFFF SHOULD be
reported.' for Negative PDV Threshold/Peak. Are there any cases of
exception? Which are these? 

8. Same question in Section 4 for SDP Signaling. Why ' if the metric is
not available, the system receiving the SDP SHOULD send the metric block
with the flag value indicating that the metric is unavailable.' Why a
SHOULD and not a MUST?

9. Section 6: 

' This block does not provide per-packet statistics so the risk to
   confidentiality documented in Section 7, paragraph 3 of [RFC3611]
   does not apply.'

This phrase seems to say that there is not risk to confidentiality which
is not accurate. Although the statistics are not per packet the risk for
confidentiality concerning the performance on path is the same as the
one pointed to in RFC 3611. 

Thanks and Regards,

Dan

'

---

From: Qin Wu <[email-masked]>
Date: Mon, 14 May 2012 13:57:45 +0800

Hi, Dan:
Thank for your valuable review, please see my replies inline below.

Regards!
-Qin
----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "xrblock" <[email-masked]>
Sent: Monday, May 14, 2012 4:06 AM
Subject: Re: [xrblock] WGLC for Packet Delay Variation Metric Reporting

>   define metrics generally in accordance with the guidelines in

[Qin]: "Generally" means metrics should be defined generally for a wide range of applications rather than
specific for one application.

> 5481? Or maybe refer of some of the applicability stuff described in

[Qin]: That's a very good point. I propose the following change:
OLD Text:
"
1.4.  Applicability

   These metrics are applicable to a range of RTP applications.

"
NEW Text:
"
1.4.  Applicability

   These metrics are applicable to a wide range of RTP applications in which the 
   application streams  are sensitive to delay  variation [RFC5481].
"

> 3. Section 2 - should not it be called 'Notations' rather than

[Qin]: Correct and will fix this.

[Qin]: Okay.

> 5. Reference [MEASI] does not exist

[Qin]: Good catch and will add.

> 5.4.

[Qin]: You are right, PDV type 0, 1,2 does not synch with 1,2,3 in the IANA Consideration section 5.4.
Actually, "1,2,3" in the Initial assignment in the current version just stand for the order of the three assignment rather than PDV type.
I will fix this by correcting "1,2,3"  in 5.4 to the pdv type value 0,1,2. 

> It does not say that the value of the field is to be interpreted as
> Integer, 

[Qin]: You are right, PDV type is of type enumerated and should be interpreted as Integer.

>and mentioning of bits 014-017 further enhances the confusion.

[Qin]: Bits 014~017 means the fourteenth bit from the left to seventeenth bit from the left.
You are right, As I explained to Rachel and Roni on the list for this confusing issue, I think bits 014~017
 in the current version should be corrected as "bits 014~011".

However we do not need to mention bits 014~17 in the IANA registry for initial allocation.

> better IMO as 0 has no special meaning, and this field allows for a max

[Qin]: Agree, see above.

> exception? Which are these? 

[Qin]: I think you are right. There is no exception case in my mind. I propose 
to use "MUST" to replace "SHOULD".

> with the flag value indicating that the metric is unavailable.' Why a

[Qin]: To be consistent, I think we should use "MUST".

> is not accurate. 
>Although the statistics are not per packet the risk for

[Qin]: You should look at the 1st sentence of Section 6:
"
   It is believed that this proposed RTCP XR report block introduces no
   new security considerations beyond those described in [RFC3611].
"
I think the 1st sentence, Section 6 of this document has already indicated that
the existing security consideration described in [RFC3611] applies
to this document except the Section 7, paragraph 3 of [RFC3611]. 

Since the section 7, paragraph 3 of [RFC3611] is only applicable to the RTCP
XR packet with per-packet information included, i.e., a sequence of received packets
should be reported in one RTCP XR Report Block. Several examples of such RTCP XR 
report block are Loss RLE, Duplicate RLE, and Packet Receipt Times Report Blocks.

Apparently PDV metric report block does not belong to such kind of Report Blocks.