draft-ietf-ippm-reporting-04.txt   draft-ietf-ippm-reporting-05.txt 
Network Working Group S. Shalunov Network Working Group S. Shalunov
Internet-Draft Internet-Draft
Intended status: Standards Track M. Swany Intended status: Standards Track M. Swany
Expires: January 14, 2010 University of Delaware Expires: January 14, 2011 University of Delaware
July 13, 2009 July 13, 2010
Reporting IP Performance Metrics to Users Reporting IP Performance Metrics to Users
draft-ietf-ippm-reporting-04.txt draft-ietf-ippm-reporting-05.txt
Abstract
The aim of this document is to define a small set of metrics that are
robust, easy to understand, orthogonal, relevant, and easy to
compute. The IPPM WG has defined a large number of richly
parameterized metrics because network measurement has many purposes.
Often, the ultimate purpose is to report a concise set of metrics
describing a network's current state to an end user. It is for this
purpose that the present set of metrics is defined, and the document
is principally concerned with "short-term" reporting considerations
(a few seconds or minutes as opposed to days, months or years.)
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 14, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract 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.
The aim of this document is to define a small set of metrics that are This document may contain material from IETF Documents or IETF
robust, easy to understand, orthogonal, relevant, and easy to Contributions published or made publicly available before November
compute. The IPPM WG has defined a large number of richly 10, 2008. The person(s) controlling the copyright in some of this
parameterized metrics because network measurement has many purposes. material may not have granted the IETF Trust the right to allow
Often, the ultimate purpose is to report a concise set of metrics modifications of such material outside the IETF Standards Process.
describing a network's state to an end user. It is for this purpose Without obtaining an adequate license from the person(s) controlling
that the present set of metrics is defined. the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
2. Goals and Motivation . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability for Long-Term Measurements . . . . . . . . . . . 7 3. Applicability for Long-Term Measurements . . . . . . . . . . . 7
4. Reportable Metrics Set . . . . . . . . . . . . . . . . . . . . 8 4. Reportable Metrics Set . . . . . . . . . . . . . . . . . . . . 8
4.1. Median Delay . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Median Delay . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Loss Ratio . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Loss Ratio . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Delay Spread . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Delay Spread . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Duplication . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Duplication . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. Reordering . . . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Reordering . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Sample Source . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Sample Source . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. One-Way Active Measurement . . . . . . . . . . . . . . . . 10 5.1. One-Way Active Measurement . . . . . . . . . . . . . . . . 10
5.2. Round-Trip Active Measurement . . . . . . . . . . . . . . 11 5.2. Round-Trip Active Measurement . . . . . . . . . . . . . . 11
5.3. Passive Measurement . . . . . . . . . . . . . . . . . . . 11 5.3. Passive Measurement . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Internationalization Considerations . . . . . . . . . . . . . 15 9. Internationalization Considerations . . . . . . . . . . . . . 15
10. Normative References . . . . . . . . . . . . . . . . . . . . . 16 10. Normative References . . . . . . . . . . . . . . . . . . . . . 16
Appendix A. Sample Source Code for Computing the Metrics . . . . 17 Appendix A. Sample Source Code for Computing the Metrics . . . . 17
Appendix B. Example Report . . . . . . . . . . . . . . . . . . . 41 Appendix B. Example Report . . . . . . . . . . . . . . . . . . . 41
Appendix C. TODO . . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
Appendix D. Revision History . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
1. Requirements Notation 1. Requirements Notation
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Goals and Motivation 2. Introduction
The IPPM working group has defined many richly parameterized The IPPM working group has defined many richly parameterized
performance metrics with a number of variants (one-way delay, one-way performance metrics with a number of variants (one-way delay, one-way
loss, delay variation, reordering, etc.) and a protocol for obtaining loss, delay variation, reordering, etc.) and a protocol for obtaining
the measurement data needed to compute these metrics (OWAMP). It the measurement data needed to compute these metrics (OWAMP). It
would be beneficial to define a standard way to report a set of would be beneficial to define a standard way to report a set of
performance metrics to end users. Parameterization might be performance metrics to end users. Parameterization might be
acceptable in such a set, but there must still be defaults for acceptable in such a set, but there must still be defaults for
everything. It is especially important to get these defaults right. everything. It is especially important to get these defaults right.
Such a set would enable different tools to produce results that can Such a set would enable different tools to produce results that can
skipping to change at page 9, line 30 skipping to change at page 9, line 30
Note: while most received packets can be ones previously seen, Note: while most received packets can be ones previously seen,
duplication can never exceed 100%. duplication can never exceed 100%.
For more information, see section 5.2 (Type-P-one-way-replicated- For more information, see section 5.2 (Type-P-one-way-replicated-
packet-rate) of RFC 5560 [RFC5560] (A One-Way Packet Duplication packet-rate) of RFC 5560 [RFC5560] (A One-Way Packet Duplication
Metric). Duplication is Type-P-one-way-replicated-packet-rate Metric). Duplication is Type-P-one-way-replicated-packet-rate
expressed as a percentage. expressed as a percentage.
4.5. Reordering 4.5. Reordering
Reordering is the fraction of packets sent but not lost for which the Reordering is the fraction of unique packets received for which the
sequence number of the packet received immediately before the first sequence number of any given packet is less than the highest sequence
copy of the given packet is not the decrement of the sequence number number largest sequence number of any packet previously received.
of the given packet. For the purposes of determining the sequence For the purposes of determining the sequence number of the preceding
number of the preceding packet in this definition, assuming sequence packets in this definition, assume sequence numbers starting with 1,
numbers starting with 1, an extra packet at the start of the stream and an extra packet at the start of the stream of received packets,
of received packets, with a sequence number of 0, is considered to be with a sequence number of 0, is considered to be present (this extra
present (this extra packet, of course, is not counted for the packet, of course, is not counted for the purposes of computing the
purposes of computing the fraction). fraction).
For more information, refer to section 4.1.3 (Type-P-Reordered-Ratio- For more information, refer to section 4.1.3 (Type-P-Reordered-Ratio-
Stream) of RFC 4737 [RFC4737] (Packet Reordering Metrics), and Stream) of RFC 4737 [RFC4737] (Packet Reordering Metrics), and
supporting text. supporting text. The precise definition of a reordered packet is in
section 3.3.
{Comment: As the non-normative sample code in Appendix A below shows, {Comment: As the non-normative sample code in Appendix A below shows,
this is also related to the amount of 1-reordering (Section 5.3 RFC this is also related to the amount of 1-reordering (Section 5.3 RFC
4737 [RFC4737]). It is not, however, the degree of 1-reordering in 4737 [RFC4737]). It is not, however, the degree of 1-reordering in
5.3; because that divides by the number of all packets received, 5.3; because 1-reordering divides by the number of all packets
instead of the number of non-duplicate packets received.} received, instead of the number of non-duplicate packets received.}
5. Sample Source 5. Sample Source
Section 4 describes the metrics to compute on a sample of Section 4 describes the metrics to compute on a sample of
measurements. The source of the sample in not discussed there, and, measurements. The source of the sample in not discussed there, and,
indeed, the metrics discussed (delay, loss, etc.) are simply indeed, the metrics discussed (delay, loss, etc.) are simply
estimators that could be applied to any sample whatsoever. For the estimators that could be applied to any sample whatsoever. For the
names of the estimators to be applicable, of course, the measurements names of the estimators to be applicable, of course, the measurements
need to come from a packet delivery network. need to come from a packet delivery network.
skipping to change at page 38, line 48 skipping to change at page 38, line 48
/* Process sample input file. */ /* Process sample input file. */
/* The sender somehow tells the receiver how many packets were /* The sender somehow tells the receiver how many packets were
actually sent. */ actually sent. */
fscanf(sf,"%lu",&packets_sent); fscanf(sf,"%lu",&packets_sent);
for (i = 0; i < max_packets && !feof(sf); i++) { for (i = 0; i < max_packets && !feof(sf); i++) {
fscanf(sf,"%lf %lu",&packet_delay[i],&packet_sqn[i]); fscanf(sf,"%lf %lu",&packet_delay[i],&packet_sqn[i]);
/* Take care of common issue of ending the file with a
newline; feof would not have been set but there is
no more data. Assume delay of 0.0 means we're done.
*/
if (packet_delay[i] == 0.0) break;
npackets++; npackets++;
/* /*
* Duplication * Duplication
*/ */
if (duplication_check(packet_sqn[i])) { if (duplication_check(packet_sqn[i])) {
/* Duplicated packet */ /* Duplicated packet */
packets_dup++; packets_dup++;
continue; continue;
} else { } else {
skipping to change at page 42, line 5 skipping to change at page 42, line 5
This report is produced by running the sample program in Appendix A This report is produced by running the sample program in Appendix A
on the sample input embedded in a comment in its source code: on the sample input embedded in a comment in its source code:
Delay: 109.000ms Delay: 109.000ms
Loss: 10.000% Loss: 10.000%
Jitter: 40.000ms Jitter: 40.000ms
Duplication: 10.000% Duplication: 10.000%
Reordering: 22.222% Reordering: 22.222%
Appendix C. TODO
FIXME: This section needs to be removed before publication.
o Verify sample percentiles
Appendix D. Revision History
FIXME: This section needs to be removed before publication.
version -04:
Edits based on IETF 74 discussion.
Duplication:
add new RFC 5560 ref, replicated-packet-rate
agreed on packets sent but not lost
Reordering:
ref Type-P-Reordered-Ratio-Stream
"fraction of packets sent but not lost"
fixed (non-normative) example, and sample code (divisor).
sample code still has newline bug; needs %-ile verification
version -03:
Add most references; some small wording changes for clarity.
version -02:
Update terminology.
Log leading up to -01:
$Log: draft-ietf-ippm-reporting.xml,v $
Revision 1.8 2006/10/23 21:45:54 shalunov
draft-ietf-ippm-reporting-01.txt
Revision 1.7 2006/10/23 21:45:13 shalunov
Add sample source code and output.
Revision 1.6 2006/06/02 21:21:57 shalunov
draft-ietf-ippm-reporting-00: Include a ``Scope'' section.
Change tags from draft-shalunov-ippm-reporting.
Revision 1.5 2006/05/02 20:25:44 shalunov
Version 03: Various refinements and clarifications based on feedback
from Reza Fardid, Ruediger Geib, and Al Morton.
Revision 1.4 2006/04/25 22:38:58 shalunov
Version 02: Address comments from Carsten Schmoll, sent in message
70524A4436C03E43A293958B505008B61B9CFB@EXCHSRV.fokus.fraunhofer.de.
My response, with clarifications and diffs, is in message
8664kxwazk.fsf@abel.internet2.edu.
Revision 1.3 2006/04/11 22:09:47 shalunov
Version 01: Wording changes based on discussion with Matt Zekauskas
(reordering, loss). Rewrite abstract a bit. Add TODO list.
Revision 1.2 2006/04/04 21:39:20 shalunov
Convert to xml2rfc 1.30 and RFC 3978 IPR statement.
Revision 1.1.1.1 2006/04/02 17:07:36 shalunov
Initial import into CVS.
Authors' Addresses Authors' Addresses
Stanislav Shalunov Stanislav Shalunov
Email: shalunov@shlang.com Email: shalunov@shlang.com
URI: http://shlang.com/ URI: http://shlang.com/
Martin Swany Martin Swany
University of Delaware University of Delaware
Department of Computer and Information Sciences Department of Computer and Information Sciences
 End of changes. 16 change blocks. 
115 lines changed or deleted 62 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/