Re: [xrblock] FW: I-D Action: draft-ietf-xrblock-rtcp-xr-pdv-06.txt

Qin Wu <bill.wu@huawei.com> Sat, 22 September 2012 02:18 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 EA25F21E80A3 for <xrblock@ietfa.amsl.com>; Fri, 21 Sep 2012 19:18:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.984
X-Spam-Level:
X-Spam-Status: No, score=-3.984 tagged_above=-999 required=5 tests=[AWL=-1.578, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_64=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24]
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 DLI0iUetmdi4 for <xrblock@ietfa.amsl.com>; Fri, 21 Sep 2012 19:18:54 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F13D921E805E for <xrblock@ietf.org>; Fri, 21 Sep 2012 19:18:53 -0700 (PDT)
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 AKX85897; Sat, 22 Sep 2012 02:18:53 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 22 Sep 2012 03:17:24 +0100
Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 22 Sep 2012 03:18:01 +0100
Received: from w53375 (10.138.41.149) by szxeml417-hub.china.huawei.com (10.82.67.156) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 22 Sep 2012 10:17:54 +0800
Message-ID: <E561737C4D424CA58127D184AB632CE3@china.huawei.com>
From: Qin Wu <bill.wu@huawei.com>
To: Glen Zorn <glenzorn@gmail.com>, "Romascanu, Dan (Dan)" <dromasca@avaya.com>
References: <EDC652A26FB23C4EB6384A4584434A0408129C10@307622ANEX5.global.avaya.com><505748C5.60701@gmail.com><EE3DB190F8C24FA29DEAB8BD531B1380@china.huawei.com><EDC652A26FB23C4EB6384A4584434A0408129D56@307622ANEX5.global.avaya.com><50584298.9040407@ericsson.com><EDC652A26FB23C4EB6384A4584434A0408129E1C@307622ANEX5.global.avaya.com><505B2088.6030208@cisco.com> <505B2F1C.7090606@ericsson.com><EDC652A26FB23C4EB6384A4584434A040812A3D4@307622ANEX5.global.avaya.com> <505C62DB.4080300@gmail.com>
Date: Sat, 22 Sep 2012 10:17:51 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: base64
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
Cc: xrblock@ietf.org
Subject: Re: [xrblock] FW: I-D Action: draft-ietf-xrblock-rtcp-xr-pdv-06.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: Sat, 22 Sep 2012 02:18:56 -0000

Hi,Glen:
Thank for your proposed change for text improvement, you save a lot of work for RFC Editor.
Please see my reply inline.

Regards!
-Qin
----- Original Message ----- 
From: "Glen Zorn" <glenzorn@gmail.com>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
Cc: <xrblock@ietf.org>
Sent: Friday, September 21, 2012 8:51 PM
Subject: Re: [xrblock] FW: I-D Action: draft-ietf-xrblock-rtcp-xr-pdv-06.txt


> More editorial comments.
> 
> Section 1.4
> OLD:
> variation[RFC5481].  For example, applications could use the
> NEW:
> variation [RFC5481].  For example, applications could use the

[Qin]:Okay.
> 
> Section 3
> OLD:
>    Metrics in this block report on packet delay variation in the stream
>    arriving at the RTP system.  The measurement of these metrics are
>    made at the receiving end of the RTP stream.  Instances of this
>    Metrics Block refer by Synchronization source (SSRC) to the separate
>    auxiliary Measurement Information block [MEASI] which contains
>    measurement intervals.  This metric block relies on the measurement
>    interval in the Measurement Information block indicating the span of
>    the report and SHOULD be sent in the same compound RTCP packet as the
>    measurement information block.  If the measurement interval is not
>    received for this metric block, this metric block MUST be discarded (
>    See section 5.4 of[MONARCH]for timing details).
> NEW:
>    Metrics in this block report on packet delay variation in the stream
>    arriving at the RTP system.  The measurement of these metrics are
>    made at the receiving end of the RTP stream.  Instances of this
>    metric block refer by Synchronization Source (SSRC) to the separate
>    auxiliary Measurement Information Block [MEASI] which contains
>    measurement intervals.  This metric block relies on the measurement
>    interval given by the value of the "Measurement Duration (Interval)"
> field in the Measurement Information Block to indicate the span of
>    the report and SHOULD be sent in the same compound RTCP packet as the
>    Measurement Information Block.  If the measurement interval is not
>    received for this metric block, this metric block MUST be discarded (
>    See section 5.4 of [MONARCH]for timing details).

[Qin]: Okay.

> COMMENT
> I find this reference rather confusing, because can't see anything about 
> timing in Section 5.4.
> Actually, the last 2 sentences are quite confusing in that they appear 
> to be rather self-contradictory:
> they say that the Measurement Information Block SHOULD be sent in the 
> same packet as this block, but if it's not received the block MUST be 
> discarded.  Wouldn't it be simpler just to say the following?
> 
>    This metric block relies on the measurement
>    interval given by the value of the "Measurement Duration (Interval)"
> field in the Measurement Information Block to indicate the span of
>    the report and MUST be sent in the same compound RTCP packet as the
>    Measurement Information Block.  If the measurement interval is not
>    received for this metric block, this metric block MUST be discarded.
> 
[Qin]: Correct, I agree, thank for your proposal.


> Section 3.2
> 
> COMMENT
> If the bits in the diagram absolutely MUST be labeled in octel, please 
> be consistent.  For example, Section 3.2 states that the SSRC of the 
> source is 32 bits in length, but the diagram in Section 3.1 clearly 
> shows it to be 37 bits long.

[Qin]: Okay, that is misunderstanding, I will change bits in the diagram labeled in octal into
bits in the diagram in decimal. 

> COMMENT
> In the definition of the Interval Metric flag (I) field the last two 
> sentences say "The value I=00 is reserved, and MUST NOT be used.  If the 
> value I=00 is received, it MUST be ignored by the receiver."  The last 
> sentence says that a value of 00 is received then the value must be 
> ignored but I think it means that if a value of 00 is received then the 
> XR block must be ignored.

[Qin]: Agree, I will change as you proposed.
OLD TEXT:
"If the value I=00 is received, then it MUST be ignored by the receiver."
NEW TEXT:
"If the value I=00 is received, then the XR block MUST be ignored by the receiverit."

> OLD
>       Packet Delay Variation Metric Type is of type enumerated and is
>       interpreted as Integer.
> NEW
>       Packet Delay Variation Metric Type is of type enumerated and is
>       to be interpreted as an unsigned, 4-bit integer.

[Qin]: Okay.

> OLD
>         bits 014-011
> NEW
>         bits 012-015
> 
[Qin]: I think the range from the 11th bit to the 14th bit counted from leftmost is correct.

> COMMENT
> I don't know what "more positive than" & "more negative than" mean WRT 
> to numbers: my understanding is that real numbers are positive, negative 
> or zero.  Is there some reason why we can't just say "greater than" and 
> "less than"?

[Qin]: I think it is kind of habit for language using. I have no difficult to understand
what "more positive than" & "more negative than" mean. But I am okay with your proposed
change, i.e.using less than to replace "more negative than" and using "greater than" to replace
"more positive than".
> 
> Section 3.3
> 
> OLD
>    MAPDV2 (Clause 6.2.3.2 of [G.1020]) is the envelope of instantaneous
>    (per-packet) delay when compared to the short term moving average
>    delay.  This metric could be useful in determining residual
>    impairment when an RTP end system uses an adaptive de-jitter buffer
>    which tracks the average delay variation, provided the adaptive de-
>    jitter buffer have similar averaging behaviour as the MAPDV2
>    algorithm.
> NEW
>    MAPDV2 (Clause 6.2.3.2 of [G.1020]) is the envelope of instantaneous
>    (per-packet) delay when compared to the short term moving average
>    delay.  This metric could be useful in determining residual
>    impairment when an RTP end system uses an adaptive de-jitter buffer
>    which tracks the average delay variation, provided that the averaging
>    behavior of the adaptive algorithm is similar to that of the MAPDV2
>    algorithm.

[Qin]: Okay.

> OLD
>    2-point PDV (Clause 6.2.4 of [Y.1540]) reports absolute packet delay
>    variation with respect to a defined reference packet transfer delay .
>    Note that the reference packet is generally selected as the packet
>    with minimum delay based on the most common criterion (See section 1
>    and section 5.1 of [RFC5481] ).  In an RTP context, the two "points"
>    are at the sender (the synchronization source which applies RTP
>    timestamps) and at the receiver.  The value of this metric for the
>    packet with index j is identical to the quantity D(i,j) defined in
>    Section 6.4.1 of [RFC3550] and the packet index i should be set equal
>    to the index of the reference packet for the metric in practice.  The
>    metric includes the effect of the frequency offsets of clocks in both
>    the sender and receiver end systems, so it is useful mainly in
>    network where synchronisation is distributed.
> NEW
>    2-point PDV (Clause 6.2.4 of [Y.1540]) reports absolute packet delay
>    variation with respect to a defined reference packet transfer delay.
>    Note that the reference packet is generally selected as the packet
>    with minimum delay based on the most common criterion (See section 1
>    and section 5.1 of [RFC5481]).  In an RTP context, the two "points"
>    are at the sender (the synchronization source which applies RTP
>    timestamps) and at the receiver.  The value of this metric for the
>    packet with index j is identical to the quantity D(i,j) defined in
>    Section 6.4.1 of [RFC3550] and the packet index i should be set equal
>    to the index of the reference packet for the metric in practice.  The
>    metric includes the effect of the frequency offsets of clocks in both
>    the sender and receiver end systems, so it is useful mainly in
>    networks where synchronisation is distributed.
> 
[Qin]: Okay.

> Section 3.4
> 
> OLD
>       (b) To report MAPDV2 [G.1020]:
> 
>          Pos PDV Threshold = 50.0; Pos PDV Percentile = 95.3; Neg PDV
>          Threshold = 50.0 (note this implies -50ms); Neg PDV Percentile
>          = 98.4; PDV type = 1 (MAPDV2)
> 
>          causes average MAPDV2 to be reported in the Mean PDV field.
> NEW
>       (a) To report MAPDV2 [G.1020]:
> 
>          Pos PDV Threshold = 50.0; Pos PDV Percentile = 95.3; Neg PDV
>          Threshold = 50.0 (note this implies -50ms); Neg PDV Percentile
>          = 98.4; PDV type = 0 (MAPDV2)
> 
>          causes average MAPDV2 to be reported in the Mean PDV field.

[Qin]: Good catch.Thanks.

> COMMENT
> The last phrase is confusing, because it seems that what causes MAPDV2 
> to be reported is that really
> the fact that the value of the pdvtype field is 0; the rest of the 
> values seem irrelevant (or at least esoteric).
 
[Qin]:It looks esoteric but required since it is up to measurement method defined in
G.1020 or Y.1540. You can see SDP also signals that.

> 
> Section 4
> COMMENT
> Is "<as defined in Section 3.4 of [RFC5234]>" valid ABNF?
> 
> COMMENT
>    When SDP is used in offer-answer, a system sending SDP may request a
>    specific type of PDV measurement.  In addition, they may state a
>    specific percentile or threshold value, and expect to receive the
>    corresponding threshold or percentile metric, respectively. The
>    system receiving the SDP SHOULD send the PDV metrics requested, but
>    if the metric is not available, the system receiving the SDP MUST
>    send the metric block with the flag value indicating that the metric
>    is unavailable.
> I don't see any flag value in this block that indicates that the metric 
> is unavailable.

[Qin]: The flag value is in the mean PDV field, Positive PDV Threshold/Peak field,Positive PDV Percentile,etc.
e.g., we use 0xFFFF to indicate metric is unavailable.

> 
> Section 5.4
> COMMENT
>    o  Initial assignments are as follows:
> 
>       *  0: MAPDV2, Clause 6.2.3.2 of [G.1020],
> 
>       *  1: 2-point PDV, Clause 6.2.4 of [Y.1540]
> 
> Are the rest of the values reserved?

[Qin]: Yes. Here we just give initial assignments.

> 
> Section 6
> OLD
>    The authors gratefully acknowledge the comments and contributions
>    made by Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin
>    Connor, Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert
>    Higashi, Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith
>    Lantz, Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho,
>    Ravi Raviraj, Albrecht Schwarz, Tom Taylor, and Hideaki Yamada,Jing
>    Zhao,Kevin Gross, Colin Perkins, Charles Eckel, Glen Zorn,Shida
>    Schubert, Benoit Claise, Adrian Farrel, Pete Resnick.
> NEW
>    The authors gratefully acknowledge the comments and contributions
>    made by Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin
>    Connor, Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert
>    Higashi, Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith
>    Lantz, Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho,
>    Ravi Raviraj, Albrecht Schwarz, Tom Taylor, Hideaki Yamada, Jing
>    Zhao, Kevin Gross, Colin Perkins, Charles Eckel, Glen Zorn, Shida
>    Schubert, Benoit Claise, Adrian Farrel and Pete Resnick.

[Qin]: Okay.

> COMMENT
> The first sentence says "The authors gratefully acknowledge the comments 
> and contributions"
> but there is a "Contributors" section.  If some of these people actually 
> contributed to the document (i.e., text), shouldn't they at a minimum be 
> in that section, if not added as authors?

[Qin]: I can't remember who is contributor and who is not in the history. Sorry about that.

> _______________________________________________
> xrblock mailing list
> xrblock@ietf.org
> https://www.ietf.org/mailman/listinfo/xrblock