Re: [xrblock] (2nd) WGLC for draft-ietf-xrblock-rtcp-xr-jb

Qin Wu <bill.wu@huawei.com> Tue, 23 April 2013 03:34 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B0221F8E96 for <xrblock@ietfa.amsl.com>; Mon, 22 Apr 2013 20:34:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.347
X-Spam-Level:
X-Spam-Status: No, score=-5.347 tagged_above=-999 required=5 tests=[AWL=1.252, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwwhBPHV3X0U for <xrblock@ietfa.amsl.com>; Mon, 22 Apr 2013 20:34:34 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9714021F8E77 for <xrblock@ietf.org>; Mon, 22 Apr 2013 20:34:32 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASC10906; Tue, 23 Apr 2013 03:34:30 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Apr 2013 04:34:02 +0100
Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Apr 2013 04:34:28 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.113]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Tue, 23 Apr 2013 11:34:24 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Colin Perkins <csp@csperkins.org>, "Romascanu, Dan (Dan)" <dromasca@avaya.com>
Thread-Topic: [xrblock] (2nd) WGLC for draft-ietf-xrblock-rtcp-xr-jb
Thread-Index: Ac40Yjq4Xn7GWM4iS5GYjSTAh3YdmgKxGpKAACrFfnA=
Date: Tue, 23 Apr 2013 03:34:23 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA43A4DB37@nkgeml501-mbs.china.huawei.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA0C42A3@AZ-FFEXMB04.global.avaya.com> <01F8E350-5922-4E68-A9C5-9E1BB0545217@csperkins.org>
In-Reply-To: <01F8E350-5922-4E68-A9C5-9E1BB0545217@csperkins.org>
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: xrblock <xrblock@ietf.org>
Subject: Re: [xrblock] (2nd) WGLC for draft-ietf-xrblock-rtcp-xr-jb
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Apr 2013 03:34:35 -0000

Hi, Colin:
I realized jitter buffer nominal delay metric can only be sampled and is not desirable to measuring them over definite intervals.
jitter buffer maximum delay metrics is corresponding to the earliest arriving packet in the reporting interval and it is more desirable 
to classify it as sampled metric. When we have several packets that arrives exactly on time in the reporting interval, we can know
which packet has the highest value of the jitter buffer nominal delay, which packet has the lowest value of the jitter buffer nominal delay.
So I like to revoke my proposed change used to address Claire's comment and add the following sentence at the end of definition of interval metric flag to say: 
"
In this document, Jitter Buffer Metrics can only be sampled , and cannot be measured over definite intervals. 
 Also, the value I=00 is reserved for future use.  Senders MUST NOT use the values I=00 or I=10 or I=11.  
If a block is received with I=00 or I=10 or I=11, the receiver MUST discard the block.
"
Note that as described in the draft, if any measurement to these metrics is not available, the value 0xFFFF MUST be reported  

Regards!
-Qin
-----Original Message-----
From: xrblock-bounces@ietf.org [mailto:xrblock-bounces@ietf.org] On Behalf Of Colin Perkins
Sent: Monday, April 22, 2013 10:57 PM
To: Romascanu, Dan (Dan)
Cc: xrblock
Subject: Re: [xrblock] (2nd) WGLC for draft-ietf-xrblock-rtcp-xr-jb

On 8 Apr 2013, at 15:06, Romascanu, Dan (Dan) wrote:
> This is the second WGLC for the Internet-Draft 'RTP Control Protocol (RTCP) Extended Report (XR) Block for Jitter Buffer Metric Reporting'. Please send your comments, questions, and concerns to the WG list before Monday 4/22 COB. If you have no comments or questions and you believe that this document is ready for submission to the IESG for consideration as a Proposed Standard, please send a message stating this. 
> 
> The latest version of the document can be retrieved from http://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-jb-10.txt.


I think this is essentially ready, but I did have a quick comments on re-reading the draft:

How is the jitter buffer nominal delay calculated for an interval metric or for a cumulative metric? The draft talks about "the current nominal jitter buffer delay", which makes sense for a sampled metric, but it's not clear how it applies for an interval or as a cumulative metric?

It might also be necessary to clarify the other jitter buffer metrics for the cumulate case.

-- 
Colin Perkins
http://csperkins.org/



_______________________________________________
xrblock mailing list
xrblock@ietf.org
https://www.ietf.org/mailman/listinfo/xrblock