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

Kevin Gross <kevin.gross@avanw.com> Thu, 07 March 2013 17:23 UTC

Return-Path: <kevin.gross@avanw.com>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C4E21F8BE7 for <xrblock@ietfa.amsl.com>; Thu, 7 Mar 2013 09:23:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.941
X-Spam-Level: ****
X-Spam-Status: No, score=4.941 tagged_above=-999 required=5 tests=[AWL=-0.712, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0TnSCvRYVpo for <xrblock@ietfa.amsl.com>; Thu, 7 Mar 2013 09:23:15 -0800 (PST)
Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 0868321F8A05 for <xrblock@ietf.org>; Thu, 7 Mar 2013 09:23:11 -0800 (PST)
Received: (qmail 27136 invoked by uid 0); 7 Mar 2013 17:22:50 -0000
Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by cpoproxy2.bluehost.com with SMTP; 7 Mar 2013 17:22:50 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=HnJRB0XV8wrhkX9dv8tLZgZGaT1W/ehF8ayBfc8p8Hg=; b=GdXGABgypflG3KyDq3xd8M3vCYTHtOyOq/1ook2VouwLClMtHphlpVJ75TvQXtUjVCMTZJFn1LJvOhLO2xSEokFvU35whAKVKrt1UH7H4ci9+AOwB7DOP3XLMk/aFQm/;
Received: from [209.85.210.170] (port=36744 helo=mail-ia0-f170.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from <kevin.gross@avanw.com>) id 1UDeWo-0003vX-5p for xrblock@ietf.org; Thu, 07 Mar 2013 10:22:50 -0700
Received: by mail-ia0-f170.google.com with SMTP id h8so645094iaa.29 for <xrblock@ietf.org>; Thu, 07 Mar 2013 09:22:48 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.50.34.231 with SMTP id c7mr14588433igj.95.1362676968754; Thu, 07 Mar 2013 09:22:48 -0800 (PST)
Received: by 10.50.183.163 with HTTP; Thu, 7 Mar 2013 09:22:48 -0800 (PST)
In-Reply-To: <CD5A7C1E.4EAD1%alan.d.clark@telchemy.com>
References: <CALw1_Q2z3nDwpRJSNomRqFVQhWAN7-7YozUL6GPEppKzL=6W1w@mail.gmail.com> <CD5A7C1E.4EAD1%alan.d.clark@telchemy.com>
Date: Thu, 7 Mar 2013 10:22:48 -0700
Message-ID: <CALw1_Q0HX9EXir5F4b4=q7j7WBdGnr-5WTjz+A3qzQUU9xnfaA@mail.gmail.com>
From: Kevin Gross <kevin.gross@avanw.com>
To: Alan Clark <alan.d.clark@telchemy.com>
Content-Type: multipart/alternative; boundary=14dae9340eebaaeb2e04d758f44c
X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.210.170 authed with kevin.gross@avanw.com}
Cc: "xrblock@ietf.org" <xrblock@ietf.org>
Subject: Re: [xrblock] =?gb2312?b?tPC4tDogtPC4tDogRnc6IEktRCBBY3Rpb246IGRyYWZ0?= =?gb2312?b?LWlldGYteHJibG9jay1ydGNwLXhyLWpiLTA4LnR4dA==?=
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <xrblock.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xrblock>, <mailto:xrblock-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xrblock>
List-Post: <mailto:xrblock@ietf.org>
List-Help: <mailto:xrblock-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xrblock>, <mailto:xrblock-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Mar 2013 17:23:21 -0000

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 <alan.d.clark@telchemy.com>wrote;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" <kevin.gross@avanw.com> 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 <alan.d.clark@telchemy.com>
> 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" <bill.wu@huawei.com <http://bill.wu@huawei.com>
> > wrote:
>
> *发件人:* Kevin Gross [mailto:kevin.gross@avanw.com <kevin.gross@avanw.com>]
> *发送时间:* 2013年3月4日 14:02
> *收件人:* Qin Wu
> *抄送:* xrblock@ietf.org <http://xrblock@ietf.org> ; 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 <bill.wu@huawei.com <
> http://bill.wu@huawei.com> > wrote:
>
>
> Hi, Kevin:
> Please see my clarification below.
> Alan, please correct me if I am wrong.
>
> Regards!
> -Qin
>
> *发件人:* Kevin Gross [mailto:kevin.gross@avanw.com <kevin.gross@avanw.com>]
> *发送时间:* 2013年3月4日 6:13
> *收件人:* Qin Wu
> *抄送:* xrblock@ietf.org <http://xrblock@ietf.org> ; 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 <bill.wu@huawei.com <
> http://bill.wu@huawei.com> > wrote:
>
> On 23 February , 2012 10:40 PM, Internet-Drafts@ietf.org <
> http://Internet-Drafts@ietf.org>  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.
>
>
>
>
>
>
>