Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-jb-02.txt

Qin Wu <bill.wu@huawei.com> Thu, 20 December 2012 08:49 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 9043B21F8440 for <xrblock@ietfa.amsl.com>; Thu, 20 Dec 2012 00:49:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.705
X-Spam-Level:
X-Spam-Status: No, score=-4.705 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aptjbvGzbS32 for <xrblock@ietfa.amsl.com>; Thu, 20 Dec 2012 00:49:10 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0B021F84A1 for <xrblock@ietf.org>; Thu, 20 Dec 2012 00:49:09 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANZ98362; Thu, 20 Dec 2012 08:49:08 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 08:48:46 +0000
Received: from SZXEML461-HUB.china.huawei.com (10.82.67.204) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 08:48:51 +0000
Received: from w53375 (10.138.41.149) by szxeml461-hub.china.huawei.com (10.82.67.204) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 16:48:47 +0800
Message-ID: <2240AA3806904019953BBA7AC49177B6@china.huawei.com>
From: Qin Wu <bill.wu@huawei.com>
To: Glen Zorn <glenzorn@gmail.com>
References: <50CAF991.8050508@gmail.com> <A58F079A8D804929AA28B535FAB72BAC@china.huawei.com> <50CC10DF.4030403@gmail.com> <A7B4A1EEC74F4B5788CE4568D1EA280F@china.huawei.com> <50D2BD3C.10507@gmail.com>
Date: Thu, 20 Dec 2012 16:48:47 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Originating-IP: [10.138.41.149]
X-CFilter-Loop: Reflected
Cc: xrblock <xrblock@ietf.org>
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-jb-02.txt
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: Thu, 20 Dec 2012 08:49:10 -0000

----- Original Message ----- 
From: "Glen Zorn" <glenzorn@gmail.com>
To: "Qin Wu" <bill.wu@huawei.com>
Cc: "Glen Zorn" <glenzorn@gmail.com>; "xrblock" <xrblock@ietf.org>
Sent: Thursday, December 20, 2012 3:24 PM
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-jb-02.txt


> On 12/17/2012 09:04 AM, Qin Wu wrote:
> ...
> 
>>>>> *Section 3.2* The description of the "jitter buffer nominal delay"
>>>>> says that "It is calculated based on the time for packets spent in
>>>>> the jitter buffer." How is it calculated?
>>>> [Qin]:It will be calculate based on the difference between the time
>>>> when the packet enter into the jitter buffer and the time when the
>>>> packet come out from jitter buffer. It is mostly up to specific
>>>> implementation and doesn't need to spell out.
>>> So it's OK if two different implementations produce different numbers
>>> from the same data?  That doesn't seem very interoperable, somehow.
>>> Maybe one problem I'm having with this is that the way the word
>>> "nominal" is used doesn't map to any definition of which I'm aware.
>> [Qin]: Suppose a lot of packets are receieved in one measurement interval. Some packets arrive very earlier, some packets arrive very late.
>> some packets arrive extractly on time. Nominal packet are referred to the packet that arrives exactly on time
>> Since they have the same reference measurement point, usually they will get the same result.
> 
> Usually?

[Qin]: one update (-05) was done to clear this ambiguity based on recent comment 
from Kevin who has the similar concern as you. The change is
replace "It is calculated based on the time for packets spent in the jitter buffer." 
with "It is calculated based on the difference between the receipt time and the 
playout time for the packet that arrives exactly on time." 

With this justification text, you will see different implementations will not produce different numbers.

>>
>> For the definition, you also can see the metric "jitter buffer nominal delay  " defined in RFC3611,section4.7.7.
> 
> Thanks for the reference, but it raises more questions than it answers 
> for me.   The draft appears to duplicate most, but not all, of the 
> fields related to jitter buffers included in the VoIP Metrics Report 
> Block defined in RFC 3611, but says nothing about its relationship to 
> that RFC (i.e., if it obsoletes or updates RFC 3611).  So as it stands 
> it looks like if "jitter buffer absolute maximum delay" is to be 
> reported the VoIP Metrics Report Block needs to be sent anyway.  I'm 
> assuming that this is intentional but I don't recall any discussion of 
> it on the list.  Was I just not paying attention?   Is there a plan to 
> obsolete RFC 3611 at some point in the future (say, when all the XR 
> blocks defined therein have been sliced & diced into the currently 
> fashionable tiny hunks)?  It's not in the charter...

[Qin]: The metric has been defined in RFC3611. However the block format to carry 
this metric need to be re-specified so that we can make such metric block can be
applicable to more other RTP applications rather than VOIP application since VOIP metric
report doesn't look reusable for video application. I don't think RFC3611 needs to be obseleted.

>>> ...
>> >
>