IPPM Working Group B. Claise
Internet-Draft A. Akhter
Intended status: Standards Track Best Current Practice Cisco Systems, Inc.
Expires: January 16, April 07, 2014 July 15, October 04, 2013
Performance Metrics Registry
draft-claise-ippm-perf-metric-registry-00.txt
draft-claise-ippm-perf-metric-registry-01.txt
Abstract
This document specifies an IANA registry for Performance Metrics. Metrics, for
both active monitoring and passive monitoring, along with the initial
content. This document also gives a set of guidelines for
Performance Metrics requesters and reviewers.
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, April 07, 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.
Table of Contents
1. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. 4
3. Guidelines for considering New Performance Metric Development 3
2.1. Requesters and Reviewers . 5
3.1. Performance Metric Metrics Template Definition . . . . . . . . . 4
2.2. Performance Metric Directorate . . . . . 5
3.2. Other Guidelines . . . . . . . . 4
3. Performance Metrics in the IPFIX Registry . . . . . . . . . . 5 . . 6
4. Initial Set of Performance Metrics . . . . . . . . . . . . . 5 6
4.1. Existing Performetrics Metrics, Based on the RFC6390
Template . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Mapping Some IPPM Performance Metrics in the Registry . . 8
4.2.1. IPPM Performance Metric Mapping Experiment . . . . . 9
4.2.2. Which IPPM Performance Metrics? . . . . . . . . . . . 12
5. Performance Metrics in the IPFIX Registry . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
8. 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. 13
9.2. Informative References . . . . . . . . . . . . . . . . . 9 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 16
1. Open Issues
1. Check whether the "Initial Set of Performance Metrics" is up to
date with the latest Performance Metrics published in XRBLOCK.
2. Do we want to organize the Performance Metrics list into
different layers? IP, transport layer stats, application stats,
etc?
3. "IPPM Performance Metric Mapping Experiment" for IPDV must be
validated.
4. The community will have to agree on which Performance Metrics
(along with the specific values of the measurements parameters)
are operationally relevant
5. Define "Measurement Parameter"
2. Introduction
The IETF has been specifying specifies and continues to specify uses Performance
Metrics. While IP Metrics of protocols and
applications transported over its protocols. Performance Metris metrics are
such an important part of the operations of IETF protocols that
[RFC6390] specifies guidelines for their development.
The definition and use of performance metrics in the IETF happens in
various working groups (WG), most notably:
The "IP Performance Metris" (IPPM) WG [IPPM] is the working group
(WG) WG primarily
focusing on Peformance Metrics definition at the IETF,
other working groups, have also specified Peformance Metrics. IETF.
The "Metric Blocks for use with RTCP's Extended Report Framework"
[XRBLOCK]
WG [XRBLOCK] 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 "Benchmarking Methodology" [BMWG] WG [BMWG] proposed some Peformance
Metrics part of the benchmarking methodology.
The IP "IP Flow Information eXport
WG eXport" (IPFIX) WG [IPFIX] Information
elements related to performance metrics are currently proposed.
The Performance "Performance Metrics for Other
Layers Layers" (PMOL) [PMOL], a concluded working group, WG
[PMOL], defined some Peformance Metrics related to Session
Initiation Protocol (SIP) voice quality [RFC6035].
It is expected that more and more Peformance Performance Metrics will be defined
in the future, not only IP based metrics, but also protocol-specific ones
and application-specific ones.
However, despite the abundance and importance of performance metrics,
there is currently no Peformance Metrics registry in IANA.
This creates a real problem are still some problems for the industry: first first, how to
discover which
performance metrics Performance Metrics have already specified, second and
second, how to avoid
Peformance Performance Metrics redefinition. Only someone
with a broad IETF knowledge would be able to find its way among all
the different
Peformance Performance Metrics specified in the different WGs.
The way in which IETF manages namespaces is with IANA registries, and
there is currently no Peformance Metrics Registry in IANA.
This document specifies an IANA registry for Performance Metrics,
along with the initial content, taken from the Performance Metrics
already specified at the IETF. Firstly, from the Performance Metrics
already specified by the RFC630 template (mentioned later on in the
document), and secondly from the existing set of IPPM Performance
Metrics. This second category requires a mapping to the RFC6390
template. This Performance Metric Registry is applicable to
Performance Metrics issued from active monitoring, passive
monitoring, or from the end point calculation. Therefore, it must
relevant to work developed in the following WGs: IPPM, LMAP, XRBLOCK,
BMWG, and IPFIX. Finally, this document gives a set of guidelines
for Performance Metrics requesters and reviewers.
Based on [RFC5226] Section 4.3, this document is processed as Best
Current Practice (BCP) [RFC2026].
The IPPM Metrics Registry (RFC4148) [RFC4148] was an attempt to create such a
Peformance
Performance Metrics registry. However, that registry was
reclassified 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 6248 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.
2.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:
The terms Performance Metric and Performance Metrics Directorate are
direct quotes from [RFC6390], and copied over in this document for
the readers convenience.
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.
Performance Metrics Registry: The IANA registry containing the
Performance Metrics. This registry is initially populated from
this document.
Measurement Parameter: NOT SURE HOW TO DEFINE THIS
3. Guidelines for considering New Performance Metric Development Requesters and Reviewers
3.1. Performance Metrics Template
"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
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
directorate members for considering new Performance Metrics and
suggests how the Performance Metrics Directorate will interact with
the rest of the IETF.
2.1. Its mission is mentioned at
[performance-metrics-directorate]. 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 Performance Metric Template Definition Directorate
reviewer. One of the primary task is to ensure that the RFC 6390 imposes
template is correctly applied, making sure that the Performance
Metric semantic is correctly specified.
RFC 6390, specified in Section 5.4, proposes a template to be used for Peformance
Performance Metrics
specification. specifications:
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.
The template specified in Section 5.4 of "Guidelines for Considering
New Performance Metric Directorate
The performance Development", [RFC6390] MUST be used as a
basis for the Performance Metrics Registry Definition.
3.2. Other Guidelines
RFC 6390 lacks a naming convention for Performance Metrics, but
specifies that "Performance Metric names are RECOMMENDED to be unique
within the set of metrics directorate mission being defined for the protocol layer and
context.". Imposing an unique Performane Metric name, while ideal,
is mentioned at
[performance-metrics-directorate]:
The not practicable in real live. Indeed, some metrics have already
been specified, and the name clashes appeared already. Therefore,
all Performance Metrics Directorate assists specified in the OPS Area Directors registry MUST have an unique
performance metric Id. Regarding naming convention, the Performance
Metric Names SHOULD be meaningfull and easily searchable in the
registry.
The group of experts (the reviewers) MUST check the requested
Peformance Metric for completeness, accuracy of the template
description, and for correct naming according to review performance-related documents intended [RFC6390].
Requests for IESG review.
The Performance Metric that duplicate the functionality of
existing Performance Metris SHOULD be declined.
4. Initial Set of Performance Metrics Directorate can also act as advisors
4.1. Existing Performetrics Metrics, Based on the RFC6390 Template
This section contains a list of Performance Metrics specified
according to
Working Groups [RFC6390], either in any area RFCs, or IETF drafts currently in
the RFC editor queue. This list should serve as initial content for
the Performance Metrics Registry.
+-------------------+---------------------------+-------------------+
| Performance | Performance Metric | Reference |
| Metric Id | | |
+-------------------+---------------------------+-------------------+
| 1 | Threshold in RTP | [RFC6958], |
| | | appendix A |
| 2 | Sum of Burst Durations in | [RFC6958], |
| | RTP | appendix A |
| 3 | RTP Packets lost in | [RFC6958], |
| | bursts | appendix A |
| 4 | Total RTP packets | [RFC6958], |
| | expected in bursts | appendix A |
| 5 | Number of bursts in RTP | [RFC6958], |
| | | appendix A |
| 6 | Sum of Squares of Burst | [RFC6958], |
| | Durations in RTP | appendix A |
| 7 | Number of RTP packets | [RFC7002], |
| | discarded Metric | appendix A |
| 8 | Threshold in RTP | [RFC7003], |
| | | appendix A |
| 9 | RTP Packets discarded in | [RFC7003], |
| | bursts | appendix A |
| 10 | Total RTP packets | [RFC7003], |
| | expected in bursts | appendix A |
| 11 | RTP Burst Loss Rate | [RFC7004], |
| | | appendix A |
| 12 | RTP Gap Loss Rate | [RFC7004], |
| | | appendix A |
| 13 | RTP Burst Duration Mean | [RFC7004], |
| | | appendix A |
| 14 | RTP Burst duration | [RFC7004], |
| | variance | appendix A |
| 15 | RTP Burst Discard Rate | [RFC7004], |
| | | appendix A |
| 16 | RTP Gap Discard Rate | [RFC7004], |
| | | appendix A |
| 17 | Number of discarded | [RFC7004], |
| | frames in RTP | appendix A |
| 18 | Number of duplicate | [RFC7004], |
| | frames in RTP | appendix A |
| 19 | Number of full lost | [RFC7004], |
| | frames in RTP | appendix A |
| 20 | Number of partial lost | [RFC7004], |
| | frames in RTP | appendix A |
| 21 | De-jitter buffer nominal | [RFC7005], |
| | delay in RTP | appendix A |
| 22 | De-jitter buffer maximum | [RFC7005], |
| | delay in RTP | appendix A |
| 23 | De-jitter buffer high | [RFC7005], |
| | water mark in RTP | appendix A |
| 24 | De-jitter buffer low | [RFC7005], |
| | water mark in RTP: | appendix A |
+-------------------+---------------------------+-------------------+
Table 1: List of Existing Performance Metrics Specified at the IETF: it provides guidance to
protocol development Working Groups when considering an Internet-
Draft that specifies IETF
4.2. Mapping Some IPPM Performance Metrics in the Registry
The IPPM WG [IPPM] specified some Measurement Parameters (or
measurement characteristics), for example Type-P [RFC2330], packet
distribution, etc.
The IPPM WG also specified Performance Metrics. For example:
A One-way Delay Metric for IPPM [RFC2679]
A One-way Packet Loss Metric for IPPM [RFC2680]
A Round-trip Delay Metric for IPPM [RFC2681]
Those Performance Metrics are based on specific values for the
Measurement Parameters. For example: the mean packet loss at IP
layer, based on a protocol. Such periodic packet distribution, represented with
percentile 95th.
The Performance Metrics Registry should contain the IPPM-specified
Performance Metrics that are operationally relevant, as oppposed to
all Performance Metrics, resulting of all the potential combination
of Measurement Parameters.
In a typical Large-Scale Measurement of Broadband Performance (LMAP)
environment, some information can complement the test to be arranged between run:
Measurement Parameters configured part of the WG chairs and test definition
run-time parameters observed during the Directorate
Administrator (or test
If a test definition requests the responsible ADs).
In forthcoming reviews, round-trip delay metric to a DNS
server to be metered "now", the DNS server is a Measurement Parameter
configured part of the test definition. Some run-time parameters
observed during the test complement the test report: the IP address
of the DNS server, the measurement start time, the measurement end
time, the DSCP, the TTL, etc.
Those run-time parameters are not part of the Performance Metrics Directorate will
be applying Metric
definition, while the Guidelines specific values for Considering New the Measurement Parameters
are part of it.
4.2.1. IPPM Performance Metric
Development, RFC 6390.
The review will be sent to Mapping Experiment
This section is an illustration on how the IP Packet Delay Variation
(IPDV) Performance Metrics Directorate
mailing list (pm-dir@ietf.org), Metric [RFC3393] maps to the draft authors, WG chairs, RFC 6390 template.
Note that the delay variation is sometimes called "jitter", as
mentioned in the section 1.1 of [RFC3393], and respective AD. in section 1 of
[RFC5481].
Normative Reference
Performance Metric Element ID
TBD1: The way next available Performance Metric Element ID in
the Performance Metric Registry.
Metric Name
Packet Delay Variation for UDP Packet with Periodic
Distribution reported as 95th percentile
Metric Description
The difference between the one-way-delay of the selected
packets, reported as the positive 95th percentile.
The default measurement parameters are
o L, a packet length in bits, in case of active probing. L
= 200 bits.
o Tmax, a maximum waiting time for packets to arrive at Dst,
set sufficiently long to reach disambiguate packets with long
delays from packets that are discarded (lost). Tmax = 3
seconds.
o Inter packets time of 20 msec
o etc. (I have not reviewed all the authors, WG chairs, parameters of [RFC3393]
If any of those measurement parameters is not the default
value, its value must be stored with the performance metric
value, as context information. THIS IS UP TO DISCUSSION.
Method of Measurement or Calculation
As documented in Section 4.1 of [RFC5481]: If we have
packets in a stream consecutively numbered i = 1,2,3,...
falling within the test interval, then IPDV(i) = D(i)-D(i-1)
where D(i) denotes the one-way delay of the ith packet of a
stream.
One-way delays are the difference between timestamps applied
at the ends of the path, or the receiver time minus the
transmission time.
So D(2) = R2-T2. With this timestamp notation, it can be
shown that IPDV also represents the change in inter-packet
spacing between transmission and
respective AD reception:
IPDV(2) = D(2) - D(1) = (R2-T2) - (R1-T1) = (R2-R1) -
(T2-T1)
Units of Measurement
As documented in Section 8.3 of [RFC5481]: With IPDV, it is
interesting to send report on a positive percentile, and an email
inter-quantile range is appropriate to "draft-
name".all@tools.ietf.org.
In practice, a weekly cron job discovers all reflect both positive
and negative tails (e.g., 5% to 95%). If the IETF drafts that
refers IPDV
distribution is symmetric around a mean of zero, then it is
sufficient to RFC 6390, report on the positive side of the
distribution.
The unit of measurement is percentile 95th.
Measurement Point(s) with potential Measurement Domain
As documented in Section 4.1 of [RFC5481]: Both IPDV and PDV
are derived from the one-way-delay metric. One-way delay
requires knowledge of time at two points, e.g., the source
and destination of an IP network path in end-to-end
measurement. Therefore, both IPDV and PDV can be
categorized as 2-point metrics because they are derived from
one-way delay. Specific methods of measurement may make
assumptions or that contains have a priori knowledge about one of the keyword "performance
metric". Once discovered,
measurement points, but the different drafts metric definitions themselves
are assigned based on information collected at two measurement
points.
Measurement Timing
As documented in Section 4.1 of [RFC5481]: The mean of all
IPDV(i) for a
Peformance Metric Directorate reviewer. One stream is usually zero. However, a slow delay
change over the life of the primary task stream, or a frequency error
between the measurement system clocks, can result in a non-
zero mean.
See also http://tools.ietf.org/html/rfc5481#section-6.3 for
"clock stability and error" considerations.
See also http://tools.ietf.org/html/rfc5481#section-8.5 for
"clock Sync Options" considerations.
Informative Reference
Implementation
As documented in Section 4.1 of [RFC5481]: Note that IPDV
can take on positive and negative values (and zero). One
way to analyze the IPDV results is to ensure concentrate on the
positive excursions. However, this approach has limitations
that are discussed in more detail below (see Section 5.3 of
[RFC5481]).
Verification
Not Applicable
Use and Applications
See section 7 " Applicability of the RFC 6390 template Delay Variation Forms
and Recommendations" of [RFC5481]:
Reporting Model
As mentioned previously: If any of those measurement
parameters is correctly applied, making
sure that not the Peformance Metric semantic default, its value must be stored with
the performance metric value, as context information.
4.2.2. Which IPPM Performance Metrics?
Not all possible combinations of Measurement Parameters for all IPPM
Performance Metrics will populate the Performance Metrics Registry.
The criteria for selecting the Performance Metrics are (based on
discussion with Brian Trammell):
(1) interpretable by the user
(2) implementable by the software designer
(3) deployable by network operators, without major impact on the
networks
(4) accurate, for interoperability and deployment across vendors
Which IPPM Performance Metrics will be selected for the Performance
Registry is correctly specified.
3. out of the scope of this document, for now. What is
envisioned is a RFC similar to "Basic Requirements for IPv6 Customer
Edge Routers", [RFC6204], but for Performance Metrics: "Basic
Performance Metrics Requirements for IP Packet SLA Monitoring with
Active Probing", or something similar. This document would explain
the list of Performance Metrics (from the Performance Metrics
Registry, so with fixed Measurement Parameters), along with some
proposed run time parameters, depending on the deployment scenario.
5. 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]. [RFC7011]. This is perfectly legal
according the "Information Model for IPFIX"
[I-D.ietf-ipfix-information-model-rfc5102bis] [RFC7012] and "Guidelines
for Authors and Reviewers of IPFIX Information Elements"
[I-D.ietf-ipfix-ie-doctors]. [RFC7013].
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 an 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 Performance Metrics to be self-
described in their own registry. When the Peformance Performance 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
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
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.
registry.
6. Security Considerations
This draft doesn't introduce any security considerations. However,
the definition of Peformance Performance Metrics may introduce some security
concerns, and should be reviewed with security in mind.
6.
7. IANA Considerations
This document refers to an initial set of Peformance Performance 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 Performance Metrics
called "Performance Metrics", and filled it with the initial list in
Section 4.
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 appointed 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 IESG upon recommendation 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. Ops Area
Directors. The experts will initially be drawn from the Working
Group Chairs and document editors of the Peformance Performance Metrics
directorate [performance-metrics-directorate].
7. Acknowledgments
To be Completed
8. Acknowledgments
Thanks to Carlos Pignataro for improving the text of version 00.
9. References
8.1.
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393,
November 2002.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation
Applicability Statement", RFC 5481, March 2009.
[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]
[RFC7002] Clark, A., Zorn, G., Schott, R., Wu, W., and R. Huang, Q. Wu, "RTP Control Protocol
(RTCP) Extended Report (XR) Blocks Block for Summary
Statistics Metrics Discard Count Metric
Reporting", draft-ietf-xrblock-rtcp-xr-
summary-stat-11 (work in progress), March RFC 7002, September 2013.
[I-D.ietf-xrblock-rtcp-xr-burst-gap-discard]
[RFC7003] Clark, A., Huang, R., and W. Q. Wu, "RTP Control
Protocol(RTCP) Protocol
(RTCP) Extended Report (XR) Block for Burst/Gap Discard metric
Metric Reporting", draft-ietf-xrblock-rtcp-xr-
burst-gap-discard-14 (work in progress), April RFC 7003, September 2013.
[I-D.ietf-xrblock-rtcp-xr-jb]
Clark, A., Singh, V., and W.
[RFC7004] Zorn, G., Schott, R., Wu, Q., and R. Huang, "RTP Control
Protocol (RTCP) Extended Report (XR) Block Blocks for De-Jitter Buffer
Metric Summary
Statistics Metrics Reporting", draft-ietf-xrblock-rtcp-xr-jb-14 (work
in progress), June RFC 7004, September 2013.
[I-D.ietf-xrblock-rtcp-xr-discard]
[RFC7005] Clark, A., Zorn, G., Singh, V., and W. Q. Wu, "RTP Control Protocol
(RTCP) Extended Report (XR) Block for Discard Count metric De-Jitter Buffer
Metric Reporting", draft-ietf-xrblock-rtcp-xr-discard-15 (work in
progress), June RFC 7005, September 2013.
8.2.
9.2. Informative References
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, May
1998.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, September 1999.
[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.
[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics
Registry", BCP 108, RFC 4148, August 2005.
[RFC6035] Pendleton, A., Clark, A., Johnston, A., and H. Sinnreich,
"Session Initiation Protocol Event Package for Voice
Quality Reporting", RFC 6035, November 2010.
[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O.
Troan, "Basic Requirements for IPv6 Customer Edge
Routers", RFC 6204, April 2011.
[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]
[RFC7011] Claise, B. and B. B., Trammell, B., and P. Aitken, "Specification of
the IP Flow Information eXport Export (IPFIX) Protocol for the
Exchange of Flow Information", draft-ietf-ipfix-protocol-rfc5101bis-10
(work in progress), July STD 77, RFC 7011, September
2013.
[I-D.ietf-ipfix-information-model-rfc5102bis]
[RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow
Information eXport Export (IPFIX)", draft-ietf-ipfix-information-
model-rfc5102bis-10 (work in progress), February RFC 7012, September 2013.
[I-D.ietf-ipfix-ie-doctors]
[RFC7013] Trammell, B. and B. Claise, "Guidelines for Authors and
Reviewers of IPFIX IP Flow Information Export (IPFIX)
Information Elements", draft-ietf-
ipfix-ie-doctors-07 (work in progress), October 2012. BCP 184, RFC 7013, September 2013.
[iana-ipfix-assignments]
Internet Assigned Numbers Authority, ., "IP Flow
Information Export Information Elements
(http://www.iana.org/assignments/ipfix/ipfix.xml)",
(http://www.iana.org/assignments/ipfix/)", .
[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/", .
[IPPM] IETF, ., "IP Performance Metrics (IPPM) Working Group,
http://datatracker.ietf.org/wg/ippm/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