draft-ietf-ippm-reporting-metrics-02.txt   draft-ietf-ippm-reporting-metrics-03.txt 
Network Working Group A. Morton Network Working Group A. Morton
Internet-Draft G. Ramachandran Internet-Draft G. Ramachandran
Intended status: Informational G. Maguluri Intended status: Informational G. Maguluri
Expires: December 1, 2010 AT&T Labs Expires: December 30, 2010 AT&T Labs
May 30, 2010 June 28, 2010
Reporting Metrics: Different Points of View Reporting Metrics: Different Points of View
draft-ietf-ippm-reporting-metrics-02 draft-ietf-ippm-reporting-metrics-03
Abstract Abstract
Consumers of IP network performance metrics have many different uses Consumers of IP network performance metrics have many different uses
in mind. This memo categorizes the different audience points of in mind. The memo provides "long-term" reporting considerations
view. It describes how the categories affect the selection of metric (e.g, days, weeks or months, as opposed to 10 seconds), based on
parameters and options when seeking info that serves their needs. analysis of the two key audience points-of-view. It describes how
The memo then proceeds to discuss "long-term" reporting the audience categories affect the selection of metric parameters and
considerations (e.g, days, weeks or months, as opposed to 10 options when seeking info that serves their needs.
seconds).
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
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
skipping to change at page 1, line 43 skipping to change at page 1, line 42
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 December 1, 2010. This Internet-Draft will expire on December 30, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 5, line 24 skipping to change at page 5, line 24
capacity measurement. The Raw and Restricted capacity metrics will capacity measurement. The Raw and Restricted capacity metrics will
be treated in separate sections, although they share one common be treated in separate sections, although they share one common
reporting issue: representing variability in capacity metric results. reporting issue: representing variability in capacity metric results.
Sampling, or the design of the active packet stream that is the basis Sampling, or the design of the active packet stream that is the basis
for the measurements, is also discussed. for the measurements, is also discussed.
3. Reporting Results 3. Reporting Results
This section gives an overview of recommendations, followed by This section gives an overview of recommendations, followed by
additional considerations for reporting results in the "long-term". additional considerations for reporting results in the "long-term",
based on the discussion and conclusions of the major sections that
follow.
3.1. Overview of Metric Statistics 3.1. Overview of Metric Statistics
This section gives an overview of reporting recommendations for the This section gives an overview of reporting recommendations for the
loss, delay, and delay variation metrics based on the discussion and loss, delay, and delay variation metrics.
conclusions of the preceding sections.
The minimal report on measurements MUST include both Loss and Delay The minimal report on measurements MUST include both Loss and Delay
Metrics. Metrics.
For Packet Loss, the loss ratio defined in [RFC2680] is a sufficient For Packet Loss, the loss ratio defined in [RFC2680] is a sufficient
starting point, especially the guidance for setting the loss starting point, especially the guidance for setting the loss
threshold waiting time. We have calculated a waiting time above that threshold waiting time. We have calculated a waiting time above that
should be sufficient to differentiate between packets that are truly should be sufficient to differentiate between packets that are truly
lost or have long finite delays under general measurement lost or have long finite delays under general measurement
circumstances, 51 seconds. Knowledge of specific conditions can help circumstances, 51 seconds. Knowledge of specific conditions can help
to reduce this threshold, but 51 seconds is considered to be to reduce this threshold, but 51 seconds is considered to be
manageable in practice. manageable in practice.
We note that a loss ratio calculated according to [Y.1540] would We note that a loss ratio calculated according to [Y.1540] would
exclude errored packets form the numerator. In practice, the exclude errored packets from the numerator. In practice, the
difference between these two loss metrics is small if any, depending difference between these two loss metrics is small if any, depending
on whether the last link prior to the destination contributes errored on whether the last link prior to the destination contributes errored
packets. packets.
For Packet Delay, we recommend providing both the mean delay and the For Packet Delay, we recommend providing both the mean delay and the
median delay with lost packets designated undefined (as permitted by median delay with lost packets designated undefined (as permitted by
[RFC2679]). Both statistics are based on a conditional distribution, [RFC2679]). Both statistics are based on a conditional distribution,
and the condition is packet arrival prior to a waiting time dT, where and the condition is packet arrival prior to a waiting time dT, where
dT has been set to take maximum packet lifetimes into account, as dT has been set to take maximum packet lifetimes into account, as
discussed above. Using a long dT helps to ensure that delay discussed below. Using a long dT helps to ensure that delay
distributions are not truncated. distributions are not truncated.
For Packet Delay Variation (PDV), the minimum delay of the For Packet Delay Variation (PDV), the minimum delay of the
conditional distribution should be used as the reference delay for conditional distribution should be used as the reference delay for
computing PDV according to [Y.1540] or [RFC3393]. A useful value to computing PDV according to [Y.1540] or [RFC5481] and [RFC3393]. A
report is a pseudo range of delay variation based on calculating the useful value to report is a pseudo range of delay variation based on
difference between a high percentile of delay and the minimum delay. calculating the difference between a high percentile of delay and the
For example, the 99.9%-ile minus the minimum will give a value that minimum delay. For example, the 99.9%-ile minus the minimum will
can be compared with objectives in [Y.1541]. give a value that can be compared with objectives in [Y.1541].
3.2. Long-Term Reporting Considerations 3.2. Long-Term Reporting Considerations
[I-D.ietf-ippm-reporting] describes methods to conduct measurements [I-D.ietf-ippm-reporting] describes methods to conduct measurements
and report the results on a near-immediate time scale (10 seconds, and report the results on a near-immediate time scale (10 seconds,
which we consider to be "short-term"). which we consider to be "short-term").
Measurement intervals and reporting intervals need not be the same Measurement intervals and reporting intervals need not be the same
length. Sometimes, the user is only concerned with the performance length. Sometimes, the user is only concerned with the performance
levels achieved over a relatively long interval of time (e.g, days, levels achieved over a relatively long interval of time (e.g, days,
skipping to change at page 7, line 26 skipping to change at page 7, line 26
of temporal aggregation is yet to be prepared. of temporal aggregation is yet to be prepared.
Yet another approach requires a numerical objective for the metric, Yet another approach requires a numerical objective for the metric,
and the results of each measurement interval are compared with the and the results of each measurement interval are compared with the
objective. Every measurement interval where the results meet the objective. Every measurement interval where the results meet the
objective contribute to the fraction of time with performance as objective contribute to the fraction of time with performance as
specified. When the reporting interval contains many measurement specified. When the reporting interval contains many measurement
intervals it is possible to present the results as "metric A was less intervals it is possible to present the results as "metric A was less
than or equal to objective X during Y% of time. than or equal to objective X during Y% of time.
NOTE that numerical thresholds are not set in IETF performance work NOTE that numerical thresholds of acceptability are not set in IETF
and are explicitly excluded from the IPPM charter. performance work and are explicitly excluded from the IPPM charter.
In all measurement, it is important to avoid unintended In all measurement, it is important to avoid unintended
synchronization with network events. This topic is treated in synchronization with network events. This topic is treated in
[RFC2330] for Poisson-distributed inter-packet time streams, and [RFC2330] for Poisson-distributed inter-packet time streams, and
[RFC3432] for Periodic streams. Both avoid synchronization through [RFC3432] for Periodic streams. Both avoid synchronization through
use of random start times. use of random start times.
There are network conditions where it is simply more useful to report There are network conditions where it is simply more useful to report
the connectivity status of the Source-Destination path, and to the connectivity status of the Source-Destination path, and to
distinguish time intervals where connectivity can be demonstrated distinguish time intervals where connectivity can be demonstrated
 End of changes. 10 change blocks. 
22 lines changed or deleted 22 lines changed or added

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