< draft-claise-ippm-perf-metric-registry-00.txt   draft-claise-ippm-perf-metric-registry-01.txt >
IPPM Working Group B. Claise IPPM Working Group B. Claise
Internet-Draft A. Akhter Internet-Draft A. Akhter
Intended status: Standards Track Cisco Systems, Inc. Intended status: Best Current Practice Cisco Systems, Inc.
Expires: January 16, 2014 July 15, 2013 Expires: April 07, 2014 October 04, 2013
Performance Metrics Registry Performance Metrics Registry
draft-claise-ippm-perf-metric-registry-00.txt draft-claise-ippm-perf-metric-registry-01.txt
Abstract Abstract
This document specifies an IANA registry for Performance Metrics. This document specifies an IANA registry for Performance 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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 16, 2014. This Internet-Draft will expire on April 07, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Guidelines for considering New Performance Metric Development 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Performance Metric Template Definition . . . . . . . . . 4 3. Guidelines for Performance Metric Requesters and Reviewers . 5
2.2. Performance Metric Directorate . . . . . . . . . . . . . 4 3.1. Performance Metrics Template . . . . . . . . . . . . . . 5
3. Performance Metrics in the IPFIX Registry . . . . . . . . . . 5 3.2. Other Guidelines . . . . . . . . . . . . . . . . . . . . 6
4. Initial Set of Performance Metrics . . . . . . . . . . . . . 5 4. Initial Set of Performance Metrics . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4.1. Existing Performetrics Metrics, Based on the RFC6390
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 Template . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Mapping Some IPPM Performance Metrics in the Registry . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2.1. IPPM Performance Metric Mapping Experiment . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 4.2.2. Which IPPM Performance Metrics? . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 9 5. Performance Metrics in the IPFIX Registry . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Open Issues
The IETF has been specifying and continues to specify Performance 1. Check whether the "Initial Set of Performance Metrics" is up to
Metrics. While IP Performance Metris (IPPM) is the working group date with the latest Performance Metrics published in XRBLOCK.
(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. 2. Do we want to organize the Performance Metrics list into
This creates a real problem for the industry: first to discover which different layers? IP, transport layer stats, application stats,
performance metrics have already specified, second to avoid etc?
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 3. "IPPM Performance Metric Mapping Experiment" for IPDV must be
Peformance Metrics registry. However, that registry was reclassified validated.
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 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 specifies and uses Performance Metrics of protocols and
applications transported over its protocols. Performance 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 WG primarily
focusing on Peformance Metrics definition at the IETF.
The "Metric Blocks for use with RTCP's Extended Report Framework"
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 Methodology" WG [BMWG] proposed some Peformance
Metrics part of the benchmarking methodology.
The "IP Flow Information eXport" (IPFIX) WG [IPFIX] Information
elements related to performance metrics are currently proposed.
The "Performance Metrics for Other Layers" (PMOL) concluded WG
[PMOL], defined some Peformance Metrics related to Session
Initiation Protocol (SIP) voice quality [RFC6035].
It is expected that more and more Performance Metrics will be defined
in the future, not only IP based metrics, but also protocol-specific
and application-specific ones.
However, despite the abundance and importance of performance metrics,
there are still some problems for the industry: first, how to
discover which Performance Metrics have already specified, and
second, how to avoid Performance Metrics redefinition. Only someone
with a broad IETF knowledge would be able to find its way among all
the different 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] was an attempt to create such a
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 6248 might help understand
the issues related to that registry. the issues related to that registry.
1. "It is not believed to be feasible or even useful to register 1. "It is not believed to be feasible or even useful to register
every possible combination of Type P, metric parameters, and every possible combination of Type P, metric parameters, and
Stream parameters using the current structure of the IPPM Metrics Stream parameters using the current structure of the IPPM Metrics
Registry." Registry."
2. "The registry structure has been found to be insufficiently 2. "The registry structure has been found to be insufficiently
detailed to uniquely identify IPPM metrics." detailed to uniquely identify IPPM metrics."
3. "Despite apparent efforts to find current or even future users, 3. "Despite apparent efforts to find current or even future users,
no one responded to the call for interest in the RFC 4148 no one responded to the call for interest in the RFC 4148
registry during the second half of 2010." registry during the second half of 2010."
1.1. Terminology 2.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [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 Performance Metric: A Performance Metric is a quantitative measure
of performance, specific to an IETF-specified protocol or specific of performance, specific to an IETF-specified protocol or specific
to an application transported over an IETF-specified protocol. to an application transported over an IETF-specified protocol.
Examples of Performance Metrics are the FTP response time for a Examples of Performance Metrics are the FTP response time for a
complete file download, the DNS response time to resolve the IP complete file download, the DNS response time to resolve the IP
address, a database logging time, etc. address, a database logging time, etc.
Performance Metrics Directorate: The Performance Metrics Directorate Performance Metrics Directorate: The Performance Metrics Directorate
is a directorate that provides guidance for Performance Metrics is a directorate that provides guidance for Performance Metrics
development in the IETF. The Performance Metrics Directorate development in the IETF. The Performance Metrics Directorate
should be composed of experts in the performance community, should be composed of experts in the performance community,
potentially selected from the IP Performance Metrics (IPPM), potentially selected from the IP Performance Metrics (IPPM),
Benchmarking Methodology (BMWG), and Performance Metrics for Other Benchmarking Methodology (BMWG), and Performance Metrics for Other
Layers (PMOL) WGs. Layers (PMOL) WGs.
2. Guidelines for considering New Performance Metric Development 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 Performance Metric Requesters and Reviewers
3.1. Performance Metrics Template
"Guidelines for Considering New Performance Metric Development", "Guidelines for Considering New Performance Metric Development",
[RFC6390] defines a framework and a process for developing [RFC6390] defines a framework and a process for developing
Performance Metrics for protocols above and below the IP layer (such Performance Metrics for protocols above and below the IP layer (such
as IP-based applications that operate over reliable or datagram as IP-based applications that operate over reliable or datagram
transport protocols). These metrics can be used to characterize transport protocols). These metrics can be used to characterize
traffic on live networks and services. As such, RFC 6390 does not traffic on live networks and services. As such, RFC 6390 does not
define any Performance Metrics. define any Performance Metrics.
RFC 6390 scope covers guidelines for the Performance Metrics RFC 6390 scope covers guidelines for the Performance Metrics
Directorate members for considering new Performance Metrics and directorate members for considering new Performance Metrics and
suggests how the Performance Metrics Directorate will interact with suggests how the Performance Metrics Directorate will interact with
the rest of the IETF. the rest of the IETF. Its mission is mentioned at
[performance-metrics-directorate]. In practice, a weekly cron job
2.1. Performance Metric Template Definition 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 Directorate
reviewer. One of the primary task is to ensure that the RFC 6390
template is correctly applied, making sure that the Performance
Metric semantic is correctly specified.
RFC 6390 imposes a template to be used for Peformance Metrics RFC 6390, specified in Section 5.4, proposes a template for
specification. Performance Metrics specifications:
Normative Normative
o Metric Name o Metric Name
o Metric Description o Metric Description
o Method of Measurement or Calculation o Method of Measurement or Calculation
o Units of Measurement o Units of Measurement
o Measurement Point(s) with potential Measurement Domain o Measurement Point(s) with potential Measurement Domain
o Measurement Timing o Measurement Timing
Informative Informative
o Implementation o Implementation
o Verification o Verification
o Use and Applications o Use and Applications
o Reporting Model o Reporting Model
2.2. Performance Metric Directorate The template specified in Section 5.4 of "Guidelines for Considering
New Performance Metric Development", [RFC6390] MUST be used as a
basis for the Performance Metrics Registry Definition.
The performance metrics directorate mission is mentioned at 3.2. Other Guidelines
[performance-metrics-directorate]:
The Performance Metrics Directorate assists the OPS Area Directors RFC 6390 lacks a naming convention for Performance Metrics, but
to review performance-related documents intended for IESG review. specifies that "Performance Metric names are RECOMMENDED to be unique
within the set of metrics being defined for the protocol layer and
context.". Imposing an unique Performane Metric name, while ideal,
is not practicable in real live. Indeed, some metrics have already
been specified, and the name clashes appeared already. Therefore,
all Performance Metrics specified in the 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 Performance Metrics Directorate can also act as advisors to The group of experts (the reviewers) MUST check the requested
Working Groups in any area of the IETF: it provides guidance to Peformance Metric for completeness, accuracy of the template
protocol development Working Groups when considering an Internet- description, and for correct naming according to [RFC6390].
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 Requests for Performance Metric that duplicate the functionality of
be applying the Guidelines for Considering New Performance Metric existing Performance Metris SHOULD be declined.
Development, RFC 6390.
The review will be sent to the Performance Metrics Directorate 4. Initial Set of Performance Metrics
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 4.1. Existing Performetrics Metrics, Based on the RFC6390 Template
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 This section contains a list of Performance Metrics specified
according to [RFC6390], either in RFCs, or IETF drafts currently in
the RFC editor queue. This list should serve as initial content for
the Performance Metrics Registry.
There are multiple proposals to add performance metrics Information +-------------------+---------------------------+-------------------+
Elements in the IPFIX IANA registry [iana-ipfix-assignments], to be | Performance | Performance Metric | Reference |
used with the IPFIX protocol [I-D.ietf-ipfix-protocol-rfc5101bis]. | Metric Id | | |
This is perfectly legal according the "Information Model for IPFIX" +-------------------+---------------------------+-------------------+
[I-D.ietf-ipfix-information-model-rfc5102bis] and "Guidelines for | 1 | Threshold in RTP | [RFC6958], |
Authors and Reviewers of IPFIX Information Elements" | | | appendix A |
[I-D.ietf-ipfix-ie-doctors]. | 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 |
+-------------------+---------------------------+-------------------+
Simply adding some text in the Information Element Description field Table 1: List of Existing Performance Metrics Specified at the IETF
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- 4.2. Mapping Some IPPM Performance Metrics in the Registry
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 The IPPM WG [IPPM] specified some Measurement Parameters (or
This section contains a list of Peformance Metrics specified measurement characteristics), for example Type-P [RFC2330], packet
according to [RFC6390], either in RFCs, or IETF drafts currently in distribution, etc.
the RFC editor queue.
Threshold in RTP: [RFC6958], appendix A The IPPM WG also specified Performance Metrics. For example:
Sum of Burst Durations in RTP: [RFC6958], appendix A A One-way Delay Metric for IPPM [RFC2679]
RTP Packets lost in bursts: [RFC6958], appendix A A One-way Packet Loss Metric for IPPM [RFC2680]
Total RTP packets expected in bursts: [RFC6958], appendix A A Round-trip Delay Metric for IPPM [RFC2681]
Threshold in RTP: [RFC6958], appendix A Those Performance Metrics are based on specific values for the
Measurement Parameters. For example: the mean packet loss at IP
layer, based on a periodic packet distribution, represented with
percentile 95th.
Number of bursts in RTP: [RFC6958], appendix A 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.
Sum of Squares of Burst Durations in RTP: In a typical Large-Scale Measurement of Broadband Performance (LMAP)
[RFC6958], appendix A environment, some information can complement the test to be run:
RTP Burst Loss Rate: Measurement Parameters configured part of the test definition
[I-D.ietf-xrblock-rtcp-xr-summary-stat], appendix A
RTP Burst Loss Rate: run-time parameters observed during the test
[I-D.ietf-xrblock-rtcp-xr-summary-stat], appendix A
RTP Gap Loss Rate: If a test definition requests the round-trip delay metric to a DNS
[I-D.ietf-xrblock-rtcp-xr-summary-stat], appendix A 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.
RTP Burst Duration Mean: Those run-time parameters are not part of the Performance Metric
[I-D.ietf-xrblock-rtcp-xr-summary-stat], appendix A definition, while the specific values for the Measurement Parameters
are part of it.
RTP Burst duration variance: 4.2.1. IPPM Performance Metric Mapping Experiment
[I-D.ietf-xrblock-rtcp-xr-summary-stat], appendix A
RTP Burst Discard Rate: This section is an illustration on how the IP Packet Delay Variation
[I-D.ietf-xrblock-rtcp-xr-summary-stat], appendix A (IPDV) Performance Metric [RFC3393] maps to the RFC 6390 template.
Note that the delay variation is sometimes called "jitter", as
mentioned in the section 1.1 of [RFC3393], and in section 1 of
[RFC5481].
RTP Gap Discard Rate: Normative Reference
[I-D.ietf-xrblock-rtcp-xr-summary-stat], appendix A
Number of discarded frames in RTP: Performance Metric Element ID
[I-D.ietf-xrblock-rtcp-xr-summary-stat], appendix A
Number of duplicate frames in RTP: TBD1: The next available Performance Metric Element ID in
[I-D.ietf-xrblock-rtcp-xr-summary-stat], appendix A the Performance Metric Registry.
Number of full lost frames in RTP: Metric Name
[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: Packet Delay Variation for UDP Packet with Periodic
[I-D.ietf-xrblock-rtcp-xr-burst-gap-discard], appendix A Distribution reported as 95th percentile
RTP Packets discarded in bursts: Metric Description
[I-D.ietf-xrblock-rtcp-xr-burst-gap-discard], appendix A
Total RTP packets expected in bursts: The difference between the one-way-delay of the selected
[I-D.ietf-xrblock-rtcp-xr-burst-gap-discard], appendix A packets, reported as the positive 95th percentile.
Number of RTP packets discarded Metric: The default measurement parameters are
[I-D.ietf-xrblock-rtcp-xr-discard], appendix A
de-jitter buffer nominal delay in RTP: o L, a packet length in bits, in case of active probing. L
[I-D.ietf-xrblock-rtcp-xr-jb], appendix A = 200 bits.
de-jitter buffer maximum delay in RTP: o Tmax, a maximum waiting time for packets to arrive at Dst,
[I-D.ietf-xrblock-rtcp-xr-jb], appendix A set sufficiently long to disambiguate packets with long
delays from packets that are discarded (lost). Tmax = 3
seconds.
de-jitter buffer high water mark in RTP: o Inter packets time of 20 msec
[I-D.ietf-xrblock-rtcp-xr-jb], appendix A o etc. (I have not reviewed all the parameters of [RFC3393]
de-jitter buffer low water mark in RTP: If any of those measurement parameters is not the default
[I-D.ietf-xrblock-rtcp-xr-jb], appendix A value, its value must be stored with the performance metric
value, as context information. THIS IS UP TO DISCUSSION.
5. Security Considerations 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 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 report on a positive percentile, and an
inter-quantile range is appropriate to reflect both positive
and negative tails (e.g., 5% to 95%). If the IPDV
distribution is symmetric around a mean of zero, then it is
sufficient to 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 have a priori knowledge about one of the
measurement points, but the metric definitions themselves
are 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 stream is usually zero. However, a slow delay
change over the life of the 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 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 Delay Variation Forms
and Recommendations" of [RFC5481]:
Reporting Model
As mentioned previously: If any of those measurement
parameters is not the 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 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 [RFC7011]. This is perfectly legal
according the "Information Model for IPFIX" [RFC7012] and "Guidelines
for Authors and Reviewers of IPFIX Information Elements" [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 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 Performance Metrics to be self-
described in their own registry. When the Performance Metrics needs
to be defined in the IPFIX IANA registry, the new Information Element
can simply refer to the specific entry in the Performance Metrics
registry.
6. Security Considerations
This draft doesn't introduce any security considerations. However, This draft doesn't introduce any security considerations. However,
the definition of Peformance Metrics may introduce some security the definition of Performance Metrics may introduce some security
concerns, and should be reviewed with security in mind. concerns, and should be reviewed with security in mind.
6. IANA Considerations 7. IANA Considerations
This document refers to an initial set of Peformance Metrics. The This document refers to an initial set of Performance Metrics. The
list of these Information Elements is given in the "Initial Set of list of these Information Elements is given in the "Initial Set of
Performance Metrics" Section. The Internet Assigned Numbers Performance Metrics" Section. The Internet Assigned Numbers
Authority (IANA) has created a new registry for Peformance Metrics Authority (IANA) has created a new registry for Performance Metrics
called "Performance Metrics", and filled it with the initial list in called "Performance Metrics", and filled it with the initial list in
Section 4. Section 4.
New assignments for Peformance Metric will be administered by IANA New assignments for Peformance Metric will be administered by IANA
through Expert Review [RFC5226], i.e., review by one of a group of through Expert Review [RFC5226], i.e., review by one of a group of
experts designated by an IETF Area Director. The group of experts experts appointed by the IESG upon recommendation of the Ops Area
MUST check the requested Peformance Metric for completeness, accuracy Directors. The experts will initially be drawn from the Working
of the template description, and for correct naming according to Group Chairs and document editors of the Performance Metrics
[RFC6390]. Requests for Performance Metric that duplicate the directorate [performance-metrics-directorate].
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 8. Acknowledgments
To be Completed Thanks to Carlos Pignataro for improving the text of version 00.
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. 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 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", BCP 170, RFC 6390, Performance Metric Development", BCP 170, RFC 6390,
October 2011. October 2011.
[RFC6958] Clark, A., Zhang, S., Zhao, J., and Q. Wu, "RTP Control [RFC6958] Clark, A., Zhang, S., Zhao, J., and Q. Wu, "RTP Control
Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Protocol (RTCP) Extended Report (XR) Block for Burst/Gap
Loss Metric Reporting", RFC 6958, May 2013. Loss Metric Reporting", RFC 6958, May 2013.
[I-D.ietf-xrblock-rtcp-xr-summary-stat] [RFC7002] Clark, A., Zorn, G., and Q. Wu, "RTP Control Protocol
Zorn, G., Schott, R., Wu, W., and R. Huang, "RTP Control (RTCP) Extended Report (XR) Block for Discard Count Metric
Protocol (RTCP) Extended Report (XR) Blocks for Summary Reporting", RFC 7002, September 2013.
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] [RFC7003] Clark, A., Huang, R., and Q. Wu, "RTP Control Protocol
Clark, A., Huang, R., and W. Wu, "RTP Control (RTCP) Extended Report (XR) Block for Burst/Gap Discard
Protocol(RTCP) Extended Report (XR) Block for Burst/Gap Metric Reporting", RFC 7003, September 2013.
Discard metric Reporting", draft-ietf-xrblock-rtcp-xr-
burst-gap-discard-14 (work in progress), April 2013.
[I-D.ietf-xrblock-rtcp-xr-jb] [RFC7004] Zorn, G., Schott, R., Wu, Q., and R. Huang, "RTP Control
Clark, A., Singh, V., and W. Wu, "RTP Control Protocol Protocol (RTCP) Extended Report (XR) Blocks for Summary
Statistics Metrics Reporting", RFC 7004, September 2013.
[RFC7005] Clark, A., Singh, V., and Q. Wu, "RTP Control Protocol
(RTCP) Extended Report (XR) Block for De-Jitter Buffer (RTCP) Extended Report (XR) Block for De-Jitter Buffer
Metric Reporting", draft-ietf-xrblock-rtcp-xr-jb-14 (work Metric Reporting", RFC 7005, September 2013.
in progress), June 2013.
[I-D.ietf-xrblock-rtcp-xr-discard] 9.2. Informative References
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 [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. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611, November Protocol Extended Reports (RTCP XR)", RFC 3611, November
2003. 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, [RFC6035] Pendleton, A., Clark, A., Johnston, A., and H. Sinnreich,
"Session Initiation Protocol Event Package for Voice "Session Initiation Protocol Event Package for Voice
Quality Reporting", RFC 6035, November 2010. 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 [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics
(IPPM) Registry of Metrics Are Obsolete", RFC 6248, April (IPPM) Registry of Metrics Are Obsolete", RFC 6248, April
2011. 2011.
[I-D.ietf-ipfix-protocol-rfc5101bis] [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of
Claise, B. and B. Trammell, "Specification of the IP Flow the IP Flow Information Export (IPFIX) Protocol for the
Information eXport (IPFIX) Protocol for the Exchange of Exchange of Flow Information", STD 77, RFC 7011, September
Flow Information", draft-ietf-ipfix-protocol-rfc5101bis-10 2013.
(work in progress), July 2013.
[I-D.ietf-ipfix-information-model-rfc5102bis] [RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow
Claise, B. and B. Trammell, "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, September 2013.
Information eXport (IPFIX)", draft-ietf-ipfix-information-
model-rfc5102bis-10 (work in progress), February 2013.
[I-D.ietf-ipfix-ie-doctors] [RFC7013] Trammell, B. and B. Claise, "Guidelines for Authors and
Trammell, B. and B. Claise, "Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX)
Reviewers of IPFIX Information Elements", draft-ietf- Information Elements", BCP 184, RFC 7013, September 2013.
ipfix-ie-doctors-07 (work in progress), October 2012.
[iana-ipfix-assignments] [iana-ipfix-assignments]
Internet Assigned Numbers Authority, ., "IP Flow Internet Assigned Numbers Authority, ., "IP Flow
Information Export Information Elements Information Export Information Elements
(http://www.iana.org/assignments/ipfix/ipfix.xml)", . (http://www.iana.org/assignments/ipfix/)", .
[performance-metrics-directorate] [performance-metrics-directorate]
IETF, ., "Performance Metrics Directorate (http:// IETF, ., "Performance Metrics Directorate (http://
www.ietf.org/iesg/directorate/performance-metrics.html)", www.ietf.org/iesg/directorate/performance-metrics.html)",
. .
[BMWG] IETF, ., "Benchmarking Methodology (BMWG) Working Group, [BMWG] IETF, ., "Benchmarking Methodology (BMWG) Working Group,
http://datatracker.ietf.org/wg/bmwg/charter/", . http://datatracker.ietf.org/wg/bmwg/charter/", .
[IPFIX] IETF, ., "IP Flow Information eXport (IPFIX) Working [IPFIX] IETF, ., "IP Flow Information eXport (IPFIX) Working
Group, http://datatracker.ietf.org/wg/ipfix/charter/", . 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) [PMOL] IETF, ., "IPerformance Metrics for Other Layers (PMOL)
Working Group, Working Group,
http://datatracker.ietf.org/wg/pmol/charter/", . http://datatracker.ietf.org/wg/pmol/charter/", .
[XRBLOCK] IETF, ., "Metric Blocks for use with RTCP's Extended [XRBLOCK] IETF, ., "Metric Blocks for use with RTCP's Extended
Report Framework (XRBLOCK), Report Framework (XRBLOCK),
http://datatracker.ietf.org/wg/xrblock/charter/", . http://datatracker.ietf.org/wg/xrblock/charter/", .
Authors' Addresses Authors' Addresses
 End of changes. 79 change blocks. 
210 lines changed or deleted 468 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/