idnits 2.17.1 draft-ietf-ippm-reporting-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 421. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 398. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 405. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 411. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2006) is 6586 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Shalunov 3 Internet-Draft Internet2 4 Expires: October 3, 2006 April 2006 6 Reporting IP Performance Metrics to Users 7 draft-ietf-ippm-reporting-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on October 3, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 The aim of this document is to define a small set of metrics that are 41 robust, easy to understand, orthogonal, relevant, and easy to 42 compute. The IPPM WG has defined a large number of richly 43 parameterized metrics because network measurement has many purposes. 44 Often, the ultimate purpose is to report a concise set of metrics 45 describing a network's state to an end user. It is for this purpose 46 that the present set of metrics is defined. 48 Table of Contents 50 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 51 2. Goals and Motivation . . . . . . . . . . . . . . . . . . . . . 4 52 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 53 4. Reportable Metrics Set . . . . . . . . . . . . . . . . . . . . 7 54 4.1. Delay . . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 4.2. Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 4.3. Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 4.4. Duplication . . . . . . . . . . . . . . . . . . . . . . . 8 58 4.5. Reordering . . . . . . . . . . . . . . . . . . . . . . . . 8 59 5. Sample Source . . . . . . . . . . . . . . . . . . . . . . . . 9 60 5.1. One-Way Active Measurement . . . . . . . . . . . . . . . . 9 61 5.2. Round-Trip Active Measurement . . . . . . . . . . . . . . 10 62 5.3. Passive Measurement . . . . . . . . . . . . . . . . . . . 10 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 7. Internationalization Considerations . . . . . . . . . . . . . 12 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 66 9. Normative References . . . . . . . . . . . . . . . . . . . . . 13 67 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14 68 Appendix B. TODO . . . . . . . . . . . . . . . . . . . . . . . . 15 69 Appendix C. Revision History . . . . . . . . . . . . . . . . . . 16 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 71 Intellectual Property and Copyright Statements . . . . . . . . . . 18 73 1. Requirements Notation 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 2. Goals and Motivation 81 The IPPM working group has defined many richly parameterized 82 performance metrics with a number of variants (one-way delay, one-way 83 loss, delay variation, reordering, etc.) and a protocol for obtaining 84 the measurement data needed to compute these metrics (OWAMP). It 85 would be beneficial to define a standard way to report a set of 86 performance metrics to end users. Parameterization might be 87 acceptable in such a set, but there must still be defaults for 88 everything. It is especially important to get these defaults right. 89 Such a set would enable different tools to produce results that can 90 be compared against each other. 92 Existing tools already report statistic about the network. This is 93 done for varying reasons: network testing tools, such as the ping 94 program available in UNIX-derived operating systems as well as in 95 Microsoft Windows, report statistics with no knowledge of why the 96 user is running the program; networked games might report statistics 97 of the network connection to the server so users can better 98 understand why they get the results they get (e.g., if something is 99 slow, is this because of the network or the CPU?), so they can 100 compare their statistics to those of others (``you're not lagged any 101 more than I am'') or perhaps so that users can decide whether they 102 need to upgrade the connection to their home; IP telephony hardware 103 and software might report the statistics for similar reasons. While 104 existing tools report statistics all right, the particular set of 105 metrics they choose is ad hoc; some metrics are not statistically 106 robust, some are not relevant, and some are not easy to understand; 107 more important than specific shortcomings, however, is the 108 incompatibility: even if the sets of metrics were perfect, they would 109 still be all different, and, therefore, metrics reported by different 110 tools would not be comparable. 112 The set of metrics of this document is meant for human consumption. 113 It must therefore be small. Anything greater than half-dozen numbers 114 is certainly too confusing. 116 Each of the metrics must be statistically robust. Intuitively, this 117 means that having a small number of bad data points and a small 118 amount of noise must not dramatically change the metric. 120 Each metric in the set must have, qualitatively, an immediate 121 intuitive meaning that has to be obvious for an advanced end user 122 without consulting documentation (that is, it has to be clear what 123 rough meaning, intuitively, the larger values of a given metric 124 have). 126 To be small, the set has to be orthogonal: each of the metrics has to 127 express a property not covered by other metrics (otherwise, there's 128 redundancy). 130 The metrics in the set must be relevant. Partly, being easy to 131 understand will help achieve this, but additional constraint may be 132 placed by relevancy. 134 Finally, while this set will most frequently be computed for small 135 data sets, where efficiency is not a serious consideration, it must 136 be possible to compute for large data sets, too. In particular, it 137 must be possible to compute the metrics in a single pass over the 138 data using a limited amount of memory (i.e., it must be possible to 139 take a source of measurement data with a high data rate and compute 140 the metrics on the fly, discarding each data point after it is 141 processed). 143 3. Scope 145 The metrics in this document are applicable to short-term network 146 measurements (seconds or at most minutes) and are aimed at real-time 147 display of such measurements. 149 One consideration that would have to be addressed to make these 150 metrics suitable for longer-term measurements (hours and days) is 151 that of network availability: during such long periods of time the 152 network may be completely down for some time and it does not seem to 153 make sense to average out the reports in such a way that the network 154 being down for 1% of the time becomes 1% packet loss. 156 4. Reportable Metrics Set 158 The following metrics comprise the set: 160 1. delay; 162 2. loss; 164 3. jitter; 166 4. duplication; 168 5. reordering. 170 Each of the above is represented by a single numeric quantity, 171 computed as described below. 173 4.1. Delay 175 The reported delay is the median of all delays in the sample. When a 176 packet is lost, its delay is to be considered +infinity for the 177 purposes of this computation; therefore, if more than half of all 178 packets are lost, the delay is +infinity. 180 FIXME: References. 182 4.2. Loss 184 Loss is the fraction, expressed as a percentage, of packets that did 185 not arrive intact within a given number of seconds (timeout value) 186 after being sent. Since this set of metrics often has to be reported 187 to a waiting human user, the default timeout value has to be small. 188 By default, 2 seconds MUST be the timeout value. 190 FIXME: References. 192 4.3. Jitter 194 Jitter is the interquartile spread of delay. In other words, jitter 195 is equal to the difference of the 75th and 25th percentiles of delay. 196 When both percentiles are +infinity, the value of jitter is 197 undefined. Therefore, if less than 25% of packets are lost, jitter 198 is defined and finite; if between 75% and 25% of packets are lost, 199 jitter is +infinity; finally, if more than 75% of packets are lost, 200 jitter is undefined. 202 FIXME: References. 204 4.4. Duplication 206 Duplication is the fraction of packets for which more than a single 207 copy of the packet was received within the timeout period (same 208 timeout as in the definition of loss), expressed in percentage 209 points. 211 Note: while most received packets can be ones previously seen, 212 duplication can never exceed 100%. 214 FIXME: References (tough one---IPPM hasn't defined duplication). 216 4.5. Reordering 218 Reordering is the fraction of sent packets for which the sequence 219 number of the packet received immediately before the first copy of 220 the given packet is not the decrement of the sequence number of the 221 given packet. For the purposes of determining the sequence number of 222 the preceding packet in this definition, assuming sequence numbers 223 starting with 1, an extra packet at the start of the stream of 224 received packets, with a sequence number of 0, is considered to be 225 present (this extra packet, of course, is not counted for the 226 purposes of computing the fraction). 228 FIXME: References. 230 5. Sample Source 232 Section 4 describes the metrics to compute on a sample of 233 measurements. The source of the sample in not discussed there, and, 234 indeed, the metrics discussed (delay, loss, etc.) are simply 235 estimators that could be applied to any sample whatsoever. For the 236 names of the estimators to be applicable, of course, the measurements 237 need to come from a packet delivery network. 239 The data in the samples for the set of metrics discussed in this 240 document can come from the following sources: one-way active 241 measurement, round-trip measurement, and passive measurement. There 242 infrequently is a choice between active and passive measurement, as, 243 typically, only one is available; consequently, no preference is 244 given to one over the other. In cases where clocks can be expected 245 to be synchronized, in general, one-way measurements are preferred 246 over round-trip measurements (as one-way measurements are more 247 informative). When one-way measurements cannot be obtained, or when 248 clocks cannot be expected to be synchronized, round-trip measurement 249 MAY be used. 251 5.1. One-Way Active Measurement 253 The default duration of the measurement interval is 10 seconds. 255 The default sending schedule is a Poisson stream. 257 The default sending rate is 10 packets/second on average. The 258 default sending schedule is a Poisson stream. When randomized 259 schedules, such as a Poisson stream, are used, the rate MUST be set 260 with the distribution parameter(s). With a randomized schedule, the 261 default sample size is 100 packets and the measurement window 262 duration can vary to some extent depending on the values of the 263 (pseudo-)random deviates. 265 The default packet size is the minimum necessary for the measurement. 267 Values other than the default ones MAY be used; if they are used, 268 their use, and specific values used, MUST be reported. 270 A one-way active measurement is characterized by the source IP 271 address, the destination IP address, the time when measurement was 272 taken, and the type of packets (e.g., UDP with given port numbers and 273 a given DSCP) used in the measurement. For the time, the middle of 274 the measurement interval MUST be reported. 276 5.2. Round-Trip Active Measurement 278 The same default parameters and characterization apply to round-trip 279 measurement as to one-way measurement (Section 5.1). 281 5.3. Passive Measurement 283 Passive measurement use whatever data it is natural to use. For 284 example, an IP telephony application or a networked game would use 285 the data that it sends. An analysis of performance of a link might 286 use all the packets that traversed the link in the measurement 287 interval. An analysis of performance of an Internet service 288 provider's network might use all the packets that traversed the 289 network in the measurement interval. An analysis of performance of a 290 specific service from the point of view of a given site might use an 291 appropriate filter to select only the relevant packets. In any case, 292 the source needs to be reported. 294 The same default duration applies to passive measurement as to one- 295 way active measurement (Section 5.1). 297 When the passive measurement data is reported in real time, a sliding 298 window SHOULD be used as a measurement period, so that recent data 299 become more quickly reflected. 301 6. Security Considerations 303 The reporting per se, not being a protocol, does not raise security 304 considerations. 306 An aspect of reporting relevant to security is how the reported 307 metrics are used and how they are collected. If it is important that 308 the metrics satisfy certain conditions (e.g., that the ISP whose 309 network is being measured be unable to make the metrics appear better 310 than they are), the collection mechanism MUST ensure that this is, 311 indeed, so. The exact mechanisms to do so our outside of scope of 312 this document and belong with discussion of particular measurement 313 data collection protocols. 315 7. Internationalization Considerations 317 The reported metrics, while they might occasionally be parsed by 318 machine, are primarily meant for human consumption. As such, they 319 MAY be reported in the language preferred by the user, using an 320 encoding suitable for the purpose, such as UTF-8. 322 8. IANA Considerations 324 This document requires no action from the IANA. 326 9. Normative References 328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 329 Requirement Levels", BCP 14, RFC 2119, March 1997. 331 Appendix A. Acknowledgments 333 The author gratefully acknowledges discussion with, encouragement 334 from, and contributions of Lawrence D. Dunn, Reza Fardid, 335 Ruediger Geib, Matt Mathis, Al Morton, Carsten Schmoll, 336 Henk Uijterwaal, and Matthew J. Zekauskas. 338 Appendix B. TODO 340 FIXME: This section needs to be removed before publication. 342 o Add references 344 o Add non-normative code for illustration 346 o Add examples (code output) 348 Appendix C. Revision History 350 FIXME: This section needs to be removed before publication. 352 $Log: draft-ietf-ippm-reporting.xml,v $ 353 Revision 1.6 2006/06/02 21:21:57 shalunov 354 draft-ietf-ippm-reporting-00: Include a ``Scope'' section. 355 Change tags from draft-shalunov-ippm-reporting. 357 Revision 1.5 2006/05/02 20:25:44 shalunov 358 Version 03: Various refinements and clarifications based on feedback 359 from Reza Fardid, Ruediger Geib, and Al Morton. 361 Revision 1.4 2006/04/25 22:38:58 shalunov 362 Version 02: Address comments from Carsten Schmoll, sent in message 363 70524A4436C03E43A293958B505008B61B9CFB@EXCHSRV.fokus.fraunhofer.de. 364 My response, with clarifications and diffs, is in message 365 8664kxwazk.fsf@abel.internet2.edu. 367 Revision 1.3 2006/04/11 22:09:47 shalunov 368 Version 01: Wording changes based on discussion with Matt Zekauskas 369 (reordering, loss). Rewrite abstract a bit. Add TODO list. 371 Revision 1.2 2006/04/04 21:39:20 shalunov 372 Convert to xml2rfc 1.30 and RFC 3978 IPR statement. 374 Revision 1.1.1.1 2006/04/02 17:07:36 shalunov 375 Initial import into CVS. 377 Author's Address 379 Stanislav Shalunov 380 Internet2 381 1000 Oakbrook Drive, Suite 300 382 Ann Arbor, MI 48104 383 US 385 Phone: +1-734-913-4260 386 Email: shalunov@internet2.edu 387 URI: http://www.internet2.edu/~shalunov/ 389 Intellectual Property Statement 391 The IETF takes no position regarding the validity or scope of any 392 Intellectual Property Rights or other rights that might be claimed to 393 pertain to the implementation or use of the technology described in 394 this document or the extent to which any license under such rights 395 might or might not be available; nor does it represent that it has 396 made any independent effort to identify any such rights. Information 397 on the procedures with respect to rights in RFC documents can be 398 found in BCP 78 and BCP 79. 400 Copies of IPR disclosures made to the IETF Secretariat and any 401 assurances of licenses to be made available, or the result of an 402 attempt made to obtain a general license or permission for the use of 403 such proprietary rights by implementers or users of this 404 specification can be obtained from the IETF on-line IPR repository at 405 http://www.ietf.org/ipr. 407 The IETF invites any interested party to bring to its attention any 408 copyrights, patents or patent applications, or other proprietary 409 rights that may cover technology that may be required to implement 410 this standard. Please address the information to the IETF at 411 ietf-ipr@ietf.org. 413 Disclaimer of Validity 415 This document and the information contained herein are provided on an 416 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 417 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 418 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 419 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 420 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 421 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 423 Copyright Statement 425 Copyright (C) The Internet Society (2006). This document is subject 426 to the rights, licenses and restrictions contained in BCP 78, and 427 except as set forth therein, the authors retain all their rights. 429 Acknowledgment 431 Funding for the RFC Editor function is currently provided by the 432 Internet Society.