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

[Glen Zorn <[e-mail]>]

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

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