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

Colin Perkins <csp@csperkins.org> Tue, 30 April 2013 10:56 UTC

Return-Path: <csp@csperkins.org>
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 6339521F9991 for <xrblock@ietfa.amsl.com>; Tue, 30 Apr 2013 03:56:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 4osoRZxaekeN for <xrblock@ietfa.amsl.com>; Tue, 30 Apr 2013 03:56:32 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id A86D221F98E4 for <xrblock@ietf.org>; Tue, 30 Apr 2013 03:56:31 -0700 (PDT)
Received: from [130.209.247.112] (port=62157 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <csp@csperkins.org>) id 1UX8EJ-0004AJ-Jq; Tue, 30 Apr 2013 11:56:18 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA43A4DB37@nkgeml501-mbs.china.huawei.com>
Date: Tue, 30 Apr 2013 11:56:14 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <FD14A0BC-1177-4AB2-A0B2-070E48EE3FF2@csperkins.org>
References: <9904FB1B0159DA42B0B887B7FA8119CA0C42A3@AZ-FFEXMB04.global.avaya.com> <01F8E350-5922-4E68-A9C5-9E1BB0545217@csperkins.org> <B8F9A780D330094D99AF023C5877DABA43A4DB37@nkgeml501-mbs.china.huawei.com>
To: Qin Wu <bill.wu@huawei.com>
X-Mailer: Apple Mail (2.1283)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
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, 30 Apr 2013 10:56:36 -0000

Thanks, this change looks good to me.
Colin


On 23 Apr 2013, at 04:34, Qin Wu wrote:

> 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



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