--- 1/draft-ietf-ippm-reporting-04.txt 2010-07-13 03:10:24.000000000 +0200 +++ 2/draft-ietf-ippm-reporting-05.txt 2010-07-13 03:10:24.000000000 +0200 @@ -1,107 +1,107 @@ Network Working Group S. Shalunov Internet-Draft Intended status: Standards Track M. Swany -Expires: January 14, 2010 University of Delaware - July 13, 2009 +Expires: January 14, 2011 University of Delaware + July 13, 2010 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 - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. This document may contain material - 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. + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. + 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." - 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 January 14, 2010. + This Internet-Draft will expire on January 14, 2011. 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. This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents in effect on the date of - publication of this document (http://trustee.ietf.org/license-info). - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. - -Abstract + 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 + described in the Simplified BSD License. - 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. + This document may contain material 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. Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 - 2. Goals and Motivation . . . . . . . . . . . . . . . . . . . . . 5 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Applicability for Long-Term Measurements . . . . . . . . . . . 7 4. Reportable Metrics Set . . . . . . . . . . . . . . . . . . . . 8 4.1. Median Delay . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Loss Ratio . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Delay Spread . . . . . . . . . . . . . . . . . . . . . . . 8 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 Appendix A. Sample Source Code for Computing the Metrics . . . . 17 Appendix B. Example Report . . . . . . . . . . . . . . . . . . . 41 - Appendix C. TODO . . . . . . . . . . . . . . . . . . . . . . . . 42 - Appendix D. Revision History . . . . . . . . . . . . . . . . . . 43 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 + 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]. -2. Goals and Motivation +2. Introduction The IPPM working group has defined many richly parameterized performance metrics with a number of variants (one-way delay, one-way loss, delay variation, reordering, etc.) and a protocol for obtaining the measurement data needed to compute these metrics (OWAMP). It would be beneficial to define a standard way to report a set of performance metrics to end users. Parameterization might be acceptable in such a set, but there must still be defaults for everything. It is especially important to get these defaults right. Such a set would enable different tools to produce results that can @@ -240,39 +240,40 @@ 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 - Reordering is the fraction of packets sent but not lost 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 - purposes of computing the fraction). + Reordering is the fraction of unique packets received for which the + sequence number of any given packet is less than the highest sequence + number largest sequence number of any packet previously received. + For the purposes of determining the sequence number of the preceding + packets in this definition, assume sequence numbers starting with 1, + and 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 purposes of computing the + fraction). For more information, refer to section 4.1.3 (Type-P-Reordered-Ratio- 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, 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 - 5.3; because that divides by the number of all packets received, - instead of the number of non-duplicate packets received.} + 5.3; because 1-reordering divides by the number of all packets + received, instead of the number of non-duplicate packets received.} 5. Sample Source Section 4 describes the metrics to compute on a sample of measurements. The source of the sample in not discussed there, and, indeed, the metrics discussed (delay, loss, etc.) are simply estimators that could be applied to any sample whatsoever. For the names of the estimators to be applicable, of course, the measurements need to come from a packet delivery network. @@ -1439,20 +1440,25 @@ /* Process sample input file. */ /* The sender somehow tells the receiver how many packets were actually sent. */ fscanf(sf,"%lu",&packets_sent); for (i = 0; i < max_packets && !feof(sf); 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++; /* * Duplication */ if (duplication_check(packet_sqn[i])) { /* Duplicated packet */ packets_dup++; continue; } else { @@ -1536,79 +1542,20 @@ This report is produced by running the sample program in Appendix A on the sample input embedded in a comment in its source code: Delay: 109.000ms Loss: 10.000% Jitter: 40.000ms Duplication: 10.000% 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 Stanislav Shalunov Email: shalunov@shlang.com URI: http://shlang.com/ Martin Swany University of Delaware Department of Computer and Information Sciences