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

[Varun Singh <[e-mail]>]

Thanks Benoit for the feedback. -11 will fix the text.

> On 17 Feb 2015, at 12:22, Benoit Claise <[e-mail]> wrote:
> 
> On 16/02/2015 13:32, Varun Singh wrote:
>> 
>>> On 16 Feb 2015, at 11:55, Benoit Claise <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> On 16/02/2015 10:31, Varun Singh wrote:
>>>> Hi Benoit,
>>>> 
>>>> Thank you for reviewing the proposal, comments inline.
>>>> 
>>>> 
>>>>> On 16 Feb 2015, at 11:14, Benoit Claise <[e-mail] <mailto:[e-mail]>> wrote:
>>>>> 
>>>>> 
>>>>> ----------------------------------------------------------------------
>>>>> DISCUSS:
>>>>> ----------------------------------------------------------------------
>>>>> 
>>>>> The following MUST versus RECOMMENDED is still an issue
>>>>> 
>>>>>  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. 
>>>>> 
>>>>> This goes against
>>>>> 
>>>>> 2. Interval report
>>>>> 
>>>>>   Some implementations may align the begin_seq and end_seq number with
>>>>>   the highest sequence numbers of consecutive RTCP RRs (RTCP interval).
>>>>>   This is NOT RECOMMENDED as packets that are not yet repaired in this
>>>>>   current RTCP interval and may repaired in the future will not be
>>>>>   reported in subsequent reports.
>>>>> 
>>>> 
>>>> 
>>>> The not recommended is if the receiver strictly aligns the begin_seq and end_seq to 
>>>> the HSNs of consecutive reports.
>>>> Example below:
>>>> 
>>>> a) HSN is 20, begin_seq is 10 end_seq is 20.
>>>> b) HSN is 30, begin_seq is 20 end_seq is 30.
>>>> If 17 and 19 were packets lost and not yet repaired in a) and 
>>>> subsequently repaired in b) then it won't be reported because the 
>>>> sequence numbers do not belong in b)’s interval, but to the previous 
>>>> begin and end seq,
>>> But you can not do that (Interval report, i.e. align the begin_seq and end_seq number with the highest sequence numbers of consecutive RTCP RRs, as in your example) according to that sentence ": This metric MUST NOT count the lost packets for which repair might still be possible.", right? What do I miss?
>> 
>> I think we are in agreement. 
>> 
>> The paragraphs attempts to highlight that (in this particular case) when those lost packets are repaired in the next interval, they won’t be reported as repaired or lost.
> I believe I now understand the source of confusion.
> I understood "This metric MUST NOT count the lost packets for which repair might still be possible" as "This metric MUST NOT be calculated until the repair mechanism has done its job."  
> Based on my understanding, this was preventing the implementation of the Interval report, i.e. align the begin_seq and end_seq number with the highest sequence numbers of consecutive RTCP RRs... unless you were sure the repair mechanism was over.
> 
> The addition of your example above would be beneficial to the draft IMO, on top of the new text proposed by Rachel  in our private conversation (and which aligns with your sentence below)
> 
> “Some implementations may align the begin_seq and end_seq number with the highest sequence numbers of consecutive RTCP RRs (RTCP interval). This is NOT RECOMMENDED as packets that are not yet repaired in this current RTCP interval and may repaired in the future will not be reported in subsequent reports. So if implementations want these packets to be reported as repaired, they MUST NOT align the begin_seq and end_seq to the RTCP intervals.”
> 
> 
>> If implementations want to report these packets as repaired they MUST NOT align the begin_seq and end_seq to the RTCP intervals.