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

From: Kevin Gross <[email-masked]>
Date: Thu, 7 Mar 2013 10:22:48 -0700

In some implementations, nominal delay is a static receiver property. It is
the quantity D in your idealized implementation.* It would be helpful to
add some of this detail to the draft. The bigger issue I am having is that
the draft does not define how to do the reporting for a more realistic
implementation or for an adaptive jitter buffer.

*This implementation compares a sender clock (RTP timestamps) with a
receiver clock (packet receive timestamp). In many systems, these clocks
run independently. It wont be long until r <> t, not necessarily because
packets are arriving early or late, but because the sender and receiver
clocks have drifted with respect to one another.

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

On Mon, Mar 4, 2013 at 2:28 PM, Alan Clark <[email-masked]>wrote:

>  Kevin
>
> The nominal delay in this case is the (additional) delay applied by the
> jitter buffer and hence is not affected by network delay (although for an
> adaptive jitter buffer could be affected by delay variation).
>
> Overall user perceived delay = network round trip delay + local (jitter
> buffer (nominal) delay + encoder serialization delay) + remote  (jitter
> buffer (nominal) delay + encoder serialization delay)
>
> An idealized jitter buffer could do the following:-
>
> (i) Receive the first packet and delay playout by D ms. Keep the RTP
> timestamp and receive time as a reference.
> RTP TS[1]
> receive time[1]
> Assume that both are normalized in ticks
>
> (ii) Receive the next packet
>
> (iii) Calculate  r = RTP TS[n] - RTP TS[1] and t = receive time[n] -
> receive time[1].  If r = t then the packet arrived on time. If r < t then
> the packet arrived late and if r > t then the packet arrived early.
>
> (iv) Delay playout of packet by D + (r -t)
>
> (v) Go back to (ii)
>
> In practice jitter buffer implementations vary considerably however should
> behave in a manner consistent with the above.
>
> Best Regards
>
> Alan
>
>
> On 3/4/13 3:28 PM, "Kevin Gross" <[email-masked]> wrote:
>
> Thank you Alan. In the context of your explanation, I have read the
> section more carefully and I agree that there is no inconsistency in the
> definitions. I still feel there is a problem and I'm sorry if it feels like
> I am leading this conversation in circles.
>
> The real question is how do receivers report "nominal delay" in a
> consistent manner. From the information provided in the draft, I can see at
> least three possible implementations for measuring nominal delay:
>
>    1. The difference between average arrival time for all packets and
>    playout time
>    2. The difference between arrival time and playout time for the first
>    packet
>    3. The difference between arrival time and playout time on an ideal
>    network without delay variation
>
> On most networks delay variation is caused by queuing delays and this
> increases average delay while increasing delay variation. I don't see how
> these different approaches would yield similar results.
>
> 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>
>
>
> On Mon, Mar 4, 2013 at 11:06 AM, Alan Clark <[email-masked]>
> wrote:
>
> It is incorrect to state that if packets arrive on-time *“there are no
> late packets and everything should arrive before the expected arrival time
> and most likely at early window”
> *
> On time packets are delayed by the nominal delay (= late window) and by
> definition “on-time” means arriving “at the expected arrival time”.  If the
> jitter buffer is configured to use a 20ms nominal delay - then packets that
> arrive on-time are delayed by 20ms before being played out.  If a packet
> arrives 10ms early it will be delayed by 30ms before being played out, and
> if the packet arrives 5ms late then it will be delayed by 15ms before being
> played out.
>
> The definition in the draft is correct
>
> Best Regards
>
> Alan
>
>
>
>
> On 3/4/13 1:38 AM, "Qin Wu" <[email-masked] <http://[email-masked]>
> > wrote:
>
> *发件人:* Kevin Gross [mailto:[email-masked] <[email-masked]>]
> *发送时间:* 2013年3月4日 14:02
> *收件人:* Qin Wu
> *抄送:* [email-masked] <http://[email-masked]> ; Alan Clark
>
> *主题:* Re: 答复: Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-08.txt
>
> Responses below.
>
>
> On Sun, Mar 3, 2013 at 7:58 PM, Qin Wu <[email-masked] <
> http://[email-masked]> > wrote:
>
>
> Hi, Kevin:
> Please see my clarification below.
> Alan, please correct me if I am wrong.
>
> Regards!
> -Qin
>
> *发件人:* Kevin Gross [mailto:[email-masked] <[email-masked]>]
> *发送时间:* 2013年3月4日 6:13
> *收件人:* Qin Wu
> *抄送:* [email-masked] <http://[email-masked]> ; Alan Clark
>
> *主题:* Re: Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-08.txt
>
>
> I'm afraid we're still not there. There is trouble in section 3:
>
>    The jitter buffer can be considered as a time window with one side
>    (the early window) aligned with the delay corresponding to the
>    earliest arriving packet and the other side (the late window)
>    representing the maximum permissible delay before a late arriving
>    packet would be discarded.  The delay applied to packets that arrive
>    at their expected time is known as the Nominal Delay and this is
>    equivalent to the late window.
>
>    The "expected arrival time" is the time that a packet would arrive if
>    there was no delay variation.  If all packets arrived at their
>    expected arrival time then every packet would be delayed by exactly
>    the Nominal Delay.  Early packets arrive before their expected
>    arrival time and late packets arrive after.  The reference for the
>    expected arrival time may, for example, be the first packet in the
>    session or the running average delay.
> Nominal delay is defined in the first paragraph as the delay inserted for
> the latest arriving playable packet. I believe this is a reasonable
> definition.
> [Qin]: Agree.
>
> The definition of expected arrival time is in error. If there is no delay
> variation, there are no late packets and everything should arrive before
> the expected arrival time and most likely at early window.
> I suggest expected arrival time should be the same as late window.
>
> [Qin]: I think “no delay variation” means packet arrives on time or the
> received packet, comparing with the reference packet, is neither a late
> packet nor a early packet.
> So I think the intention here for the definition of expected arrive time
> is to emphasize the delay variation is zero by comparing with the reference
> packet,
> So maybe we can do a little rewording to say:
> “
>   The "expected arrival time" is the time that a packet would arrive as if
>    there was no delay variation.
> “
>
>
>
>
> [kg] Changing "if" to "as if" does not significantly clarify or change the
> meaning of the sentence. Are you saying you believe this paragraph is
> basically clear and correct as it stands?
>
>
> [Qin]: yes, I think it stands, what I clarify here is delay variation of
> one packet is calculated with reference to the reference packet, e.g.,the
> first packet.
>
>
> .
>
> I also find the "window", "early window", "late window" terminology
> unclear. Early window and late window are actually the edges of a single
> receive buffering "window".
>
> [Qin]: “Window” means time window or time segment not time instance or xxx
> millisecond (ms) point. You may look at section 4.1, 2nd paragraph of the
> following URL:
> http://www.voiptroubleshooter.com/indepth/jittersources.html
> which give a clear definition of time window we are talking about here.
>
>
>
>
> [kg] I believe I understand what the draft is trying to say. My comment is
> that the draft does not say it clearly (i.e there is one window, not
> three). The draft needs to be clarified.
>
>
>
> [Qin]:  Yes, you are correct, it is not suppose to define three window.
> How about rephrase the 2nd paragraph of section 3 as follows:
> OLD TEXT:
> “
>    The jitter buffer can be considered as a time window with one side
>    (the early window) aligned with the delay corresponding to the
>    earliest arriving packet and the other side (the late window)
>    representing the maximum permissible delay before a late arriving
>    packet would be discarded.  The delay applied to packets that arrive
>    at their expected time is known as the Nominal Delay and this is
>    equivalent to the late window.
> ”
> NEW TEXT:
> “
>    The jitter buffer can be considered as a time window with one side
>    (the early side corresponding to left half window or early window)
> aligned with the delay corresponding to the
>    earliest arriving packet and the other side (the late side
> corresponding to right half window or late window)
>    representing the maximum permissible delay before a late arriving
>    packet would be discarded.  The delay applied to packets that arrive
>    at their expected time is known as the Nominal Delay and this is
>    equivalent to the late window.
>
> ”
>
>
>
>
>
>
> I have not done a comprehensive re-review. There are possibly other
> problems in this short draft.
>
>
> Kevin Gross
>
> +1-303-447-0517 <tel:%2B1-303-447-0517>  <tel:%2B1-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>
>
>
> On Sun, Feb 24, 2013 at 6:28 PM, Qin Wu <[email-masked] <
> http://[email-masked]> > wrote:
>
> On 23 February , 2012 10:40 PM, [email-masked] <
> http://[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-08.txt
> > Pages           : 17
> > Date            : 2013-02-23
> >
> > 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
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-jb-08
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=draft-ietf-xrblock-rtcp-xr-jb-08
> [Qin]: Here is our another update to JB draft. In this version (-08),
> We rewrote descriptive text and definitions for clarification, thanks for
> Alan's proposed text change.
>
> Kevin: Would you like to take a look this version and see if your comments
> are addressed.
>
>
>
>
>
>
>

---

From: Qin Wu <[email-masked]>
Date: Sun, 10 Mar 2013 01:15:03 +0000

发件人: Kevin Gross [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
发送时间: 2013年3月8日 1:23
收件人: Alan Clark
抄送: Qin Wu; [email-masked]<mailto:[email-masked]>
主题: Re: 答复: 答复: Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-08.txt

In some implementations, nominal delay is a static receiver property. It is the quantity D in your idealized implementation.* It would be helpful to add some of this detail to the draft. The bigger issue I am having is that the draft does not define how to do the reporting for a more realistic implementation or for an adaptive jitter buffer.

[Qin]: I would say the method described by Alan applies to both fixed jitter buffer and adaptive jitter buffer since delay variance has already been represented using r-t, which is similar to calculation of “the difference in the "relative transit time" for the two packets” defined in section 6.4.1 of RFC3550.

*This implementation compares a sender clock (RTP timestamps) with a receiver clock (packet receive timestamp). In many systems, these clocks run independently. It wont be long until r <> t, not necessarily because packets are arriving early or late, but because the sender and receiver clocks have drifted with respect to one another.

[Qin]: I don’t believe jitter buffer delay should be affected by clock synchronization since the report value is more about relative value comparing with the reference packet.

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, Mar 4, 2013 at 2:28 PM, Alan Clark <[email-masked]<mailto:[email-masked]>> wrote:
Kevin

The nominal delay in this case is the (additional) delay applied by the jitter buffer and hence is not affected by network delay (although for an adaptive jitter buffer could be affected by delay variation).

Overall user perceived delay = network round trip delay + local (jitter buffer (nominal) delay + encoder serialization delay) + remote  (jitter buffer (nominal) delay + encoder serialization delay)

(i) Receive the first packet and delay playout by D ms. Keep the RTP timestamp and receive time as a reference.
RTP TS[1]
receive time[1]
Assume that both are normalized in ticks

(iii) Calculate  r = RTP TS[n] - RTP TS[1] and t = receive time[n] - receive time[1].  If r = t then the packet arrived on time. If r < t then the packet arrived late and if r > t then the packet arrived early.

(v) Go back to (ii)

In practice jitter buffer implementations vary considerably however should behave in a manner consistent with the above.

Best Regards

Alan

On 3/4/13 3:28 PM, "Kevin Gross" <[email-masked]<http://[email-masked]>> wrote:
Thank you Alan. In the context of your explanation, I have read the section more carefully and I agree that there is no inconsistency in the definitions. I still feel there is a problem and I'm sorry if it feels like I am leading this conversation in circles.

The real question is how do receivers report "nominal delay" in a consistent manner. From the information provided in the draft, I can see at least three possible implementations for measuring nominal delay:

  1.  The difference between average arrival time for all packets and playout time
  2.  The difference between arrival time and playout time for the first packet
  3.  The difference between arrival time and playout time on an ideal network without delay variation
On most networks delay variation is caused by queuing delays and this increases average delay while increasing delay variation. I don't see how these different approaches would yield similar results.

Kevin Gross
+1-303-447-0517<tel:%2B1-303-447-0517> <tel:%2B1-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>

On Mon, Mar 4, 2013 at 11:06 AM, Alan Clark <[email-masked]<http://[email-masked]>> wrote:
It is incorrect to state that if packets arrive on-time “there are no late packets and everything should arrive before the expected arrival time and most likely at early window”

On time packets are delayed by the nominal delay (= late window) and by definition “on-time” means arriving “at the expected arrival time”.  If the jitter buffer is configured to use a 20ms nominal delay - then packets that arrive on-time are delayed by 20ms before being played out.  If a packet arrives 10ms early it will be delayed by 30ms before being played out, and if the packet arrives 5ms late then it will be delayed by 15ms before being played out.

Best Regards

Alan

On 3/4/13 1:38 AM, "Qin Wu" <[email-masked]<http://[email-masked]> <http://[email-masked]> > wrote:
发件人: Kevin Gross [mailto:[email-masked]]
发送时间: 2013年3月4日 14:02
收件人: Qin Wu
抄送: [email-masked]<http://[email-masked]> <http://[email-masked]> ; Alan Clark

主题: Re: 答复: Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-08.txt

Responses below.

On Sun, Mar 3, 2013 at 7:58 PM, Qin Wu <[email-masked]<http://[email-masked]> <http://[email-masked]> > wrote:

Hi, Kevin:

Regards!
-Qin
发件人: Kevin Gross [mailto:[email-masked]]
发送时间: 2013年3月4日 6:13
收件人: Qin Wu
抄送: [email-masked]<http://[email-masked]> <http://[email-masked]> ; Alan Clark

主题: Re: Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-08.txt

Nominal delay is defined in the first paragraph as the delay inserted for the latest arriving playable packet. I believe this is a reasonable definition.
[Qin]: Agree.

The definition of expected arrival time is in error. If there is no delay variation, there are no late packets and everything should arrive before the expected arrival time and most likely at early window.
I suggest expected arrival time should be the same as late window.

[Qin]: I think “no delay variation” means packet arrives on time or the received packet, comparing with the reference packet, is neither a late packet nor a early packet.
So I think the intention here for the definition of expected arrive time is to emphasize the delay variation is zero by comparing with the reference packet,
So maybe we can do a little rewording to say:
“
 The "expected arrival time" is the time that a packet would arrive as if
  there was no delay variation.
“

[kg] Changing "if" to "as if" does not significantly clarify or change the meaning of the sentence. Are you saying you believe this paragraph is basically clear and correct as it stands?

[Qin]: yes, I think it stands, what I clarify here is delay variation of one packet is calculated with reference to the reference packet, e.g.,the first packet.

.

I also find the "window", "early window", "late window" terminology unclear. Early window and late window are actually the edges of a single receive buffering "window".

[Qin]: “Window” means time window or time segment not time instance or xxx millisecond (ms) point. You may look at section 4.1, 2nd paragraph of the following URL:
http://www.voiptroubleshooter.com/indepth/jittersources.html
which give a clear definition of time window we are talking about here.

[kg] I believe I understand what the draft is trying to say. My comment is that the draft does not say it clearly (i.e there is one window, not three). The draft needs to be clarified.

[Qin]:  Yes, you are correct, it is not suppose to define three window. How about rephrase the 2nd paragraph of section 3 as follows:
OLD TEXT:
“
   The jitter buffer can be considered as a time window with one side
   (the early window) aligned with the delay corresponding to the
   earliest arriving packet and the other side (the late window)
   representing the maximum permissible delay before a late arriving
   packet would be discarded.  The delay applied to packets that arrive
   at their expected time is known as the Nominal Delay and this is
   equivalent to the late window.
”
NEW TEXT:
“
  The jitter buffer can be considered as a time window with one side
   (the early side corresponding to left half window or early window) aligned with the delay corresponding to the
   earliest arriving packet and the other side (the late side corresponding to right half window or late window)
   representing the maximum permissible delay before a late arriving
   packet would be discarded.  The delay applied to packets that arrive
   at their expected time is known as the Nominal Delay and this is
   equivalent to the late window.

”

I have not done a comprehensive re-review. There are possibly other problems in this short draft.

Kevin Gross
+1-303-447-0517<tel:%2B1-303-447-0517> <tel:%2B1-303-447-0517>  <tel:%2B1-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>

On Sun, Feb 24, 2013 at 6:28 PM, Qin Wu <[email-masked]<http://[email-masked]> <http://[email-masked]> > wrote:

On 23 February , 2012 10:40 PM, [email-masked]<http://[email-masked]> <http://[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

Kevin: Would you like to take a look this version and see if your comments are addressed.

---

From: Qin Wu <[email-masked]>
Date: Fri, 15 Mar 2013 23:55:23 +0000

Hi,Kevin:
Thank for your proposed change. We authors of this draft all think the change is reasonable.
I have incorporated your proposed text to the (-v09).

http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-jb-09

To chairs: Dan and Shida, we think this version has resolved the issue and is ready for WGLC.

Regards!
-Qin
发件人: Kevin Gross [mailto:[email-masked]]
发送时间: 2013年3月14日 11:07
收件人: Qin Wu
抄送: Alan Clark; [email-masked]
主题: Re: 答复: 答复: 答复: Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-08.txt

I met with Qin yesterday to try and find a quick way through this. The idea we came up with was to include the jitter buffer model Alan posted a couple messages back into the draft and use that as a reference point for Nominal Delay reporting. Because of the numerous ways in which a jitter buffer may be implemented, we're not going to be able to a achieve fully interoperable reporting. The goal of the proposed revisions are to make users and implementers aware of these limitations. I've attached rough text implementing this idea.

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

On Sat, Mar 9, 2013 at 8:15 PM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:
发件人: Kevin Gross [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
发送时间: 2013年3月8日 1:23
收件人: Alan Clark
抄送: Qin Wu; [email-masked]<mailto:[email-masked]>
主题: Re: 答复: 答复: Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-08.txt

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>

(v) Go back to (ii)

Best Regards

Alan

Kevin Gross

Best Regards

Alan

Responses below.

Hi, Kevin:

Regards!
-Qin

.

”

Kevin Gross

Media Network Consultant

---

From: Qin Wu <[email-masked]>
Date: Wed, 20 Mar 2013 20:45:37 +0800

Hi,Kevin:
Thank for your quick checking.
Please see my reply inline.

Regards!
-Qin
  ----- Original Message ----- 
  From: Kevin Gross 
  To: Qin Wu 
  Cc: Alan Clark ; [email-masked] ; Romascanu, Dan (Dan) ; Shida Schubert 
  Sent: Sunday, March 17, 2013 6:10 AM
  Subject: Re: 答复: 答复: 答复: 答复: Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-08.txt

  I said my contributions were rough and it doesn't look like they were improved much in the new revision.

  Section 3

  "The delay applied to
   packets that arrive at their expected time is known as the Nominal
   Delay and this is equivalent to the late edge."Nominal delay is not equivalent to late edge.[Qin]: Please refer to example provide by Alan in Jan 16,2013 when clarifing to Roni on what nominal delay means.http://www.ietf.org/mail-archive/web/xrblock/current/msg01090.htmlOne sentence in Alan's example I highlighted here is:"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."So the nominal delay is equivalent to the time difference between the expected arrival time and the time when a late arriving packet is consumed.or we can say nominal delay is equivalent to late edge, what am I missing?Section 3.2"The fixed jitter buffers have a fixed size and the packets leaving
   the jitter buffer have a constant delay."There is just one jitter buffer and we need a bit more elaboration on how a fixed jitter buffer is used, its limitations and how maximum delay and nominal delay are reported for it.[Qin]: I believe these have been explained in the Definition of Fields in Jitter Buffer Metrics Block of section 4.2.Section 3.3"An adaptive jitter buffer have variable size and variable delay."Fix grammar. Change "and" to "or" or "and/or".[Qin]: Agree, thanks.Kevin Gross

  +1-303-447-0517
  Media Network Consultant

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

  On Fri, Mar 15, 2013 at 5:55 PM, Qin Wu <[email-masked]> wrote:

    Hi,Kevin:

    Regards!

    -Qin

    发送时间: 2013年3月14日 11:07
    收件人: Qin Wu

    Kevin Gross

    +1-303-447-0517

    Media Network Consultant

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

    On Sat, Mar 9, 2013 at 8:15 PM, Qin Wu <[email-masked]> wrote:

    发送时间: 2013年3月8日 1:23
    收件人: Alan Clark
    抄送: Qin Wu; [email-masked]
    主题: Re: 答复: 答复: Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-08.txt

    Kevin Gross

    +1-303-447-0517

    Media Network Consultant

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

    On Mon, Mar 4, 2013 at 2:28 PM, Alan Clark <[email-masked]> wrote:

    Kevin

    (v) Go back to (ii)

    Best Regards

    Alan

        1.. The difference between average arrival time for all packets and playout time 
        2.. The difference between arrival time and playout time for the first packet 
        3.. The difference between arrival time and playout time on an ideal network without delay variation 
      On most networks delay variation is caused by queuing delays and this increases average delay while increasing delay variation. I don't see how these different approaches would yield similar results.

      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> 

      On Mon, Mar 4, 2013 at 11:06 AM, Alan Clark <[email-masked]> wrote:

        Best Regards

        Alan

        On 3/4/13 1:38 AM, "Qin Wu" <[email-masked] <http://[email-masked]> > wrote:

          抄送: [email-masked] <http://[email-masked]> ; Alan Clark

          Responses below.

          On Sun, Mar 3, 2013 at 7:58 PM, Qin Wu <[email-masked] <http://[email-masked]> > wrote:

            Hi, Kevin:
             
            Regards!
            -Qin

            抄送: [email-masked] <http://[email-masked]> ; Alan Clark

             

          .

            ”

            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> 

            On Sun, Feb 24, 2013 at 6:28 PM, Qin Wu <[email-masked] <http://[email-masked]> > wrote: