[xrblock] FW: Request for an RFC 6369 review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count
Qin Wu <bill.wu@huawei.com> Mon, 10 February 2014 04:59 UTC
Return-Path: <bill.wu@huawei.com>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5B51A07AA for <xrblock@ietfa.amsl.com>; Sun, 9 Feb 2014 20:59:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level:
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juDrAkONcwcu for <xrblock@ietfa.amsl.com>; Sun, 9 Feb 2014 20:59:36 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAAD1A0237 for <xrblock@ietf.org>; Sun, 9 Feb 2014 20:59:35 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAY42496; Mon, 10 Feb 2014 04:59:34 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 04:58:24 +0000
Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 04:59:32 +0000
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Mon, 10 Feb 2014 12:59:26 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "xrblock@ietf.org" <xrblock@ietf.org>
Thread-Topic: Request for an RFC 6369 review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count
Thread-Index: Ac8mHMohgTqbV6RzRzOEe/CvyioJpwAAAXlA
Date: Mon, 10 Feb 2014 04:59:25 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA43C7B965@nkgeml501-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.41.149]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43C7B965nkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [xrblock] FW: Request for an RFC 6369 review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <xrblock.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xrblock>, <mailto:xrblock-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xrblock/>
List-Post: <mailto:xrblock@ietf.org>
List-Help: <mailto:xrblock-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xrblock>, <mailto:xrblock-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Feb 2014 04:59:40 -0000
FYI. From: Qin Wu Sent: Monday, February 10, 2014 12:59 PM To: pm-dir@ietf.org; 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
- [xrblock] FW: Request for an RFC 6369 review of d… Qin Wu
- Re: [xrblock] Request for an RFC 6369 review of d… Huangyihong (Rachel)