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

From: Kevin Gross <[email-masked]>
Date: Mon, 17 Dec 2012 14:41:53 -0700

Sorry for the delay in getting these comments published. I had originally
reviewed version 01. Some of my minor comments were resolved in this new
version and so are not included here.

Section 1.2

RFC 3611 is still in force -
s/[RFC3611] defined/[RFC3611] defines

Section 1.3

Missing conjunction -
s/guidelines in [RFC6390][RFC6792]/guidelines in [RFC6390] and [RFC6792]

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

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.

Jitter buffer nominal delay
Needs to specify reference points for reported delay: From receipt to
playout? From RTP timestamp to playout?
If one of the reference points is a playout time, and depending on expected
use cases, higher resolution may be justified here.

Jitter buffer maximum delay
Needs to specify reference points for reported delay: From receipt to
playout? From RTP timestamp to playout?

Another clarification -
s/correspond to the nominal size./correspond to the size of the jitter
buffer.

Jitter buffer high water mark
Explain whether this applies to fixed jitter buffer or only to adaptive.

Jitter buffer low water mark
Explain whether this applies to fixed jitter buffer or only to adaptive.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org

On Mon, Nov 26, 2012 at 5:51 PM, Qin Wu <[email-masked]> wrote:

> Sorry, I forgot what Kevin said in the last presentation.
> I think Dan's proposal looks good.:-)
>
> Regards!
> -Qin
> ----- Original Message -----
> From: "Romascanu, Dan (Dan)" <[email-masked]>
> To: "Varun Singh" <[email-masked]>
> Cc: "Qin Wu" <[email-masked]>; <[email-masked]>
> Sent: Monday, November 26, 2012 9:25 PM
> Subject: RE: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt
>
>
> Indeed, this was Kevin Gross.
>
> The question is whether Kevin's comments could be made during the WGLC, or
> they are severe enough to make us wait before issuing a LC. I hope that
> Kevin can answer this.
>
> Thanks and Regards,
>
> Dan
>
>
>
> > -----Original Message-----
> > From: Varun Singh [mailto:[email-masked]]
> > Sent: Monday, November 26, 2012 3:18 PM
> > To: Romascanu, Dan (Dan)
> > Cc: Qin Wu; [email-masked]
> > Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-
> > 02.txt
> >
> > Hi,
> >
> > AFAIR, someone (maybe Kevin Gross) remarked that he had some comments on
> > the draft.
> >
> > Regards,
> > Varun
> >
> > ----
> > http://www.netlab.tkk.fi/~varun
> >
> > On 26.11.2012, at 18.10, "Romascanu, Dan (Dan)" <[email-masked]>
> > wrote:
> >
> > > Thanks, Qin.
> > >
> > > Unless somebody has good reasons to object we shall issue the last
> > call in the coming days.
> > >
> > > Regards,
> > >
> > > Dan
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: [email-masked] [mailto:[email-masked]] On
> > >> Behalf Of Qin Wu
> > >> Sent: Monday, November 26, 2012 10:57 AM
> > >> To: [email-masked]
> > >> Subject: [xrblock] Fw: I-D Action:
> > >> draft-ietf-xrblock-rtcp-xr-jb-02.txt
> > >>
> > >> On 26 November , 2012 4:54 PM, [email-masked] wrote:
> > >>>
> > >>> A New Internet-Draft is available from the on-line Internet-Drafts
> > >> directories.
> > >>> This draft is a work item of the Metric Blocks for use with RTCP's
> > >> Extended Report Framework Working Group of the IETF.
> > >>>
> > >>> Title           : RTP Control Protocol (RTCP) Extended Report (XR)
> > >> Block for Jitter Buffer Metric Reporting
> > >>> Author(s)       : Alan Clark
> > >>>                         Varun Singh
> > >>>                         Qin Wu
> > >>> Filename        : draft-ietf-xrblock-rtcp-xr-jb-02.txt
> > >>> Pages           : 14
> > >>> Date            : 2012-11-26
> > >>>
> > >>> Abstract:
> > >>>  This document defines an RTP Control Protocol (RTCP) Extended
> > >>> Report
> > >>>  (XR) Block that allows the reporting of Jitter Buffer metrics for a
> > >>> range of RTP applications.
> > >>>
> > >>>
> > >>> The IETF datatracker status page for this draft is:
> > >>> https://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-jb
> > >>
> > >>
> > >> [Qin]: I believe this version address resolve the comments discussed
> > >> in the last Atalanta IETF meeting and now is ready for WGLC.
> > >> _______________________________________________
> > >> xrblock mailing list
> > >> [email-masked]
> > >> https://www.ietf.org/mailman/listinfo/xrblock
> > > _______________________________________________
> > > xrblock mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/xrblock
> _______________________________________________
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock
>

---

From: Qin Wu <[email-masked]>
Date: Tue, 18 Dec 2012 09:38:34 +0800

Hi, Kevin:
Thank for your feedback and valuable review. Please see my reply inline.

Regards!
-Qin
  ----- Original Message ----- 
  From: Kevin Gross 
  To: Qin Wu 
  Cc: Romascanu, Dan (Dan) ; Varun Singh ; [email-masked] 
  Sent: Tuesday, December 18, 2012 5:41 AM
  Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt

  Sorry for the delay in getting these comments published. I had originally reviewed version 01. Some of my minor comments were resolved in this new version and so are not included here.

  Section 1.2

[Qin]:Okay.

  Section 1.3

  Missing conjunction - 

[Qin]:Okay.

  Section 3.2

  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:

[Qin]:Sounds good to me.

  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.

"

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

  Another clarification - 
  s/correspond to the nominal size./correspond to the size of the jitter buffer.

[Qin]: Make sense to me.

  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.

"

[Qin]:Same proposed change above.

  Kevin Gross
  +1-303-447-0517
  Media Network Consultant

  AVA Networks - www.AVAnw.com, www.X192.org

    Regards!
    -Qin

    ----- Original Message -----
    From: "Romascanu, Dan (Dan)" <[email-masked]>
    To: "Varun Singh" <[email-masked]>
    Cc: "Qin Wu" <[email-masked]>; <[email-masked]>
    Sent: Monday, November 26, 2012 9:25 PM
    Subject: RE: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt

    The question is whether Kevin's comments could be made during the WGLC, or they are severe enough to make us wait before issuing a LC. I hope that Kevin can answer this.

    Thanks and Regards,

    Dan

---

From: Kevin Gross <[email-masked]>
Date: Fri, 21 Dec 2012 15:19:32 -0700

Discussion below...

On Mon, Dec 17, 2012 at 6:38 PM, Qin Wu <[email-masked]> wrote:

> **

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

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

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

>  If one of the reference points is a playout time, and depending on
> expected use cases, higher resolution may be justified here.
>

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 is calculated based on the difference
> between the receipt time and playout time

I can't evaluate this proposal until I understand who we expect will use
Jitter buffer maximum delay information and for what purpose.

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

---

From: Qin Wu <[email-masked]>
Date: Sat, 22 Dec 2012 09:38:10 +0800

Hi,
  ----- Original Message ----- 
  From: Kevin Gross 
  To: Qin Wu 
  Cc: Romascanu, Dan (Dan) ; Varun Singh ; [email-masked] 
  Sent: Saturday, December 22, 2012 6:19 AM
  Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt

  Discussion below...

      Section 3.2

    [Qin]:Sounds good to me.

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

[Qin]: Good.

      Block length

    "

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

[Qin]:Sorry for my misunderstanding what you said above. My answer to your question "Is requirement to discard reports with unexpected length common practice with these reports?" . The reason we add "The block MUST be discarded if the block length is set to a different value." is becos somebody raised commments to say "what the receiver will do if the block lenght is set to a different value". I assume it was Dan. That's why we bring this proposal. currently this proposal applies to burst gap loss draft, burst gap discard draft, jb draft and discard draft.To be consistent with RFC3611,already published RFC6798 and my answer to your question, it looks to me the proposed text "The block MUST be discarded if the block length is
 set to a different value." doesn't need.

  We need a definition for the "exactly on time". Exactly on time according to whom and with respect to what? 

[Qin]:It relies on "implementation specific time window" just like burst gap loss, burst discard did, i.e., if a packet arrives within this window and can be successuflly played out, this packet will be the packet that arrive exactly on time. please see the term "Received, Lost and Discarded" in the section 2.1 of burst gap loss draft for "implementation specific time window"

  The other reference point is playout time. This also needs to be defined. Playout of first byte in the payload?

[Qin]: I agree with you, your understanding to the playout time is more accurate.
      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? 
[Qin]: Network manager may want to measure what impact the jitter buffer have on a VOIP service or IPTV service or we can say jitter buffer metric is one important quality of service factor in
assessment of the end to end network performance including both transport performance and end system performance or in evaluation of the user perception of the service in end to end mode.
      Jitter buffer maximum delay
      Needs to specify reference points for reported delay: From receipt to playout? From RTP timestamp to playout?

  I can't evaluate this proposal until I understand who we expect will use Jitter buffer maximum delay information and for what purpose.

[Qin]:See above.

    "

  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.
[Qin]: Okay.

---

From: Glen Zorn <[email-masked]>
Date: Sun, 23 Dec 2012 15:06:41 +0700

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

 > 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: "
 >
 > 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?
 >
 >
 > 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 ;-)

 > [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
 > [email-masked] https://www.ietf.org/mailman/listinfo/xrblock

---

From: Qin Wu <[email-masked]>
Date: Mon, 24 Dec 2012 09:38:22 +0800

----- Original Message ----- 
From: "Glen Zorn" <[email-masked]>
To: "Kevin Gross" <[email-masked]>
Cc: "Qin Wu" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Sunday, December 23, 2012 4:06 PM
Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt

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

> Is the "jitter buffer rate" field useless?  If not, why is an 

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

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

---

From: Glen Zorn <[email-masked]>
Date: Mon, 24 Dec 2012 14:23:49 +0700

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

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

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

---

From: Qin Wu <[email-masked]>
Date: Mon, 24 Dec 2012 17:46:08 +0800

> > buffer rate is measured in unit from 0 to 15.

[Qin]: My point, jitter buffer rate does not belong to jitter buffer metric for delay.

> is it also the consensus of the WG?

[Qin]: See above.
I don't know why you think jitter buffer rate is so much important?
> OK, but what is the difference between this and jitter buffer maximum 

[Qin]: It seems I had clarified this to you on the list more than once.
Please look into the draft and my previous comments. The difference is they have different reference point,i.e.,
jitter buffer maximum delay will be measured based on the earliest arriving packet rathen than the packet
arrives on time.