Subject: [xrblock] Review of draft-zorn-xrblock-rtcp-xr-al-stat-4

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Mon, 6 Feb 2012 15:56:29 +0000

Hi all,

I've reviewed draft-zorn-xrblock-rtcp-xr-al-stat-4. Let me start by saying that I think the metrics discussed in this draft can be very useful in reporting on video quality, so I think in that sense that this draft definitely presents useful work. However, I do have some comments on the structure of the draft itself.

-          Section 1: Introduction. This section can use some improvement in the area of describing exactly why these specific metrics are needed and useful. What are the use cases? Why are these use cases not covered by the existing metrics? Although I definitely agree that they are useful, this should be documented.

-          Section 3.1: Burst/Gap Loss Summary Block. Again, this section can use some introduction. What is the context in which this block is used? Please give an overview of what it is supposed to convey.

-          Section 3.1: "The metrics described here are intended to be used as described in this section, in conjunction with information from the Measurement information block" If this is the block defined in draft-ietf-xrblock-rtcp-xr-meas-identity-02, then please add a reference to that document.

-          Section 3.2: See comment on section 3.1, please add some introduction and context.

-          Section 4.1: See above.

-          Section 4.1: If I understand correctly, the (T) field is used to indicate whether all frame-related metrics in the block relate to key-frames or derivation frames. How would this work in practice? For example, if I report on a certain period (let's say 4 seconds), do I send two loss/duplication blocks? One for both key-frames and derivation frames (both covering the same 4-second period)? Or do I send only one?

-          Section 4.1: I don't understand the 'number of frames expected' field. Can't this be calculated from the SSRC and the period indicated by the sequence numbers?

-          Section 4.1: Is it really necessary to have 32-bits fields for the four fields containing the number of frames expected/lost/duplicated? With a 16bit field and 25 fps, you can still report on a 43-minute period.

Best regards,

Ray van Brandenburg

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer

---

From: Qin Wu <[email-masked]>
Date: Fri, 10 Feb 2012 16:57:47 +0800

Hi, Ray:
Thank for valuable comments, please see my reply inline.

Regards!
-Qin
  ----- Original Message ----- 
  From: Brandenburg, R. (Ray) van 
  To: [email-masked] 
  Cc: [email-masked] 
  Sent: Monday, February 06, 2012 11:56 PM
  Subject: [xrblock] Review of draft-zorn-xrblock-rtcp-xr-al-stat-4

  Hi all,

[Qin]: Good point. That's one issue we need to fix in the update. In this draft we defines three new block types. The first two blocks should be used with Burst Gap Discard Block or Burst Gap Loss Block and depend on them to calculate summary statistics parameters. The use case we have are two

      1. media sender calculate summary statistics based on received burst gap loss block or burst gap discard block.

      2. media reciever calcualte summary statistics along with burst gap loss metric and burst gap discard metric.

      Burst Gap relate draft doesn't provide transport for these summary statistics since it assume these summary statitistics parameters can always be calculated by the reciepient of burst gap related metric block.

      The third block types we defined focus on report I/P/B frame statistics, since to form an accruate assessment of user quality of experience, it is therefore necessary to know not just overall rates of packet loss/discard, but also which frame type were affected. 

      I will rewrite the introduction to make this clear.

      [Qin]: Okay. Good suggestions.

     [Qin]: Okay.

    [Qin]: Okay.

   [Qin]: Okay.

 [Qin]: I think you can send two XRblock with each frame type  in one compount RTCP packet.

[Qin]: Good point, China Telecom lady als address the similar issue. I like to change the number of frame expected to "the number of frame received" since this metric is easy to be calculated by user end point.

[Qin]: I think your statement is correct.

However 32bit fields design follow the Statistics Summary Report Block defined in the section 4.6 of RFC3611.

Therefore I am not sure if changing 32bit field into 16bit field will break in some cases.

  Ray van Brandenburg

------------------------------------------------------------------------------

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