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

[Qin Wu <[e-mail]>]

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" <[e-mail]>
To: "Romascanu, Dan (Dan)" <[e-mail]>
Cc: <[e-mail]>
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xrblock