Subject: [AVT] Question on draft-ietf-avt-rtcp-report-extns-05

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 6 May 2003 13:27:57 -0400

Folks,

As I was looking at this document, it appears that the extended reporting
fields are all "mandatory".  That is, it does not appear possible, for
example, to signal "round trip delay" without also signaling "burst
duration".  Am I reading this correctly?  Would it not be reasonable to
consider that some devices may or may not have the capability to advertise
some metrics, but not others.

Please clarify.

Thanks,
Paul

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

---

From: "Alan Clark" <[email-masked]>
Date: Tue, 6 May 2003 14:44:41 -0400

Paul

The -05 draft makes it mandatory to provide values for each field in the
report however in most cases there are defined values that can be used to
indicate that a specific metric is unknown or unsupported.  If this approach
was not used then we would have to use a TLV approach (as ASN.1) or some
other method of indicating whether a parameter was present or not.  The ONLY
mandatory parameters are SSRC and the packet loss and discard metrics.

Within the intended application of the VoIP metrics payload - i.e. VoIP - it
makes sense promote some minimal level of reporting.  Part of the rationale
for having this payload was to support more detailed reporting of packet
loss and discard statistics than that currently provided by RFC1889.

Regards

Alan Clark
Telchemy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Paul E.
Jones
Sent: Tuesday, May 06, 2003 1:28 PM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: [AVT] Question on draft-ietf-avt-rtcp-report-extns-05

Folks,

Please clarify.

Thanks,
Paul

---

From: Timur Friedman <[email-masked]>
Date: Wed, 7 May 2003 16:52:13 +0200

> some metrics, but not others.

The RTCP XR draft specifies a number of report blocks:

Loss RLE Report Block
Duplicate RLE Report Block
Packet Receipt Times Report Block
Receiver Reference Time Report Block
DLRR Report Block
Statistics Summary Report Block
VoIP Metrics Report Block

None of these blocks are mandatory.  However, an application can perfectly 
well require the use of some of these blocks.  The SDP signaling mechanism 
described in the draft allows an application to signal that certain blocks 
should be used.  Other signaling mechanisms or norms not described in the 
draft could do the same.

Some blocks necessarily come in pairs.  For instance, the DLRR Report Block 
only makes sense in response to a Receiver Reference Time Report Block.  In 
the SDP signaling section, this is referred to as "collaborative 
functionality", and the use of the two blocks is signaled collectively.  
Other blocks have "unilateral functionality", and and their use is signaled 
individually.

Within a block, there might be mechanisms for reporting on certain fields and 
not on others.  For instance, in the Statistics Summary Report Blocks, there 
are flags that indicate which fields are populated with values and which are 
not.  No signaling has been specified at this level, though the existing 
signaling mechanism could conceivably be extended to cover the choice of 
fields.

For the VoIP Metrics Report Block, on the other hand, all fields must be 
reported upon.  This is from the introduction to Section 4.7: 
"Implementations MUST provide values for all the fields defined here.  For 
certain metrics, if the value is undefined or unknown, then the specified 
default or unknown field value MUST be provided."  VoIP equipment cannot pick 
and choose and remain compliant with this draft.  If partial implementations 
were allowed, the utility of this report block would be significantly 
diminished.

As I understand, from those much better versed in the field (notably the 
authors of this VoIP Metrics Report Block section), the set of parameters 
defined for the block is fairly standard and readily-implementable.  It would 
be surprising if equipment could not be designed to report upon all of these 
values.  A provision is made, nonetheless, for indicating that certain values 
are not yet available at the time of reporting.

- Timur Friedman

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 9 May 2003 17:03:42 -0400

Timur, Alan,

Thanks for your feedback.

> were allowed, the utility of this report block would be significantly

This is the kind of thing that concerns me a bit.  I don't think we
necessarily want to mandate that every single parameter be signaled.
Perhaps it does not have the value or perhaps it does not want to waste
cycles producing the value.  Would the value of the report be diminished?
Possibly, but then again, one could argue that some information is better
than no information at all.

I think we should have the flexibility of indicating, within every report
block, which fields are and are not present.

Paul

---

From: "Alan Clark" <[email-masked]>
Date: Fri, 9 May 2003 17:39:18 -0400

Paul

The current format can also encourage implementers to try and populate as
many fields as possible.  If we make everything optional then it would be
possible to comply with RTCP XR but send no information.

At the end of the day we should be trying to encourage product developers to
move towards a common useful set of management performance data - the RTCP
XR VoIP metrics payload provides good insight into the operation of a VoIP
endpoint and can help considerably in diagnosing typical problems.

Regards

Alan

-----Original Message-----
From: Paul E. Jones [mailto:[email-masked]]
Sent: Friday, May 09, 2003 5:04 PM
To: Timur Friedman; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [AVT] Question on draft-ietf-avt-rtcp-report-extns-05

Timur, Alan,

Paul

---

From: Stephen Casner <[email-masked]>
Date: Fri, 9 May 2003 14:43:30 -0700 (PDT)

Paul,

> > were allowed, the utility of this report block would be significantly

The fact that some fields specify a default or unknown value means
that can still be compliant while supplying the default or unknown
value for those fields.  Therefore, it is not quite true to say that
all fields must be reported on.

> than no information at all.

It may well be the case that the bandwidth cost of sending the VoIP
metrics block is not justified if some minimum set of fields is not
complete.

> block, which fields are and are not present.

One important point about which I think there may be some confusion in
this discussion:  The layout of fields in the VoIP metrics block is
fixed.  It is not possible to include some fields and omit others.  To
allow doing so would require extra overhead for a variable format.
What is allowed is to supply a value for some fields that indicates no
information is present in that field.

                                                        -- Steve

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 9 May 2003 21:01:17 -0400

Alan,

> endpoint and can help considerably in diagnosing typical problems.

I think your arguments would be justified when it comes to call control
signaling.  Certainly, a tightly-defined call signaling protocol improves
interoperability and improves products.

However, these fields are, by their very nature, are ones that are not
absolutely essential to call establishment and not every field is absolutely
useful in ensuring quality of service.  I would venture to guess that, if
these are used, vendors will pick and choose which metrics will be used and
which will not... if they have the option.  I can certainly say that I'd
rather have the option of excluding some value I don't want to compute or
maintain stats for.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 9 May 2003 21:42:08 -0400

Steve,

> all fields must be reported on.

OK.. this part I missed.  So, for every field in every block, it is possible
to insert a "dummy" value that is recognized as a "dummy"?

> metrics block is not justified if some minimum set of fields is not

Actually, bandwidth is not my concern, really.  I don't see those stats as
being bandwidth constrained.

> information is present in that field.

I know that they're fixed in position.  That's OK.  In fact, given the
nature and size of each datagram, having these fixed field positions would
be good, as processing performance can be improved when both sending and
receiving.  However, I would like a means of either marking fields as
present or not or having a "dummy" value.

Statistics Summary, for example, allows one to signal presence of most
fields.  However, the "J" flag, for example, requires the inclusion of a
number of fields, including one that reports a measures the standard
deviation.  Perhaps I would prefer not to report that value... as it is, I
have no option, as far as I can tell.

Certainly, for most other fields, I do think they're required to be present.
If there is a "dummy" default for each, then that would be fine, but I
missed that part.

Paul

---

From: Stephen Casner <[email-masked]>
Date: Fri, 9 May 2003 19:21:27 -0700 (PDT)

> to insert a "dummy" value that is recognized as a "dummy"?

No, that statement does not hold true for every field in every block.
My comments were regarding the VoIP metrics block in particular.

Some of the other blocks do use a variable format rather than dummy
values.

> present or not or having a "dummy" value.

So, for the VoIP block, that means does exist for several of the
fields.  For some of the fields, providing a dummy value may not make
sense (because the entire space is used).  Extra bits could be
allocated to indicate presence, but that may not be justified -- that
is, I believe it is perfectly reasonable to say that there is a
minimum subset of fields without which it does not make sense to send
the block.  I guess the selection of that subset is the point of
disagreement.

> If there is a "dummy" default for each, then that would be fine, but I

As I say above, not every block type has dummy values defined.

                                                        -- Steve