Subject: Re: [AVT] Comments on draft-ietf-avt-rtcp-report-extns-04.txt

From: Timur Friedman <[email-masked]>
Date: Thu, 1 May 2003 03:50:44 +0200

I have prepared an 05 version of the draft in response to the Last Call 
comments by Colin Perkins and responses from my co-editor Alan Clark.  That 
draft will follow shortly.  What follows are the details of the differences 
between the 04 and 05 drafts.

- Timur Friedman

>  - The draft needs an explicit statement that the standard RTCP timing
>    rules apply, and that use of the extended report blocks will likely
>    increase the reporting interval.
>
> [Alan] Suggest adding to Section 1.1 paragraph 1
> "The XR report blocks defined in this document MUST be sent within the
> defined guidelines for RTCP reporting intervals.  In certain applications
> the use of RTCP XR payloads may mean that less frequent reports are needed
> in order to provide a sufficient degree of feedback on performance."

The suggested text would make it a normative requirement that the already 
existing normative requirements be adhered to.  My understanding is that the 
"explicit statement" Colin refers to should be on the order of clarifying 
remarks.  I have added the following paragraph to Section 1.1, as the second 
to last paragraph (note that the reference numbers have changed, and 
reference [9] is for the RTP spec):

--- begin quote ---

XR packets supplement the existing RTCP packets, and may be stacked
with other RTCP packets to form compound RTCP packets [9, Section 6].
The introduction of XR packets into a session in no way changes the
rules governing the calculation of the RTCP reporting interval [9,
Section 6.2].  As XR packets are RTCP packets, they count as such for
bandwidth calculations.  As a result, the addition of extended
reporting information may tend to increase the average RTCP packet
size, and thus the average reporting interval.  This increase may be
limited by limiting the size of XR packets.

--- end quote ---

>  - The second paragraph of section 1.1 talks about "broadcast" sessions.
>    I assume that one-to-many streaming is intended, but the text should
>    be clarified since broadcast IP is presumably not used.
>
> [Alan] Suggest either
> (i) replacing "broadcast" with "one-to-many streaming"
> (ii) delete broadcast as multicast will cover most cases

I have replaced "any conversational, multicast or broadcast application" with 
"any one-to-one or one-to-many voice application".  Further down in the 
paragraph, I have replaced "conferencing, multicast and broadcast 
applications" with "multicast conferencing applications".

>  - First paragraph of section 2: "thus backwards compatibility with" ->
>    "this backwards compatible with"

Corrected.

>  - The packet format in section 2 has an "SSRC/CSRC" field; this should
>    presumably be "SSRC" only? (diagram and text following)

Correct.  I have fixed this.

>  - In explanation of the DLRR field in section 4.5 mentions LSR and DLSR
>    in a couple of places. Should be talking about LRR and DLRR?

Correct.  I have fixed this.

>  - Second paragraph of section 4.6 "The fields corresponding to unreported
>    parameters MUST be set to zero" may be clearer as "...MUST be present,
>    but are set to zero"?

OK, I have made this change.

>  - In section 4.6, the avg_jitter and avt_ttl_or_hl fields are listed as
>    being the "average" of a particular statistic. Which average is used?
>    I assume the mean, but should clarify.

Yes, the mean is used.  I have changed "avg_" to "mean_", and "average" to 
"mean" in this section.  I have also clarified that means are to be rounded 
to the closest possible value (integers for TTL values and RTP timestamp 
values for jitter).

>  - Section 4.7, second paragraph: "between RTCP end points" -> "between
>    RTP end points"
>
> [Alan] Agreed

Corrected.

>  - I don't understand the first paragraph of section 4.7.2; please reword
>    for clarity.
>
> [Alan] "A burst is a period during which a high proportion of packets are
> either lost in transit or discarded due to late arrival.  A burst is
> defined as a longest sequence that (a) starts with a lost or discarded
> packet, (b) does not contain any occurrences of Gmin or more consecutive
> received (and not discarded) packets, and (c) ends with a lost or discarded
> packet."

I have incorporated the suggested text, inserting "defined, in terms of a 
value Gmin", in order to introduce the value Gmin before it is used.

>  - The example of page 28 reference loss density and discard density, but
>    these do not appear to be defined? (they're briefly mentioned earlier
>    in the section, but are not reported)
>
> [Alan] these should be "loss rate" and "discard rate", both of which are
> defined in section 4.7.1

I have changed the three uses of "density" with respect to losses and discards 
in this section to "rate";  I have made the same change to three uses of 
"density" in the code in Appendix A2.

>  - In section 4.7.3, the round trip delay is calculated in milliseconds,
>    but the discussion talk about calculating it using RTCP LSR/DLSR. Can
>    you confirm that milliseconds are intended? And, if so, note in the
>    explanation that a units conversion is needed.
>
> [Alan] The use of milliseconds was intentional.
> Suggest changing second sentence of "round trip delay" definition to:
> "This value MAY be measured using RTCP or the DLRR method defined in
> Section 4.5 of this document, in which case it is necessary to convert the
> units of measurement from NTP to milliseconds, or other approaches."

I have incorporated the suggested text, but specify "NTP timestamp values" 
instead of "NTP".

>  - In section 4.7.3, the end system delay estimate makes the assumption
>    that the system can send and receive, and that it has a local analog
>    interface to loop-back audio. Neither of these are necessarily valid.
>    Accordingly, the I'd like to see the "MUST be provided" turn into a
>    SHOULD, and some explanation of what to do if the data cannot be
>    provided.
>
> [Alan] This was defined as an estimated rather than measured delay, and can
> typically be determined by adding known framing and encode/decode delays -
> it was not intended that it be measured literally. We can change the
> wording to clarify.
> "The most recently estimated end system delay, expressed in milliseconds.
> End system delay is defined as the sum of the total sample accumulation and
> encoding delay associated with the sending direction and the jitter buffer,
> decoding and playout buffer delay associated with the receiving direction;
> this delay MAY be estimated or measured.  This value MUST be provided in
> all VoIP metrics reports."

I have incorporated the suggested text.

>  - In section 4.7.4, the signal and noise levels are defined as a ratio in
>    terms of a "reference digital milliwatt" and "rms talkspurt power (mW)".
>    Can you clarify the definition of these terms? I wouldn't know how to
>    calculate them, in the PC-based implementation I'm familiar with.
>
> [Alan] The term "digital milliwatt" is widely used in both PCM and VoIP
> systems to denote the digital representation of a 0 dBm0 signal.  I've not
> yet found the official definition of it, although it may originate in an
> IEEE standard - we can substitute a 0dBm0 reference signal.
> Suggest:-
>
> for "signal level" and "noise level" change "digital milliwatt" to "0 dBm0
> reference [18]"
>
> add reference [18] TIA/EIA-810-A Transmission Requirements for Narrowband
> Voice over IP and Voice over PCM Digital Wireline Telephones, December 2000

I have made the suggested changes, but have added the new reference as a 
normative reference rather than a non-normative reference (which the 
suggested reference number 18 might be thought to imply).  The reference has 
been inserted in alphabetic order in the Normative References section, 
entailing reference renumbering.

>  - In section 4.7.4, the definition of the residual echo return loss is not
>    clear, and seems to assume particular implmentations of gateway devices.
>    Recommend separating the normative definition of the field out from the
>    non-normative examples of how it might be measured in particular cases.
>
> [Alan] This should be typical of VoIP gateways with line echo cancellers
> and isn't specific to any implementations.  I've checked with a number of
> echo canceller software developers and the parameters are typically
> available as ERL and ERLE in dB or in some format that can easily be
> converted. Suggest clarifying the wording to:
>
> The residual echo return loss is defined as the sum of the measured echo
> return loss (ERL) and the echo return loss enhancement (ERLE) of the echo
> canceller (if present) expressed in dB as a signed integer in 2's
> complement form.
>
> The residual echo return loss relates to the effective echo level that a
> user would hear.  The amount of echo that can occur in analog loops can be
> significant, and therefore echo cancellers are typically used to try and
> eliminate or reduce the audible echo. The amount of echo is typically
> described as a "echo return loss" (i.e. ratio between the transmitted
> signal level and the received echo level) expressed in dB.  The
> effectiveness of an echo canceller is normally described in terms of "echo
> return loss enhancement", i.e. an echo canceller increases the effective
> echo return loss and makes the audible echo smaller.  Hence the residual
> echo return loss (RERL) is the sum of the echo return loss (ERL) and the
> echo return loss enhancement (ERLE) expressed in dB.

I have incorporated the suggested text.

>  - In section 4.7.5, the fields are mostly 8 bits, with only a subset of
>    values being legal. Would it be appropriate to use smaller fields in
>    some cases? What should receivers do if they receive a report where a
>    field has an illegal value?
>
> [Alan] I suggest keeping these as 8 bit, otherwise we would need to handle
> 6 bit values.  We could change the "A value of" sentences to read
>
> "A value of 127 indicates that this parameter is unavailable.  Values other
> than 127 and the valid range defined above MUST not be sent and MUST be
> ignored by the receiving system."

I have incorporated the suggested text.

>  - In section 4.7.5, the chosen values for the PLC are not contiguous: I
>    can indicate a PLC that can conceal less than 3% (standard PLC), or
>    more than 10% (enhanced PLC), but nothing in the middle. Is there
>    intended to be a "better-than-standard but not quite enhanced" range?
>    How does this relate to the "unspecified" category?
>
> [Alan] There is a continuum of possibilities in terms of PLC effectiveness.
> "Standard" in this case refers to algorithms that use some form of last
> packet replay with attenuation and filtering/smoothing.  "Enhanced" refers
> to algorithms that use some form of error correction(sometimes introducing
> additional delay or bandwidth overhead). "Unspecified" simply means that
> the CODEC details are outside the domain of knowledge of the RTCP XR
> reporting instance - they are typically internal to a DSP.
> I think the standard and enhanced definitions cover what is used in the
> industry today, and generally implementors could figure out which to use.

This comment refers to Section 4.7.6.  In keeping with the response above, I 
have made no changes to address this comment.

>  - In section 4.7.6, the jitter buffer rate assumes that the jitter buffer
>    can cope with a step change in jitter from 30ms to 100ms. This seems to
>    be somewhat aggressive?
>
> [Alan] Let's hope people aren't using 10BaseT and hubs for VoIP!! :-)  Many
> adaptive jitter buffers max out at 200-400mS although they would typically
> operate in the 20-50mS range.  As the description suggests, this is
> intended to be an easily measured parameter that provides a guide to the JB
> ramp time, in reality jitter/PDV would not behave quite this way.

In keeping with the response above, I have made no changes to address this 
comment.

>  - In section 4.7.7, the units for the "JB max" and "JB abs max" fields are
>    not specified. Also, what is reported if the "JB abs max" is larger than
>    the maximum expressible value?
>
> [Alan] Suggested changes
>
> jitter buffer maximum delay...
> This is the current maximum jitter buffer delay in milliseconds which
> corresponds to the earliest arriving packet that would not be discarded. 
> In simple queue.......
>
> jitter buffer absolute maximum delay...
> This is the absolute maximum delay in milliseconds that the adaptive jitter
> buffer can reach under worst case conditions.  If this value exceeds 65535
> milliseconds then it shall be limited to 65535. This parameter MUST....

I have made the suggested changes, except that I wrote "If this value exceeds 
65535 milliseconds then this field SHALL convey the value 65535", giving 
normative force to the statement.

>  - In section 5.1, need a reference to the definitions of DIGIT and CRLF.

I have defined these as follows, in keeping with RFC 2234:

DIGIT          = %x30-39
CRLF           = %d13.10

>  - Section 6.2 should define what information needs to be included in any
>    new registrations of attribute block types. There is, presumably, some
>    minimum degree of specification that is required for interoperability?

Yes.  I have added the following text:

--- begin quote ---

Any registration MUST contain the following information:

- Contact information of the one doing the registration, including at 
  least name, address, and email. 

- The format of the block type being registered, consistent with the
  extended report block format described in Section 3.

--- end quote ---

>  - In section 6.2, if the BT value of 255 is reserved for future extension,
>    it becomes necessary to indicate how it might be extended. I expect that
>    this space is large enough, that we don't have to worry about reserving
>    the block.

If memory serves, this issue came up when the 03 draft was discussed in open 
sesssion in San Francisco.  The 03 draft did not have a reserved value.  A 
suggestion was made to add a reserved value for future extensions.  I raised 
the concern that then we would need to define an extension mechanism.  I 
believe it was Henning Schulzrinne who suggested it would suffice to state 
that the value is reserved.  My impression was that this formed the basis for 
a concensus in the room at the time in favor of adding a simple statement 
concerning a reserved value, and so I am reluctant to go back on it.

>  - End of section 6.3, talks about an ABNF definition of new parameters, in
>    accordance3 with the "format-ext" definition. It needs to reference the
>    location of the "format-ext" definition.

Done.

>  - Section 7 needs to reference the standard RTCP reporting mechanism, when
>    it says that the security considerations therein apply.

Done.

>  - In section 7, I'm not sure it's appropriate to mandate that XR packets
>    SHOULD NOT be encrypted or filtered.
>
> [Alan] Isn't SHOULD an advisory qualifier, unlike MUST?  The goal is to
> encourage implementors to turn encryption of RTCP off when sending RTCP XR
> reports as this is desirable from a network management perspective.

It seems to me odd to include a normative statement with pretences beyond the 
definition of the XR packets, regarding how third parties should treat the 
packets.  On the other hand, I believe the advice is warranted.  I have 
removed the normative character of this statement by replacing "SHOULD NOT" 
with "should not".

>  - Appendix A.2: If differences are found, or if the ETSI spec is updated,
>    what happens?
>
> [Alan] We are refering to a specific dated release of the ETSI spec.  The
> VoIP metrics payload is actually substantially more comprehensive than the
> ETSI spec, which only relates to methods for calculating R factors.
> We should make the reference at the end of the second paragraph in 4.7 "(as
> described by the E Model defined in [6,3]) and.."

I have made the suggested change.

>  - References: RFC 1700 is listed as Historic in my copy of the RFC index.

I have replaced this reference with a non-normative reference to RFC 3232.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Mon, 05 May 2003 16:15:41 -0400

Timur, Alan,

Thanks for the update. These mostly look good, although I have a few
comments inline.
Colin

>between the 04 and 05 drafts.
...
>I have incorporated the suggested text.

This doesn't address my concern: what about systems that cannot transmit? I
might want to build a receiver with no capture and encoding capability, and
to have that report on voice quality. What does that receiver do: it cannot
estimate the end system delay as specified, yet the draft says it "MUST" be
reported?

>I have incorporated the suggested text.

This is an improvement, but my main concern was the text following (page 32
of the -05 draft). In particular, I'd like to see the normative description
of how the parameter is calculated separated from the examples of particular
devices. 

>I have incorporated the suggested text.

You might consider the use of 6 bit fields, with reserved bits padding out
the packet format to 8 bit alignment? Be explicit about the reserved values,
rather than hiding them in the text.

>have made no changes to address this comment.

I understand Alan's explanation, but the draft is still unclear. The
simplest fix is probably to remove the loss rates from the text, and
to improve the explanation of what is intended for each value.

>In keeping with the response above, I have made no changes to address this 

If you believe a step change from 30ms to 100ms is within the range of
adaptation of most implementations, then okay. 

>  extended report block format described in Section 3.

...and presumably, some guideance on how the block is to be used?

>concerning a reserved value, and so I am reluctant to go back on it.

I don't recall the discussion, but okay.

>I have made the suggested change.

Which spec takes precedence if they are found to differ? The code in A.2 or
the code in the ETSI spec? 

Colin