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

[Glen Zorn <[e-mail]>]

More editorial comments.

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


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).

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.


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.

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.

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.

OLD
         bits 014-011
NEW
         bits 012-015


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"?


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.

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.


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.
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).


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.


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?


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.

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?

RANT
Is nobody else bothered by the amazing lack of precision in the xrblock 
WG drafts (perhaps not all, but not just this one, either)?  For 
example, the (presumably) same thing is referred to by 2, 3 or even 4 
different names in this document, leaving the reader to figure out that 
"Pos PDV Threshold/Peak", "Positive PDV Threshold/Peak" and "Pos PDV 
Threshold" all mean the same thing.  It's not rocket science, but it 
does (like labeling block diagrams in octal and the characterizing the 
fields in decimal and inconsistent capitalization) make reading the 
documents unnecessarily tedious.