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

From: "Benoit Claise" <[email-masked]>
Date: Mon, 16 Feb 2015 01:14:55 -0800

Benoit Claise has entered the following ballot position for
draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-10: 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:
----------------------------------------------------------------------

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.

I understand the explanations you provided in the past. The only logical
solution is to change the "MUST NOT" with "NOT RECOMMENDED"

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks, the draft improved.
However, There are still sentences that I had to read multiple times, to
"get" them. I believe that I have spent enough time on this draft by now.
So will not comment on those.

-

   in 6 still to be repaired lost packet = cumulative number of packets
   lost - cumulative post-repair loss count -  cumulative repaired loss
   count

"in 6"?

- Why doesn't this section 3 mention "repaired loss count"?

---

From: Benoit Claise <[email-masked]>
Date: Mon, 16 Feb 2015 10:55:23 +0100

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 <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>
> 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?
> 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

---

From: Benoit Claise <[email-masked]>
Date: Mon, 16 Feb 2015 10:55:23 +0100

Regards, Benoit

---

From: Varun Singh <[email-masked]>
Date: Mon, 16 Feb 2015 11:31:25 +0200

Hi Benoit,

> On 16 Feb 2015, at 11:14, Benoit Claise <[email-masked]> wrote:
> 
> 

The not recommended is if the receiver strictly aligns the begin_seq and end_seq to 
the HSNs of consecutive reports. Example below:

begin and end seq, therefore it is not recommended to align the begin_seq 

> "in 6”?

I assume this is an .nroff error, indent 6 spaces? 

> - Why doesn't this section 3 mention "repaired loss count"?

I am not sure what you mean, however 3.1 has the following:

repaired loss count: 16 bits

      Total number of packets fully repaired 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.
      Note that this metric MUST measure only primary source RTP
      packets.

---

From: Varun Singh <[email-masked]>
Date: Mon, 16 Feb 2015 11:31:25 +0200

Hi Benoit,

---

From: Varun Singh <[email-masked]>
Date: Mon, 16 Feb 2015 14:32:19 +0200

> On 16 Feb 2015, at 11:55, Benoit Claise <[email-masked]> wrote:
> 
>>> On 16 Feb 2015, at 11:14, Benoit Claise <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 
> 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. If implementations want to report these packets as repaired they MUST NOT align the begin_seq and end_seq to the RTCP intervals.

---

From: Varun Singh <[email-masked]>
Date: Mon, 16 Feb 2015 14:32:19 +0200

---

From: Benoit Claise <[email-masked]>
Date: Tue, 17 Feb 2015 11:22:28 +0100

On 16/02/2015 13:32, Varun Singh wrote:
>
>> On 16 Feb 2015, at 11:55, Benoit Claise <[email-masked] 
>> 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?
>
> 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

---

From: Benoit Claise <[email-masked]>
Date: Tue, 17 Feb 2015 11:22:28 +0100

Regards, Benoit

---

From: Varun Singh <[email-masked]>
Date: Tue, 17 Feb 2015 12:33:37 +0200

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

> On 17 Feb 2015, at 12:22, Benoit Claise <[email-masked]> wrote:
> 
>>> On 16 Feb 2015, at 11:55, Benoit Claise <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>> 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 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.

---

From: Varun Singh <[email-masked]>
Date: Tue, 17 Feb 2015 12:33:37 +0200

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 19 Feb 2015 16:08:28 -0800

Hi Benoit,

Are you able to clear based on the -11?

Thanks,
Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 19 Feb 2015 16:08:28 -0800

Hi Benoit,

Thanks,
Alissa