Re: [xrblock] Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-08: (with DISCUSS and COMMENT)

[Varun Singh <[e-mail]>]

Hi Benoit,

Thank you for reviewing the document, responses are inline.

Cheers,
Varun

> On 06 Jan 2015, at 19:42, Benoit Claise <[e-mail]> wrote:
> 
> Benoit Claise has entered the following ballot position for
> draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-08: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-post-repair-loss-count/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 1. post-repair loss count: 16 bits
> 
>      Total number of packets finally lost after applying one or more
>      loss-repair methods, e.g., FEC and/or retransmission, during the
>      actual sequence number range indicated by begin_seq and end_seq.
>      This metric MUST NOT count the lost packets for which repair might
>      still be possible. Note that this metric MUST measure only primary
>      source RTP packets.
> 
> I see the MUST above, and the RECOMMENDED below.
> 
>   Thus it is RECOMMENDED that this report block should be generated
>   only for those source packets that have no further chance of being
>   repaired and not for any other packets. This block needs to specify
>   its own measurement period to avoid ambiguity in calculating the
>   post-repair loss count.
> 
> I was expecting a MUST instead of RECOMMENDED.
> Did the WG discuss that point? 
This was discussed in Vancouver IETF and decide to keep the language as close to the one in http://tools.ietf.org/html/rfc5725. 

> In which situation would you need this exception, and what could you
> actually deduce if you apply it?
> 

One reason that it is not MUST is to align the end_seq to the Highest sequence number in the RTCP RR.


> 
> 2. Question:
>   The relationship
>   between the metrics in this report block and the pre-repair loss
>   metric of RTCP XR could be expressed in the following formula:
> 
>      cumulative number of packets lost = post-repair loss count +
>      repaired loss count + to be repaired lost packet
> 
>   "cumulative number of packets lost" is the metric from RTCP SR/RR.
>   "post-repair loss count" and "repaired loss count" are the metrics
>   defined in this draft.
> 
> Am I correct that it's difficult (if not impossible) to compare those
> values with a small granularity because:
> 1. RFC 3550 section 6.4.1 SR: Sender Report RTCP Packet sends the
> "cumulative number of packets lost" with timestamps

The RR has a highest sequence number, the cumulative lost is from the beginning of the session. The XR can point the first sequence received to begin_seq and HSN to the end_seq and then values in the  RR and the XR are synchronized. 


> 2. draft-ietf-xrblock-rtcp-xr-post-repair-loss-count sends "post-repair
> loss count" and "repaired loss count" with sequence numbers.
> On top of that, the intervals are different!

I think this is an implementation concern. It is possible for the endpoint to report 
1. Cumulatively, begin_seq points to the first packet
2. Interval, begin_seq points to the HSN of the previous RTCP RR
In which case the XR and the RTCP RRs are the same intervals

However, it is correct that if the begin_seq and end_seq report on different intervals than the RTCP rr then the cumulative loss reported in the RR won't match the XR. However, in these cases the endpoint would need to rely on the post-repair loss count and repaired loss count to calculate the efficiency of the error resilience algorithm. 


> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> - The abstract mentions:
>   This document defines an RTP Control Protocol (RTCP) Extended Report
>   (XR) Block that allows reporting of post-repair loss count metrics
>   for a range of RTP applications.
> 
> This draft introduces two metrics: post-repair loss count and repaired
> loss count
> This is slightly confusing. 
> I believe you want to include the two metrics in the abstract.
> Alternatively:
> NEW:
>   This document defines an RTP Control Protocol (RTCP) Extended Report
>   (XR) Block that allows reporting of post-repair loss-related metrics
>   for a range of RTP applications.
> 
> 
> -
>   In
>   addition,  another metric, repaired loss count, is also introduced in
>   this report block for calculating the pre-repair loss count during
>   the this range, 
> 
> the this -> chose one.
>