Subject: Re: [xrblock] I-D Action: draft-zorn-xrblock-rtcp-xr-al-stat-04.txt

From: [email-masked]
Date: Tue, 31 Jan 2012 17:10:30 +0800 (CST)

Hi, Qin:

I have review draft-zorn-xrblock-rtcp-xr-al-stat and have two comments.

1.This draft specifies three new XR Blocks. The first two are linked to burst gap

loss draft and burst gap discard draft. I agree with you that these two XR blocks

define calculation method for the derived metrics mentioned in the burst gap drafts.

and are two most important metric blocks which the burst gap drafts count on.

My question is who sends these two XR blocks?

2. The third XR Block defined in this draft is Statistics Summary Block for

Application Layer Loss/Duplication. I think this XR Block is linked to I/P/B frame statistics.

This metric blocks can tell us which frame types were affected and is therefore a useful metric

to form an accurate assessment of user quality of experience. However it is not clear to me

how do you calculate Number of frames expected? Isn't more easier to calculate how many frames are received

ranther than gathering the number of frame expected?

Another comment is isn't it useful to collect how many different type of frames were discarded

by the media reciever?

Cheers!

ZhaoJing

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

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

From: "Qin Wu" <[email-masked]>

To: <[email-masked]>

Sent: Thursday, January 19, 2012 4:40 PM

Subject: Re: [xrblock] I-D Action: draft-zorn-xrblock-rtcp-xr-al-stat-04.txt

> Hi,

> A minor update to draft-zorn-xrblock-rtcp-xr-al-stat which is used to get consistent with Burst Gap related draft.

> This draft missed the discussion due to presentation timeout  in the last IETF meeting. However this draft provides calculation method

> for the derived metric listed in the two burst gap related draft and also defines RTCP XR packet format to carry these derived

> metric.

> I like to see WG adopt this draft as work item or adopt a milestone to link to this draft.

> Any review and comments are welcome.

> Regards!

> -Qin

> ----- Original Message -----

> From: <[email-masked]>

> To: <[email-masked]>

> Sent: Thursday, January 19, 2012 3:04 PM

> Subject: I-D Action: draft-zorn-xrblock-rtcp-xr-al-stat-04.txt

>> A New Internet-Draft is available from the on-line Internet-Drafts directories.

>> Title           : RTCP XR for Summary Statistics Metrics Reporting

>> Author(s)       : Glen Zorn

>>                          Roland Schott

>>                          Qin Wu

>>                          Rachel Huang

>> Filename        : draft-zorn-xrblock-rtcp-xr-al-stat-04.txt

>> Pages           : 15

>> Date            : 2012-01-18

>>   This document defines three RTCP XR Report Blocks and associated SDP

>>   parameters that allows the reporting of loss, duplication and discard

>>   summary statistics metrics for use in a range of RTP applications.

>> A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-zorn-xrblock-rtcp-xr-al-stat-04.txt

>> Internet-Drafts are also available by anonymous FTP at:

>> ftp://ftp.ietf.org/internet-drafts/

>> This Internet-Draft can be retrieved at:

>> ftp://ftp.ietf.org/internet-drafts/draft-zorn-xrblock-rtcp-xr-al-stat-04.txt

>> _______________________________________________

>> I-D-Announce mailing list

>> [email-masked]

https://www.ietf.org/mailman/listinfo/i-d-announce

>> Internet-Draft directories:
http://www.ietf.org/shadow.html

>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

> _______________________________________________

> xrblock mailing list

> [email-masked]

https://www.ietf.org/mailman/listinfo/xrblock

---

From: Qin Wu <[email-masked]>
Date: Wed, 01 Feb 2012 10:29:56 +0800

Hi, Jing:
Thank for taking time to review this document. Please see my replies inline below.

Regards!
-Qin
  ----- Original Message ----- 
  From: [email-masked] 
  To: Qin Wu ; xrblock 
  Sent: Tuesday, January 31, 2012 5:10 PM
  Subject: Re: Re: [xrblock] I-D Action: draft-zorn-xrblock-rtcp-xr-al-stat-04.txt

  Hi, Qin: 
   
  1.This draft specifies three new XR Blocks. The first two are linked to burst gap  
  loss draft and burst gap discard draft. I agree with you that these two XR blocks 
  define calculation method for the derived metrics mentioned in the burst gap drafts. 
  and are two most important metric blocks which the burst gap drafts count on.  
  My question is who sends these two XR blocks? 
[Qin]: There are two cases:
a. The media receiver sends these two new XR Blocks (i.e., Burst/Gap Loss Summsary Statistics Block
and Burst/Gap Discard Summsary Statistics Block in the draft-zorn-xrblock-rtcp-xr-al-stat)
b. The media sender sends these two new XR Blocks.
If the media receiver is responsible for sending, the media receiver need to first calculate basic direct metrics(i.e.,Burst/Gap Loss 
and Burst/Gap discard) defined in the draft-ietf-xrblock-rtcp-xr-burst-gap-loss and draft-ietf-xrblock-rtcp-xr-burst-gap-discard and then use these basic
metrics to calculate burst gap summary statistics defined in the draft-zorn-xrblock-rtcp-xr-al-stat.

If the media sender is responsible for sending, the implicit assumption is the media sender has already received the Burst/Gap Loss 
and Burst/Gap discard defined in draft-ietf-xrblock-rtcp-xr-burst-gap-loss and draft-ietf-xrblock-rtcp-xr-burst-gap-discard. The media sender
can use recieved the Burst/Gap Loss and Burst/Gap discard to calculate burst gap summary statistics defined in the draft-zorn-xrblock-rtcp-xr-al-stat.
   
  2. The third XR Block defined in this draft is Statistics Summary Block for 
   Application Layer Loss/Duplication. I think this XR Block is linked to I/P/B frame statistics. 
  This metric blocks can tell us which frame types were affected and is therefore a useful metric 
   to form an accurate assessment of user quality of experience. 

[Qin]:  Exactly.

  However it is not clear to me  
  how do you calculate Number of frames expected?

[Qin]:  The metrics we defined in this XR Block is not easy to be captured. You should look into RTP packet or deep parse RTP packet.
Fortunately these metrics reflect end to end performance at the service level and therefore we can measure them at the user end point, e.g., from
decoder or demuxer.
   Isn't more easier to calculate how many frames are received 
  ranther than gathering the number of frame expected? 

[Qin]: your are right, if we measure these metrics at the user end point, it is more easy to gather the number of frames received
than the number of frames expected since it is easy for the user end point to know how many frames received.  I will fix this in the update.

>Another comment is isn't it useful to collect how many different type of frames were discarded  by the media reciever? 

[Qin]: That's a good point. But this is only useful in the case where only the receiver is allowed to discard impaired frames.
I propose to add this metric into the new version. Thanks.
  Cheers! 
  ZhaoJing 
  ---------------------------- 
  ----- Original Message -----  
  From: "Qin Wu" <[email-masked]> 
  To: <[email-masked]> 
  Sent: Thursday, January 19, 2012 4:40 PM 
  Subject: Re: [xrblock] I-D Action: draft-zorn-xrblock-rtcp-xr-al-stat-04.txt 

  >> Internet-Draft directories: http://www.ietf.org/shadow.html