--- 1/draft-ietf-ippm-reporting-03.txt 2009-07-13 22:12:14.000000000 +0200 +++ 2/draft-ietf-ippm-reporting-04.txt 2009-07-13 22:12:14.000000000 +0200 @@ -1,19 +1,19 @@ Network Working Group S. Shalunov Internet-Draft Intended status: Standards Track M. Swany -Expires: September 10, 2009 University of Delaware - March 9, 2009 +Expires: January 14, 2010 University of Delaware + July 13, 2009 Reporting IP Performance Metrics to Users - draft-ietf-ippm-reporting-03.txt + draft-ietf-ippm-reporting-04.txt 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 @@ -32,21 +32,21 @@ 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 September 10, 2009. + This Internet-Draft will expire on January 14, 2010. Copyright Notice Copyright (c) 2009 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 @@ -79,21 +79,21 @@ 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 . . . . . . . . . . . . . . . . . . . . . . . . 44 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 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 @@ -225,46 +225,54 @@ are lost, it is +infinity; finally, if more than 75% of packets are lost, it is undefined. 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 transmitted packets for which more - than a single copy of the packet was received within the timeout + 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. 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 TBD-duplicate [I-D.ietf-ippm-duplicate] (A One- - Way Packet Duplication Metric). Duplication is 100*Type-P-one-way- - replicated-packet-rate. + 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 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 + 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). - FIXME: References. + For more information, refer to section 4.1.3 (Type-P-Reordered-Ratio- + Stream) of RFC 4737 [RFC4737] (Packet Reordering Metrics), and + supporting text. + + {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. 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. @@ -358,34 +366,36 @@ 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 - [I-D.ietf-ippm-duplicate] - Uijterwaal, H., "A One-Way Packet Duplication Metric", - draft-ietf-ippm-duplicate-07 (work in progress), - January 2009. - [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. + 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 @@ -510,21 +520,21 @@ r = (r + 1) % reordering_max; return 0; } double reordering_output(uint64_t j) { if (j >= reordering_max) return -1; else - return (double)reordering_m[j] / (l - j - 1); + return (double)reordering_m[j] / l); } void reordering_exit(void) { free(reordering_ring); free(reordering_m); } int @@ -1332,33 +1342,36 @@ fprintf(stderr, "Error: Unknown quantile_algorithm error."); } exit(1); } /** * Will read a sample data file (first and only parameter) whose * lines give two values per line (per received packet): measured * packet delay and packet sequence number (in "%lf %lu" * format). As an exception, the first line specifies the number - * of packets actually sent. Example: + * of packets actually sent. + * NOTE: The code as written assume there is no newline on the last + * line. FIXME. + * Example: * ---- 10 - 0.101 0 - 0.109 1 - 0.12 1 - 0.10 3 - 0.14 4 - 0.15 5 - 0.13 2 - 0.09 6 - 0.1 8 - 0.091 7 + 0.101 1 + 0.109 2 + 0.12 2 + 0.10 4 + 0.14 5 + 0.15 6 + 0.13 3 + 0.09 7 + 0.1 9 + 0.091 8 * ---- * * To compile this sample reporting main(): * * gcc -std=c99 -DTHRULAY_REPORTING_SAMPLE_LOOP reporting.c -lm * **/ int main(int argc, char *argv[]) { @@ -1509,33 +1524,44 @@ Appendix B. Example Report This appendix only serves for illustrative purposes. 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: 18.182% - Reordering: 25.000% + Duplication: 10.000% + Reordering: 22.222% Appendix C. TODO FIXME: This section needs to be removed before publication. - o Add references + 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