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

[Benoit Claise <[e-mail]>]

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.
Regards, Benoit
>
>>> therefore it is not recommended to align the begin_seq
>>> and end_seq to HSN of consecutive RTCP reports, unless repairs occur
>>> within that interval.
>>>
>>> Hence, (hopefully the next paragraph in the section clarifies) 
>>> receivers
>>> should prefer begin_ and end_seq use longer than an RTCP interval.
>>>
>>>
>> Regards, Benoit
>