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,

Comment inline.

> On 08 Jan 2015, at 17:42, Benoit Claise <[e-mail]> wrote:
> 
> Hi Varun,
>>> 
>>> 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 <http://tools.ietf.org/html/rfc5725>. 
> Then the mistake is in RFC 5725, no?

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


One reason for synchronising the intervals of the XR end_seq and the RR’s HSN is, there is no ambiguity in calculating the number of  packets that are yet to be repaired:
still to be repaired lost packet = cumulative number of packets lost - post-repair loss count -  repaired loss count.

The first is reported in the RR, the other two are in the XR, and this only works if the begin_seq points to the first packet in the session. The "still to be repaired lost packets" can help the sender adapt the FEC interval i.e., generate fewer or more FEC packets.

If it were a MUST, then the end_seq will be a value smaller than the HSN unless the endpoint generates the RR+XR when all the FEC packet for an interval have arrived.

Alternatively, applications that are not concerned about the “still to be repaired packets” instead wish to compare post-repair loss with repaired loss count may prefer to count only those packets for which all the FEC packets are available. For example, this information can help switch between error-repair schemes. 


> And, if you want to better align the intervals, you align the end_seq to the Highest sequence number in the RTCP RR. 

Yes, and if the endpoint does not have all the FEC packet that covers the HSN, it won’t be able to align the interval.

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


Do you think we need to add some examples?

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

It is possible to keep it fixed. Further due to the unreliability of RTCP, many implementations pick begin_seq that spans across multiple reporting intervals. Further, the description of begin_seq does not limit the application, but does it need clarification?

begin_seq: 16 bits

      The first sequence number that this block reports on.

We can add:

      The first sequence number that this block reports on. It can remain fixed when calculating metrics over several RTCP reporting 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

---
http://www.netlab.tkk.fi/~varun