Subject: [pm-dir] Request for an RFC 6369 review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count

From: Qin Wu <[email-masked]>
Date: Mon, 10 Feb 2014 04:58:51 +0000

Hi, Authors:
I am the assigned PM-DIR reviewer for this draft.
Here is my review to this draft based on RFC6390 PM template.
This draft defines two new metrics  in the same metric block and has already applied RFC6390 template
to these two metrics, However I do have some comments below regarding metrics definition.

1. Appendix A, Part a, Bullet 3 says:
"
* Method of Measurement or Calculation: It must be measured in the
  source stream. It must be measured for the packets that
  have no further chance of being repaired.
"
The first sentence is a little bit confusing, are you saying the measurement is
applied to source stream, I think you can reference to section 3, the definition "SSRC of source" for that.
The second sentence seems also repeat what the definition of "unrepaired loss count",
you can simply reference that definition.

2. Appendix A, Part a, Bullet 5 says:
"
Measurement Point(s) with Potential Measurement Domain: See
      section 3, 1st paragraph.
"
Section 3, 1st paragraph doesn't explain where to measure?
I suggest you can add the following sentence to the section 3, 1st paragraph as follows:
"
The measurement of these metrics is made at the receiving end of the RTP stream
"
And you then you reference section 3 for measurement points.

3. Appendix A, Part a, Bullet 6 says:
"
* Measurement Timing: See Section 4 for measurement timing.

"
Section 4 has no text to explain measurement timing. Since
Since this metric doesn't rely on the
measurement interval in the Measurement Information Block [RFC6776]
indicating the span of the report, I believe you rely on sequence number
range to indicate measurement  timing, please make it clear in the text.

4. Appendix A, Part b, Bullet 3
My comment on Appendix A, part a Bullet 3 is also applied here.

5. Appendix A, Part b, Bullet 5
My comment on Appendix A, part a Bullet 5 is also applied here.

6. Appendix A, Part b, Bullet 6
My comment on Appendix A, part a Bullet 6 is also applied here.

7. Section 1, paragraph 1
s/measured on media stream/measured on RTP stream

8.Section 1, Paragraph 1 says:
"
Hence, the sending
endpoint cannot assess the performance of the repair mechanism by
observing the change in fraction loss and the cumulative loss
statistics.
"

It is better to add a reference for fraction loss and the cumulative loss, I think
It should be RFC 3550 RTCP SR which carries fraction loss statistics.

9. Section 1, Paragraph 1 says:
"

When

applications use multiple XR blocks, the endpoints require more

concise reporting to save bandwidth.

"
I don't think the endpoints MUST have such concise reporting in such case.
Therefore I suggest to say the endpoint may require more concise reporting in such case.

10. Section 1, Paragraph 2 says:
"
Thus it is RECOMMENDED that this report
block should be generated for those source packets that have no
further chance of being repaired. But a potential ambiguity may
result from sequence number range inconsistent. To address this
issue, we use begin sequence number and end sequence number to
explicitly indicate the actual sequence number range that the report
   block reports on.
"
Whose ambiguity? RFC3550 or RFC5725?
Not sure you should highlight using begin seq or end seq since RFC5725 also use this.
You'd better have more text to explain where sequence number inconsistency come from?

11. Section 1, Paragraph 2 says:
"
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. Note that the metrics in
this report block MUST NOT be directly compared with the pre-repair
loss metric of RFC3550<http://tools.ietf.org/html/rfc3550>.
"
The definition of repaired loss count here is not consistent with the definition of repaired loss count in section 3?
It looks repaired loss count here is referred to the value carried in the SR while repaired loss count in section is
referred to the packet that is repaired after loss repair mechanism is applied. Please fix this to make them consistent.

12. Section 3, Paragraph 1 says:
"
This block describes the residual number of packets lost after
applying repair mechanisms. The report block is complementary to the
RTCP XR metrics defined in [RFC5725<http://tools.ietf.org/html/rfc5725>] as it uses a non-RLE format.
"
What Does residual number mean? Suggest to remove residual.
It doesn't add any benefit but introduce confusing.

13. Section 3 says:
"

   begin_seq: 16 bits

      The sequence number of the first packet in the session or the

      sequence number of the first packet fully repaired that this block

      reports on.

   end_seq: 16 bits

      The sequence number of the last packet fully repaired that this

      block reports on plus one.

"
Why not use the same definition as defined in the RFC3611 or RFC5725, why make these definitions so specific?
I don't think the begin_seq should only be chosen either as the first packet sequence number in the session
Or the first packet sequence number that is fully repaired. Why not choose the sequence number of any packet you received?
In some case, you may not lose any packet, then in such case, both unrepaired loss count  and  repaired loss count should be set to zero.

Regards!
-Qin
________________________________

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Mon, 10 Feb 2014 09:57:35 +0000

Hi Qin,

Thanks for your comments. Please see inline.

Best regards,
Rachel

From: Qin Wu
Sent: Monday, February 10, 2014 12:59 PM
To: [email-masked]; Varun Singh; Huangyihong (Rachel)
Cc: MORTON, ALFRED C (AL); Benoit Claise
Subject: Request for an RFC 6369 review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count

Hi, Authors:

[Rachel]: Sorry. It should be the "primary source stream". For some implementations using retransmission, it is possible that retransmission stream has the same SSRC with the primary source stream, but in different sessions.

[Rachel]: How about changing to "It must be measured in the primary source stream for the packets with no further chance to be repaired"?

[Rachel]: Good suggestion. Thanks.

"

[Rachel]: Good point. How about adding the following sentence to section 3?

"This new RTCP extended report block share the same timing interval with RTCP SR/RR "

[Rachel]: Okay.

[Rachel]: Okay.

[Rachel]: Okay.

[Rachel]: Okay.

[Rachel]: Will do.

When

"

[Rachel]: You're right. Will do.

[Rachel]: That's why we don't use the measurement interval in the Measurement information Block [RFC6776]. The report block we develop is reporting the number of  repaired  packets and packets that won't be repaired anymore in the current interval. Some of the packets may not be repaired in current interval, instead, they may be repaired in next or next several intervals. If we use the same sequence range defined in RFC6776, like other RTCP XRs, only cumulative counts are meaningful. So we choose to use the same interval with RTCP SR/RR and indicating the sequence number range explicitly.
I will explain more in the draft to let people understand well.

[Rachel]: I'm not trying to define repaired loss count here. I'm trying to say that repaired loss count is used to calculating the pre-repaired loss count.  repaired loss count + unrepaired loss count = pre-repaired loss count. Since  some of the packet in the SR may not be repaired in current interval, pre-repaired loss count is not equal to the loss  metrics in RTCP SR.

[Rachel]: Okay.

13. Section 3 says:
"

   begin_seq: 16 bits

      reports on.

   end_seq: 16 bits

"
[Rachel]: Yes, you're right. The definition in RFC3611 is good.

Regards!
-Qin