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

From: "Benoit Claise" <[email-masked]>
Date: Tue, 06 Jan 2015 09:42:54 -0800

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? 
In which situation would you need this exception, and what could you
actually deduce if you apply it?

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

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

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Wed, 7 Jan 2015 23:53:10 +0000

Hi Benoit,

Thank you for the comments. Please see my replies inline.

BR,
Rachel

> -----Original Message-----
> From: xrblock [mailto:[email-masked]] On Behalf Of Benoit Claise
> Sent: Wednesday, January 07, 2015 1:43 AM
> To: The IESG
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: [xrblock] Benoit Claise's Discuss on
> draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-08: (with DISCUSS and
> COMMENT)
> 
> 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.)
> 
> 
> In which situation would you need this exception, and what could you actually
> deduce if you apply it?

[Rachel]: We haven't given it some careful thought until you brought it up. But we agree that this is a issue of inconsistency. So I propose to change the RECOMMEND sentence into following:
" Accordingly, only packets that have no further chance of being repaired are included in this report block. This block needs to specify its own measurement period to avoid ambiguity in calculating the post-repair loss count."
Will it make sense to you?

> Am I correct that it's difficult (if not impossible) to compare those values with a
> small granularity because:
> "cumulative number of packets lost" with timestamps 2.
> draft-ietf-xrblock-rtcp-xr-post-repair-loss-count sends "post-repair loss count"
> and "repaired loss count" with sequence numbers.

[Rachel]: The Report Blocks in SR and RR packets give the cumulative number of packets lost, and the sequence number range of the interval (by comparing the extended highest sequence number received fields on consecutive packets). See RFC 3550 section 6.4.4. 
The XR report block defined in this document has explicit sequence number ranges. The sender of the XR reports can ensure it match the SR/RR packet sent in the same compound RTCP packet. Given this, they will be comparable. We could recommend this is done in the update.
It's also possible to send this XR report block and SR/RR reports with different intervals, in which case they won't be easily comparable.
Maybe we should add some clarification words in the next version.

> This draft introduces two metrics: post-repair loss count and repaired loss
> count This is slightly confusing.

[Rachel]: Will do. Thanks.
> 
> _______________________________________________
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock

---

From: Benoit Claise <[email-masked]>
Date: Thu, 08 Jan 2015 16:22:51 +0100

Hi Rachel,
> Will it make sense to you?
Yes, thanks.
> [Rachel]: The Report Blocks in SR and RR packets give the cumulative number of packets lost, and the sequence number range of the interval (by comparing the extended highest sequence number receive…
Ok, I overlook this "extended highest sequence number received", but 
this is just one boundary of the interval.
> The XR report block defined in this document has explicit sequence number ranges. The sender of the XR reports can ensure it match the SR/RR packet sent in the same compound RTCP packet. Given this…
If you chose to do so, does it imply that the SR/RR will be sent with a 
little of delay (due to the FEC)?
> Maybe we should add some clarification words in the next version.
Thanks.

Regards, Benoit
> .

---

From: Benoit Claise <[email-masked]>
Date: Thu, 08 Jan 2015 16:42:56 +0100

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

      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.

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

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Fri, 9 Jan 2015 01:54:50 +0000

Hi Benoit,

Please see inline.

BR,
Rachel

> From: Benoit Claise [mailto:[email-masked]]
> Sent: Thursday, January 08, 2015 11:23 PM
> To: Huangyihong (Rachel); The IESG
> Cc: [email-masked];
> [email-masked];
> [email-masked]
> Subject: Re: [xrblock] Benoit Claise's Discuss on
> >> 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
> >> http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-post-repai
> >> r-loss-count
> >> /
> >>
> >>
> >>
> > [Rachel]: We haven't given it some careful thought until you brought it up. But
> we agree that this is a issue of inconsistency. So I propose to change the
> RECOMMEND sentence into following:
> > " Accordingly, only packets that have no further chance of being repaired are
> included in this report block. This block needs to specify its own measurement
> period to avoid ambiguity in calculating the post-repair loss count."
> > [Rachel]: The Report Blocks in SR and RR packets give the cumulative number
> of packets lost, and the sequence number range of the interval (by comparing
> the extended highest sequence number received fields on consecutive packets).
> See RFC 3550 section 6.4.4.
> Ok, I overlook this "extended highest sequence number received", but this is
> just one boundary of the interval.

[Rachel]: Another boundary of the interval is the sequence number 1. 

> > The XR report block defined in this document has explicit sequence number
> ranges. The sender of the XR reports can ensure it match the SR/RR packet
> sent in the same compound RTCP packet. Given this, they will be comparable.
> We could recommend this is done in the update.
> If you chose to do so, does it imply that the SR/RR will be sent with a little of
> delay (due to the FEC)?

[Rachel]: No, it doesn't have to be. The begin_seq could be set to 1, but the end_seq could be set to the sequence number of packet which is the last one applied repair mechanisms and smaller than extended highest sequence number received. Thus, it can be still compared:
     to be repaired lost packet = cumulative number of packets lost - post-repair loss count - repaired loss count.
Where " still to be repaired lost packet " is in the range of from end_seq to extended highest sequence number received.

> > It's also possible to send this XR report block and SR/RR reports with different
> intervals, in which case they won't be easily comparable.
> >> This draft introduces two metrics: post-repair loss count and
> >> repaired loss count This is slightly confusing.

---

From: Varun Singh <[email-masked]>
Date: Thu, 8 Jan 2015 02:08:08 +0200

Hi Benoit,

Cheers,
Varun

> "cumulative number of packets lost" with timestamps

The RR has a highest sequence number, the cumulative lost is from the beginning of the session. 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.

---

From: Varun Singh <[email-masked]>
Date: Thu, 8 Jan 2015 21:24:00 +0200

Hi Benoit,

Comment inline.

> On 08 Jan 2015, at 17:42, Benoit Claise <[email-masked]> wrote:
> 
> Hi Varun,
>>> 
>> 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>. 

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

> Ok, I completely missed that from the draft.

Do you think we need to add some examples?

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

> I believe this needs some clarifying text.

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

---

From: Benoit Claise <[email-masked]>
Date: Thu, 15 Jan 2015 19:05:56 +0100

Varun, Rachel,

I believe that we are converging.
Do I understand correctly that you want to remove the MUST NOT in "This 
metric MUST NOT count the lost packets for which repair might still be 
possible."?
What I'm missing at this point is either an OLD/NEW type of email from 
both of you (there were conflicting messages earlier on), or a new draft 
version.

Regards, Benoit
> Hi Benoit,
>
> Comment inline.
>
>> On 08 Jan 2015, at 17:42, Benoit Claise <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Varun,
>>> This was discussed in Vancouver IETF and decide to keep the language as close to the one inhttp://tools.ietf.org/html/rfc5725.
> 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
>> 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
>
> http://www.netlab.tkk.fi/~varun <http://www.netlab.tkk.fi/%7Evarun>
>

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Fri, 16 Jan 2015 01:22:47 +0000

Hi Benoit,

Varun and I are working together to bring a new version to address your concerns. Please see my replies inline.

BR,
Rachel

From: Benoit Claise [mailto:[email-masked]]
Sent: Friday, January 16, 2015 2:06 AM
To: Varun Singh; Huangyihong (Rachel)
Cc: The IESG; Tina TSOU; [email-masked]; [email-masked]; [email-masked]; Dan Romascanu
Subject: Re: Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-08: (with DISCUSS and COMMENT)

Varun, Rachel,

I believe that we are converging.
Do I understand correctly that you want to remove the MUST NOT in "This metric MUST NOT count the lost packets for which repair might still be possible."?

[Rachel]: Not exactly. What we propose in the new version is to change "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."
into
"Accordingly, only packets that have no further chance of being repaired are included in this report block.
"

Besides that, we also propose following changes:

1.       Section 3, 1st paragraph, change  "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]."  into

"The sender of this XR report can ensure it match the SR/RR packet sent in the same compound RTCP packet."

2.       Section 3, 3rd paragraph, change the 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."   into

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

     "cumulative number of packets lost" is the metric from RTCP SR/RR.
     "cumulative post-repair loss count" and "cumulative repaired loss
     count" could be obtained by the way introduced in the end of this
      section.
       It is also possible to send this XR report block and SR/RR with
   different intervals, in which case the "cumulative number of packets
   lost" can't be easily compared with the post-repair metrics defined
   in this draft. However, the endpoint could rely on the post-repair
   loss count and repaired loss count to calculate the efficiency of the error resilience algorithm.
"

3.       Add a sub section in Section 3 after the definition of the report block structure

"

3.2  Report Block Example Usage

   This block could be reported by the endpoint in 2 different ways:

   1. Cumulative report

   In this case, implementations may set begin_seq to the first packet

   in the RTP session and remain fixed. "Post-repair loss count" and

   "repaired loss count" respectively equal to "cumulative post-repair

   loss count" and "cumulative repaired loss count".

   2. Interval report

   Implementations may choose to use begin and end sequence number to

   correspond to the last RTCP interval or several RTCP intervals. If

   the reports are consecutive and there's no sequence number range

   overlap or RTCP XR packets loss, "cumulative post-repair loss count"

   and "cumulative repaired loss count" could be respectively calculated

   by sum of "post-repair loss count" and by sum of "repaired loss

   count".

"

So what do you think?

What I'm missing at this point is either an OLD/NEW type of email from both of you (there were conflicting messages earlier on), or a new draft version.

[Rachel]: It will be a new draft version.

Regards, Benoit
Hi Benoit,

Comment inline.

On 08 Jan 2015, at 17:42, Benoit Claise <[email-masked]<mailto:[email-masked]>> wrote:

Hi Varun,

see below.

     still be possible.
>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.

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.

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

  defined in this draft.

   the RTCP method described in [RFC3550<http://tools.ietf.org/html/rfc3550>]. When comparing this metric

   noted in [RFC5725<http://tools.ietf.org/html/rfc5725>]: Some packets will not be repaired in the current

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

begin_seq: 16 bits

We can add:

Thanks for engaging.

Regards, Benoit

---
http://www.netlab.tkk.fi/~varun<http://www.netlab.tkk.fi/%7Evarun>

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Wed, 21 Jan 2015 07:00:29 +0000

Hi Benoit,

Just ping your response. Do you think the texts we proposed below address your concern? We'll submit a new version if you're okay with these changes.

BR,
Rachel

From: Huangyihong (Rachel) [mailto:[email-masked]]
Sent: Friday, January 16, 2015 9:23 AM
To: Benoit Claise; Varun Singh
Cc: The IESG; Tina TSOU; [email-masked]; [email-masked]; [email-masked]; Dan Romascanu
Subject: RE: Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-08: (with DISCUSS and COMMENT)

Hi Benoit,

BR,
Rachel

Cc: The IESG; Tina TSOU; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Dan Romascanu

Varun, Rachel,

"

   1. Cumulative report

   2. Interval report

   count".

"

So what do you think?

Regards, Benoit
Hi Benoit,

Comment inline.

Hi Varun,

see below.

     still be possible.

2. Question:

  The relationship

  defined in this draft.

begin_seq: 16 bits

We can add:

Thanks for engaging.

Regards, Benoit

---

---

From: Benoit Claise <[email-masked]>
Date: Wed, 21 Jan 2015 10:21:09 +0100

Hi Rachel,
>
> Hi Benoit,
>
> Just ping your response. Do you think the texts we proposed below 
> address your concern? We’ll submit a new version if you’re okay with 
> these changes.
>
Ah. Based on your last email "Varun and I are working together to bring 
a new version to address your concerns", I was waiting for a new draft 
version.
I believe the changes below address my DISCUSS, but I can't say for 
sure. At this point, I would have to re-read the new draft version, 
along with the diffs.

Regards, Benoit

> BR,
>
> Rachel
>
> *From:*Huangyihong (Rachel) [mailto:[email-masked]]
> *Sent:* Friday, January 16, 2015 9:23 AM
> *To:* Benoit Claise; Varun Singh
> *Cc:* The IESG; Tina TSOU; [email-masked]; 
> [email-masked]; Dan Romascanu
> *Subject:* RE: Benoit Claise's Discuss on 
> draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-08: (with DISCUSS 
> and COMMENT)
>
> Hi Benoit,
>
> Varun and I are working together to bring a new version to address 
> your concerns. Please see my replies inline.
>
> BR,
>
> Rachel
>
> *From:*Benoit Claise [mailto:[email-masked]]
> *Sent:* Friday, January 16, 2015 2:06 AM
> *To:* Varun Singh; Huangyihong (Rachel)
> *Cc:* The IESG; Tina TSOU; [email-masked] 
> <mailto:[email-masked]>; 
> <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>; Dan Romascanu
> *Subject:* Re: Benoit Claise's Discuss on 
> draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-08: (with DISCUSS 
> and COMMENT)
>
> Varun, Rachel,
>
> Do I understand correctly that you want to remove the MUST NOT in 
> "This metric MUST NOT count the lost packets for which repair might 
> still be possible."?
>
> [Rachel]: Not exactly. What we propose in the new version is to change “Thus it is RECOMMENDED that this report block should be generated
>
>    repaired and not for any other packets.”
>
> into
>
> “Accordingly, only packets that have no further chance of being 
> repaired are included in this report block.
>
> ”
>
> 1.        Section 3, 1^st    paragraph, change  “This packet may be stacked with other RTCP packets to form compound
>
>    the RTCP method described in [RFC3550].”  into
>
> “The sender of this XR report can ensure it match the SR/RR packet 
> sent in the same compound RTCP packet.”
>
> 2.        Section 3, 3^rd    paragraph, change the formula “cumulative number of packets lost = post-repair loss count +
>
>    defined in this draft.”   into
>
> “still to be repaired lost packet = cumulative number of packets
>
> ”
> 3.Add a sub section in Section 3 after the definition of the report 
> block structure
>
> “
>
> ”
> both of you (there were conflicting messages earlier on), or a new 
> draft version.
>
>     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
>
>     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
>
>       
>

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Wed, 21 Jan 2015 09:32:28 +0000

All right. I'll submit it immediately^^.

BR,
Rachel

From: Benoit Claise [mailto:[email-masked]]
Sent: Wednesday, January 21, 2015 5:21 PM
To: Huangyihong (Rachel)
Cc: The IESG; [email-masked]; [email-masked]; [email-masked]; Dan Romascanu
Subject: Re: Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-08: (with DISCUSS and COMMENT)

Hi Rachel,
Hi Benoit,

Just ping your response. Do you think the texts we proposed below address your concern? We'll submit a new version if you're okay with these changes.
Ah. Based on your last email "Varun and I are working together to bring a new version to address your concerns", I was waiting for a new draft version.
I believe the changes below address my DISCUSS, but I can't say for sure. At this point, I would have to re-read the new draft version, along with the diffs.

Regards, Benoit

BR,
Rachel

Hi Benoit,

BR,
Rachel

Varun, Rachel,

"

   1. Cumulative report

   2. Interval report

   count".

"

So what do you think?

Regards, Benoit
Hi Benoit,

Comment inline.

Hi Varun,

see below.

     still be possible.

2. Question:

  The relationship

  defined in this draft.

begin_seq: 16 bits

We can add:

Thanks for engaging.

Regards, Benoit

---