Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-jb-02.txt

Qin Wu <bill.wu@huawei.com> Fri, 14 December 2012 11:20 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 422C321F851A for <xrblock@ietfa.amsl.com>; Fri, 14 Dec 2012 03:20:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.831
X-Spam-Level:
X-Spam-Status: No, score=-3.831 tagged_above=-999 required=5 tests=[AWL=-0.786, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_66=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id el0Ob6sV9JMu for <xrblock@ietfa.amsl.com>; Fri, 14 Dec 2012 03:20:09 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4D35121F8519 for <xrblock@ietf.org>; Fri, 14 Dec 2012 03:20:08 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANV37353; Fri, 14 Dec 2012 11:20:06 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 14 Dec 2012 11:19:10 +0000
Received: from SZXEML443-HUB.china.huawei.com (10.82.67.181) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 14 Dec 2012 19:20:05 +0800
Received: from w53375 (10.138.41.149) by SZXEML443-HUB.china.huawei.com (10.82.67.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 14 Dec 2012 19:20:00 +0800
Message-ID: <A58F079A8D804929AA28B535FAB72BAC@china.huawei.com>
From: Qin Wu <bill.wu@huawei.com>
To: Glen Zorn <glenzorn@gmail.com>, xrblock <xrblock@ietf.org>
References: <50CAF991.8050508@gmail.com>
Date: Fri, 14 Dec 2012 19:20:00 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0306_01CDDA30.03144D80"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Originating-IP: [10.138.41.149]
X-CFilter-Loop: Reflected
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-jb-02.txt
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: Fri, 14 Dec 2012 11:20:10 -0000

----- Original Message ----- 
From: "Glen Zorn" <glenzorn@gmail.com>
To: "xrblock" <xrblock@ietf.org>
Sent: Friday, December 14, 2012 6:04 PM
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-jb-02.txt


>I have reviewed this draft and have some comments.
> 
> *Section 1.1*
> "SSRC" should be expanded on first usage.

[Qin]: Okay.

> *Section 1.4*
> I'm pretty sure that jitter cannot be "encountered", because it is a 
> timing abberation, not a physical object.  Suggest using "introduced" 
> instead.

[Qin]: Accepted.
> 
> The second sentence says:
> 
>    These metrics are used to measure how the jitter buffer behave as a 
> result of the
>    jitter and applicable to a range of RTP applications.
> 
> The English language usage needs to be cleaned up a bit, 

[Qin]: Okay, maybe we can say:
"
These metrics are used to measure how the jitter buffer behaves according to a result of the

Packet Delay Variation and can be applicable to a range of RTP applications. 
"
>but more 
> importantly the statement sees to contradict the first sentence of 
> Section 3 which says
> 
>    This block describes the configuration and operating parameters of
>    the jitter buffer in the receiver of the RTP end system or RTP mixer
>    which sends the report.
> 
> How can both be correct?

[Qin]: I don't see they contradict. The configuration parameters are referred to 
Jitter Buffer Configuration set in the block header while
the operating parameters are referred to those metrics included 
in the payload of the block.

> 
> Sorry, but I have no idea what the third sentence means.

[Qin]:What the third sentence means is
usually we don't consider how the terminal affect 
real-time application quality. however in pratice user may have different experience

to the application quality when they choose different terminal to playout the received RTP stream,e.g., ipad,PC,smartphone with

difference screen size, resolution and different buffer size to process the data.

So maybe we should rephase the paragraph in the section 4 as follows:

"

Real-time applications employ a jitter buffer to smooth out jitter

   introduced on the path from source to destination.  These metrics

   are used to measure how the jitter buffer at the receiving end of RTP stream behaves according to a result of the

   Packet Delay Variation in the network and applicable to a range of RTP applications.  

 These metrics reflect how terminal related factor affects real-time

   application quality and useful to provide more accurate end user quality experience.


"
> *Section 3*
> It would be a very good idea, I think, to make capitalization and 
> terminology consistent throughout the document.  An example from this 
> section: "Instances of this Metrics Block" in sentence one but "this 
> metric block" elsewhere.


[Qin]: Good point. We will check to fix that.

> Sentence two says "Instances of this Metrics Block refer by SSRC to the 
> separate auxiliary Measurement Information block  [RFC6776] which 
> contains measurement intervals." but AFAICT the Measurement Information 
> lock describes only one interval.  Suggest changing to "Instances of 
> this metric block refer by SSRC to the separate auxiliary Measurement 
> Information block [RFC6776] which describes the measurement interval in 
> use."

[Qin]: Okay.

> *Section 3.2*
> The description of the "jitter buffer nominal delay" says that "It is 
> calculated based on the time for packets spent in the jitter buffer."  
> How is it calculated?

[Qin]:It will be calculate based on the difference between the time when the packet enter into the jitter buffer 
and the time when the packet come out from jitter buffer. It is mostly up to specific
implementation and doesn't need to spell out.

> *Section 8*
> s/Hideaki Yamada,Claire Bi,Colin Perkin/Hideaki Yamada, Claire Bi, Colin 
> Perkins, Glen Zorn

[Qin]: Okay, no problem. Thanks.
> :-)
> 
> 
> 
> _______________________________________________
> xrblock mailing list
> xrblock@ietf.org
> https://www.ietf.org/mailman/listinfo/xrblock