Re: [xrblock] ippm metrics registry for xrblock metrics

"Huangyihong (Rachel)" <> Thu, 18 January 2018 06:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 93B3512EAEB for <>; Wed, 17 Jan 2018 22:54:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ic6vExfUPNdp for <>; Wed, 17 Jan 2018 22:54:24 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 94D3112EB15 for <>; Wed, 17 Jan 2018 22:54:21 -0800 (PST)
Received: from (unknown []) by Forcepoint Email with ESMTP id 6723C9C7159E3 for <>; Thu, 18 Jan 2018 06:54:18 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 18 Jan 2018 06:54:20 +0000
Received: from ([]) by ([]) with mapi id 14.03.0361.001; Thu, 18 Jan 2018 14:54:12 +0800
From: "Huangyihong (Rachel)" <>
To: "MORTON, ALFRED C (AL)" <>, xrblock <>
Thread-Topic: ippm metrics registry for xrblock metrics
Thread-Index: AdOI9MsxSVjLXGxIRRi+9VvWBmCmogEGqNJQAFiOoNA=
Date: Thu, 18 Jan 2018 06:54:11 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB9C687E92nkgeml513mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [xrblock] ippm metrics registry for xrblock metrics
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Jan 2018 06:54:28 -0000

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.


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,

From: Huangyihong (Rachel) []
Sent: Monday, January 08, 2018 9:52 PM
To: xrblock
Subject: ippm metrics registry for xrblock metrics


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.
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?
First, it's worthwhile to examine the criteria for Metric Registration:
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.