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

[Glen Zorn <[e-mail]>]

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

>
 > [KG] I've seen recent discussion from others that leads me to wonder
 > whether they're going to be OK with it. I hope this proposal can get
 > a more thorough review before being included in the draft.
 >
 >
 > Block length Is requirement to discard reports with unexpected length
 > common practice with these reports? The alternative is to allow
 > reports to be revised to increased size with appended data. Original
 > implementations then ignore anything beyond the original size. It's a
 > little more flexible but maybe we don't want to go there. I've
 > checked RFC 3611 and don't see any guidance on this. It would be nice
 > to specify consistent behavior around this for all reports.
 >
 >
 > [Qin]:Yes. I have fixed this with adding the following sentence to
 > say: "
 >
 > The block MUST be discarded if the block length is
 >
 > set to a different value.
 >
 > "
 >
 >
 > [KG] I did not claim there was anything broken in the draft so I am
 > confused that you claim to have fixed it. If your "Yes" reply was in
 > response to "Is requirement to discard reports with unexpected length
 > common practice with these reports?" it would be helpful to point out
 > a draft or two on which you've modeled this behavior.
 >
 >
 > Jitter buffer nominal delay Needs to specify reference points for
 > reported delay: From receipt to playout? From RTP timestamp to
 > playout?
 >
 >
 > [Qin]:One reference point is the packet that arrives exact on time.
 >
 >
 > We need a definition for the "exactly on time". Exactly on time
 > according to whom and with respect to what? The other reference point
 > is playout time. This also needs to be defined. Playout of first byte
 > in the payload?

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 ;-)

> If one of the reference points  is a playout time, and depending on
 > expected use cases, higher resolution may be justified here.
 >
 > [Qin]:What's your suggested change? How about adding the following
 > sentence to say: " It is calculated based on the difference between
 > the receipt time and playout time for the packet that arrives exactly
 > on time. "
 >
 >
 > I need more information before making a proposal. Who do we expect
 > will use Jitter buffer nominal delay information and for what
 > purpose?
 >
 > Jitter buffer maximum delay Needs to specify reference points for
 > reported delay: From receipt to playout? From RTP timestamp to
 > playout?
 >
 >
 > [Qin]: How about adding the following sentence to say: " Jitter
 > buffer maximum delay is calculated based on the difference between
 > the receipt time and playout time for the earliest arriving packet"
 >
 >
 > I can't evaluate this proposal until I understand who we expect will
 > use Jitter buffer maximum delay information and for what purpose.
 >
 >
 > Jitter buffer high water mark Explain whether this applies to fixed
 > jitter buffer or only to adaptive.
 >
 > [Qin]: I think "Jitter buffer high water mark" applies to adaptive
 > jitter buffer implementation. its value MUST be set to jitter buffer
 > maximum delay for fixed jitter buffer implementations. How about
 > adding one sentence to say: " This parameter MUST be provided for
 > adaptive jitter buffer implementations and its value MUST be set to
 > JB maximum for fixed jitter buffer implementations. "
 >
 > This looks like an improvement but I can't fully evaluate the
 > proposal until we address the issues above and have a better
 > definition for Jitter buffer nominal delay.

I pretty much completely agree with Kevin on these points.

>
 >
 > _______________________________________________ xrblock mailing list
 > [e-mail] https://www.ietf.org/mailman/listinfo/xrblock