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

Glen Zorn <> Thu, 20 December 2012 07:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C141121F8A40 for <>; Wed, 19 Dec 2012 23:24:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.186
X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jUROd0LNvrlR for <>; Wed, 19 Dec 2012 23:24:48 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 39B4F21F89ED for <>; Wed, 19 Dec 2012 23:24:48 -0800 (PST)
Received: by with SMTP id mc8so1767369pbc.4 for <>; Wed, 19 Dec 2012 23:24:48 -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=VayQIwad0RJs2bAUzQfUPiaSTnhD13dwjXNEKmZRCig=; b=dV/wAidW2sbkLMq4luZCFhcMm3Tde8/txRGNkylF6Ics1o64JsG+RYSY41vERAoOj3 mgvQ/s3UsscCBDh1OkqfE4GxJWP4O+WtFOvYpwCD2xeCwiMnX/Ca5T2Wx3FCKyGA/YiR IDJjKWVY22wMMnWcQVmNZNMBFw9pPJPTK5gi2NBUtRDlvNKD9btpViHtH3LQEis2uj5W se/AwF/+ft+z1c/oPdkVboHVYmxxW+eKW02y0SCNNoaeXZ0byA6Dk34xa78ANGvoYt/W TZVQdgfv4MtrLzJUC+7YUJObT6lbJXwKfy5U5AaOA471DPIeRQlSHTjWsErCZbwLVXsM Ucrw==
X-Received: by with SMTP id bc9mr26766645pbd.61.1355988288006; Wed, 19 Dec 2012 23:24:48 -0800 (PST)
Received: from [] ( []) by with ESMTPS id oj5sm4561367pbb.47.2012. (version=SSLv3 cipher=OTHER); Wed, 19 Dec 2012 23:24:47 -0800 (PST)
Message-ID: <>
Date: Thu, 20 Dec 2012 14:24:44 +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 07:24:48 -0000

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.


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

>> ...
> >