IETF Logo Mail Archive

Re: [xrblock] review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count

"Huangyihong (Rachel)" <rachel.huang@huawei.com> Tue, 11 February 2014 02:57 UTC

Return-Path: <rachel.huang@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 587381A0763 for <xrblock@ietfa.amsl.com>; Mon, 10 Feb 2014 18:57:11 -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 qwPgR0s-8IIB for <xrblock@ietfa.amsl.com>; Mon, 10 Feb 2014 18:57:09 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD951A0760 for <xrblock@ietf.org>; Mon, 10 Feb 2014 18:57:08 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDL48537; Tue, 11 Feb 2014 02:57:08 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Feb 2014 02:56:57 +0000
Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Feb 2014 02:57:07 +0000
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Tue, 11 Feb 2014 10:57:00 +0800
From: "Huangyihong (Rachel)" <rachel.huang@huawei.com>
To: Roni Even <ron.even.tlv@gmail.com>, 'xrblock' <xrblock@ietf.org>
Thread-Topic: [xrblock] review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count
Thread-Index: Ac8mTF5h5WrKU6iPTX602kQgjBUH9wAfPEww
Date: Tue, 11 Feb 2014 02:56:59 +0000
Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB4591EA14@nkgeml501-mbs.china.huawei.com>
References: <07c901cf264d$1e805d60$5b811820$@gmail.com>
In-Reply-To: <07c901cf264d$1e805d60$5b811820$@gmail.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.116]
Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB4591EA14nkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [xrblock] 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: Tue, 11 Feb 2014 02:57:11 -0000

Hi Roni,

Thank you for your comments. Please see inline.

Best regards,
Rachel

From: xrblock [mailto:xrblock-bounces@ietf.org] On Behalf Of Roni Even
Sent: Monday, February 10, 2014 6:45 PM
To: 'xrblock'
Subject: [xrblock] review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count

Hi,
I reviewed the draft and it looks OK some small comments


1.       Section 1 discuss the delay of the reporting to allow for the repair to take place. There may be a difference in the delay between conversional services and streaming application. Is the delay related to the jitter buffer size?
           [Rachel]: The delay is raised in [RFC5725]. Yes, I think it indicates the jitter buffer size.


2.       In section 3 "begin_seq", I am not sure why you have two options and why not use the RFC3611 definition
           [Rachel]: Will fix it.  Thanks.

Roni Even

v2.23.0 | Report a Bug | By Email