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

From: Colin Perkins <[email-masked]>
Date: Mon, 28 Apr 2003 16:17:38 -0400

Please consider the following as my last call comments on the RTCP XR
draft.  The working group last call is due to end today - if you have
comments on this draft, please send them shortly.

Colin

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

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

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

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

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

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

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

 - Section 4.7, second paragraph: "between RTCP end points" -> "between
   RTP end points"

 - I don't understand the first paragraph of section 4.7.2; please reword
   for clarity.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 - In section 7, I'm not sure it's appropriate to mandate that XR packets
   SHOULD NOT be encrypted or filtered. 

 - Appendix A.2: If differences are found, or if the ETSI spec is updated,
   what happens?

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

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Alan Clark" <[email-masked]>
Date: Mon, 28 Apr 2003 19:28:05 -0400

Colin

Thanks for the comments - I've responded on those related to VoIP

Regards

Alan Clark

[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."

[Alan] Suggest either
(i) replacing "broadcast" with "one-to-many streaming"
(ii) delete broadcast as multicast will cover most cases

[Alan] Agreed

[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."

[Alan] these should be "loss rate" and "discard rate", both of which are
defined in section 4.7.1

[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."

[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."

[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

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

[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."

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

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

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

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

[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.."