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

From: Kevin Gross <[email-masked]>
Date: Sat, 12 Jan 2013 15:04:34 -0700

Qin,

Of the jitter buffer delay metric, the draft currently says "It is
calculated based on the difference between the receipt time and the playout
time for the packet that arrives exactly on time."

My issue is that I don't know how to identify a "packet that arrives
exactly on time".

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

On Thu, Jan 10, 2013 at 6:09 PM, Qin Wu <[email-masked]> wrote:

> **
>
>   [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]: Regarding calculation method for "jitter buffer nominal delay" , I
> talked with Colin offline long time ago.
> He was okay with my early proposal, i.e.,
> "
> It is calculated based on the time
>  for packets spent in the jitter buffer.
> "
> But he also suggested that we may  use another proposal to make the
> definition more clear as follows
> "
>  It is calculated based on the difference between the receipt time and
> playout time for the packet that
> arrives exactly on time.
> "
> That's why we propose to have such change.
>
>   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.
>
>>
>>
>>

---

From: Qin Wu <[email-masked]>
Date: Mon, 14 Jan 2013 08:46:42 +0800

Kevin:
As I clarified to you in the previous email, "implemention specific time window" described in Burst Gap drafts will be used to identify a "packet that arrives exactly on time".
That is to say, if the receiving packet falls within  implemention specific time window and can be sucessfully playout, such packet will be regarded as packet that arrives exactly on time.
Hope this clarifies.

Regards!
-Qin
  ----- Original Message ----- 
  From: Kevin Gross 
  To: Qin Wu 
  Cc: xrblock 
  Sent: Sunday, January 13, 2013 6:04 AM
  Subject: Re: offlist//Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt

  Qin,

  Of the jitter buffer delay metric, the draft currently says "It is calculated based on the difference between the receipt time and the playout time for the packet that arrives exactly on time."

  My issue is that I don't know how to identify a "packet that arrives exactly on time".

  Kevin Gross

  +1-303-447-0517
  Media Network Consultant

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

---

From: Qin Wu <[email-masked]>
Date: Tue, 15 Jan 2013 11:27:05 +0800

Hi,Kevin:
I like to make some additioal clarification to your question.
I think the packet arrives exactly on time, is also referred to the packet that has nominal delay.
So we have two ways to address this. 
a. It is more like implementation specific issue,e.g., rely on timing information in the headers of previous 
packet and current packet or rely on time window to determine this. So we can leave this to the specific
 implemenations. 

b. we can explain the packet that arrives exactly on time as the packet that has nominal delay.
The nominal delay can either be choosen as the jitter buffer delay for the packet with minimal delay(i.e., 
the reference packet is choosen as the packet with minmal delay) or average delay for all the packets that arrives
within the implementation specific time window during the measurement interval.
I am not sure we should details to talk about this, but If we take (b), we prefer to add the following sentence in the draft to say:
"Note that the reference packet is generally selected as the packet
 with minimum delay based on the most common criterion (see Sections 1 and 5.1 of [RFC5481]).
"
Let me know what you think about this.

Regards!
-Qin
  ----- Original Message ----- 
  From: Qin Wu 
  To: Kevin Gross 
  Cc: xrblock 
  Sent: Monday, January 14, 2013 8:46 AM
  Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt

  Kevin:

  Regards!
  -Qin
    ----- Original Message ----- 
    From: Kevin Gross 
    To: Qin Wu 
    Cc: xrblock 
    Sent: Sunday, January 13, 2013 6:04 AM
    Subject: Re: offlist//Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt

    Qin, 

    Kevin Gross

    +1-303-447-0517
    Media Network Consultant

------------------------------------------------------------------------------

  _______________________________________________
  xrblock mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/xrblock

---

From: Kevin Gross <[email-masked]>
Date: Tue, 15 Jan 2013 14:08:16 -0700

I think we need to have a phone call to discuss this whole thing.

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

On Mon, Jan 14, 2013 at 8:27 PM, Qin Wu <[email-masked]> wrote:

> the reference packet is choosen as the packet with minmal delay) or
> average delay for all the packets that arrives
> I am not sure we should details to talk about this, but If we take (b),
> we prefer to add the following sentence in the draft to say:
>  with minimum delay based on the most common criterion (see Sections 1<http://tools.ietf.org/html/rfc6798#section-1> and
> 5.1 of [RFC5481 <http://tools.ietf.org/html/rfc5481>]).
> "
> *From:* Qin Wu <[email-masked]>
> *To:* Kevin Gross <[email-masked]>
> *Cc:* xrblock <[email-masked]>
> *Sent:* Monday, January 14, 2013 8:46 AM
> *Subject:* Re: [xrblock] Fw: I-D Action:
> draft-ietf-xrblock-rtcp-xr-jb-02.txt
>
> Kevin:
> As I clarified to you in the previous email, "implemention specific time
> window" described in Burst Gap drafts will be used to identify a "packet
> that arrives exactly on time".
> That is to say, if the receiving packet falls within  implemention
> specific time window and can be sucessfully playout, such packet will be
> regarded as packet that arrives exactly on time.
> Hope this clarifies.
>
> Regards!
> -Qin
>
> *From:* Kevin Gross <[email-masked]>
> *To:* Qin Wu <[email-masked]>
> *Cc:* xrblock <[email-masked]>
> *Sent:* Sunday, January 13, 2013 6:04 AM
> *Subject:* Re: offlist//Re: [xrblock] Fw: I-D Action:
> draft-ietf-xrblock-rtcp-xr-jb-02.txt
>
> Qin,
>
> calculated based on the difference between the receipt time and the
> playout time for the packet that arrives exactly on time."
>
>  ------------------------------
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 16 Jan 2013 10:36:56 +0000

Kevin, Qin,

Do you want to discuss this one2one, or should we organize a short conference call? Do other think that they can contribute to clarify the issues, or want to participate?

Dan

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kevin Gross
Sent: Tuesday, January 15, 2013 11:08 PM
To: Qin Wu
Cc: xrblock
Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt

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

On Mon, Jan 14, 2013 at 8:27 PM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:
Hi,Kevin:

 with minimum delay based on the most common criterion (see Sections 1<http://tools.ietf.org/html/rfc6798#section-1> and 5.1 of [RFC5481<http://tools.ietf.org/html/rfc5481>]).

Regards!
-Qin
----- Original Message -----
From: Qin Wu<mailto:[email-masked]>
To: Kevin Gross<mailto:[email-masked]>
Cc: xrblock<mailto:[email-masked]>
Sent: Monday, January 14, 2013 8:46 AM
Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt

Kevin:

Regards!
-Qin
----- Original Message -----
From: Kevin Gross<mailto:[email-masked]>
To: Qin Wu<mailto:[email-masked]>
Cc: xrblock<mailto:[email-masked]>
Sent: Sunday, January 13, 2013 6:04 AM
Subject: Re: offlist//Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt

Qin,

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

________________________________
_______________________________________________
xrblock mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/xrblock

---

From: Alan Clark <[email-masked]>
Date: Wed, 16 Jan 2013 07:17:31 -0500

A typical jitter buffer uses the first packet received as its timing
reference, and applies a nominal delay to that before playing out.  During
later operation, the jitter buffer may increase or reduce the nominal delay
or may pick a new reference packet. This nominal delay represents the ³late
window² - so if a packet arrives more than ³nominal delay ms² after its
expected time then it will be discarded.

³On time² - in this case - refers to the expected arrival time of the packet
when calculated with reference to the first or a later selected reference
packet.

Jitter buffer implementations don¹t necessary do this mathematically however
this is a generalized description that models the behavior of most jitter
buffers used for VoIP and Videoconferencing.

Playout buffers used in video streaming applications operate quite
differently. Basically a received chunk of encoded video is added to the
playout buffer - encoded video is read from the buffer. When the buffer
level drops below a threshold then another chunk of video is requested from
the server. There is an equivalent to ³nominal delay² as the buffer will
always try to make sure there is at least a minimal level of video in the
buffer before playing out - however there would not be the equivalent of an
³on time² packet.

Regards

Alan

On 1/16/13 5:36 AM, "Dan (Dan)" <[email-masked]> wrote:

> Kevin, Qin,
>  
> Do you want to discuss this one2one, or should we organize a short conference
> call? Do other think that they can contribute to clarify the issues, or want
> to participate? 
>  
> Dan
>  
>  
>  
> 
> AVA Networks - www.AVAnw.com <http://www.avanw.com/> , www.X192.org
> <http://www.X192.org>
>  
> 
> I am not sure we should details to talk about this, but If we take (b), we
> prefer to add the following sentence in the draft to say:
> 
>  with minimum delay based on the most common criterion (see Sections 1
> <http://tools.ietf.org/html/rfc6798#section-1>  and 5.1 of [RFC5481
> <http://tools.ietf.org/html/rfc5481> ]).
> 
> "
> 
>> From: Qin Wu <mailto:[email-masked]>
>> 
>> To: Kevin Gross <mailto:[email-masked]>
>> 
>> Cc: xrblock <mailto:[email-masked]>
>> 
>> window" described in Burst Gap drafts will be used to identify a "packet that
>> arrives exactly on time".
>> 
>> That is to say, if the receiving packet falls within  implemention specific
>> time window and can be sucessfully playout, such packet will be regarded as
>> packet that arrives exactly on time.
>> 
>> Hope this clarifies.
>> 
>>  
>> 
>> Regards!
>> 
>> -Qin
>>> 
>>> From: Kevin Gross <mailto:[email-masked]>
>>> 
>>> To: Qin Wu <mailto:[email-masked]>
>>> 
>>> Cc: xrblock <mailto:[email-masked]>
>>> 
>>> +1-303-447-0517 <tel:%2B1-303-447-0517>
>>> 
>>> Media Network Consultant
>>> 
>>> AVA Networks - www.AVAnw.com <http://www.AVAnw.com> , www.X192.org
>>> <http://www.X192.org>
>>>  
>> 
>>

---

From: "Roni Even" <[email-masked]>
Date: Wed, 16 Jan 2013 17:01:19 +0200

Hi Alan,

I am not sure what applies a nominal delay means. Is the first packet
defines the start of the jitter buffer and nominal delay is the size of the
fixed jitter buffer.  

When saying that the jitter buffer may increase or reduce is this for the
adaptive jitter buffer?

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alan Clark
Sent: 16 January, 2013 2:18 PM
To: Dan (Dan); Kevin Gross; Qin Wu
Cc: xrblock
Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt

A typical jitter buffer uses the first packet received as its timing
reference, and applies a nominal delay to that before playing out.  During
later operation, the jitter buffer may increase or reduce the nominal delay
or may pick a new reference packet. This nominal delay represents the "late
window" - so if a packet arrives more than "nominal delay ms" after its
expected time then it will be discarded.

"On time" - in this case - refers to the expected arrival time of the packet
when calculated with reference to the first or a later selected reference
packet.

Jitter buffer implementations don't necessary do this mathematically however
this is a generalized description that models the behavior of most jitter
buffers used for VoIP and Videoconferencing.

the server. There is an equivalent to "nominal delay" as the buffer will
"on time" packet.

Regards

Alan

Kevin, Qin,
 
Do you want to discuss this one2one, or should we organize a short
conference call? Do other think that they can contribute to clarify the
issues, or want to participate? 
 
Dan

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Kevin Gross
Sent: Tuesday, January 15, 2013 11:08 PM
To: Qin Wu
Cc: xrblock
Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt

Kevin Gross

+1-303-447-0517

Media Network Consultant

Hi,Kevin:

I think the packet arrives exactly on time, is also referred to the packet
that has nominal delay.

a. It is more like implementation specific issue,e.g., rely on timing
information in the headers of previous 

packet and current packet or rely on time window to determine this. So we
can leave this to the specific

implemenations. 

b. we can explain the packet that arrives exactly on time as the packet that
has nominal delay.

The nominal delay can either be choosen as the jitter buffer delay for the
packet with minimal delay(i.e., 

the reference packet is choosen as the packet with minmal delay) or average
delay for all the packets that arrives

within the implementation specific time window during the measurement
interval.

"

Regards!

-Qin

----- Original Message ----- 

Kevin:

Hope this clarifies.

Regards!

-Qin

----- Original Message ----- 

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

Qin, 

My issue is that I don't know how to identify a "packet that arrives exactly
on time".

Kevin Gross

Media Network Consultant

  _____  

  _____

---

From: Alan Clark <[email-masked]>
Date: Wed, 16 Jan 2013 11:29:11 -0500

Hi Roni

Nominal delay is the delay that is applied to a packet that arrives at its
expected time (i.e. 0 jitter) - and corresponds to the late window of the
jitter buffer

Jitter buffer size can be ambiguous as the term is sometimes used to mean
the late window and sometimes the overall buffer size.

For example.

A jitter buffer is configured to have 200ms of overall buffer space.
Initially packets are inserted into this at the 40ms point and hence incur
40ms of delay as they propagate to the 0ms ³read² point. If all the packets
arrive with zero jitter they would all incur 40ms of delay within the
buffer.

If a packet arrives 10ms later than expected then it is written to the
buffer at the (40-10)ms point however if a packet arrives more than 40ms
late then it is discarded.

If a packet arrives 50ms earlier than expected it is written to the
(40+50)ms point and would wait 90ms before being played out.

With an adaptive jitter buffer, If the jitter level is high and packets are
being discarded then the insertion point for on-time packets could be moved
to say 100ms. This results in the delay for on-time/ zero jitter packets
being 100ms but would reduce the discard rate

So the nominal delay is the time difference/ buffer size difference between
the on-time insertion point and the point at which packets are read out and
decoded.

Regards

Alan

On 1/16/13 10:01 AM, "Roni Even" <[email-masked]> wrote:

> Hi Alan,
> I am not sure what applies a nominal delay means. Is the first packet defines
> the start of the jitter buffer and nominal delay is the size of the fixed
> jitter buffer.  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alan Clark
> later operation, the jitter buffer may increase or reduce the nominal delay or
> may pick a new reference packet. This nominal delay represents the ³late
> playout buffer - encoded video is read from the buffer. When the buffer level
> drops below a threshold then another chunk of video is requested from the
> server. There is an equivalent to ³nominal delay² as the buffer will always
> try to make sure there is at least a minimal level of video in the buffer
> before playing out - however there would not be the equivalent of an ³on time²
> packet.
> 
> Regards
> 
> Alan
> 
> 
> AVA Networks - www.AVAnw.com <http://www.AVAnw.com>  <http://www.avanw.com/> ,
> www.X192.org <http://www.X192.org>  <http://www.X192.org>
>  
> 
> Of the jitter buffer delay metric, the draft currently says "It is calculated
> based on the difference between the receipt time and the playout time for the
> packet that arrives exactly on time."
> 
> 
> 
> AVA Networks - www.AVAnw.com <http://www.AVAnw.com>  <http://www.AVAnw.com> ,
> www.X192.org <http://www.X192.org>  <http://www.X192.org>
>   
> 
> 
>

---

From: "Roni Even" <[email-masked]>
Date: Wed, 16 Jan 2013 23:15:58 +0200

Hi Alan,

If you insert the received packet at 40 ms and you are currently start
reading from 0 you are delaying by 40 ms and 40 ms is the nominal delay.  So
it does not matter what is the jitter buffer size, you are expecting to
render or decode a packet if it arrives between 0 or 40 ms compared to the
first packet. I assume for fixed buffer this will not change but for
adaptive buffer the nominal delay may change.

I agree on the last sentence of your explanation, the question is how you
define the on-time insertion point or expected time. I believe you  are
saying it is based on the first packet that arrives.

Roni

From: Alan Clark [mailto:[email-masked]] 
Sent: 16 January, 2013 6:29 PM
To: Roni Even; Dan (Dan); 'Kevin Gross'; Qin Wu
Cc: 'xrblock'
Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt

Hi Roni

For example.

A jitter buffer is configured to have 200ms of overall buffer space.
Initially packets are inserted into this at the 40ms point and hence incur
40ms of delay as they propagate to the 0ms "read" point. If all the packets
arrive with zero jitter they would all incur 40ms of delay within the
buffer.

Regards

Alan

Hi Alan,
 
Roni

Regards

Alan

 
Dan

Kevin Gross

+1-303-447-0517

Media Network Consultant

AVA Networks - www.AVAnw.com <http://www.AVAnw.com>  <http://www.avanw.com/>
, www.X192.org <http://www.X192.org>  <http://www.X192.org> 

Hi,Kevin:

implemenations. 

"

Regards!

-Qin

----- Original Message ----- 

Kevin:

Hope this clarifies.

Regards!

-Qin

----- Original Message ----- 

Qin, 

Kevin Gross

Media Network Consultant

AVA Networks - www.AVAnw.com <http://www.AVAnw.com>  <http://www.AVAnw.com>
, www.X192.org <http://www.X192.org>  <http://www.X192.org> 

  _____  

  _____

---

From: Alan Clark <[email-masked]>
Date: Wed, 16 Jan 2013 16:38:55 -0500

Hi Roni

That is correct.

With regard to the choice of reference point - this would typically be the
first packet however could also be based on a running average of the delay.
A jitter buffer does need to deal with timing drift, which could cause a
gradual empty or fill of the buffer, and also with delay
increases/reductions due to route changes - this can be addressed either by
detecting the condition and resetting the reference point or by using the
running average delay value.

Best Regards

Alan 

On 1/16/13 4:15 PM, "Roni Even" <[email-masked]> wrote:

> it does not matter what is the jitter buffer size, you are expecting to render
> or decode a packet if it arrives between 0 or 40 ms compared to the first
> packet. I assume for fixed buffer this will not change but for adaptive buffer
> the nominal delay may change.
> define the on-time insertion point or expected time. I believe you  are saying
> it is based on the first packet that arrives.
> Roni
>  
> 
> Jitter buffer size can be ambiguous as the term is sometimes used to mean the
> late window and sometimes the overall buffer size.
> 
> For example.
> 
> A jitter buffer is configured to have 200ms of overall buffer space. Initially
> packets are inserted into this at the 40ms point and hence incur 40ms of delay
> as they propagate to the 0ms ³read² point. If all the packets arrive with zero
> jitter they would all incur 40ms of delay within the buffer.
> 
> If a packet arrives 10ms later than expected then it is written to the buffer
> at the (40-10)ms point however if a packet arrives more than 40ms late then it
> is discarded.
> 
> If a packet arrives 50ms earlier than expected it is written to the (40+50)ms
> point and would wait 90ms before being played out.
> 
> being discarded then the insertion point for on-time packets could be moved to
> say 100ms. This results in the delay for on-time/ zero jitter packets being
> 100ms but would reduce the discard rate
> 
> <http://www.avanw.com/> , www.X192.org <http://www.X192.org>
> <http://www.X192.org>  <http://www.X192.org>
>  
> 
> <http://www.AVAnw.com> , www.X192.org <http://www.X192.org>
> <http://www.X192.org>  <http://www.X192.org>
>    
> 
> 
> 
>

---

From: Kevin Gross <[email-masked]>
Date: Wed, 16 Jan 2013 17:58:18 -0700

Qin and I talked last night (his morning) and we got to a place where I can
propose some changes. It looks like there's been more discussion on this
today. I'll also review that before proposing anything.

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

On Wed, Jan 16, 2013 at 3:36 AM, Romascanu, Dan (Dan) <[email-masked]>wrote:

>  Kevin, Qin,****
> ** **
> issues, or want to participate? ****
>
> ** **
>
> Dan****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Kevin Gross
> *Sent:* Tuesday, January 15, 2013 11:08 PM
>
> *To:* Qin Wu
> *Cc:* xrblock
> draft-ietf-xrblock-rtcp-xr-jb-02.txt****
>
>  ** **
>
> I think we need to have a phone call to discuss this whole thing.****
>
>
> ****
>
> Kevin Gross****
>
> +1-303-447-0517****
>
> Media Network Consultant****
>
> AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org****
>
> ** **
>
> On Mon, Jan 14, 2013 at 8:27 PM, Qin Wu <[email-masked]> wrote:****
>
> Hi,Kevin:****
>
> I like to make some additioal clarification to your question.****
>
> that has nominal delay.****
>
> So we have two ways to address this. ****
>
> information in the headers of previous ****
>
> can leave this to the specific****
>
>  implemenations. ****
>
>  ****
>
> b. we can explain the packet that arrives exactly on time as the packet
> that has nominal delay.****
>
> packet with minimal delay(i.e., ****
>
> average delay for all the packets that arrives****
>
> interval.****
> we prefer to add the following sentence in the draft to say:****
>
> 5.1 of [RFC5481 <http://tools.ietf.org/html/rfc5481>]).****
>
> "****
>
> Let me know what you think about this.****
>
>  ****
>
> Regards!****
>
> -Qin****
>
>   ----- Original Message ----- ****
>
> *From:* Qin Wu <[email-masked]> ****
>
> *To:* Kevin Gross <[email-masked]> ****
>
> *Cc:* xrblock <[email-masked]> ****
>
> *Sent:* Monday, January 14, 2013 8:46 AM****
>
> draft-ietf-xrblock-rtcp-xr-jb-02.txt****
>
> ** **
>
> Kevin:****
>
> that arrives exactly on time".****
>
> regarded as packet that arrives exactly on time.****
>
> Hope this clarifies.****
>
>  ****
>
> Regards!****
>
> -Qin****
>
>  ----- Original Message ----- ****
>
> *From:* Kevin Gross <[email-masked]> ****
>
> *To:* Qin Wu <[email-masked]> ****
>
> *Cc:* xrblock <[email-masked]> ****
>
> *Sent:* Sunday, January 13, 2013 6:04 AM****
>
> draft-ietf-xrblock-rtcp-xr-jb-02.txt****
>
> ** **
>
> Qin, ****
>
> ** **
>
> time for the packet that arrives exactly on time."****
>
> ** **
>
> exactly on time".****
> ****
> Kevin Gross****
> +1-303-447-0517****
> Media Network Consultant****
>
> AVA Networks - www.AVAnw.com, www.X192.org****
>
> ** **
>
> https://www.ietf.org/mailman/listinfo/xrblock****
>
>  ** **
>

---

From: Qin Wu <[email-masked]>
Date: Thu, 17 Jan 2013 17:03:04 +0800

Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txtHi,Alan:
Thank for your clarification.That's what I thought in my second proposal below, i.e., choose the reference point as the average delay for all the received packets during the measurement Interval.
I think the choosing the 1st packet received as the reference point is also reasonable.

Regards!
-Qin
  ----- Original Message ----- 
  From: Alan Clark 
  To: Roni Even ; Dan (Dan) ; 'Kevin Gross' ; Qin Wu 
  Cc: 'xrblock' 
  Sent: Thursday, January 17, 2013 5:38 AM
  Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt

  Hi Roni

  That is correct.

  With regard to the choice of reference point - this would typically be the first packet however could also be based on a running average of the delay.  A jitter buffer does need to deal with timing drift, which could cause a gradual empty or fill of the buffer, and also with delay increases/reductions due to route changes - this can be addressed either by detecting the condition and resetting the reference point or by using the running average delay value.

  Best Regards

  Alan 

    Hi Alan,
    If you insert the received packet at 40 ms and you are currently start  reading from 0 you are delaying by 40 ms and 40 ms is the nominal delay.  So it does not matter what is the jitter buffer size, you are expecting to render or decode a packet if it arrives between 0 or 40 ms compared to the first packet. I assume for fixed buffer this will not change but for adaptive buffer the nominal delay may change.
    I agree on the last sentence of your explanation, the question is how you define the on-time insertion point or expected time. I believe you  are saying it is based on the first packet that arrives.
    Roni

    Hi Roni

    Nominal delay is the delay that is applied to a packet that arrives at its expected time (i.e. 0 jitter) - and corresponds to the late window of the jitter buffer

    Jitter buffer size can be ambiguous as the term is sometimes used to mean the late window and sometimes the overall buffer size. 

    For example.

    A jitter buffer is configured to have 200ms of overall buffer space. Initially packets are inserted into this at the 40ms point and hence incur 40ms of delay as they propagate to the 0ms "read" point. If all the packets arrive with zero jitter they would all incur 40ms of delay within the buffer.

    If a packet arrives 10ms later than expected then it is written to the buffer at the (40-10)ms point however if a packet arrives more than 40ms late then it is discarded.

    If a packet arrives 50ms earlier than expected it is written to the (40+50)ms point and would wait 90ms before being played out.

    With an adaptive jitter buffer, If the jitter level is high and packets are being discarded then the insertion point for on-time packets could be moved to say 100ms. This results in the delay for on-time/ zero jitter packets being 100ms but would reduce the discard rate

    So the nominal delay is the time difference/ buffer size difference between the on-time insertion point and the point at which packets are read out and decoded.

    Regards

    Alan

    On 1/16/13 10:01 AM, "Roni Even" <[email-masked]> wrote:
    Hi Alan,
    I am not sure what applies a nominal delay means. Is the first packet defines the start of the jitter buffer and nominal delay is the size of the fixed jitter buffer.  
    When saying that the jitter buffer may increase or reduce is this for the adaptive jitter buffer?
     
    Roni

    From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan Clark
    Sent: 16 January, 2013 2:18 PM
    To: Dan (Dan); Kevin Gross; Qin Wu
    Cc: xrblock
    Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt

    A typical jitter buffer uses the first packet received as its timing reference, and applies a nominal delay to that before playing out.  During later operation, the jitter buffer may increase or reduce the nominal delay or may pick a new reference packet. This nominal delay represents the "late window" - so if a packet arrives more than "nominal delay ms" after its expected time then it will be discarded.

    "On time" - in this case - refers to the expected arrival time of the packet when calculated with reference to the first or a later selected reference packet.

    Jitter buffer implementations don't necessary do this mathematically however this is a generalized description that models the behavior of most jitter buffers used for VoIP and Videoconferencing.

    Playout buffers used in video streaming applications operate quite differently. Basically a received chunk of encoded video is added to the playout buffer - encoded video is read from the buffer. When the buffer level drops below a threshold then another chunk of video is requested from the server. There is an equivalent to "nominal delay" as the buffer will always try to make sure there is at least a minimal level of video in the buffer before playing out - however there would not be the equivalent of an "on time" packet.

    Regards

    Alan

     
    Dan

    Kevin Gross

    +1-303-447-0517

    Media Network Consultant

    AVA Networks - www.AVAnw.com <http://www.AVAnw.com>  <http://www.AVAnw.com>  <http://www.avanw.com/> , www.X192.org <http://www.X192.org>  <http://www.X192.org>  <http://www.X192.org> 

    Hi,Kevin:

    implemenations. 

    "Note that the reference packet is generally selected as the packet
     with minimum delay based on the most common criterion (see Sections 1 <http://tools.ietf.org/html/rfc6798#section-1>  and 5.1 of [RFC5481 <http://tools.ietf.org/html/rfc5481> ]).

    "

    Regards!

    -Qin

    ----- Original Message ----- 

    Kevin:

    Hope this clarifies.

    Regards!

    -Qin

    ----- Original Message ----- 

    Qin, 

    Kevin Gross

    Media Network Consultant

    AVA Networks - www.AVAnw.com <http://www.AVAnw.com>  <http://www.AVAnw.com>  <http://www.AVAnw.com> , www.X192.org <http://www.X192.org>  <http://www.X192.org>  <http://www.X192.org> 

----------------------------------------------------------------------------

----------------------------------------------------------------------------

---

From: Kevin Gross <[email-masked]>
Date: Thu, 17 Jan 2013 21:50:32 -0700

Thanks Alan for an explanation of what nominal delay is. I think we need to
add an explanation of this to the draft. I think we also need to add
an explanation of adaptive vs. fixed buffering. I propose the following
should be added after section 2. Warning: the following needs integration
and copy editing.

    <section title="Jitter Buffer Operation">
      <t>A jitter buffer is required to absorb delay variation in network
delivery of media packets. A jitter buffer works by holding media date for
a period of time after it is received but before it s played out. Packets
that arrive relatively early are held in the jitter buffer relatively
longer. Playout can fail if packets arrive too early and find
no available jitter buffer space to be held until time for playout. Playout
can also fail if packets are delayed excessively by the network and arrive
after they are scheduled to be played.</t>

      <t>Nominal playout delay is the difference between the time the media
data is generated and when it is played. Nominal
playout delay must accommodate delays in the sender, delays in the network
and delay in the receiver. Selection of nominal playout delay is critical
for reliable playout. When nominal playout delay is too short, reasonably
expected delays in the network may cause media data to arrive after it is
scheduled to be played out rendering it unusable. If playout delay is
large, a generous amount of buffering is required in receivers to hold
media data that arrives promptly. Large playout delays may unnecessarily
delay media playback causing long delays that are detrimental for some
applications - live closed-circuit systems, for example.</t>

      <section title="Fixed Jitter Buffer">
        <t>A receiver can use either a fixed or adaptive playout delay
selection. A fixed playout delay is a simple implementation but may not do
a good job of accommodating varying network performance. A fixed playout
delay also may require extra buffer memory and media latency compared to an
adaptive implementation.</t>

        <t>The fixed value for the playout delay is chosen through device
configuration or may be determined and fixed by the timing of delivery of
the first packet(s) of stream data.</t>
      </section>

      <section title="Adaptive Jitter Buffer">
        <t>An adaptive jitter buffer may adjust nominal playout delay
during playback in response to changing sender or network performance.
Playout delay is typically adjusted to minimize media latency
while also minimizing of lost data due to packets arriving to early or too
late. The change in playout delay can be made instantly by introducing a
discontinuity in media playout or gradually by adjusting the rate of
playout over a period of time,</t>
      </section>
    </section>

This is a start. The definitions in section 3 for how to actually measure
nominal playout delay and specify jitter buffer maximum delay needs some
work. A contribution from me on that will have to wait until another day.
Perhaps one of the authors in the meantime has time to revise these to
describe something that can be unambiguously implemented. As it stands now,
I don't believe the specification is specific enough to foster
interoperable reporting. e.g. there is no definition of "exactly on time".

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

On Thu, Jan 17, 2013 at 2:03 AM, Qin Wu <[email-masked]> wrote:

> **
> Hi,Alan:
> Thank for your clarification.That's what I thought in my second proposal
> below, i.e., choose the reference point as the average delay for all the
> received packets during the measurement Interval.
> *From:* Alan Clark <[email-masked]>
> *To:* Roni Even <[email-masked]> ; Dan (Dan) <[email-masked]>; 'Kevin
> Gross' <[email-masked]> ; Qin Wu <[email-masked]>
> *Cc:* 'xrblock' <[email-masked]>
> *Sent:* Thursday, January 17, 2013 5:38 AM
>  reading from 0 you are delaying by 40 ms and 40 ms is the nominal delay.
>  So it does not matter what is the jitter buffer size, you are expecting to
> *From:* Alan Clark [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* 16 January, 2013 6:29 PM
> *To:* Roni Even; Dan (Dan); 'Kevin Gross'; Qin Wu
> *Cc:* 'xrblock'
> 40ms of delay as they propagate to the 0ms “read” point. If all the packets
> With an adaptive jitter buffer, If the jitter level is high and packets
> are being discarded then the insertion point for on-time packets could be
> moved to say 100ms. This results in the delay for on-time/ zero jitter
> packets being 100ms but would reduce the discard rate
>
> So the nominal delay is the time difference/ buffer size difference
> between the on-time insertion point and the point at which packets are read
> out and decoded.
>
> Regards
>
> Alan
>
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Alan Clark
> *Sent:* 16 January, 2013 2:18 PM
> *To:* Dan (Dan); Kevin Gross; Qin Wu
> *Cc:* xrblock
> or may pick a new reference packet. This nominal delay represents the “late
> window” - so if a packet arrives more than “nominal delay ms” after its
> “On time” - in this case - refers to the expected arrival time of the
> packet when calculated with reference to the first or a later selected
> reference packet.
>
> Jitter buffer implementations don’t necessary do this mathematically
> however this is a generalized description that models the behavior of most
> jitter buffers used for VoIP and Videoconferencing.
>
> the server. There is an equivalent to “nominal delay” as the buffer will
> “on time” packet.
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Kevin Gross
>  <http://www.avanw.com/> , www.X192.org <http://www.X192.org>  <
> http://www.X192.org>  <http://www.X192.org>
>
>
>  with minimum delay based on the most common criterion (see Sections 1 <
> http://tools.ietf.org/html/rfc6798#section-1>  and 5.1 of [RFC5481 <
> http://tools.ietf.org/html/rfc5481> ]).
>
> "
>
> *From:* Qin Wu <mailto:[email-masked] <[email-masked]>>
>
> *To:* Kevin Gross <mailto:[email-masked] <[email-masked]>>
>
> *Cc:* xrblock <mailto:[email-masked] <[email-masked]>>
>
> *From:* Kevin Gross <mailto:[email-masked] <[email-masked]>>
>
>
> *To:* Qin Wu <mailto:[email-masked] <[email-masked]>>
>
> *Cc:* xrblock <mailto:[email-masked] <[email-masked]>>
>
>  <http://www.AVAnw.com> , www.X192.org <http://www.X192.org>  <
> http://www.X192.org>  <http://www.X192.org>
>
>

---

From: Qin Wu <[email-masked]>
Date: Mon, 21 Jan 2013 15:00:36 +0800

Hi,Kevin:
Thank for your proposed text below.
It looks to me the playout delay is not right term for jitter buffer metric, It is not clear to me the playout delay should be part of jitter buffer delay or jitter buffer should be adjusted in response to
the playout rate.
Also I am aware "the playout delay" you proposed here a little contradicts with what Alan said in this thread as follows:
"
Playout buffers used in video streaming applications operate quite differently. Basically a received chunk of encoded video is added to the playout buffer - encoded video is read from the buffer. When the buffer level drops below a threshold then another chunk of video is requested from the server. There is an equivalent to �nominal delay� as the buffer will always try to make sure there is at least a minimal level of video in the buffer before playing out - however there would not be the equivalent of an �on time� packet.

"
Taking both Alan's clarification and your proposed text, I like to propose to add the following section based on your proposed text as follows if we think something is really needed:
"
x.Jitter Buffer Operation

  A jitter buffer is required to absorb delay variation in network delivery of media packets. A jitter buffer works by holding media data for a period of time after it is received but before it s played out. Packets that arrive relatively early are held in the jitter buffer relatively longer. Playout can fail if packets arrive too early and find no available jitter buffer space to be held until time for playout. Playout can also fail if packets are delayed excessively by the network and arrive too late after they are scheduled to be played.

  The jitter buffer can be considered as a time window with one side (the early side) aligned with the delay corresponding to the early arriving packet and the other side (the late side) representing the maximum permissible delay before a late arriving packet would be discarded. The Jitter Buffer delay is the difference between the time the media data is inserted into the jitter buffer and when it is played. 

When a packet arrives at its expected time (i.e. 0 jitter or falling between left window and right window ), we also call this packet as the packet that arrives exactly on time. The jitter buffer nominal delay calculation relies on the packet that arrives at its expected time, i.e.,the reference packet. The reference packet would typically be the first packet however could also be based on a running average of the delay.The Jitter Buffer Nominal delay is the delay that is applied to a packet that arrives at its expected time (i.e. 0 jitter) - and corresponds to the late window of the jitter buffer. The Jitter buffer maximum delay is the delay that is applied to an earliest arriving packet that is not discarded and corresponds to the early window of the jitter buffer. 

x.1 Fixed Jitter Buffer

  A receiver can use either a fixed or adaptive jitter buffer method. A fixed jitter buffer method is a simple implementation with the fixed jitter buffer size but may not do a good job of accommodating varying network performance. The delay of fixed jitter buffer also may have too big buffer memory and therefore incur extra media latency compared to an adaptive implementation.

x.2 Adaptive Jitter Buffer

  An adaptive jitter buffer method has adaptive jitter buffer size and may adjust nominal jitter buffer delay during playback in response to changing network performance. The jitter buffer delay is typically adjusted to minimize media latency while also minimizing of lost data due to packets arriving too early or too late. 

"
Which also explain what the exactly on time means.

Regards!
-Qin
  ----- Original Message ----- 
  From: Kevin Gross 
  To: Qin Wu 
  Cc: Alan Clark ; Roni Even ; Dan (Dan) ; xrblock 
  Sent: Friday, January 18, 2013 12:50 PM
  Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt

  Thanks Alan for an explanation of what nominal delay is. I think we need to add an explanation of this to the draft. I think we also need to add an explanation of adaptive vs. fixed buffering. I propose the following should be added after section 2. Warning: the following needs integration and copy editing.

      <section title="Jitter Buffer Operation">
        <t>A jitter buffer is required to absorb delay variation in network delivery of media packets. A jitter buffer works by holding media date for a period of time after it is received but before it s played out. Packets that arrive relatively early are held in the jitter buffer relatively longer. Playout can fail if packets arrive too early and find no available jitter buffer space to be held until time for playout. Playout can also fail if packets are delayed excessively by the network and arrive after they are scheduled to be played.</t>
        
        <t>Nominal playout delay is the difference between the time the media data is generated and when it is played. Nominal playout delay must accommodate delays in the sender, delays in the network and delay in the receiver. Selection of nominal playout delay is critical for reliable playout. When nominal playout delay is too short, reasonably expected delays in the network may cause media data to arrive after it is scheduled to be played out rendering it unusable. If playout delay is large, a generous amount of buffering is required in receivers to hold media data that arrives promptly. Large playout delays may unnecessarily delay media playback causing long delays that are detrimental for some applications - live closed-circuit systems, for example.</t>
        
        <section title="Fixed Jitter Buffer">
          <t>A receiver can use either a fixed or adaptive playout delay selection. A fixed playout delay is a simple implementation but may not do a good job of accommodating varying network performance. A fixed playout delay also may require extra buffer memory and media latency compared to an adaptive implementation.</t>
        
          <t>The fixed value for the playout delay is chosen through device configuration or may be determined and fixed by the timing of delivery of the first packet(s) of stream data.</t>
        </section>
        
        <section title="Adaptive Jitter Buffer">
          <t>An adaptive jitter buffer may adjust nominal playout delay during playback in response to changing sender or network performance. Playout delay is typically adjusted to minimize media latency while also minimizing of lost data due to packets arriving to early or too late. The change in playout delay can be made instantly by introducing a discontinuity in media playout or gradually by adjusting the rate of playout over a period of time,</t>
        </section>
      </section>

  This is a start. The definitions in section 3 for how to actually measure nominal playout delay and specify jitter buffer maximum delay needs some work. A contribution from me on that will have to wait until another day. Perhaps one of the authors in the meantime has time to revise these to describe something that can be unambiguously implemented. As it stands now, I don't believe the specification is specific enough to foster interoperable reporting. e.g. there is no definition of "exactly on time".

  Kevin Gross

  +1-303-447-0517
  Media Network Consultant

    Hi,Alan:

    Regards!
    -Qin
      ----- Original Message ----- 
      From: Alan Clark 
      To: Roni Even ; Dan (Dan) ; 'Kevin Gross' ; Qin Wu 
      Cc: 'xrblock' 
      Sent: Thursday, January 17, 2013 5:38 AM
      Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt

      Hi Roni

      That is correct.

      Best Regards

      Alan 

        Hi Alan,

        Hi Roni

        For example.

        A jitter buffer is configured to have 200ms of overall buffer space. Initially packets are inserted into this at the 40ms point and hence incur 40ms of delay as they propagate to the 0ms “read” point. If all the packets arrive with zero jitter they would all incur 40ms of delay within the buffer.

        Regards

        Alan

        Roni

        A typical jitter buffer uses the first packet received as its timing reference, and applies a nominal delay to that before playing out.  During later operation, the jitter buffer may increase or reduce the nominal delay or may pick a new reference packet. This nominal delay represents the “late window” - so if a packet arrives more than “nominal delay ms” after its expected time then it will be discarded.

        “On time” - in this case - refers to the expected arrival time of the packet when calculated with reference to the first or a later selected reference packet.

        Jitter buffer implementations don’t necessary do this mathematically however this is a generalized description that models the behavior of most jitter buffers used for VoIP and Videoconferencing.

        Playout buffers used in video streaming applications operate quite differently. Basically a received chunk of encoded video is added to the playout buffer - encoded video is read from the buffer. When the buffer level drops below a threshold then another chunk of video is requested from the server. There is an equivalent to “nominal delay” as the buffer will always try to make sure there is at least a minimal level of video in the buffer before playing out - however there would not be the equivalent of an “on time” packet.

        Regards

        Alan

         
        Dan

        Kevin Gross

        +1-303-447-0517

        Media Network Consultant

        Hi,Kevin:

        implemenations. 

        "

        Regards!

        -Qin

        ----- Original Message ----- 

        Kevin:

        Hope this clarifies.

        Regards!

        -Qin

        ----- Original Message ----- 

        Qin, 

        Kevin Gross

        Media Network Consultant

------------------------------------------------------------------------

------------------------------------------------------------------------