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

[Benoit Claise <[e-mail]>]

Hi Varun,

See in-line.
> 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.
Then the mistake is in RFC 5725, no?
>
>> 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.
Help me understand something.
I'll repeat my question: what could you actually deduce if you apply it?
I thought the goal was it the reverse.

      This metric MUST NOT count the lost packets for which repair might
      still be possible.

Therefore you have to wait until all repair mechanisms have done their jobs.
 From there, you send this block.
And, if you want to better align the intervals, you 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.
Ok.
> 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.
Ok, I completely missed that from the draft.
>
>
>> 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
Is this covered in the draft?
I read:

    This packet may be stacked with other RTCP packets to form compound
    RTCP packets and share the average reporting interval calculated by
    the RTCP method described in [RFC3550  <http://tools.ietf.org/html/rfc3550>]. When comparing this metric
    with pre-repair loss metric of RTCP SR/RR, ambiguity may occur as
    noted in [RFC5725  <http://tools.ietf.org/html/rfc5725>]: Some packets will not be repaired in the current
    RTCP interval, but could be repaired later.


Specifically the "average reporting interval". I could not have deduced 
that the begin_seq could remain 1 for all "intervals".

> 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.
I believe this needs some clarifying text.

Thanks for engaging.

Regards, Benoit
>
>
>>
>> ----------------------------------------------------------------------
>> 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.
>>
> .
>