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

Hi Benoit,

Thank you for the comments. Please see my replies inline.

BR,
Rachel

> -----Original Message-----
> From: xrblock [mailto:xrblock-bounces@ietf.org] On Behalf Of Benoit Claise
> Sent: Wednesday, January 07, 2015 1:43 AM
> To: The IESG
> Cc: xrblock-chairs@tools.ietf.org; xrblock@ietf.org;
> draft-ietf-xrblock-rtcp-xr-post-repair-loss-count.all@tools.ietf.org
> Subject: [xrblock] Benoit Claise's Discuss on
> draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-08: (with DISCUSS and
> COMMENT)
> 
> 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?
> In which situation would you need this exception, and what could you actually
> deduce if you apply it?

[Rachel]: We haven't given it some careful thought until you brought it up. But we agree that this is a issue of inconsistency. So I propose to change the RECOMMEND sentence into following:
" Accordingly, only packets that have no further chance of being repaired are included in this report block. This block needs to specify its own measurement period to avoid ambiguity in calculating the post-repair loss count."
Will it make sense to you?

> 
> 
> 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 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!

[Rachel]: The Report Blocks in SR and RR packets give the cumulative number of packets lost, and the sequence number range of the interval (by comparing the extended highest sequence number received fields on consecutive packets). See RFC 3550 section 6.4.4. 
The XR report block defined in this document has explicit sequence number ranges. The sender of the XR reports can ensure it match the SR/RR packet sent in the same compound RTCP packet. Given this, they will be comparable. We could recommend this is done in the update.
It's also possible to send this XR report block and SR/RR reports with different intervals, in which case they won't be easily comparable.
Maybe we should add some clarification words in the next version.

> 
> 
> ----------------------------------------------------------------------
> 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.
> 

[Rachel]: Will do. Thanks.
> 
> _______________________________________________
> xrblock mailing list
> xrblock@ietf.org
> https://www.ietf.org/mailman/listinfo/xrblock