Re: [xrblock] ippm metrics registry for xrblock metrics

"MORTON, ALFRED C (AL)" <acmorton@att.com> Sun, 14 January 2018 08:38 UTC

Return-Path: <acmorton@att.com>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED33C126C0F for <xrblock@ietfa.amsl.com>; Sun, 14 Jan 2018 00:38:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.72
X-Spam-Level:
X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eflaS0LXCyZk for <xrblock@ietfa.amsl.com>; Sun, 14 Jan 2018 00:38:26 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 083E9126B6D for <xrblock@ietf.org>; Sun, 14 Jan 2018 00:38:26 -0800 (PST)
Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id w0E8ZDep002032; Sun, 14 Jan 2018 03:38:22 -0500
Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by mx0a-00191d01.pphosted.com with ESMTP id 2ffvm75b1q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 14 Jan 2018 03:38:21 -0500
Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id w0E8cKv7078872; Sun, 14 Jan 2018 02:38:21 -0600
Received: from dalint01.pst.cso.att.com (dalint01.pst.cso.att.com [135.31.133.159]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id w0E8cElS078825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 14 Jan 2018 02:38:15 -0600
Received: from zlp30494.vci.att.com (zlp30494.vci.att.com [135.46.181.159]) by dalint01.pst.cso.att.com (RSA Interceptor); Sun, 14 Jan 2018 08:37:59 GMT
Received: from zlp30494.vci.att.com (zlp30494.vci.att.com [127.0.0.1]) by zlp30494.vci.att.com (Service) with ESMTP id AB69C4000484; Sun, 14 Jan 2018 08:37:59 +0000 (GMT)
Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30494.vci.att.com (Service) with ESMTP id 8EE2F4000481; Sun, 14 Jan 2018 08:37:59 +0000 (GMT)
Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id w0E8bxiO029647; Sun, 14 Jan 2018 02:37:59 -0600
Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.255.15]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id w0E8bseB029437; Sun, 14 Jan 2018 02:37:54 -0600
Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-green.research.att.com (Postfix) with ESMTP id 740D1E494E; Sun, 14 Jan 2018 03:36:27 -0500 (EST)
Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0361.001; Sun, 14 Jan 2018 03:37:53 -0500
From: "MORTON, ALFRED C (AL)" <acmorton@att.com>
To: "Huangyihong (Rachel)" <rachel.huang@huawei.com>, xrblock <xrblock@ietf.org>
Thread-Topic: ippm metrics registry for xrblock metrics
Thread-Index: AdOI9MsxSVjLXGxIRRi+9VvWBmCmogEGqNJQ
Date: Sun, 14 Jan 2018 08:37:52 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CF490A1494@njmtexg5.research.att.com>
References: <51E6A56BD6A85142B9D172C87FC3ABBB9C684C77@nkgeml513-mbs.china.huawei.com>
In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB9C684C77@nkgeml513-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.10.154.45]
Content-Type: multipart/alternative; boundary="_000_4D7F4AD313D3FC43A053B309F97543CF490A1494njmtexg5researc_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-14_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801140123
Archived-At: <https://mailarchive.ietf.org/arch/msg/xrblock/vcvrwS2Xeza_BdNZgBnw0Fjw7w4>
Subject: Re: [xrblock] ippm metrics registry for xrblock metrics
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <xrblock.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xrblock>, <mailto:xrblock-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xrblock/>
List-Post: <mailto:xrblock@ietf.org>
List-Help: <mailto:xrblock-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xrblock>, <mailto:xrblock-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Jan 2018 08:38:28 -0000

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

From: Huangyihong (Rachel) [mailto:rachel.huang@huawei.com]
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