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

Glen Zorn <> Thu, 20 December 2012 10:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 413CF21F88C4 for <>; Thu, 20 Dec 2012 02:21:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.278
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cqNkbTjDC1bf for <>; Thu, 20 Dec 2012 02:21:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 965E821F883B for <>; Thu, 20 Dec 2012 02:21:04 -0800 (PST)
Received: by with SMTP id hz11so1991676pad.17 for <>; Thu, 20 Dec 2012 02:20:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id aa9mr28092404pbd.102.1355998859805; Thu, 20 Dec 2012 02:20:59 -0800 (PST)
Received: from [] ( []) by with ESMTPS id jo6sm1130124pbb.5.2012. (version=SSLv3 cipher=OTHER); Thu, 20 Dec 2012 02:20:58 -0800 (PST)
Message-ID: <>
Date: Thu, 20 Dec 2012 17:20:55 +0700
From: Glen Zorn <>
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 <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: xrblock <>
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-jb-02.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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?'

>>>> ...
> >