idnits 2.17.1 draft-morton-ippm-composition-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 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 471. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 482. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 489. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 495. ** 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Unrecognized Status in 'Category: Individual', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'T' is mentioned on line 275, but not defined == Missing Reference: 'Tf' is mentioned on line 275, but not defined == Unused Reference: 'RFC791' is defined on line 393, but no explicit reference was found in the text == Unused Reference: 'RFC3148' is defined on line 410, but no explicit reference was found in the text == Unused Reference: 'RFC3432' is defined on line 415, but no explicit reference was found in the text == Unused Reference: 'Pax98' is defined on line 424, but no explicit reference was found in the text == Unused Reference: 'RFC3393' is defined on line 428, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2330 ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Downref: Normative reference to an Informational RFC: RFC 3148 Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A.Morton,Editor 2 Internet Draft AT&T Labs 3 Document: 4 Category: Individual 6 Composition of Metrics 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 This document is an Internet-Draft and is subject to all provisions 16 of section 3 of BCP 78. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This memo intends to define metrics that are applicable to both 41 complete paths and sub-paths, where a corresponding relationship can 42 be specified to compose the complete path metric from the sub-path 43 metrics with sufficient accuracy. The current memo gives some 44 background and proposes wording for a Scope and Application section 45 to define this new work. The description of an example metric and 46 statistic follows. 48 Contents 50 Status of this Memo................................................1 51 Copyright Notice...................................................1 52 Abstract...........................................................1 53 Authors/Contributors...............................................2 54 1. Conventions used in this document...............................3 55 2. Introduction....................................................3 56 3. Proposed Scope and Application..................................4 57 3.1 Scope of Work.................................................4 58 3.2 Application...................................................4 59 3.3 Measurement Points............................................5 60 4. One-way Delay Composition Metrics and Statistics................5 61 4.1 Name: Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream......5 62 4.1.1 Metric Parameters:...........................................5 63 4.1.2 Definition:..................................................5 64 4.1.3 Discussion and other details.................................6 65 4.1.4 Mean Statistic...............................................6 66 4.1.5 Composition Relationship: Sum of Mean Delays.................6 67 4.1.6 Statement of Conjecture......................................6 68 4.1.7 Justification for the composite relationship.................6 69 4.1.8 Sources of Error.............................................6 70 4.1.9 Specific cases where the conjecture might fail...............7 71 4.1.10 Application of Measurement Methodology......................7 72 5. Loss Metrics/Statistics.........................................7 73 6. Delay Variation Metrics/Statistics..............................7 74 7. Other Metrics/Statistics........................................7 75 8. Security Considerations.........................................7 76 8.1 Denial of Service Attacks......................................7 77 8.2 User data confidentiality......................................8 78 8.3 Interference with the metric...................................8 79 9. IANA Considerations.............................................8 80 10. Normative References...........................................8 81 11. Informative References.........................................9 82 12. Acknowledgments................................................9 83 13. Author's Addresses.............................................9 84 Full Copyright Statement..........................................10 85 Intellectual Property.............................................10 86 Acknowledgement...................................................10 88 Authors/Contributors 90 Thus far, the following people have contributed useful ideas or 91 suggestions that have been incorporated into this memo: 93 - Phil Chimento 94 - Reza Fardid 95 - Roman Krzanowski 96 - Maurizio Molina 97 - Emile Stephan 99 1. Conventions used in this document 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 Although RFC 2119 was written with protocols in mind, the key words 105 are used in this document for similar reasons. They are used to 106 ensure the results of measurements from two different 107 implementations are comparable, and to note instances when an 108 implementation could perturb the network. 110 In this memo, the characters "<=" should be read as "less than or 111 equal to" and ">=" as "greater than or equal to". 113 2. Introduction 115 The IPPM framework RFC 2330 [RFC2330] describes two forms of metric 116 composition, spatial and temporal. Spatial composition encompasses 117 the definitions of performance metrics that are applicable to the 118 complete path, and to various sub-paths. Also, the text suggests 119 that the concepts of the analytical framework (or A-frame) would 120 help to define useful relationships between the complete path 121 metrics and the sub-path metrics. The effectiveness of such metrics 122 is dependent on their usefulness in analysis and applicability with 123 practical measurement methods. 125 The relationships may involve conjecture, and [RFC2330] lists four 126 points that the metric definitions should include: 128 + the specific conjecture applied to the metric, 129 + a justification of the practical utility of the composition in 130 terms of making accurate measurements of the metric on the path, 131 + a justification of the usefulness of the composition in terms of 132 making analysis of the path using A-frame concepts more 133 effective, and 134 + an analysis of how the conjecture could be incorrect. 136 RFC 2330 also gives an example where a conjecture that the delay of 137 a path is very nearly the sum of the delays of the exchanges and 138 clouds of the corresponding path digest. This example is 139 particularly relevant to those who wish to assess the performance of 140 an Inter-domain path without direct measurement, and the performance 141 estimate of the complete path is related to the measured results for 142 various sub-paths instead. 144 Approximate relationships between the sub-path and complete path 145 metrics are useful, with knowledge of the circumstances where the 146 relationships are/are not applicable. For example, we would not 147 expect that delay singletons from each sub-path would sum to produce 148 an accurate estimate of a delay singleton for the complete path 149 (unless all the delays were essentially constant - very unlikely). 150 However, other delay statistics (based on a reasonable sample size) 151 may have a sufficiently large set of circumstances where they are 152 applicable. 154 3. Proposed Scope and Application 156 3.1 Scope of Work 158 For the primary IPPM metrics (currently Loss, Delay, and Delay 159 Variation), this memo gives a set of complete path metrics that can 160 be composed from the same or similar sub-path metrics. This means 161 that the complete path metric may be composed from: 163 + the same metric for each sub-path 165 + multiple metrics for each sub-path (possibly one that is the same 166 as the complete path metric) 168 + a single sub-path metrics that is different from the complete 169 path metric 171 Each metric will clearly state: 173 - the definition (and statistic, where appropriate) 175 - the composition relationship 177 - the specific conjecture on which the relationship is based 179 - a justification of practical utility or usefulness for analysis 180 using the A-frame concepts 182 - one or more examples of how the conjecture could be incorrect and 183 lead to inaccuracy 185 3.2 Application 187 For each metric, the applicable circumstances are defined, in terms 188 of whether the composition: 190 Requires the same test packets to traverse all sub-paths, or may use 191 similar packets sent and collected separately in each sub-path. 193 Requires homogeneity of measurement methodologies, or can allow a 194 degree of flexibility (e.g., active or passive methods produce the 195 "same" metric). 197 Needs information or access that will only be available within an 198 operator's domain, or is applicable to Inter-domain composition. 200 Requires synchronized measurement time intervals in all sub-paths, 201 or largely overlapping, or no timing requirements. 203 Requires assumption of sub-path independence w.r.t. the metric being 204 defined/composed, or other assumptions. 206 Has known sources of inaccuracy/error, and identifies the sources. 208 3.3 Measurement Points 210 This section will define the terminology applicable to both complete 211 path and sub-path metrics. 213 4. One-way Delay Composition Metrics and Statistics 215 4.1 Name: Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream 217 4.1.1 Metric Parameters: 219 + Src, the IP address of a host 221 + Dst, the IP address of a host 223 + T, a time (start of test interval) 225 + Tf, a time (end of test interval) 227 + lambda, a rate in reciprocal seconds (for Poisson Streams) 229 + incT, the nominal duration of inter-packet interval, first bit to 230 first bit (for Periodic Streams) 232 + T0, a time that MUST be selected at random from the interval 233 [T, T+dT] to start generating packets and taking measurements 234 (for Periodic Streams) 236 + TstampSrc, the wire time of the packet as measured at MP(Src) 238 + TstampDst, the wire time of the packet as measured at MP(Dst), 239 assigned to packets that arrive within a "reasonable" time. 241 4.1.2 Definition: 243 Using the parameters above, we obtain the value of Type-P-One-way- 244 Delay singleton as per RFC 2679 [RFC2679]. For each packet [i] that 245 has a finite One-way Delay (in other words, excluding packets which 246 have undefined, or infinite one-way delay): 248 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i] = 249 FiniteDelay[i] = TstampDst - TstampSrc 251 4.1.3 Discussion and other details... 253 4.1.4 Mean Statistic 255 + L, the total number of packets received at Dst (sent between T0 256 and Tf) 258 The 260 Type-P-Finite-One-way-Delay-Mean = 262 MeanDelay = (1/L)Sum(from i=1 to L, FiniteDelay[i]) 264 where all packets i= 1 through L have finite singleton delays. 266 4.1.5 Composition Relationship: Sum of Mean Delays 268 The Type-P-Finite-One-way-Delay-Mean, or MeanDelay for the complete 269 Source to Destination path can be calculated from sum of the Mean 270 Delays of all its constituent sub-paths. 272 4.1.6 Statement of Conjecture 274 The mean of a sufficiently large stream of packets measured on each 275 sub-path during the interval [T, Tf] will be representative of the 276 true mean of the delay distribution (and the distributions 277 themselves are sufficiently independent), such that the means may be 278 added to produce an estimate of the complete path mean delay. 280 4.1.7 Justification for the composite relationship 282 It is sometimes impractical to conduct active measurements between 283 every Src-Dst pair. For example, it may not be possible to collect 284 the desired sample size in each test interval when access link speed 285 is limited, because of the potential for measurement traffic to 286 degrade the user traffic performance. The conditions on a low-speed 287 access link may be understood well-enough to permit use of a small 288 sample size/rate, while a larger sample size/rate may be used on 289 other sub-paths. 291 Also, since measurement operations have a real monetary cost, there 292 is value in re-using measurements where they are applicable, rather 293 than launching new measurements for every possible source- 294 destination pair. 296 4.1.8 Sources of Error 298 The measurement packets, each having source and destination 299 addresses intended for collection at edges of the sub-path, may take 300 a different specific path through the network equipment and parallel 301 exchanges than packets with the source and destination addresses of 302 the complete path. Therefore, the sub-path measurements may differ 303 from the performance experienced by packets on the complete path. 304 Measurements employing sufficient sub-path address pairs might 305 produce bounds on the extent of this error. 307 others... 309 4.1.9 Specific cases where the conjecture might fail 311 If any of the sub-path distributions are bimodal, then the measured 312 means may not be stable, and in this case the mean will not be a 313 particularly useful statistic when describing the delay distribution 314 of the complete path. 316 The mean may not be sufficiently robust statistic to produce a 317 reliable estimate, or to be useful even if it can be measured. 319 others... 321 4.1.10 Application of Measurement Methodology 323 SHOULD use similar packets sent and collected separately in each 324 sub-path. 326 Allows a degree of flexibility (e.g., active or passive methods can 327 produce the "same" metric, but timing and correlation of passive 328 measurements is much more challenging). 330 Applicable to both Inter-domain and Intra-domain composition. 332 SHOULD have synchronized measurement time intervals in all sub- 333 paths, but largely overlapping intervals MAY suffice. 335 REQUIRES assumption of sub-path independence w.r.t. the metric being 336 defined/composed. 338 5. Loss Metrics/Statistics 340 6. Delay Variation Metrics/Statistics 342 7. Other Metrics/Statistics 344 8. Security Considerations 346 8.1 Denial of Service Attacks 348 This metric requires a stream of packets sent from one host (source) 349 to another host (destination) through intervening networks. This 350 method could be abused for denial of service attacks directed at 351 destination and/or the intervening network(s). 353 Administrators of source, destination, and the intervening 354 network(s) should establish bilateral or multi-lateral agreements 355 regarding the timing, size, and frequency of collection of sample 356 metrics. Use of this method in excess of the terms agreed between 357 the participants may be cause for immediate rejection or discard of 358 packets or other escalation procedures defined between the affected 359 parties. 361 8.2 User data confidentiality 363 Active use of this method generates packets for a sample, rather 364 than taking samples based on user data, and does not threaten user 365 data confidentiality. Passive measurement must restrict attention to 366 the headers of interest. Since user payloads may be temporarily 367 stored for length analysis, suitable precautions MUST be taken to 368 keep this information safe and confidential. In most cases, a 369 hashing function will produce a value suitable for payload 370 comparisons. 372 8.3 Interference with the metric 374 It may be possible to identify that a certain packet or stream of 375 packets is part of a sample. With that knowledge at the destination 376 and/or the intervening networks, it is possible to change the 377 processing of the packets (e.g. increasing or decreasing delay) that 378 may distort the measured performance. It may also be possible to 379 generate additional packets that appear to be part of the sample 380 metric. These additional packets are likely to perturb the results 381 of the sample measurement. 383 To discourage the kind of interference mentioned above, packet 384 interference checks, such as cryptographic hash, may be used. 386 9. IANA Considerations 388 Since this metric does not define a protocol or well-known values, 389 there are no IANA considerations in this memo. 391 10. Normative References 393 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, 394 September 1981. 395 Obtain via: http://www.rfc-editor.org/rfc/rfc791.txt 397 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 398 Requirement Levels", RFC 2119, March 1997. 399 Obtain via: http://www.rfc-editor.org/rfc/rfc2119.txt 401 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and Mathis, M., 402 "Framework for IP Performance Metrics", RFC 2330, May 403 1998. 404 Obtain via: http://www.rfc-editor.org/rfc/rfc2330.txt 406 [RFC2679] Almes, G., Kalidindi, S. and M. Zekauskas, "A one-way 407 delay metric for IPPM", RFC 2679, September 1999. 408 Obtain via: http://www.rfc-editor.org/rfc/rfc2679.txt 410 [RFC3148] Mathis, M. and Allman, M., "A Framework for Defining 411 Empirical Bulk Transfer Capacity Metrics", RFC 3148, July 412 2001. 413 Obtain via: http://www.rfc-editor.org/rfc/rfc3148.txt 415 [RFC3432] Raisanen, V., Grotefeld, G., and Morton, A., "Network 416 performance measurement with periodic streams", RFC 3432, 417 November 2002. 419 11. Informative References 421 [I.356] ITU-T Recommendation I.356, "B-ISDN ATM layer cell 422 transfer performance", March 2000. 424 [Pax98] V.Paxson, "Measurements and Analysis of End-to-End 425 Internet Dynamics," Ph.D. dissertation, U.C. Berkeley, 426 1997, ftp://ftp.ee.lbl.gov/papers/vp-thesis/dis.ps.gz. 428 [RFC3393] Demichelis, C., and Chimento, P., "IP Packet Delay 429 Variation Metric for IP Performance Metrics (IPPM)", RFC 430 3393, November 2002. 432 [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data 433 communication service - IP packet transfer and 434 availability performance parameters", December 2002. 436 12. Acknowledgments 438 The authors would like to acknowledge many helpful discussions with 439 . . . (lots of people, eventually). 441 13. Author's Addresses 443 Al Morton 444 AT&T Labs 445 Room D3 - 3C06 446 200 Laurel Ave. South 447 Middletown, NJ 07748 USA 448 Phone +1 732 420 1571 449 EMail: 450 Need addresses for: 451 - Phil Chimento 452 - Reza Fardid 453 - Roman Krzanowski 454 - Maurizio Molina 455 - Emile Stephan 457 Full Copyright Statement 459 Copyright (C) The Internet Society (2005). 461 This document is subject to the rights, licenses and restrictions 462 contained in BCP 78, and except as set forth therein, the authors 463 retain all their rights. 465 This document and the information contained herein are provided on 466 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 467 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 468 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 469 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 470 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 471 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 473 Intellectual Property 475 The IETF takes no position regarding the validity or scope of any 476 Intellectual Property Rights or other rights that might be claimed 477 to pertain to the implementation or use of the technology described 478 in this document or the extent to which any license under such 479 rights might or might not be available; nor does it represent that 480 it has made any independent effort to identify any such rights. 481 Information on the procedures with respect to rights in RFC 482 documents can be found in BCP 78 and BCP 79. 484 Copies of IPR disclosures made to the IETF Secretariat and any 485 assurances of licenses to be made available, or the result of an 486 attempt made to obtain a general license or permission for the use 487 of such proprietary rights by implementers or users of this 488 specification can be obtained from the IETF on-line IPR repository 489 at http://www.ietf.org/ipr. 491 The IETF invites any interested party to bring to its attention any 492 copyrights, patents or patent applications, or other proprietary 493 rights that may cover technology that may be required to implement 494 this standard. Please address the information to the IETF at ietf- 495 ipr@ietf.org. 497 Acknowledgement 498 Funding for the RFC Editor function is currently provided by the 499 Internet Society.