Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt

[Glen Zorn <[e-mail]>]

On 12/24/2012 08:38 AM, Qin Wu wrote:

>> On 12/22/2012 05:19 AM,  Kevin Gross wrote:
 >>
 >>> Section 3.2
 >>>
 >>> Jitter Buffer Configuration I think the two reporting options
 >>> are potentially over simplification of how these systems can
 >>> work. An adaptive receiver has to adapt to maximum latency and to
 >>> delay variation. The former is accomplish by adjusting the
 >>> playout delay, the latter by reallocating buffer space. I suggest
 >>> we might want to report these behaviors separately, for example:
 >>> 00 - fixed jitter buffer and delay 10 - adaptive playout delay 01
 >>> - adaptive buffer size 11 - adaptive delay and size
 >>>
 >>>
 >>> [Qin]:Sounds good to me.
 >>
 >> RFC 3611 allows reporting the following jitter buffer configuration
 >> parameters in the VoIP Metrics Report Block:
 >>
 >> jitter buffer adaptive (JBA): 2 bits Adaptive (11) / non-adaptive
 >> (10) / reserved (01)/ unknown (00). When the jitter buffer is
 >> adaptive, then its size is being dynamically adjusted to deal with
 >> varying levels of jitter. When non-adaptive, the jitter buffer
 >> size is maintained at a fixed level. When either adaptive or non-
 >> adaptive modes are specified, then the jitter buffer size
 >> parameters below MUST be specified.
 >>
 >> jitter buffer rate (JB rate): 4 bits J = adjustment rate (0-15).
 >> This represents the implementation specific adjustment rate of a
 >> jitter buffer in adaptive mode. This parameter is defined in terms
 >> of the approximate time taken to fully adjust to a step change in
 >> peak to peak jitter from 30 ms to 100 ms such that:
 >>
 >> adjustment time = 2 * J * frame size (ms)
 >>
 >> This parameter is intended only to provide a guide to the degree of
 >> "aggressiveness" of an adaptive jitter buffer and may be estimated.
 >> A value of 0 indicates that the adjustment time is unknown for this
 >> implementation.
 >>
 >> Kevin's suggested text seems to cover the first two values of the
 >> "jitter buffer adaptive" field more than adequately but "unknown"
 >> seems to be MIA. Is it not possible that the type of jitter buffer
 >> might be unknown?
 >
 > [Qin]: Good question. It looks we need to get alignment beween JB
 > draft and RFC3611 for this. Kevin, would you like to clarify why you
 > classify the adaptive one further into three?

Just to be clear, I think that Kevin's suggestion is fine (as far as it 
goes): I have no problem augmenting the functionality already provided 
by RFC 3611, just with decreasing it...

>
 >> Is the "jitter buffer rate" field useless? If not, why is an
 >> equivalent not included in the new draft? It seems like if the
 >> plan is to have these new report blocks replace the old ones, they
 >> should at least contain the same data...
 >
 > [Qin]: JB draft focus on reporting How jitter buffers are capable of
 > automatically adjusting to changes in delay rather than changs in
 > rate. That is say jb metrics are measured in millisecond while jitter
 > buffer rate is measured in unit from 0 to 15.

Who cares?

> Also jitter buffer rate
 > is more like configuration parameter that is only applied to adaptive
 > jitter buffer and doesn't look to me a mandotary feature that need to
 > be supported for the implementation.

So as it stands, in order to report the jitter buffer rate, an 
implementation would be required to send the VoIP Metrics Report Block 
even if it was not a VoIP application.  It seems like you're OK w/that; 
is it also the consensus of the WG?

...

>> I'm still waiting for  someone to define "nominal" in this context
 >> (hint: this
 >>
 >> jitter buffer nominal delay (JB nominal): 16 bits This is the
 >> current nominal jitter buffer delay in milliseconds, which
 >> corresponds to the nominal jitter buffer delay for packets that
 >> arrive exactly on time. This parameter MUST be provided for both
 >> fixed and adaptive jitter buffer implementations.
 >>
 >> does not contain a definition ;-)
 >
 > [Qin]: As I clarified to Kevin, implementation specific time window
 > will tell us what the exactly on time means. the jitter buffer can be
 > considered as a time window with one side (the early side) aligned
 > with the recent minimum delay and the other side (the late side)
 > representing the maximum permissible delay before a packet would be
 > discarded.
 >
 > So nominal just means packets arrive within the time wondow and can
 > be successully played out.

OK, but what is the difference between this and jitter buffer maximum 
delay, then?

>