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

[Kevin Gross <[e-mail]>]

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
[phone]
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 <[e-mail]>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" <[e-mail]> 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
> [phone] <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 <[e-mail]>
> 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" <[e-mail] <http://[e-mail]>
> > wrote:
>
> *发件人:* Kevin Gross [mailto:[e-mail] <[e-mail]>]
> *发送时间:* 2013年3月4日 14:02
> *收件人:* Qin Wu
> *抄送:* [e-mail] <http://[e-mail]> ; 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 <[e-mail] <
> http://[e-mail]> > wrote:
>
>
> Hi, Kevin:
> Please see my clarification below.
> Alan, please correct me if I am wrong.
>
> Regards!
> -Qin
>
> *发件人:* Kevin Gross [mailto:[e-mail] <[e-mail]>]
> *发送时间:* 2013年3月4日 6:13
> *收件人:* Qin Wu
> *抄送:* [e-mail] <http://[e-mail]> ; 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
>
> [phone] <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 <[e-mail] <
> http://[e-mail]> > wrote:
>
> On 23 February , 2012 10:40 PM, [e-mail] <
> http://[e-mail]>  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.
>
>
>
>
>
>
>