draft-ietf-ippm-reporting-01.txt   draft-ietf-ippm-reporting-02.txt 
Network Working Group S. Shalunov Network Working Group S. Shalunov
Internet-Draft Internet2 Internet-Draft
Expires: April 26, 2007 B. Lutzmann Intended status: Standards Track M. Swany
F. Pouzols Expires: January 15, 2009 University of Delaware
October 23, 2006 July 14, 2008
Reporting IP Performance Metrics to Users Reporting IP Performance Metrics to Users
draft-ietf-ippm-reporting-01.txt draft-ietf-ippm-reporting-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 2007. This Internet-Draft will expire on January 15, 2009.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract Abstract
The aim of this document is to define a small set of metrics that are The aim of this document is to define a small set of metrics that are
robust, easy to understand, orthogonal, relevant, and easy to robust, easy to understand, orthogonal, relevant, and easy to
compute. The IPPM WG has defined a large number of richly compute. The IPPM WG has defined a large number of richly
parameterized metrics because network measurement has many purposes. parameterized metrics because network measurement has many purposes.
Often, the ultimate purpose is to report a concise set of metrics Often, the ultimate purpose is to report a concise set of metrics
describing a network's state to an end user. It is for this purpose describing a network's state to an end user. It is for this purpose
that the present set of metrics is defined. that the present set of metrics is defined.
Table of Contents Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
2. Goals and Motivation . . . . . . . . . . . . . . . . . . . . . 4 2. Goals and Motivation . . . . . . . . . . . . . . . . . . . . . 4
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Applicability for Long-Term Measurements . . . . . . . . . . . 6
4. Reportable Metrics Set . . . . . . . . . . . . . . . . . . . . 7 4. Reportable Metrics Set . . . . . . . . . . . . . . . . . . . . 7
4.1. Delay . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Median Delay . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Loss Ratio . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Delay Spread . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Duplication . . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Duplication . . . . . . . . . . . . . . . . . . . . . . . 7
4.5. Reordering . . . . . . . . . . . . . . . . . . . . . . . . 8 4.5. Reordering . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Sample Source . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Sample Source . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. One-Way Active Measurement . . . . . . . . . . . . . . . . 9 5.1. One-Way Active Measurement . . . . . . . . . . . . . . . . 9
5.2. Round-Trip Active Measurement . . . . . . . . . . . . . . 10 5.2. Round-Trip Active Measurement . . . . . . . . . . . . . . 10
5.3. Passive Measurement . . . . . . . . . . . . . . . . . . . 10 5.3. Passive Measurement . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Internationalization Considerations . . . . . . . . . . . . . 14 9. Internationalization Considerations . . . . . . . . . . . . . 14
10. Normative References . . . . . . . . . . . . . . . . . . . . . 14 10. Normative References . . . . . . . . . . . . . . . . . . . . . 15
Appendix A. Sample Source Code for Computing the Metrics . . . . 15 Appendix A. Sample Source Code for Computing the Metrics . . . . 16
Appendix B. Example Report . . . . . . . . . . . . . . . . . . . 39 Appendix B. Example Report . . . . . . . . . . . . . . . . . . . 40
Appendix C. TODO . . . . . . . . . . . . . . . . . . . . . . . . 40 Appendix C. TODO . . . . . . . . . . . . . . . . . . . . . . . . 41
Appendix D. Revision History . . . . . . . . . . . . . . . . . . 41 Appendix D. Revision History . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
Intellectual Property and Copyright Statements . . . . . . . . . . 43 Intellectual Property and Copyright Statements . . . . . . . . . . 44
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. Goals and Motivation
The IPPM working group has defined many richly parameterized The IPPM working group has defined many richly parameterized
skipping to change at page 4, line 26 skipping to change at page 4, line 26
be compared against each other. be compared against each other.
Existing tools already report statistic about the network. This is Existing tools already report statistic about the network. This is
done for varying reasons: network testing tools, such as the ping done for varying reasons: network testing tools, such as the ping
program available in UNIX-derived operating systems as well as in program available in UNIX-derived operating systems as well as in
Microsoft Windows, report statistics with no knowledge of why the Microsoft Windows, report statistics with no knowledge of why the
user is running the program; networked games might report statistics user is running the program; networked games might report statistics
of the network connection to the server so users can better of the network connection to the server so users can better
understand why they get the results they get (e.g., if something is understand why they get the results they get (e.g., if something is
slow, is this because of the network or the CPU?), so they can slow, is this because of the network or the CPU?), so they can
compare their statistics to those of others (``you're not lagged any compare their statistics to those of others ("you're not lagged any
more than I am'') or perhaps so that users can decide whether they more than I am") or perhaps so that users can decide whether they
need to upgrade the connection to their home; IP telephony hardware need to upgrade the connection to their home; IP telephony hardware
and software might report the statistics for similar reasons. While and software might report the statistics for similar reasons. While
existing tools report statistics all right, the particular set of existing tools report statistics all right, the particular set of
metrics they choose is ad hoc; some metrics are not statistically metrics they choose is ad hoc; some metrics are not statistically
robust, some are not relevant, and some are not easy to understand; robust, some are not relevant, and some are not easy to understand;
more important than specific shortcomings, however, is the more important than specific shortcomings, however, is the
incompatibility: even if the sets of metrics were perfect, they would incompatibility: even if the sets of metrics were perfect, they would
still be all different, and, therefore, metrics reported by different still be all different, and, therefore, metrics reported by different
tools would not be comparable. tools would not be comparable.
skipping to change at page 6, line 5 skipping to change at page 6, line 5
Finally, while this set will most frequently be computed for small Finally, while this set will most frequently be computed for small
data sets, where efficiency is not a serious consideration, it must data sets, where efficiency is not a serious consideration, it must
be possible to compute for large data sets, too. In particular, it be possible to compute for large data sets, too. In particular, it
must be possible to compute the metrics in a single pass over the must be possible to compute the metrics in a single pass over the
data using a limited amount of memory (i.e., it must be possible to data using a limited amount of memory (i.e., it must be possible to
take a source of measurement data with a high data rate and compute take a source of measurement data with a high data rate and compute
the metrics on the fly, discarding each data point after it is the metrics on the fly, discarding each data point after it is
processed). processed).
3. Scope 3. Applicability for Long-Term Measurements
The metrics in this document are applicable to short-term network The metrics in this document are most applicable to short-term
measurements (seconds or at most minutes) and are aimed at real-time network measurements (seconds or at most minutes) and are targeted
display of such measurements. for real-time display of such measurements.
One consideration that would have to be addressed to make these One consideration that would have to be addressed to make these
metrics suitable for longer-term measurements (hours and days) is metrics suitable for longer-term measurements (hours and days) is
that of network availability: during such long periods of time the that of network availability: during such long periods of time the
network may be completely down for some time and it does not seem to network may be completely down for some time and it does not seem to
make sense to average out the reports in such a way that the network make sense to average out the reports in such a way that the network
being down for 1% of the time becomes 1% packet loss. being down for 1% of the time becomes 1% packet loss.
4. Reportable Metrics Set 4. Reportable Metrics Set
The following metrics comprise the set: The following metrics comprise the set:
1. delay; 1. median delay;
2. loss; 2. loss ratio;
3. jitter; 3. delay spread;
4. duplication; 4. duplication;
5. reordering. 5. reordering.
Each of the above is represented by a single numeric quantity, Each of the above is represented by a single numeric quantity,
computed as described below. computed as described below.
4.1. Delay 4.1. Median Delay
The reported delay is the median of all delays in the sample. When a The reported median delay is the median of all delays in the sample.
packet is lost, its delay is to be considered +infinity for the When a packet is lost, its delay is to be considered +infinity for
purposes of this computation; therefore, if more than half of all the purposes of this computation; therefore, if more than half of all
packets are lost, the delay is +infinity. packets are lost, the delay is +infinity.
FIXME: References. 4.2. Loss Ratio
4.2. Loss
Loss is the fraction, expressed as a percentage, of packets that did
not arrive intact within a given number of seconds (timeout value)
after being sent. Since this set of metrics often has to be reported
to a waiting human user, the default timeout value has to be small.
By default, 2 seconds MUST be the timeout value.
FIXME: References.
4.3. Jitter Loss Ratio is the fraction, expressed as a percentile, of packets
that did not arrive intact within a given number of seconds (the
timeout value) after being sent. Since this set of metrics often has
to be reported to a waiting human user, the default timeout value
should be small. By default, 2 seconds MUST be the timeout value.
Use of a different timeout value MUST be reported.
Jitter is the interquartile spread of delay. In other words, jitter 4.3. Delay Spread
is equal to the difference of the 75th and 25th percentiles of delay.
When both percentiles are +infinity, the value of jitter is
undefined. Therefore, if less than 25% of packets are lost, jitter
is defined and finite; if between 75% and 25% of packets are lost,
jitter is +infinity; finally, if more than 75% of packets are lost,
jitter is undefined.
FIXME: References. Delay spread is the interquartile spread of observed delays. This is
a metric to represent what is commonly referred to as "jitter".
Delay spread is reported as the difference of the 75th and 25th
percentiles of delay. When both percentiles are +infinity, the value
of delay spread is undefined. Therefore, if less than 25% of packets
are lost, it is defined and finite; if between 75% and 25% of packets
are lost, it is +infinity; finally, if more than 75% of packets are
lost, it is undefined.
4.4. Duplication 4.4. Duplication
Duplication is the fraction of packets for which more than a single Duplication is the fraction of transmitted packets for which more
copy of the packet was received within the timeout period (same than a single copy of the packet was received within the timeout
timeout as in the definition of loss), expressed in percentage period (ideally using the same timeout as in the definition of loss),
points. expressed in percentage points.
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%.
FIXME: References (tough one---IPPM hasn't defined duplication).
4.5. Reordering 4.5. Reordering
Reordering is the fraction of sent packets for which the sequence Reordering is the fraction of sent packets for which the sequence
number of the packet received immediately before the first copy of number of the packet received immediately before the first copy of
the given packet is not the decrement of the sequence number of the the given packet is not the decrement of the sequence number of the
given packet. For the purposes of determining the sequence number of given packet. For the purposes of determining the sequence number of
the preceding packet in this definition, assuming sequence numbers the preceding packet in this definition, assuming sequence numbers
starting with 1, an extra packet at the start of the stream of starting with 1, an extra packet at the start of the stream of
received packets, with a sequence number of 0, is considered to be received packets, with a sequence number of 0, is considered to be
present (this extra packet, of course, is not counted for the present (this extra packet, of course, is not counted for the
skipping to change at page 9, line 48 skipping to change at page 9, line 48
(pseudo-)random deviates. (pseudo-)random deviates.
The default packet size is the minimum necessary for the measurement. The default packet size is the minimum necessary for the measurement.
Values other than the default ones MAY be used; if they are used, Values other than the default ones MAY be used; if they are used,
their use, and specific values used, MUST be reported. their use, and specific values used, MUST be reported.
A one-way active measurement is characterized by the source IP A one-way active measurement is characterized by the source IP
address, the destination IP address, the time when measurement was address, the destination IP address, the time when measurement was
taken, and the type of packets (e.g., UDP with given port numbers and taken, and the type of packets (e.g., UDP with given port numbers and
a given DSCP) used in the measurement. For the time, the middle of a given DSCP) used in the measurement. For the time, the end of the
the measurement interval MUST be reported. measurement interval MUST be reported.
5.2. Round-Trip Active Measurement 5.2. Round-Trip Active Measurement
The same default parameters and characterization apply to round-trip The same default parameters and characterization apply to round-trip
measurement as to one-way measurement (Section 5.1). measurement as to one-way measurement (Section 5.1).
5.3. Passive Measurement 5.3. Passive Measurement
Passive measurement use whatever data it is natural to use. For Passive measurement use whatever data it is natural to use. For
example, an IP telephony application or a networked game would use example, an IP telephony application or a networked game would use
skipping to change at page 10, line 26 skipping to change at page 10, line 26
interval. An analysis of performance of an Internet service interval. An analysis of performance of an Internet service
provider's network might use all the packets that traversed the provider's network might use all the packets that traversed the
network in the measurement interval. An analysis of performance of a network in the measurement interval. An analysis of performance of a
specific service from the point of view of a given site might use an specific service from the point of view of a given site might use an
appropriate filter to select only the relevant packets. In any case, appropriate filter to select only the relevant packets. In any case,
the source needs to be reported. the source needs to be reported.
The same default duration applies to passive measurement as to one- The same default duration applies to passive measurement as to one-
way active measurement (Section 5.1). way active measurement (Section 5.1).
When the passive measurement data is reported in real time, a sliding When the passive measurement data is reported in real time, or based
window SHOULD be used as a measurement period, so that recent data on user demand, a sliding window SHOULD be used as a measurement
become more quickly reflected. period, so that recent data become more quickly reflected. For
historical reporting purposes, a fixed interval may be preferable.
6. Security Considerations 6. Security Considerations
The reporting per se, not being a protocol, does not raise security The reporting per se, not being a protocol, does not raise security
considerations. considerations.
An aspect of reporting relevant to security is how the reported An aspect of reporting relevant to security is how the reported
metrics are used and how they are collected. If it is important that metrics are used and how they are collected. If it is important that
the metrics satisfy certain conditions (e.g., that the ISP whose the metrics satisfy certain conditions (e.g., that the ISP whose
network is being measured be unable to make the metrics appear better network is being measured be unable to make the metrics appear better
than they are), the collection mechanism MUST ensure that this is, than they are), the collection mechanism MUST ensure that this is,
indeed, so. The exact mechanisms to do so our outside of scope of indeed, so. The exact mechanisms to do so are outside of scope of
this document and belong with discussion of particular measurement this document and belong with discussion of particular measurement
data collection protocols. data collection protocols.
7. Acknowledgments 7. Acknowledgments
We gratefully acknowledge discussion with, encouragement from, and We gratefully acknowledge discussion with, encouragement from, and
contributions of Lawrence D. Dunn, Reza Fardid, Ruediger Geib, contributions of Lawrence D. Dunn, Reza Fardid, Ruediger Geib,
Matt Mathis, Al Morton, Carsten Schmoll, Henk Uijterwaal, and Matt Mathis, Al Morton, Carsten Schmoll, Henk Uijterwaal, and
Matthew J. Zekauskas. Matthew J. Zekauskas.
skipping to change at page 42, line 8 skipping to change at page 43, line 8
Revision 1.2 2006/04/04 21:39:20 shalunov Revision 1.2 2006/04/04 21:39:20 shalunov
Convert to xml2rfc 1.30 and RFC 3978 IPR statement. Convert to xml2rfc 1.30 and RFC 3978 IPR statement.
Revision 1.1.1.1 2006/04/02 17:07:36 shalunov Revision 1.1.1.1 2006/04/02 17:07:36 shalunov
Initial import into CVS. Initial import into CVS.
Authors' Addresses Authors' Addresses
Stanislav Shalunov Stanislav Shalunov
Internet2
1000 Oakbrook Drive, Suite 300 Email: shalunov@shlang.com
Ann Arbor, MI 48104 URI: http://shlang.com/
Martin Swany
University of Delaware
Department of Computer and Information Sciences
Newark, DE 19716
US US
Email: shalunov@internet2.edu Email: swany@cis.udel.edu
URI: http://www.internet2.edu/~shalunov/ URI: http://www.cis.udel.edu/~swany/
Bernhard Lutzmann Full Copyright Statement
Email: belu@users.sf.net Copyright (C) The IETF Trust (2008).
Federico Montesino Pouzols This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Email: fedemp@altern.org This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Statement Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 43, line 28 skipping to change at line 1569
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 31 change blocks. 
77 lines changed or deleted 81 lines changed or added

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