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

["Huangyihong (Rachel)" <[e-mail]>]

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:[e-mail]]
Sent: Friday, January 16, 2015 2:06 AM
To: Varun Singh; Huangyihong (Rachel)
Cc: The IESG; Tina TSOU; [e-mail]; [e-mail]; [e-mail]; 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 <[e-mail]<mailto:[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.
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<http://www.netlab.tkk.fi/%7Evarun>