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

Qin Wu <bill.wu@huawei.com> Mon, 04 March 2013 18:39 UTC

Return-Path: <bill.wu@huawei.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 D5A0321F8A41 for <xrblock@ietfa.amsl.com>; Mon, 4 Mar 2013 10:39:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.231
X-Spam-Level: **
X-Spam-Status: No, score=2.231 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, 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 Y1F0BGpmfTN8 for <xrblock@ietfa.amsl.com>; Mon, 4 Mar 2013 10:39:54 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D2F5321F8C53 for <xrblock@ietf.org>; Mon, 4 Mar 2013 10:39:52 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APA48196; Mon, 04 Mar 2013 18:39:52 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 4 Mar 2013 18:39:46 +0000
Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 4 Mar 2013 18:39:50 +0000
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.45]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.01.0323.007; Tue, 5 Mar 2013 02:39:45 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Alan Clark <alan.d.clark@telchemy.com>, Kevin Gross <kevin.gross@avanw.com>
Thread-Topic: =?gb2312?B?tPC4tDogILTwuLQ6IEZ3OiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXhyYmxv?= =?gb2312?Q?ck-rtcp-xr-jb-08.txt?=
Thread-Index: AQHOGFxPgF+396RJX0WJCEk0UNqM3piU0HEQ//+0VwCAAIjXEIAAx5SUgAAJJZA=
Date: Mon, 4 Mar 2013 18:39:44 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA43A241AB@nkgeml501-mbs.china.huawei.com>
References: <B8F9A780D330094D99AF023C5877DABA43A23830@nkgeml501-mbs.china.huawei.com> <CD5A4CC7.4EAB1%alan.d.clark@telchemy.com>
In-Reply-To: <CD5A4CC7.4EAB1%alan.d.clark@telchemy.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.150.171]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43A241ABnkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "xrblock@ietf.org" <xrblock@ietf.org>
Subject: [xrblock] =?gb2312?b?tPC4tDogtPC4tDogILTwuLQ6IEZ3OiBJLUQgQWN0aW9u?= =?gb2312?b?OiBkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1qYi0wOC50eHQ=?=
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: Mon, 04 Mar 2013 18:39:59 -0000

Thank for your confirmation. That is what I thought.

Regards!
-Qin
发件人: Alan Clark [mailto:alan.d.clark@telchemy.com]
发送时间: 2013年3月5日 2:06
收件人: Qin Wu; Kevin Gross
抄送: xrblock@ietf.org
主题: Re: 答复: 答复: Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-08.txt

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> wrote:
发件人: Kevin Gross [mailto:kevin.gross@avanw.com]
发送时间: 2013年3月4日 14:02
收件人: Qin Wu
抄送: 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> 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]
发送时间: 2013年3月4日 6:13
收件人: Qin Wu
抄送: 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>

Media Network Consultant

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


On Sun, Feb 24, 2013 at 6:28 PM, Qin Wu <bill.wu@huawei.com> wrote:

On 23 February , 2012 10:40 PM, 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.