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

[Qin Wu <[e-mail]>]

FYI.

From: Qin Wu
Sent: Monday, February 10, 2014 12:59 PM
To: [e-mail]; 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:
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