Performance Metrics Registry
draft-claise-ippm-perf-metric-registry-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Benoît Claise , Aamer Akhter | ||
| Last updated | 2013-07-15 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-claise-ippm-perf-metric-registry-00
IPPM Working Group B. Claise
Internet-Draft A. Akhter
Intended status: Standards Track Cisco Systems, Inc.
Expires: January 16, 2014 July 15, 2013
Performance Metrics Registry
draft-claise-ippm-perf-metric-registry-00.txt
Abstract
This document specifies an IANA registry for Performance Metrics.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 16, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Claise & Akhter Expires January 16, 2014 [Page 1]
Internet-Draft PERF-METRIC REGISTRY July 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Guidelines for considering New Performance Metric Development 3
2.1. Performance Metric Template Definition . . . . . . . . . 4
2.2. Performance Metric Directorate . . . . . . . . . . . . . 4
3. Performance Metrics in the IPFIX Registry . . . . . . . . . . 5
4. Initial Set of Performance Metrics . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
The IETF has been specifying and continues to specify Performance
Metrics. While IP Performance Metris (IPPM) is the working group
(WG) primarily focusing on Peformance Metrics definition at the IETF,
other working groups, have also specified Peformance Metrics. The
"Metric Blocks for use with RTCP's Extended Report Framework"
[XRBLOCK] WG recently specified many Peformance Metrics related to
"RTP Control Protocol Extended Reports (RTCP XR)" [RFC3611], which
establishes a framework to allow new information to be conveyed in
RTCP, supplementing the original report blocks defined in "RTP: A
Transport Protocol for Real-Time Applications", [RFC3550]. The
Benchmarking Methodology" [BMWG] WG proposed some Peformance Metrics
part of the benchmarking methodology. The IP Flow Information eXport
WG (IPFIX) [IPFIX] Information elements related to performance
metrics are currently proposed. The Performance Metrics for Other
Layers (PMOL) [PMOL], a concluded working group, defined some
Peformance Metrics related to Session Initiation Protocol (SIP) voice
quality [RFC6035]. It is expected that more and more Peformance
Metrics will be defined in the future, not only IP based metrics, but
also protocol-specific ones and application-specific ones.
However, there is currently no Peformance Metrics registry in IANA.
This creates a real problem for the industry: first to discover which
performance metrics have already specified, second to avoid
Peformance Metrics redefinition. Only someone with a broad IETF
knowledge would be able to find its way among all the different
Peformance Metrics specified in the different WGs.
The IPPM Metrics Registry (RFC4148) was an attempt to create such a
Peformance Metrics registry. However, that registry was reclassified
Claise & Akhter Expires January 16, 2014 [Page 2]
Internet-Draft PERF-METRIC REGISTRY July 2013
as obsolete with [RFC6248], "RFC 4148 and the IP Performance Metrics
(IPPM) Registry of Metrics Are Obsolete", and consequently withdrawn.
A couple of interesting quotes from RFC 4148 might help understand
the issues related to that registry.
1. "It is not believed to be feasible or even useful to register
every possible combination of Type P, metric parameters, and
Stream parameters using the current structure of the IPPM Metrics
Registry."
2. "The registry structure has been found to be insufficiently
detailed to uniquely identify IPPM metrics."
3. "Despite apparent efforts to find current or even future users,
no one responded to the call for interest in the RFC 4148
registry during the second half of 2010."
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
[RFC6390] defines:
Performance Metric: A Performance Metric is a quantitative measure
of performance, specific to an IETF-specified protocol or specific
to an application transported over an IETF-specified protocol.
Examples of Performance Metrics are the FTP response time for a
complete file download, the DNS response time to resolve the IP
address, a database logging time, etc.
Performance Metrics Directorate: The Performance Metrics Directorate
is a directorate that provides guidance for Performance Metrics
development in the IETF. The Performance Metrics Directorate
should be composed of experts in the performance community,
potentially selected from the IP Performance Metrics (IPPM),
Benchmarking Methodology (BMWG), and Performance Metrics for Other
Layers (PMOL) WGs.
2. Guidelines for considering New Performance Metric Development
"Guidelines for Considering New Performance Metric Development",
[RFC6390] defines a framework and a process for developing
Performance Metrics for protocols above and below the IP layer (such
as IP-based applications that operate over reliable or datagram
Claise & Akhter Expires January 16, 2014 [Page 3]
Internet-Draft PERF-METRIC REGISTRY July 2013
transport protocols). These metrics can be used to characterize
traffic on live networks and services. As such, RFC 6390 does not
define any Performance Metrics.
RFC 6390 scope covers guidelines for the Performance Metrics
Directorate members for considering new Performance Metrics and
suggests how the Performance Metrics Directorate will interact with
the rest of the IETF.
2.1. Performance Metric Template Definition
RFC 6390 imposes a template to be used for Peformance Metrics
specification.
Normative
o Metric Name
o Metric Description
o Method of Measurement or Calculation
o Units of Measurement
o Measurement Point(s) with potential Measurement Domain
o Measurement Timing
Informative
o Implementation
o Verification
o Use and Applications
o Reporting Model
2.2. Performance Metric Directorate
The performance metrics directorate mission is mentioned at
[performance-metrics-directorate]:
The Performance Metrics Directorate assists the OPS Area Directors
to review performance-related documents intended for IESG review.
The Performance Metrics Directorate can also act as advisors to
Working Groups in any area of the IETF: it provides guidance to
Claise & Akhter Expires January 16, 2014 [Page 4]
Internet-Draft PERF-METRIC REGISTRY July 2013
protocol development Working Groups when considering an Internet-
Draft that specifies Performance Metrics for a protocol. Such can
be arranged between the WG chairs and the Directorate
Administrator (or the responsible ADs).
In forthcoming reviews, the Performance Metrics Directorate will
be applying the Guidelines for Considering New Performance Metric
Development, RFC 6390.
The review will be sent to the Performance Metrics Directorate
mailing list (pm-dir@ietf.org), to the draft authors, WG chairs,
and respective AD. The way to reach the authors, WG chairs, and
respective AD is to send an email to "draft-
name".all@tools.ietf.org.
In practice, a weekly cron job discovers all the IETF drafts that
refers to RFC 6390, or that contains the keyword "performance
metric". Once discovered, the different drafts are assigned a
Peformance Metric Directorate reviewer. One of the primary task is
to ensure that the RFC 6390 template is correctly applied, making
sure that the Peformance Metric semantic is correctly specified.
3. Performance Metrics in the IPFIX Registry
There are multiple proposals to add performance metrics Information
Elements in the IPFIX IANA registry [iana-ipfix-assignments], to be
used with the IPFIX protocol [I-D.ietf-ipfix-protocol-rfc5101bis].
This is perfectly legal according the "Information Model for IPFIX"
[I-D.ietf-ipfix-information-model-rfc5102bis] and "Guidelines for
Authors and Reviewers of IPFIX Information Elements"
[I-D.ietf-ipfix-ie-doctors].
Simply adding some text in the Information Element Description field
might be a solution if this description is compliant with the RFC6390
template definition. However, this is not a ideal solution. On the
top of having potentially long descriptions, this imposes a specific
formatting for the description field of the performance metrics-
related Information Elements, while none is imposed for the non
performance metrics-related ones.
The preferred approach is for the Peformance Metrics to be self-
described in their own registry. When the Peformance Metrics needs
to be defined in the IPFIX IANA registry, the new Information Element
can simply refer to the specific entry in the Peformance Metrics
registry.
4. Initial Set of Performance Metrics
Claise & Akhter Expires January 16, 2014 [Page 5]
Internet-Draft PERF-METRIC REGISTRY July 2013
This section contains a list of Peformance Metrics specified
according to [RFC6390], either in RFCs, or IETF drafts currently in
the RFC editor queue.
Threshold in RTP: [RFC6958], appendix A
Sum of Burst Durations in RTP: [RFC6958], appendix A
RTP Packets lost in bursts: [RFC6958], appendix A
Total RTP packets expected in bursts: [RFC6958], appendix A
Threshold in RTP: [RFC6958], appendix A
Number of bursts in RTP: [RFC6958], appendix A
Sum of Squares of Burst Durations in RTP:
[RFC6958], appendix A
RTP Burst Loss Rate:
[I-D.ietf-xrblock-rtcp-xr-summary-stat], appendix A
RTP Burst Loss Rate:
[I-D.ietf-xrblock-rtcp-xr-summary-stat], appendix A
RTP Gap Loss Rate:
[I-D.ietf-xrblock-rtcp-xr-summary-stat], appendix A
RTP Burst Duration Mean:
[I-D.ietf-xrblock-rtcp-xr-summary-stat], appendix A
RTP Burst duration variance:
[I-D.ietf-xrblock-rtcp-xr-summary-stat], appendix A
RTP Burst Discard Rate:
[I-D.ietf-xrblock-rtcp-xr-summary-stat], appendix A
RTP Gap Discard Rate:
[I-D.ietf-xrblock-rtcp-xr-summary-stat], appendix A
Number of discarded frames in RTP:
[I-D.ietf-xrblock-rtcp-xr-summary-stat], appendix A
Number of duplicate frames in RTP:
[I-D.ietf-xrblock-rtcp-xr-summary-stat], appendix A
Number of full lost frames in RTP:
[I-D.ietf-xrblock-rtcp-xr-summary-stat], appendix A
Claise & Akhter Expires January 16, 2014 [Page 6]
Internet-Draft PERF-METRIC REGISTRY July 2013
Number of partial lost frames in RTP:
[I-D.ietf-xrblock-rtcp-xr-summary-stat], appendix A
Threshold in RTP:
[I-D.ietf-xrblock-rtcp-xr-burst-gap-discard], appendix A
RTP Packets discarded in bursts:
[I-D.ietf-xrblock-rtcp-xr-burst-gap-discard], appendix A
Total RTP packets expected in bursts:
[I-D.ietf-xrblock-rtcp-xr-burst-gap-discard], appendix A
Number of RTP packets discarded Metric:
[I-D.ietf-xrblock-rtcp-xr-discard], appendix A
de-jitter buffer nominal delay in RTP:
[I-D.ietf-xrblock-rtcp-xr-jb], appendix A
de-jitter buffer maximum delay in RTP:
[I-D.ietf-xrblock-rtcp-xr-jb], appendix A
de-jitter buffer high water mark in RTP:
[I-D.ietf-xrblock-rtcp-xr-jb], appendix A
de-jitter buffer low water mark in RTP:
[I-D.ietf-xrblock-rtcp-xr-jb], appendix A
5. Security Considerations
This draft doesn't introduce any security considerations. However,
the definition of Peformance Metrics may introduce some security
concerns, and should be reviewed with security in mind.
6. IANA Considerations
This document refers to an initial set of Peformance Metrics. The
list of these Information Elements is given in the "Initial Set of
Performance Metrics" Section. The Internet Assigned Numbers
Authority (IANA) has created a new registry for Peformance Metrics
called "Performance Metrics", and filled it with the initial list in
Section 4.
Claise & Akhter Expires January 16, 2014 [Page 7]
Internet-Draft PERF-METRIC REGISTRY July 2013
New assignments for Peformance Metric will be administered by IANA
through Expert Review [RFC5226], i.e., review by one of a group of
experts designated by an IETF Area Director. The group of experts
MUST check the requested Peformance Metric for completeness, accuracy
of the template description, and for correct naming according to
[RFC6390]. Requests for Performance Metric that duplicate the
functionality of existing Performance Metris SHOULD be declined.
The specification of new Performance Metrics MUST use the template
specified in Section 5.4.4 of RFC 6390 and MUST be published using a
well-established and persistent publication medium. The experts will
initially be drawn from the Working Group Chairs and document editors
of the Peformance Metrics directorate
[performance-metrics-directorate].
7. Acknowledgments
To be Completed
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", BCP 170, RFC 6390,
October 2011.
[RFC6958] Clark, A., Zhang, S., Zhao, J., and Q. Wu, "RTP Control
Protocol (RTCP) Extended Report (XR) Block for Burst/Gap
Loss Metric Reporting", RFC 6958, May 2013.
[I-D.ietf-xrblock-rtcp-xr-summary-stat]
Zorn, G., Schott, R., Wu, W., and R. Huang, "RTP Control
Protocol (RTCP) Extended Report (XR) Blocks for Summary
Statistics Metrics Reporting", draft-ietf-xrblock-rtcp-xr-
summary-stat-11 (work in progress), March 2013.
[I-D.ietf-xrblock-rtcp-xr-burst-gap-discard]
Claise & Akhter Expires January 16, 2014 [Page 8]
Internet-Draft PERF-METRIC REGISTRY July 2013
Clark, A., Huang, R., and W. Wu, "RTP Control
Protocol(RTCP) Extended Report (XR) Block for Burst/Gap
Discard metric Reporting", draft-ietf-xrblock-rtcp-xr-
burst-gap-discard-14 (work in progress), April 2013.
[I-D.ietf-xrblock-rtcp-xr-jb]
Clark, A., Singh, V., and W. Wu, "RTP Control Protocol
(RTCP) Extended Report (XR) Block for De-Jitter Buffer
Metric Reporting", draft-ietf-xrblock-rtcp-xr-jb-14 (work
in progress), June 2013.
[I-D.ietf-xrblock-rtcp-xr-discard]
Clark, A., Zorn, G., and W. Wu, "RTP Control Protocol
(RTCP) Extended Report (XR) Block for Discard Count metric
Reporting", draft-ietf-xrblock-rtcp-xr-discard-15 (work in
progress), June 2013.
8.2. Informative References
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611, November
2003.
[RFC6035] Pendleton, A., Clark, A., Johnston, A., and H. Sinnreich,
"Session Initiation Protocol Event Package for Voice
Quality Reporting", RFC 6035, November 2010.
[RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics
(IPPM) Registry of Metrics Are Obsolete", RFC 6248, April
2011.
[I-D.ietf-ipfix-protocol-rfc5101bis]
Claise, B. and B. Trammell, "Specification of the IP Flow
Information eXport (IPFIX) Protocol for the Exchange of
Flow Information", draft-ietf-ipfix-protocol-rfc5101bis-10
(work in progress), July 2013.
[I-D.ietf-ipfix-information-model-rfc5102bis]
Claise, B. and B. Trammell, "Information Model for IP Flow
Information eXport (IPFIX)", draft-ietf-ipfix-information-
model-rfc5102bis-10 (work in progress), February 2013.
[I-D.ietf-ipfix-ie-doctors]
Claise & Akhter Expires January 16, 2014 [Page 9]
Internet-Draft PERF-METRIC REGISTRY July 2013
Trammell, B. and B. Claise, "Guidelines for Authors and
Reviewers of IPFIX Information Elements", draft-ietf-
ipfix-ie-doctors-07 (work in progress), October 2012.
[iana-ipfix-assignments]
Internet Assigned Numbers Authority, ., "IP Flow
Information Export Information Elements
(http://www.iana.org/assignments/ipfix/ipfix.xml)", .
[performance-metrics-directorate]
IETF, ., "Performance Metrics Directorate (http://
www.ietf.org/iesg/directorate/performance-metrics.html)",
.
[BMWG] IETF, ., "Benchmarking Methodology (BMWG) Working Group,
http://datatracker.ietf.org/wg/bmwg/charter/", .
[IPFIX] IETF, ., "IP Flow Information eXport (IPFIX) Working
Group, http://datatracker.ietf.org/wg/ipfix/charter/", .
[PMOL] IETF, ., "IPerformance Metrics for Other Layers (PMOL)
Working Group,
http://datatracker.ietf.org/wg/pmol/charter/", .
[XRBLOCK] IETF, ., "Metric Blocks for use with RTCP's Extended
Report Framework (XRBLOCK),
http://datatracker.ietf.org/wg/xrblock/charter/", .
Authors' Addresses
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
1831 Diegem
Belgium
Phone: +32 2 704 5622
Email: bclaise@cisco.com
Aamer Akhter
Cisco Systems, Inc.
7025 Kit Creek Road
RTP, NC 27709
USA
Email: aakhter@cisco.com
Claise & Akhter Expires January 16, 2014 [Page 10]