--- 1/draft-ietf-ippm-reporting-05.txt 2011-03-14 22:14:43.000000000 +0100 +++ 2/draft-ietf-ippm-reporting-06.txt 2011-03-14 22:14:43.000000000 +0100 @@ -1,19 +1,19 @@ Network Working Group S. Shalunov Internet-Draft Intended status: Standards Track M. Swany -Expires: January 14, 2011 University of Delaware - July 13, 2010 +Expires: September 15, 2011 University of Delaware + March 14, 2011 Reporting IP Performance Metrics to Users - draft-ietf-ippm-reporting-05.txt + draft-ietf-ippm-reporting-06.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 @@ -28,25 +28,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months 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." - This Internet-Draft will expire on January 14, 2011. + This Internet-Draft will expire on September 15, 2011. Copyright Notice - Copyright (c) 2010 IETF Trust and the persons identified as the + Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -76,21 +76,23 @@ 4.4. Duplication . . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Reordering . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Sample Source . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. One-Way Active Measurement . . . . . . . . . . . . . . . . 10 5.2. Round-Trip Active Measurement . . . . . . . . . . . . . . 11 5.3. Passive Measurement . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Internationalization Considerations . . . . . . . . . . . . . 15 - 10. Normative References . . . . . . . . . . . . . . . . . . . . . 16 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 Appendix A. Sample Source Code for Computing the Metrics . . . . 17 Appendix B. Example Report . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 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]. @@ -123,22 +125,22 @@ 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. The set of metrics of this document is meant for human consumption. It must therefore be small. A screen full of numbers is likely to be too confusing. Restricting output to a single number would likewise - not be descriptive enough. (Would you pick loss? delay? throughput? - something else?) In this document we aim for a "handful" of numbers. + not be descriptive enough. This document aims for a small set of + easily understood numbers. Each of the metrics must be statistically robust. Intuitively, this means that having a small number of bad data points and a small amount of noise must not dramatically change the metric. Each metric in the set must have, qualitatively, an immediate intuitive meaning that has to be obvious for an advanced end user without consulting documentation (that is, it has to be clear what rough meaning, intuitively, the larger values of a given metric have). @@ -166,20 +168,24 @@ 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. + Long-term reporting considerations are now being developed within the + IPPM working group. See the working group draft + [I-D.ietf-ippm-reporting-metrics] (or future RFC) for details. + 4. Reportable Metrics Set The following metrics comprise the set: 1. median delay; 2. loss ratio; 3. delay spread; @@ -227,22 +233,22 @@ For more information, refer to section 5.1 (Type-P-One-way-Delay- Percentile) of RFC 2679 [RFC2679] (A One-way Delay Metric for IPPM), and supporting text. The Delay Spread is the 75th Type-P-One-way- Delay-Percentile minus the 25th Type-P-One-way-Delay-Percentile. 4.4. Duplication Duplication is the fraction of packets sent but not lost 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. + period (ideally using the same timeout as in the definition of loss). + It is expressed as a percentage. Note: while most received packets can be ones previously seen, duplication can never exceed 100%. For more information, see section 5.2 (Type-P-one-way-replicated- packet-rate) of RFC 5560 [RFC5560] (A One-Way Packet Duplication Metric). Duplication is Type-P-one-way-replicated-packet-rate expressed as a percentage. 4.5. Reordering @@ -314,21 +320,21 @@ 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 + Passive measurements use whatever data it is natural to use. For example, an IP telephony application or a networked game would use the data that it sends. An analysis of performance of a link might use all the packets that traversed the link in the measurement 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. @@ -365,38 +371,48 @@ This document requires no action from the IANA. 9. Internationalization Considerations The reported metrics, while they might occasionally be parsed by machine, are primarily meant for human consumption. As such, they MAY be reported in the language preferred by the user, using an encoding suitable for the purpose, such as UTF-8. -10. Normative References +10. References + +10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, November 2006. [RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric", RFC 5560, May 2009. +10.2. Informative References + + [I-D.ietf-ippm-reporting-metrics] + Morton, A., Ramachandran, G., and G. Maguluri, "Reporting + Metrics: Different Points of View", + draft-ietf-ippm-reporting-metrics-04 (work in progress), + October 2010. + Appendix A. Sample Source Code for Computing the Metrics This appendix only serves for illustrative purposes. /* * reporting.c -- performance metrics reporting as in Internet Draft * draft-ietf-ippm-reporting. * * Written by Stanislav Shalunov, http://www.internet2.edu/~shalunov/ * Bernhard Lutzmann, belu@users.sf.net