Subject: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-discard and xrblock-rtcp-xr-discard-rle-metrics

From: Shida Schubert <[email-masked]>
Date: Mon, 11 Jun 2012 15:27:05 +0900

All;

 We have had very little feedback (actually none) on 
WGLC for xrblock-rtcp-xr-discard-rle-metrics, which is 
ending on the 14th. 

 As xrblock-rtcp-xr-discard-rle-metrics references 
draft-ietf-xrblock-rtcp-xr-discard, we will try to run WGLC 
for these two drafts in parallel to hope for more feedbacks. 

 We will carry this WGLC until June 28th.

 If you are interested in one of the draft, please try to 
read through both drafts and provide some comments on 
the list. If there are no issues, please indicate that on the 
list as well to show that you have read and happy with the 
document(s).

 Many Thanks & Regards
  Shida Schubert as co-chair

---

From: Qin Wu <[email-masked]>
Date: Thu, 14 Jun 2012 15:24:30 +0800

Hi,
I have reviewed RLE discard draft. It will be good to see RLE discard draft getting in line with Discard draft.
Here are my comments to draft-ietf-xrblock-rtcp-xr-discard-rle-metrics:
1. Section 1, Paragraph 1:
s/individual events to report/individual events

s/long-term and short-term feedback/long-term and short-term feedbacks

2.Section 1, Paragraph 2:

s/albeit/but

3. Section 1, Paragraph 3:

s/Among many other fields/Among report blocks defined in RFC3611

4. Section 1, Pragraph 3:

OLD TEXT:

"

RFC3611 specifies the Loss RLE block which
   define runs of packets received and lost with the granularity of
   individual packets.

"

NEW TEXT"

"

the Loss RLE block reports runs of packets received and lost with the granularity of
 individual packets. 

"

5. Section 1, Paragraph 3:

OLD TEXT:

"

This metric is part of the
   VoIP metrics report block even though it is not just applicable to
   audio: it is specified as the fraction of discarded packets since the
   beginning of the session.  See section 4.7.1 of RFC3611 [RFC3611].

"

NEW TEXT:

"

 The related metric "discard rate" is part of the
   VoIP metrics report block even though it is not just applicable to
   audio: it is specified as the fraction of discarded packets from media source since the
   beginning of the reception  

"

6.Section1, Pragraph4:

s/cumulatively since the beginning of the session/ the duration of the session

7.Section 1, Paragraph 5:

OLD TEXT:

"

While this information could in theory
   be derived from high-frequency reporting on the number of discarded
   packets or from the gap/burst report

"

NEW TEXT:

"

While this information could in theory
   be derived from high-frequency reporting on the number of discarded
   packets [I-D.ietf-xrblock-rtcp-xr-discard] or from the gap/burst report

"

8. Section 3, Paragraph 1:

"figure" repeat twice, please delete either one.

9.Section 3, Paragraph 4:

Discard draft support report packets discarded due to both early and late arrival.

 It is better for this draft to get in line with Discard draft. If it is in this case, I suggest

 to allocate 2bits for E flag and using 2 bits flag to support reporting discarded due to

 both early and late arrival.

10. Section 3, Paragraph 4:

Are you emphasizing that packets reported in this block should be the packets that is not 

properly received but discarded? If not, please clarify.

11.Section 4, Paragraph 2,definition of Interval metric flag

Do you think this metric could be sampled metric or not? 

12.Section 4, Paragraph 3, definition of "E"flag

I think chunk is not defined in this report block format and should be removed or replaced. 

13.Section 4, Paragraph 3, definition of "E"flag

The last sentence of this paragraph said:

"In caseboth early and late discarded packets shall be reported, two Bytes

   Discarded report blocks MUST be included.

"

Why not expand 1 bit E flag into 2 bits flag to support reporting bytes discarded due to

 both early and late arrival?

14. Section 4, Paragraph 7:

"From" repeated twice in the paragraph 7.

Shouldn't the measurement information block is followed by related metric blocks in the same RTCP compound packet?

I suggest remove "If the XR block is not preceded by a measurement identity block
" with the following change:

OLD TEXT:

"

   If the XR block is not preceded by a measurement identity block
   [I-D.ietf-xrblock-rtcp-xr-meas-identity] then the value indicates the
   bytes lost from from the start of the session (I=11), or the number
   of bytes discarded since the last RTCP XR Bytes Discarded block was
   received (I=10).

"

NEW TEXT:

"

If Interval Metric flag (I=11) is set, the value in the field indicates the 

bytes lost from the start of the session, if Interval Metric 

flag (I=01) is set, it indicates the number of bytes discarded since the

 last RTCP XR Byte Discarded Block was received.

"

15.Section 4, Paragraph 8:

s/in an RTCP RR packet/ in the same RTCP compound packet

16.Section 4, Paragraph 8:

It looks interval metric flag can not be set to (I=01) and (I=11) at the same time, suggest the following change:

OLD TEXT:

"then the cumulative (I=11) and interval (I=10) correspond to the values in

   the measurement block.

"

NEW TEXT:

"

Then the cumulative interval (I=11) or interval (I=10) for this report block

 corresponds to the value of "measurement duration" in the measurement

 information block.

"

17.Section 5, Paragraph 1:

Suggest to change RTP node into RTCP reporting node (media receiver )

and change sender RTP node into RTCP report collector (Media Sener)

This comment also apply other place that uses RTP node and sender RTP node.

18.Section 5.1, Paragraph 2:

I think XR report is for regular RTCP reporting not used for timely feedback. 

Therefore I am not sure Discard RLE report can be included in immediate or early feedback packets as per RFC4585.

19.Section 5.2, last paragraph:

Do we have compound RTCP RR? Did you mean

 this report block is received with RR in the same RTCP compound packet?

20. Section 6, Paragraph 1:

s/RTCP report metrics/RTCP report

21. Section 6, Paragraph 2:

s/the discard metric/the RLE discard metrics and bytes discarded metrics

22. Section 6, Paragraph 3:

s/literal/parameter,

this comment also apply to other place which use "literal"

"section: repeat twice, please remove either one.

23. Section 6,Paragraph 4:

s/discard metric/RLE discard metrics and bytes discarded metrics

s/this metric/these metrics

Regards!

-Qin

----- Original Message ----- 

From: "Shida Schubert" <[email-masked]>
To: "xrblock" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, June 11, 2012 2:27 PM
Subject: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-discard andxrblock-rtcp-xr-discard-rle-metrics

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

---

From: "Roni Even" <[email-masked]>
Date: Fri, 15 Jun 2012 23:12:23 +0300

Hi,
I read draft-ietf-xrblock-rtcp-xr-discard. In general it is ready.

One nit is in figure 1 it says BT=NBGD while elsewhere it says BT=ND

As for the number of packet discarded I was wondering if the relevant
information is the number of packet or in the case of video for example
where a couple of packet constitute one frame and have the same time stamp
they should count as one packet (or one video frame)

Roni

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Shida Schubert
> Sent: Monday, June 11, 2012 9:27 AM
> To: xrblock
> Cc: [email-masked]; draft-
> [email-masked]
>  We have had very little feedback (actually none) on WGLC for xrblock-
> rtcp-xr-discard-rle-metrics, which is ending on the 14th.
> 
>  As xrblock-rtcp-xr-discard-rle-metrics references draft-ietf-xrblock-
> rtcp-xr-discard, we will try to run WGLC for these two drafts in
> parallel to hope for more feedbacks.
> 
>  If you are interested in one of the draft, please try to read through
> both drafts and provide some comments on the list. If there are no
> issues, please indicate that on the list as well to show that you have
> read and happy with the document(s).
> 
>  Many Thanks & Regards

---

From: Qin Wu <[email-masked]>
Date: Mon, 18 Jun 2012 09:57:36 +0800

----- Original Message ----- 
From: "Roni Even" <[email-masked]>
To: "'Shida Schubert'" <[email-masked]>; "'xrblock'" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Saturday, June 16, 2012 4:12 AM
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-discardand xrblock-rtcp-xr-discard-rle-metrics

> One nit is in figure 1 it says BT=NBGD while elsewhere it says BT=ND

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

> they should count as one packet (or one video frame)

[Qin]: It is former since it rely on time window and is still calculated based on sequence number of RTP packet.
Also it is used with "Packets Expected " to calculate "Gap Discard Rate" in draft-zorn-xrblock-rtcp-xr-al-stat.
As described in draft-zorn-xrblock-rtcp-xr-al-stat, 

"Packets Expected is calculated as the
 difference between "extended last sequence number" and "extended
 first sequence number" (Interval or Cumulative) provided in the
 Measurement Information block [MEASIDENT].
"

Regarding a couple of packet constituting a frame, I think you refer to 
"the number of frame discarded", this metric is actually not specified in the Discard draft but in 
"Frame Impairment Statistics Summary Block " defined in draft-zorn-xrblock-rtcp-xr-al-stat.
That is to say, Frame Impairment Statistics Summary Block can be used to report "the 
number of frame discarded".

---

From: Shida Schubert <[email-masked]>
Date: Tue, 26 Jun 2012 12:23:49 +0900

Folks;

 The WGLC is ending soon. 

 If you haven't reviewed the draft or you have but haven't 
provided any feedback please do so.

 Many Thanks.

 Shida as co-chair

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 28 Jun 2012 14:02:27 +0200

(as contributor)

I read the documents and they look almost ready for submission to the
IESG. 

Here are a few comments on draft-ietf-xrblock-rtcp-xr-discard:

1. It would be useful I think to say more about the relation between
this metric and the discard rate metric defined in section 4.7.1 of RFC
3611. Maybe calling the metric here Discarded Packets metric would help,
as both RFC 3611 and this document refer to 'discard metric' but the two
are different (one is rate, the other packets). 

2. In Section 3.1 diagram we use NBGD for Block Type, while the text in
Section 3.2 refers to the ND constant. We should get to a consistent
representation 

3. 

Section 2.1: 

      A packet that arrives within
      this time window but is too early or late to be played out shall
      be regarded as discarded.  A packet shall be classified as one of
      received (or OK), discarded or lost.  The Discard Metric counts
      only discarded packets.  

Section 3.1 however includes: 

         00: packets are discarded due to other reasons than late
         arrival, early arrival, or both (e.g., duplicate, redundant
         packets).

This seems inconsistent. 

4. Is there any reasons for the Interval Metric flag (I) to be 2 bits,
rather than one bit, with the other one reserved? 

5. number of packets discarded:

> If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE
      SHOULD be reported to indicate an over-range measurement.  

Why is this a SHOULD and not a MUST? Are there any exceptions? 

6. In the IANA Considerations section: 

s/ The contact information for the registrations is/ The following
contact information is provided for all registrations in this document/

Here are a few comments on
draft-ietf-xrblock-rtcp-xr-discard-rle-metrics:

1. Runing idnits indicates that references to RFC 3551 and RFC 5760 are
unused. 

2. Section 3 - explain that the BT field MUST be assigned the DRLE value
assigned by IANA as per the assignment required in the IANA
Considerations section. Also there are three 'rsvd' bits in Figure 1,
while the text mentions only 2. 

3. Section 4 - explain that the BT field MUST be assigned the BDR value
assigned by IANA as per the assignment required in the IANA
Considerations section.

4. Is there any reasons for the Interval Metric flag (I) to be 2 bits,
rather than one bit, with the other one reserved?

Regards,

Dan

> Cc: [email-masked];
draft-ietf-
> [email-masked]

---

From: Qin Wu <[email-masked]>
Date: Fri, 29 Jun 2012 11:33:11 +0800

Hi,Dan:
Thank for your valuable review to draft-ietf-xrblock-rtcp-xr-discard.
Please see my replies inline.

Regards!
-Qin
----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Shida Schubert" <[email-masked]>; "xrblock" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, June 28, 2012 8:02 PM
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-discardandxrblock-rtcp-xr-discard-rle-metrics

> are different (one is rate, the other packets). 

[Qin]: Good point, I propose to change 'discard metric' in this document into 'discard count  metric' since
abstract in this draft also uses 'discard count metric'.

To make this consistent with SDP parameter defined in this document, I also like to propose to do the following change
OLD TEXT:
"
   xr-format =/ xr-pd-block

    xr-pd-block = "pkt-dscrd"

"
NEW TEXT:
"
   xr-format =/ xr-pdc-block

    xr-pdc-block = "pkt-dscrd-count"

"

> Section 3.2 refers to the ND constant. We should get to a consistent

[Qin]: It is a typo and will fix this by changing NBGD into ND.
>         arrival, early arrival, or both (e.g., duplicate, redundant

[Qin]: Good question. To make them consistent, I propose do the following change to Section 2.1
OLD TEXT:
"

"
NEW TEXT:
"

this time window but is too early or late to be played out 

or is thrown away before playout (e.g., packet duplication or redundancy) 

shall be regarded as discarded.  A packet shall be classified as one of

received (or OK), discarded or lost.  The Discard Count Metric counts

only discarded packets.
"

> rather than one bit, with the other one reserved? 

[Qin]: Good question, I remembered we got a suggestion on the list before from Kevin Gross which suggested to 
remove Sampled metric related description from the definition of Interval Metric flag. Since Sampled metric is 
measured only at a particular time instant however metrics defined in this document is 
measured over one or several reporting intervals.To get in line with the defintion 
of the Interval Metric flag in other XR BLOCK drafts and address your comment, 
I propose the following change to the defintion of the interval metric flag:

OLD TEXT:
"
   Interval Metric flag (I): 2 bits

      This field is used to indicate whether the Discard metric is an
      Interval or Cumulative metric, that is, whether the reported
      values applies to the most recent measurement interval duration
      between successive metrics reports (I=10) (the Interval Duration)
      or to the accumulation period characteristic of cumulative
      measurements (I=11) (the Cumulative Duration).

"
NEW TEXT:
"
   Interval Metric flag (I): 2 bits

      This field is used to indicate whether the Discard Count Metric is an

      Interval or Cumulative metric, Sample metric,that is, whether the reported

      values applies to the most recent measurement interval duration

      between successive metrics reports (I=10) (the Interval Duration)

      or to the accumulation period characteristic of cumulative

      measurements (I=11) (the Cumulative Duration) or is a

      sampled instantaneous value (I=01) (Sampled Value). In this document, 

      Discard Count Metric is not measured at a particular time instant but over 

      one or several reporting intervals. Therefore Discard Count Metric MUST not 

      be chosen as Sampled Metric.

"

> Why is this a SHOULD and not a MUST? Are there any exceptions? 

[Qin]: No,  I will use MUST based on your comment.

> contact information is provided for all registrations in this document/

[Qin]: Okay.