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

Glen Zorn <glenzorn@gmail.com> Thu, 20 December 2012 10:21 UTC

Return-Path: <glenzorn@gmail.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 413CF21F88C4 for <xrblock@ietfa.amsl.com>; Thu, 20 Dec 2012 02:21:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.278
X-Spam-Level:
X-Spam-Status: No, score=-3.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 cqNkbTjDC1bf for <xrblock@ietfa.amsl.com>; Thu, 20 Dec 2012 02:21:04 -0800 (PST)
Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 965E821F883B for <xrblock@ietf.org>; Thu, 20 Dec 2012 02:21:04 -0800 (PST)
Received: by mail-pa0-f44.google.com with SMTP id hz11so1991676pad.17 for <xrblock@ietf.org>; Thu, 20 Dec 2012 02:20:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mmlEfL7IpWOVuVoTVLDHTsdbLPgws5m8dPZmBkqlhqc=; b=D1wjqz9EVhN0dALvrlyql2dVbnuWMO3VTKDtYbzntjXbKcYUo/RlKCIWzFIK5oBzFd wFsoeUiMRyGpG8/g7jjn9HnUiG6jqo//b8XKpbgiq7wQnsbTzN88iP33xiaSjYBJPQUU bMWNUxa07hF5WlBsGOGJMyPCP0zBQIslguXUJJarPFWii8/bGvakRPBnNSfq1kIeuOcq gP5rbfDNndfTbisF7Z/+nhd1M/uZ3tlMmAk1/uDyQYuHbPts5hJR/vjbHIPT4BgDbZgi TPwlXYdoOtC8nTcvEaf9YG8A4I3s+7fS2kAeHFB1x2XXVljU0AamWCPUmizPekO8KuIF tuhg==
X-Received: by 10.68.253.137 with SMTP id aa9mr28092404pbd.102.1355998859805; Thu, 20 Dec 2012 02:20:59 -0800 (PST)
Received: from [192.168.0.102] (ppp-110-169-255-188.revip5.asianet.co.th. [110.169.255.188]) by mx.google.com with ESMTPS id jo6sm1130124pbb.5.2012.12.20.02.20.57 (version=SSLv3 cipher=OTHER); Thu, 20 Dec 2012 02:20:58 -0800 (PST)
Message-ID: <50D2E687.9090306@gmail.com>
Date: Thu, 20 Dec 2012 17:20:55 +0700
From: Glen Zorn <glenzorn@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Qin Wu <bill.wu@huawei.com>
References: <50CAF991.8050508@gmail.com> <A58F079A8D804929AA28B535FAB72BAC@china.huawei.com> <50CC10DF.4030403@gmail.com> <A7B4A1EEC74F4B5788CE4568D1EA280F@china.huawei.com> <50D2BD3C.10507@gmail.com> <2240AA3806904019953BBA7AC49177B6@china.huawei.com>
In-Reply-To: <2240AA3806904019953BBA7AC49177B6@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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 10:21:05 -0000

On 12/20/2012 03:48 PM, Qin Wu wrote:
>> 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.
Doesn't that depend upon what the application defines "exactly on time" 
to mean?

>
>>> 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.

So this block is for use with any real-time application _except_ VOIP?'

>
>>>> ...
>>>>
> >