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

Qin Wu <> Thu, 20 December 2012 10:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5FE8021F87E5 for <>; Thu, 20 Dec 2012 02:50:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.718
X-Spam-Status: No, score=-4.718 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 89rMnN2gatB8 for <>; Thu, 20 Dec 2012 02:50:02 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B1E4F21F8A4D for <>; Thu, 20 Dec 2012 02:50:01 -0800 (PST)
Received: from (EHLO ([]) by (MOS 4.3.5-GA FastPath queued) with ESMTP id AMR25937; Thu, 20 Dec 2012 10:49:59 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 10:49:27 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 10:49:39 +0000
Received: from w53375 ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 18:49:10 +0800
Message-ID: <>
From: Qin Wu <>
To: Glen Zorn <>
References: <><><><><><> <>
Date: Thu, 20 Dec 2012 18:49:09 +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: []
X-CFilter-Loop: Reflected
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:50:03 -0000

----- Original Message ----- 
From: "Glen Zorn" <>
To: "Qin Wu" <>
Cc: "xrblock" <>
Sent: Thursday, December 20, 2012 6:20 PM
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-jb-02.txt

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

[Qin]: I think you can rely on the synchronization metadata at the RTP layer or TS layer (e.g., DTS/PTS ) to know whether the packet arrives on time.

>>>> 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?'

[Qin]: Not necessary, it can apply to VOIP since the block is defined in the generic way.

>>>>> ...
>> >
> _______________________________________________
> xrblock mailing list