--- 1/draft-ietf-ippm-reporting-01.txt 2008-07-15 04:13:54.000000000 +0200 +++ 2/draft-ietf-ippm-reporting-02.txt 2008-07-15 04:13:54.000000000 +0200 @@ -1,19 +1,19 @@ Network Working Group S. Shalunov -Internet-Draft Internet2 -Expires: April 26, 2007 B. Lutzmann - F. Pouzols - October 23, 2006 +Internet-Draft +Intended status: Standards Track M. Swany +Expires: January 15, 2009 University of Delaware + July 14, 2008 Reporting IP Performance Metrics to Users - draft-ietf-ippm-reporting-01.txt + draft-ietf-ippm-reporting-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -24,62 +24,58 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at 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 April 26, 2007. - -Copyright Notice - - Copyright (C) The Internet Society (2006). + This Internet-Draft will expire on January 15, 2009. 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 state to an end user. It is for this purpose that the present set of metrics is defined. Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Goals and Motivation . . . . . . . . . . . . . . . . . . . . . 4 - 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3. Applicability for Long-Term Measurements . . . . . . . . . . . 6 4. Reportable Metrics Set . . . . . . . . . . . . . . . . . . . . 7 - 4.1. Delay . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 4.2. Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 4.3. Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 4.4. Duplication . . . . . . . . . . . . . . . . . . . . . . . 8 + 4.1. Median Delay . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.2. Loss Ratio . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.3. Delay Spread . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.4. Duplication . . . . . . . . . . . . . . . . . . . . . . . 7 4.5. Reordering . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Sample Source . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. One-Way Active Measurement . . . . . . . . . . . . . . . . 9 5.2. Round-Trip Active Measurement . . . . . . . . . . . . . . 10 5.3. Passive Measurement . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Internationalization Considerations . . . . . . . . . . . . . 14 - 10. Normative References . . . . . . . . . . . . . . . . . . . . . 14 - Appendix A. Sample Source Code for Computing the Metrics . . . . 15 - Appendix B. Example Report . . . . . . . . . . . . . . . . . . . 39 - Appendix C. TODO . . . . . . . . . . . . . . . . . . . . . . . . 40 - Appendix D. Revision History . . . . . . . . . . . . . . . . . . 41 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 - Intellectual Property and Copyright Statements . . . . . . . . . . 43 + 10. Normative References . . . . . . . . . . . . . . . . . . . . . 15 + Appendix A. Sample Source Code for Computing the Metrics . . . . 16 + Appendix B. Example Report . . . . . . . . . . . . . . . . . . . 40 + Appendix C. TODO . . . . . . . . . . . . . . . . . . . . . . . . 41 + Appendix D. Revision History . . . . . . . . . . . . . . . . . . 42 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 + Intellectual Property and Copyright Statements . . . . . . . . . . 44 1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Goals and Motivation The IPPM working group has defined many richly parameterized @@ -94,22 +90,22 @@ be compared against each other. Existing tools already report statistic about the network. This is done for varying reasons: network testing tools, such as the ping program available in UNIX-derived operating systems as well as in Microsoft Windows, report statistics with no knowledge of why the user is running the program; networked games might report statistics of the network connection to the server so users can better 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 - 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 + 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 need to upgrade the connection to their home; IP telephony hardware and software might report the statistics for similar reasons. While existing tools report statistics all right, the particular set of metrics they choose is ad hoc; some metrics are not statistically robust, some are not relevant, and some are not easy to understand; more important than specific shortcomings, however, is the incompatibility: even if the sets of metrics were perfect, they would still be all different, and, therefore, metrics reported by different tools would not be comparable. @@ -137,93 +133,87 @@ Finally, while this set will most frequently be computed for small data sets, where efficiency is not a serious consideration, it must 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 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 the metrics on the fly, discarding each data point after it is processed). -3. Scope +3. Applicability for Long-Term Measurements - The metrics in this document are applicable to short-term network - measurements (seconds or at most minutes) and are aimed at real-time - display of such measurements. + The metrics in this document are most applicable to short-term + network measurements (seconds or at most minutes) and are targeted + for real-time display of such measurements. One consideration that would have to be addressed to make these metrics suitable for longer-term measurements (hours and days) is 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 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. 4. Reportable Metrics Set The following metrics comprise the set: - 1. delay; + 1. median delay; - 2. loss; + 2. loss ratio; - 3. jitter; + 3. delay spread; 4. duplication; 5. reordering. Each of the above is represented by a single numeric quantity, 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 - packet is lost, its delay is to be considered +infinity for the - purposes of this computation; therefore, if more than half of all + The reported median delay is the median of all delays in the sample. + When a packet is lost, its delay is to be considered +infinity for + the purposes of this computation; therefore, if more than half of all packets are lost, the delay is +infinity. - FIXME: References. - -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.2. Loss Ratio -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 - 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. +4.3. Delay Spread - 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 - Duplication is the fraction of packets for which more than a single - copy of the packet was received within the timeout period (same - timeout as in the definition of loss), expressed in percentage - points. + Duplication is the fraction of transmitted packets for which more + than a single copy of the packet was received within the timeout + period (ideally using the same timeout as in the definition of loss), + expressed in percentage points. Note: while most received packets can be ones previously seen, duplication can never exceed 100%. - FIXME: References (tough one---IPPM hasn't defined duplication). - 4.5. Reordering Reordering is the fraction of sent packets for which the sequence number of the packet received immediately before the first copy of the given packet is not the decrement of the sequence number of the given packet. For the purposes of determining the sequence number of the preceding packet in this definition, assuming sequence numbers 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 present (this extra packet, of course, is not counted for the @@ -267,22 +257,22 @@ (pseudo-)random deviates. The default packet size is the minimum necessary for the measurement. Values other than the default ones MAY be used; if they are used, their use, and specific values used, MUST be reported. A one-way active measurement is characterized by the source IP address, the destination IP address, the time when measurement was 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 - the measurement interval MUST be reported. + a given DSCP) used in the measurement. For the time, the end of the + measurement interval MUST be reported. 5.2. Round-Trip Active Measurement The same default parameters and characterization apply to round-trip measurement as to one-way measurement (Section 5.1). 5.3. Passive Measurement Passive measurement use whatever data it is natural to use. For example, an IP telephony application or a networked game would use @@ -291,35 +281,36 @@ interval. An analysis of performance of an Internet service provider's network might use all the packets that traversed the 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 appropriate filter to select only the relevant packets. In any case, the source needs to be reported. The same default duration applies to passive measurement as to one- way active measurement (Section 5.1). - When the passive measurement data is reported in real time, a sliding - window SHOULD be used as a measurement period, so that recent data - become more quickly reflected. + When the passive measurement data is reported in real time, or based + on user demand, a sliding window SHOULD be used as a measurement + period, so that recent data become more quickly reflected. For + historical reporting purposes, a fixed interval may be preferable. 6. Security Considerations The reporting per se, not being a protocol, does not raise security considerations. An aspect of reporting relevant to security is how the reported metrics are used and how they are collected. If it is important that the metrics satisfy certain conditions (e.g., that the ISP whose network is being measured be unable to make the metrics appear better 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 data collection protocols. 7. Acknowledgments We gratefully acknowledge discussion with, encouragement from, and contributions of Lawrence D. Dunn, Reza Fardid, Ruediger Geib, Matt Mathis, Al Morton, Carsten Schmoll, Henk Uijterwaal, and Matthew J. Zekauskas. @@ -1516,37 +1507,50 @@ 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 Stanislav Shalunov - Internet2 - 1000 Oakbrook Drive, Suite 300 - Ann Arbor, MI 48104 + + Email: shalunov@shlang.com + URI: http://shlang.com/ + + Martin Swany + University of Delaware + Department of Computer and Information Sciences + Newark, DE 19716 US - Email: shalunov@internet2.edu - URI: http://www.internet2.edu/~shalunov/ + Email: swany@cis.udel.edu + 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 Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in 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 made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. @@ -1555,31 +1559,10 @@ attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at 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.