Re: [xrblock] ippm metrics registry for xrblock metrics

["Huangyihong (Rachel)" <[e-mail]>]

Hi Al,

Thanks for correcting what I wrote, and pointing out the criteria. I totally agree with you. If we want to register some RTCP XR metrics, they should be well qualified according to section 5 of  draft-ietf-ippm-metric-registry-13.

Certainly, we don't have to register all the XR metrics. Most of them are application related metrics that are implemented in the RTP endpoints, so that they can be sent back to the senders/monitors to get know of the receiving status by using RTCP XR protocol. We should not consider those.

But some basic RTP layer metrics (e.g., loss, delay, burst), IMHO, are also required in multiple devices other than RTP endpoints. A typical scenario is that operators may need to understand the network performance when delivering some RTP services, e.g., IPTV. Then, these metrics may be required to be registered so that they can be implemented in different network devices, like routers, OLTs, ONTs, etc.

BR,
Rachel

From: MORTON, ALFRED C (AL) [mailto:[e-mail]]
Sent: Sunday, January 14, 2018 4:38 PM
To: Huangyihong (Rachel); xrblock
Subject: RE: ippm metrics registry for xrblock metrics

Hi Rachel,
please see replies/opinion in-line,
Al

From: Huangyihong (Rachel) [mailto:[e-mail]]
Sent: Monday, January 08, 2018 9:52 PM
To: xrblock
Cc: MORTON, ALFRED C (AL)
Subject: ippm metrics registry for xrblock metrics

Hi,

IPPM has the work that defines the Entries for the Performance Metrics Registry (draft-ietf-ippm-metric-registry-13).  The motivation is to have a single point of reference for performance metrics defined in different working groups, and also achieved interoperability. The initial entries for the performance metrics registry (draft-ietf-ippm-initial-registry-05) has a section 12 to show an example that RTCP XR metrics could also be registered into it, but the authors didn't put too energy in this and expect some RTCP XR people could be do this if they think it's useful.
[ACM]
The original purpose of section 12 was to demonstrate that the
registry structure (at the time) was sufficiently detailed to
specify an RTCP-XR metric, and what the entry would look like.
It was important to illustrate how the concepts of Fixed and Run-time
Parameters were well-matched to the needs of RTCP-XR.

I'm following this work. From my point of view, it's useful as it is allowed for some reporting protocols other than RTCP SR/RR/XR to report these RTP related metrics. But we don't need to registry all the existing XR metrics. Some of them like Loss, Discard, Delay, Burst metrics, defined in RFC3611, 6843, 6958, 7003 may be quite useful and widely used in the industry.

I'm sending this email to ask for WG's opinions. Do you think it is a valuable work, and if it is, do these metrics make sense to you?
[ACM]
First, it's worthwhile to examine the criteria for Metric Registration:
https://tools.ietf.org/html/draft-ietf-ippm-metric-registry-13#section-5
especially the last paragraph.

Another goal (enabled by item 4) is to facilitate comparison
of measurements, even when using independent implementations
of measurement systems, so that performance of networks can
be compared.  Item 4 is fairly demanding in terms of the
specificity of the Registry Entry details, and it may be
more demanding than necessary to use RTCP XR metrics for
operational monitoring or other purposes internal to the
network operator or user.

So, section 5 and the demands it places on Registry entry composition
are worth considering further. There is no need to have a
detailed registry entry for *every* metric specified, IMO.


BR,
Rachel