idnits 2.17.1 draft-ietf-ippm-spatial-composition-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 21, 2009) is 5415 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) == Missing Reference: 'T' is mentioned on line 977, but not defined == Missing Reference: 'Tf' is mentioned on line 977, but not defined == Missing Reference: 'TBP' is mentioned on line 950, but not defined == Unused Reference: 'I-D.ietf-ippm-multimetrics' is defined on line 1163, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-ippm-framework-compagg-07 ** Downref: Normative reference to an Informational draft: draft-ietf-ippm-framework-compagg (ref. 'I-D.ietf-ippm-framework-compagg') ** Downref: Normative reference to an Informational RFC: RFC 2330 ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) ** Obsolete normative reference: RFC 4148 (Obsoleted by RFC 6248) == Outdated reference: A later version (-12) exists of draft-ietf-ippm-multimetrics-11 Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Morton 3 Internet-Draft AT&T Labs 4 Intended status: Standards Track E. Stephan 5 Expires: December 23, 2009 France Telecom Division R&D 6 June 21, 2009 8 Spatial Composition of Metrics 9 draft-ietf-ippm-spatial-composition-09 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on December 23, 2009. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This memo utilizes IPPM metrics that are applicable to both complete 58 paths and sub-paths, and defines relationships to compose a complete 59 path metric from the sub-path metrics with some accuracy w.r.t. the 60 actual metrics. This is called Spatial Composition in RFC 2330. The 61 memo refers to the Framework for Metric Composition, and provides 62 background and motivation for combining metrics to derive others. 63 The descriptions of several composed metrics and statistics follow. 65 Requirements Language 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in RFC 2119 [RFC2119]. 71 In this memo, the characters "<=" should be read as "less than or 72 equal to" and ">=" as "greater than or equal to". 74 Table of Contents 76 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6 79 3. Scope and Application . . . . . . . . . . . . . . . . . . . . 6 80 3.1. Scope of work . . . . . . . . . . . . . . . . . . . . . . 7 81 3.2. Application . . . . . . . . . . . . . . . . . . . . . . . 7 82 3.3. Incomplete Information . . . . . . . . . . . . . . . . . . 8 83 4. Common Specifications for Composed Metrics . . . . . . . . . . 8 84 4.1. Name: Type-P . . . . . . . . . . . . . . . . . . . . . . . 8 85 4.1.1. Metric Parameters . . . . . . . . . . . . . . . . . . 8 86 4.1.2. Definition and Metric Units . . . . . . . . . . . . . 9 87 4.1.3. Discussion and other details . . . . . . . . . . . . . 9 88 4.1.4. Statistic: . . . . . . . . . . . . . . . . . . . . . . 9 89 4.1.5. Composition Function . . . . . . . . . . . . . . . . . 9 90 4.1.6. Statement of Conjecture and Assumptions . . . . . . . 9 91 4.1.7. Justification of the Composition Function . . . . . . 10 92 4.1.8. Sources of Deviation from the Ground Truth . . . . . . 10 93 4.1.9. Specific cases where the conjecture might fail . . . . 11 94 4.1.10. Application of Measurement Methodology . . . . . . . . 12 95 5. One-way Delay Composed Metrics and Statistics . . . . . . . . 12 96 5.1. Name: 97 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream . . . 12 98 5.1.1. Metric Parameters . . . . . . . . . . . . . . . . . . 12 99 5.1.2. Definition and Metric Units . . . . . . . . . . . . . 12 100 5.1.3. Discussion and other details . . . . . . . . . . . . . 13 101 5.1.4. Statistic: . . . . . . . . . . . . . . . . . . . . . . 13 102 5.2. Name: Type-P-Finite-Composite-One-way-Delay-Mean . . . . . 13 103 5.2.1. Metric Parameters . . . . . . . . . . . . . . . . . . 13 104 5.2.2. Definition and Metric Units of the Mean Statistic . . 13 105 5.2.3. Discussion and other details . . . . . . . . . . . . . 14 106 5.2.4. Statistic: . . . . . . . . . . . . . . . . . . . . . . 14 107 5.2.5. Composition Function: Sum of Means . . . . . . . . . . 14 108 5.2.6. Statement of Conjecture and Assumptions . . . . . . . 14 109 5.2.7. Justification of the Composition Function . . . . . . 15 110 5.2.8. Sources of Deviation from the Ground Truth . . . . . . 15 111 5.2.9. Specific cases where the conjecture might fail . . . . 15 112 5.2.10. Application of Measurement Methodology . . . . . . . . 15 113 5.3. Name: Type-P-Finite-Composite-One-way-Delay-Minimum . . . 15 114 5.3.1. Metric Parameters . . . . . . . . . . . . . . . . . . 15 115 5.3.2. Definition and Metric Units of the Minimum 116 Statistic . . . . . . . . . . . . . . . . . . . . . . 15 117 5.3.3. Discussion and other details . . . . . . . . . . . . . 16 118 5.3.4. Statistic: . . . . . . . . . . . . . . . . . . . . . . 16 119 5.3.5. Composition Function: Sum of Minima . . . . . . . . . 16 120 5.3.6. Statement of Conjecture and Assumptions . . . . . . . 16 121 5.3.7. Justification of the Composition Function . . . . . . 17 122 5.3.8. Sources of Deviation from the Ground Truth . . . . . . 17 123 5.3.9. Specific cases where the conjecture might fail . . . . 17 124 5.3.10. Application of Measurement Methodology . . . . . . . . 17 125 6. Loss Metrics and Statistics . . . . . . . . . . . . . . . . . 17 126 6.1. Type-P-Composite-One-way-Packet-Loss-Empirical-Probability 17 127 6.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 17 128 6.1.2. Definition and Metric Units . . . . . . . . . . . . . 17 129 6.1.3. Discussion and other details . . . . . . . . . . . . . 17 130 6.1.4. Statistic: 131 Type-P-One-way-Packet-Loss-Empirical-Probability . . . 18 132 6.1.5. Composition Function: Composition of Empirical 133 Probabilities . . . . . . . . . . . . . . . . . . . . 18 134 6.1.6. Statement of Conjecture and Assumptions . . . . . . . 18 135 6.1.7. Justification of the Composition Function . . . . . . 18 136 6.1.8. Sources of Deviation from the Ground Truth . . . . . . 19 137 6.1.9. Specific cases where the conjecture might fail . . . . 19 138 6.1.10. Application of Measurement Methodology . . . . . . . . 19 139 7. Delay Variation Metrics and Statistics . . . . . . . . . . . . 19 140 7.1. Name: Type-P-One-way-pdv-refmin-Poisson/Periodic-Stream . 19 141 7.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 19 142 7.1.2. Definition and Metric Units . . . . . . . . . . . . . 20 143 7.1.3. Discussion and other details . . . . . . . . . . . . . 20 144 7.1.4. Statistics: Mean, Variance, Skewness, Quanitle . . . . 20 145 7.1.5. Composition Functions: . . . . . . . . . . . . . . . . 21 146 7.1.6. Statement of Conjecture and Assumptions . . . . . . . 22 147 7.1.7. Justification of the Composition Function . . . . . . 22 148 7.1.8. Sources of Deviation from the Ground Truth . . . . . . 23 149 7.1.9. Specific cases where the conjecture might fail . . . . 23 150 7.1.10. Application of Measurement Methodology . . . . . . . . 23 151 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 152 8.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 23 153 8.2. User Data Confidentiality . . . . . . . . . . . . . . . . 23 154 8.3. Interference with the metrics . . . . . . . . . . . . . . 24 155 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 156 10. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 24 157 11. Issues (Open and Closed) . . . . . . . . . . . . . . . . . . . 24 158 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 159 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 160 13.1. Normative References . . . . . . . . . . . . . . . . . . . 26 161 13.2. Informative References . . . . . . . . . . . . . . . . . . 26 162 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 163 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 165 1. Contributors 167 Thus far, the following people have contributed useful ideas, 168 suggestions, or the text of sections that have been incorporated into 169 this memo: 171 - Phil Chimento 173 - Reza Fardid 175 - Roman Krzanowski 177 - Maurizio Molina 179 - Lei Liang 181 - Dave Hoeflin 183 2. Introduction 185 The IPPM framework [RFC2330] describes two forms of metric 186 composition, spatial and temporal. The new composition framework 187 [I-D.ietf-ippm-framework-compagg] expands and further qualifies these 188 original forms into three categories. This memo describes Spatial 189 Composition, one of the categories of metrics under the umbrella of 190 the composition framework. 192 Spatial composition encompasses the definition of performance metrics 193 that are applicable to a complete path, based on metrics collected on 194 various sub-paths. 196 The main purpose of this memo is to define the deterministic 197 functions that yield the complete path metrics using metrics of the 198 sub-paths. The effectiveness of such metrics is dependent on their 199 usefulness in analysis and applicability with practical measurement 200 methods. 202 The relationships may involve conjecture, and [RFC2330] lists four 203 points that the metric definitions should include: 205 o the specific conjecture applied to the metric and assumptions of 206 the statistical model of the process being measured (if any, see 207 [RFC2330] section 12), 209 o a justification of the practical utility of the composition in 210 terms of making accurate measurements of the metric on the path, 212 o a justification of the usefulness of the composition in terms of 213 making analysis of the path using A-frame concepts more effective, 214 and 216 o an analysis of how the conjecture could be incorrect. 218 Also, [RFC2330] gives an example using the conjecture that the delay 219 of a path is very nearly the sum of the delays of the exchanges and 220 clouds of the corresponding path digest. This example is 221 particularly relevant to those who wish to assess the performance of 222 an Inter-domain path without direct measurement, and the performance 223 estimate of the complete path is related to the measured results for 224 various sub-paths instead. 226 Approximate functions between the sub-path and complete path metrics 227 are useful, with knowledge of the circumstances where the 228 relationships are/are not applicable. For example, we would not 229 expect that delay singletons from each sub-path would sum to produce 230 an accurate estimate of a delay singleton for the complete path 231 (unless all the delays were essentially constant - very unlikely). 232 However, other delay statistics (based on a reasonable sample size) 233 may have a sufficiently large set of circumstances where they are 234 applicable. 236 2.1. Motivation 238 One-way metrics defined in other IPPM RFCs all assume that the 239 measurement can be practically carried out between the source and the 240 destination of the interest. Sometimes there are reasons that the 241 measurement can not be executed from the source to the destination. 242 For instance, the measurement path may cross several independent 243 domains that have conflicting policies, measurement tools and 244 methods, and measurement time assignment. The solution then may be 245 the composition of several sub-path measurements. This means each 246 domain performs the One-way measurement on a sub path between two 247 nodes that are involved in the complete path following its own 248 policy, using its own measurement tools and methods, and using its 249 own measurement timing. Under the appropriate conditions, one can 250 combine the sub-path One-way metric results to estimate the complete 251 path One-way measurement metric with some degree of accuracy. 253 3. Scope and Application 254 3.1. Scope of work 256 For the primary IPPM metrics of Loss, Delay, and Delay Variation, 257 this memo gives a set of metrics that can be composed from the same 258 or similar sub-path metrics. This means that the composition 259 function may utilize: 261 o the same metric for each sub-path; 263 o multiple metrics for each sub-path (possibly one that is the same 264 as the complete path metric); 266 o a single sub-path metric that is different from the complete path 267 metric; 269 o different measurement techniques like active and passive 270 (recognizing that PSAMP WG will define capabilities to sample 271 packets to support measurement). 273 We note a possibility: Using a complete path metric and all but one 274 sub-path metric to infer the performance of the missing sub-path, 275 especially when the "last" sub-path metric is missing. However, such 276 de-composition calculations, and the corresponding set of issues they 277 raise, are beyond the scope of this memo. 279 3.2. Application 281 The new composition framework [I-D.ietf-ippm-framework-compagg] 282 requires the specification of the applicable circumstances for each 283 metric. In particular, each section addresses whether the metric: 285 Requires the same test packets to traverse all sub-paths, or may use 286 similar packets sent and collected separately in each sub-path. 288 Requires homogeneity of measurement methodologies, or can allow a 289 degree of flexibility (e.g., active or passive methods produce the 290 "same" metric). Also, the applicable sending streams will be 291 specified, such as Poisson, Periodic, or both. 293 Needs information or access that will only be available within an 294 operator's domain, or is applicable to Inter-domain composition. 296 Requires synchronized measurement time intervals in all sub-paths, or 297 largely overlapping, or no timing requirements. 299 Requires assumption of sub-path independence w.r.t. the metric being 300 defined/composed, or other assumptions. 302 Has known sources of inaccuracy/error, and identifies the sources. 304 3.3. Incomplete Information 306 In practice, when measurements cannot be initiated on a sub-path (and 307 perhaps the measurement system gives up during the test interval), 308 then there will not be a value for the sub-path reported, and the 309 entire test result SHOULD be recorded as "undefined". This case 310 should be distinguished from the case where the measurement system 311 continued to send packets throughout the test interval, but all were 312 declared lost. 314 When a composed metric requires measurements from sub paths A, B, and 315 C, and one or more of the sub-path results are undefined, then the 316 composed metric SHOULD also be recorded as undefined. 318 4. Common Specifications for Composed Metrics 320 To reduce the redundant information presented in the detailed metrics 321 sections that follow, this section presents the specifications that 322 are common to two or more metrics. The section is organized using 323 the same subsections as the individual metrics, to simplify 324 comparisons. 326 Also, the following index variables represent the following: 328 o m = index for packets sent 330 o n = index for packets received 332 o s = index for involved sub-paths 334 4.1. Name: Type-P 336 All metrics use the Type-P convention as described in [RFC2330]. The 337 rest of the name is unique to each metric. 339 4.1.1. Metric Parameters 341 o Src, the IP address of a host 343 o Dst, the IP address of a host 345 o T, a time (start of test interval) 347 o Tf, a time (end of test interval) 348 o lambda, a rate in reciprocal seconds (for Poisson Streams) 350 o incT, the nominal duration of inter-packet interval, first bit to 351 first bit (for Periodic Streams) 353 o T0, a time that MUST be selected at random from the interval [T, 354 T+dT] to start generating packets and taking measurements (for 355 Periodic Streams) 357 o TstampSrc, the wire time of the packet as measured at MP(Src) 359 o TstampDst, the wire time of the packet as measured at MP(Dst), 360 assigned to packets that arrive within a "reasonable" time. 362 o Tmax, a maximum waiting time for packets at the destination, set 363 sufficiently long to disambiguate packets with long delays from 364 packets that are discarded (lost), thus the distribution of delay 365 is not truncated. 367 o M, the total number of packets sent between T0 and Tf 369 o N, the total number of packets received at Dst (sent between T0 370 and Tf) 372 o S, the number of sub-paths involved in the complete Src-Dst path 374 4.1.2. Definition and Metric Units 376 This section is unique for every metric. 378 4.1.3. Discussion and other details 380 This section is unique for every metric. 382 4.1.4. Statistic: 384 This section is unique for every metric. 386 4.1.5. Composition Function 388 This section is unique for every metric. 390 4.1.6. Statement of Conjecture and Assumptions 392 This section is unique for each metric. 394 4.1.7. Justification of the Composition Function 396 It is sometimes impractical to conduct active measurements between 397 every Src-Dst pair. Since the full mesh of N measurement points 398 grows as N x N, the scope of measurement may be limited by testing 399 resources. 401 There may be varying limitations on active testing in different parts 402 of the network. For example, it may not be possible to collect the 403 desired sample size in each test interval when access link speed is 404 limited, because of the potential for measurement traffic to degrade 405 the user traffic performance. The conditions on a low-speed access 406 link may be understood well-enough to permit use of a small sample 407 size/rate, while a larger sample size/rate may be used on other sub- 408 paths. 410 Also, since measurement operations have a real monetary cost, there 411 is value in re-using measurements where they are applicable, rather 412 than launching new measurements for every possible source-destination 413 pair. 415 4.1.8. Sources of Deviation from the Ground Truth 417 4.1.8.1. Sub-path List Differs from Complete Path 419 The measurement packets, each having source and destination addresses 420 intended for collection at edges of the sub-path, may take a 421 different specific path through the network equipment and links when 422 compared to packets with the source and destination addresses of the 423 complete path. Examples sources of parallel paths include Equal Cost 424 Multi-Path and parallel (or bundled) links. Therefore, the 425 performance estimated from the composition of sub-path measurements 426 may differ from the performance experienced by packets on the 427 complete path. Multiple measurements employing sufficient sub-path 428 address pairs might produce bounds on the extent of this error. 430 We also note the possibility of re-routing during a measurement 431 interval, as it may affect the correspondence between packets 432 traversing the complete path and the sub-paths that were "involved" 433 prior to the re-route. 435 4.1.8.2. Sub-path Contains Extra Network Elements 437 Related to the case of an alternate path described above is the case 438 where elements in the measured path are unique to measurement system 439 connectivity. For example, a measurement system may use a dedicated 440 link to a LAN switch, and packets on the complete path do not 441 traverse that link. The performance of such a dedicated link would 442 be measured continuously, and its contribution to the sub-path 443 metrics SHOULD be minimized as a source of error. 445 4.1.8.3. Sub-paths Have Incomplete Coverage 447 Measurements of sub-path performance may not cover all the network 448 elements on the complete path. For example, the network exchange 449 points might be excluded unless a cooperative measurement is 450 conducted. In this example, test packets on the previous sub-path 451 are received just before the exchange point and test packets on the 452 next sub-path are injected just after the same exchange point. 453 Clearly, the set of sub-path measurements SHOULD cover all critical 454 network elements in the complete path. 456 4.1.8.4. Absence of route 458 ******************** 460 Note: this section may be expressing the point of 4.1.8.1 in 461 different words - its status is TBD. 463 ******************** 465 Sub-path destination addresses and complete path addresses do not 466 belong to the same network. Therefore routes selected to reach each 467 sub-path destinations differ from the route that would be selected to 468 reach the destination address of the complete path. Consequently 469 spatial composition may produce finite estimation of a ground true 470 metric between a source Src and a destination Dst when the route 471 between Src and Dst is undefined. 473 4.1.9. Specific cases where the conjecture might fail 475 This section is unique for most metrics (see the metric-specific 476 sections). 478 For delay-related metrics, One-way delay always depends on packet 479 size and link capacity, since it is measured in [RFC2679] from first 480 bit to last bit. If the size of an IP packet changes (due to 481 encapsulation for security reasons), this will influence delay 482 performance. 484 Fragmentation is a major issue for compostion accuracy, since all 485 metrics require all fragments to arrive before proceeding, and 486 fragmented complete path performance is likely to be different from 487 performance with non-fragmented packets and composed metrics based on 488 non-fragmented sub-path measurements. 490 4.1.10. Application of Measurement Methodology 492 The methodology: 494 SHOULD use similar packets sent and collected separately in each sub- 495 path. 497 Allows a degree of flexibility regarding test stream generation 498 (e.g., active or passive methods can produce an equivalent result, 499 but the lack of control over the source, timing and correlation of 500 passive measurements is much more challenging). 502 Poisson and/or Periodic streams are RECOMMENDED. 504 Applies to both Inter-domain and Intra-domain composition. 506 SHOULD have synchronized measurement time intervals in all sub-paths, 507 but largely overlapping intervals MAY suffice. 509 REQUIRES assumption of sub-path independence w.r.t. the metric being 510 defined/composed. 512 5. One-way Delay Composed Metrics and Statistics 514 5.1. Name: Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream 516 This metric is a necessary element of Delay Composition metrics, and 517 its definition does not formally exist elsewhere in IPPM literature. 519 5.1.1. Metric Parameters 521 See the common parameters section above. 523 5.1.2. Definition and Metric Units 525 Using the parameters above, we obtain the value of Type-P-One-way- 526 Delay singleton as per [RFC2679]. 528 For each packet [i] that has a finite One-way Delay (in other words, 529 excluding packets which have undefined one-way delay): 531 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i] = 533 FiniteDelay[i] = TstampDst - TstampSrc 535 The units of measure for this metric are time in seconds, expressed 536 in sufficiently low resolution to convey meaningful quantitative 537 information. For example, resolution of microseconds is usually 538 sufficient. 540 5.1.3. Discussion and other details 542 The "Type-P-Finite-One-way-Delay" metric permits calculation of the 543 sample mean statistic. This resolves the problem of including lost 544 packets in the sample (whose delay is undefined), and the issue with 545 the informal assignment of infinite delay to lost packets (practical 546 systems can only assign some very large value). 548 The Finite-One-way-Delay approach handles the problem of lost packets 549 by reducing the event space. We consider conditional statistics, and 550 estimate the mean one-way delay conditioned on the event that all 551 packets in the sample arrive at the destination (within the specified 552 waiting time, Tmax). This offers a way to make some valid statements 553 about one-way delay, and at the same time avoiding events with 554 undefined outcomes. This approach is derived from the treatment of 555 lost packets in [RFC3393], and is similar to [Y.1540] . 557 5.1.4. Statistic: 559 All statistics defined in [RFC2679] are applicable to the finite one- 560 way delay,and additional metrics are possible, such as the mean (see 561 below). 563 5.2. Name: Type-P-Finite-Composite-One-way-Delay-Mean 565 This section describes a statistic based on the Type-P-Finite-One- 566 way-Delay-Poisson/Periodic-Stream metric. 568 5.2.1. Metric Parameters 570 See the common parameters section above. 572 5.2.2. Definition and Metric Units of the Mean Statistic 574 We define 575 Type-P-Finite-One-way-Delay-Mean = 576 N 577 --- 578 1 \ 579 MeanDelay = - * > (FiniteDelay [n]) 580 N / 581 --- 582 n = 1 584 where all packets n= 1 through N have finite singleton delays. 586 The units of measure for this metric are time in seconds, expressed 587 in sufficiently fine resolution to convey meaningful quantitative 588 information. For example, resolution of microseconds is usually 589 sufficient. 591 5.2.3. Discussion and other details 593 The Type-P-Finite-One-way-Delay-Mean metric requires the conditional 594 delay distribution described in section 5.1. 596 5.2.4. Statistic: 598 This metric, a mean, does not require additional statistics. 600 5.2.5. Composition Function: Sum of Means 602 The Type-P-Finite--Composite-One-way-Delay-Mean, or CompMeanDelay, 603 for the complete Source to Destination path can be calculated from 604 sum of the Mean Delays of all its S constituent sub-paths. 606 Then the 608 Type-P-Finite-Composite-One-way-Delay-Mean = 609 S 610 --- 611 \ 612 CompMeanDelay = > (MeanDelay [s]) 613 / 614 --- 615 s = 1 616 where sub-paths s = 1 to S are invloved in the complete path. 618 5.2.6. Statement of Conjecture and Assumptions 620 The mean of a sufficiently large stream of packets measured on each 621 sub-path during the interval [T, Tf] will be representative of the 622 ground truth mean of the delay distribution (and the distributions 623 themselves are sufficiently independent), such that the means may be 624 added to produce an estimate of the complete path mean delay. 626 It is assumed that the one-way delay distributions of the sub-paths 627 and the complete path are continuous. The mean of bi-modal 628 distributions have the unfortunate property that such a value may 629 never occur. 631 5.2.7. Justification of the Composition Function 633 See the common section. 635 5.2.8. Sources of Deviation from the Ground Truth 637 See the common section. 639 5.2.9. Specific cases where the conjecture might fail 641 If any of the sub-path distributions are bimodal, then the measured 642 means may not be stable, and in this case the mean will not be a 643 particularly useful statistic when describing the delay distribution 644 of the complete path. 646 The mean may not be sufficiently robust statistic to produce a 647 reliable estimate, or to be useful even if it can be measured. 649 If a link contributing non-negligible delay is erroneously included 650 or excluded, the composition will be in error. 652 5.2.10. Application of Measurement Methodology 654 The requirements of the common section apply here as well. 656 5.3. Name: Type-P-Finite-Composite-One-way-Delay-Minimum 658 This section describes is a statistic based on the Type-P-Finite-One- 659 way-Delay-Poisson/Periodic-Stream metric, and the composed metric 660 based on that statistic. 662 5.3.1. Metric Parameters 664 See the common parameters section above. 666 5.3.2. Definition and Metric Units of the Minimum Statistic 668 We define 669 Type-P-Finite-One-way-Delay-Minimum = 670 = MinDelay = (FiniteDelay [j]) 672 such that for some index, j, where 1<= j <= N 673 FiniteDelay[j] <= FiniteDelay[n] for all n 675 where all packets n = 1 through N have finite singleton delays. 677 The units of measure for this metric are time in seconds, expressed 678 in sufficiently fine resolution to convey meaningful quantitative 679 information. For example, resolution of microseconds is usually 680 sufficient. 682 5.3.3. Discussion and other details 684 The Type-P-Finite-One-way-Delay-Minimum metric requires the 685 conditional delay distribution described in section 5.1.3. 687 5.3.4. Statistic: 689 This metric, a minimum, does not require additional statistics. 691 5.3.5. Composition Function: Sum of Minima 693 The Type-P-Finite--Composite-One-way-Delay-Minimum, or CompMinDelay, 694 for the complete Source to Destination path can be calculated from 695 sum of the Minimum Delays of all its S constituent sub-paths. 697 Then the 699 Type-P-Finite-Composite-One-way-Delay-Minimum = 700 S 701 --- 702 \ 703 CompMinDelay = > (MinDelay [s]) 704 / 705 --- 706 s = 1 708 5.3.6. Statement of Conjecture and Assumptions 710 The minimum of a sufficiently large stream of packets measured on 711 each sub-path during the interval [T, Tf] will be representative of 712 the ground truth minimum of the delay distribution (and the 713 distributions themselves are sufficiently independent), such that the 714 minima may be added to produce an estimate of the complete path 715 minimum delay. 717 It is assumed that the one-way delay distributions of the sub-paths 718 and the complete path are continuous. 720 5.3.7. Justification of the Composition Function 722 See the common section. 724 5.3.8. Sources of Deviation from the Ground Truth 726 See the common section. 728 5.3.9. Specific cases where the conjecture might fail 730 If the routing on any of the sub-paths is not stable, then the 731 measured minimum may not be stable. In this case the composite 732 minimum would tend to produce an estimate for the complete path that 733 may be too low for the current path. 735 5.3.10. Application of Measurement Methodology 737 The requirements of the common section apply here as well. 739 6. Loss Metrics and Statistics 741 6.1. Type-P-Composite-One-way-Packet-Loss-Empirical-Probability 743 6.1.1. Metric Parameters: 745 Same as section 4.1.1. 747 6.1.2. Definition and Metric Units 749 Using the parameters above, we obtain the value of Type-P-One-way- 750 Packet-Loss singleton and stream as per [RFC2680]. 752 We obtain a sequence of pairs with elements as follows: 754 o TstampSrc, as above 756 o L, either zero or one, where L=1 indicates loss and L=0 indicates 757 arrival at the destination within TstampSrc + Tmax. 759 6.1.3. Discussion and other details 760 6.1.4. Statistic: Type-P-One-way-Packet-Loss-Empirical-Probability 762 Given the stream parameter M, the number of packets sent, we can 763 define the Empirical Probability of Loss Statistic (Ep), consistent 764 with Average Loss in [RFC2680], as follows: 766 Type-P-One-way-Packet-Loss-Empirical-Probability = 767 M 768 --- 769 1 \ 770 Ep = - * > (L[m]) 771 M / 772 --- 773 m = 1 775 where all packets m = 1 through M have a value for L. 777 6.1.5. Composition Function: Composition of Empirical Probabilities 779 The Type-P-One-way-Composite-Packet-Loss-Empirical-Probability, or 780 CompEp for the complete Source to Destination path can be calculated 781 by combining Ep of all its constituent sub-paths (Ep1, Ep2, Ep3, ... 782 Epn) as 784 Type-P-Composite-One-way-Packet-Loss-Empirical-Probability = 785 CompEp = 1 - {(1 - Ep1) x (1 - Ep2) x (1 - Ep3) x ... x (1 - EpS)} 787 If any Eps is undefined in a particular measurement interval, 788 possibly because a measurement system failed to report a value, then 789 any CompEp that uses sub-path s for that measurement interval is 790 undefined. 792 6.1.6. Statement of Conjecture and Assumptions 794 The empirical probability of loss calculated on a sufficiently large 795 stream of packets measured on each sub-path during the interval [T, 796 Tf] will be representative of the ground truth empirical loss 797 probability (and the probabilities themselves are sufficiently 798 independent), such that the sub-path probabilities may be combined to 799 produce an estimate of the complete path empirical loss probability. 801 6.1.7. Justification of the Composition Function 803 See the common section. 805 6.1.8. Sources of Deviation from the Ground Truth 807 See the common section. 809 6.1.9. Specific cases where the conjecture might fail 811 A concern for loss measurements combined in this way is that root 812 causes may be correlated to some degree. 814 For example, if the links of different networks follow the same 815 physical route, then a single catastrophic event like a fire in a 816 tunnel could cause an outage or congestion on remaining paths in 817 multiple networks. Here it is important to ensure that measurements 818 before the event and after the event are not combined to estimate the 819 composite performance. 821 Or, when traffic volumes rise due to the rapid spread of an email- 822 born worm, loss due to queue overflow in one network may help another 823 network to carry its traffic without loss. 825 others... 827 6.1.10. Application of Measurement Methodology 829 See the common section. 831 7. Delay Variation Metrics and Statistics 833 7.1. Name: Type-P-One-way-pdv-refmin-Poisson/Periodic-Stream 835 This packet delay variation (PDV) metric is a necessary element of 836 Composed Delay Variation metrics, and its definition does not 837 formally exist elsewhere in IPPM literature. 839 7.1.1. Metric Parameters: 841 In addition to the parameters of section 4.1.1: 843 o TstampSrc[i], the wire time of packet[i] as measured at MP(Src) 844 (measurement point at the source) 846 o TstampDst[i], the wire time of packet[i] as measured at MP(Dst), 847 assigned to packets that arrive within a "reasonable" time. 849 o B, a packet length in bits 850 o F, a selection function unambiguously defining the packets from 851 the stream that are selected for the packet-pair computation of 852 this metric. F(first packet), the first packet of the pair, MUST 853 have a valid Type-P-Finite-One-way-Delay less than Tmax (in other 854 words, excluding packets which have undefined one-way delay) and 855 MUST have been transmitted during the interval T, Tf. The second 856 packet in the pair, F(second packet) MUST be the packet with the 857 minimum valid value of Type-P-Finite-One-way-Delay for the stream, 858 in addition to the criteria for F(first packet). If multiple 859 packets have equal minimum Type-P-Finite-One-way-Delay values, 860 then the value for the earliest arriving packet SHOULD be used. 862 o MinDelay, the Type-P-Finite-One-way-Delay value for F(second 863 packet) given above. 865 o N, the number of packets received at the Destination meeting the 866 F(first packet) criteria. 868 7.1.2. Definition and Metric Units 870 Using the definition above in section 5.1.2, we obtain the value of 871 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[n], the singleton 872 for each packet[i] in the stream (a.k.a. FiniteDelay[i]). 874 For each packet[n] that meets the F(first packet) criteria given 875 above: Type-P-One-way-pdv-refmin-Poisson/Periodic-Stream[n] = 877 PDV[n] = FiniteDelay[n] - MinDelay 879 where PDV[i] is in units of time in seconds, expressed in 880 sufficiently fine resolution to convey meaningful quantitative 881 information. For example, resolution of microseconds is usually 882 sufficient. 884 7.1.3. Discussion and other details 886 This metric produces a sample of delay variation normalized to the 887 minimum delay of the sample. The resulting delay variation 888 distribution is independent of the sending sequence (although 889 specific FiniteDelay values within the distribution may be 890 correlated, depending on various stream parameters such as packet 891 spacing). This metric is equivalent to the IP Packet Delay Variation 892 parameter defined in [Y.1540]. 894 7.1.4. Statistics: Mean, Variance, Skewness, Quanitle 896 We define the mean PDV as follows (where all packets n = 1 through N 897 have a value for PDV[n]): 899 Type-P-One-way-pdv-refmin-Mean = MeanPDV = 900 N 901 --- 902 1 \ 903 - * > (PDV[n]) 904 N / 905 --- 906 n = 1 908 We define the variance of PDV as follows: 910 Type-P-One-way-pdv-refmin-Variance = VarPDV = 911 N 912 --- 913 1 \ 2 914 ------- > (PDV[n] - MeanPDV) 915 (N - 1) / 916 --- 917 n = 1 919 We define the skewness of PDV as follows: 921 Type-P-One-way-pdv-refmin-Skewness = SkewPDV = 922 N 923 --- 3 924 \ / \ 925 > | PDV[n]- MeanPDV | 926 / \ / 927 --- 928 n = 1 929 ----------------------------------- 930 / \ 931 | ( 3/2 ) | 932 \ (N - 1) * VarPDV / 934 We define the Quantile of the IPDVRefMin sample as the value where 935 the specified fraction of singletons is less than the given value. 937 7.1.5. Composition Functions: 939 This section gives two alternative composition functions. The 940 objective is to estimate a quantile of the complete path delay 941 variation distribution. The composed quantile will be estimated 942 using information from the sub-path delay variation distributions. 944 7.1.5.1. Approximate Convolution 946 The Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream samples from 947 each sub-path are summarized as a histogram with 1 ms bins 948 representing the one-way delay distribution. 950 From [TBP], the distribution of the sum of independent random 951 variables can be derived using the relation: 953 Type-P-Composite-One-way-pdv-refmin-quantile-a = 954 / / 955 P(X + Y + Z <= a) = | | P(X <= a-y-z) * P(Y = y) * P(Z = z) dy dz 956 / / 957 z y 958 where X, Y, and Z are random variables representing the delay 959 variation distributions of the sub-paths of the complete path (in 960 this case, there are three sub-paths), and a is the quantile of 961 interest. Note dy and dz indicate partial integration here.This 962 relation can be used to compose a quantile of interest for the 963 complete path from the sub-path delay distributions. The histograms 964 with 1 ms bins are discrete approximations of the delay 965 distributions. 967 7.1.5.2. Normal Power Approximation 969 Type-P-One-way-Composite-pdv-refmin-NPA for the complete Source to 970 Destination path can be calculated by combining statistics of all the 971 constituent sub-paths in the process described in [Y.1541] clause 8 972 and Appendix X. 974 7.1.6. Statement of Conjecture and Assumptions 976 The delay distribution of a sufficiently large stream of packets 977 measured on each sub-path during the interval [T, Tf] will be 978 sufficiently stationary and the sub-path distributions themselves are 979 sufficiently independent, so that summary information describing the 980 sub-path distributions can be combined to estimate the delay 981 distribution of complete path. 983 It is assumed that the one-way delay distributions of the sub-paths 984 and the complete path are continuous. 986 7.1.7. Justification of the Composition Function 988 See the common section. 990 7.1.8. Sources of Deviation from the Ground Truth 992 In addition to the common deviations, a few additional sources exist 993 here. For one, very tight distributions with range on the order of a 994 few milliseconds are not accurately represented by a histogram with 1 995 ms bins. This size was chosen assuming an implicit requirement on 996 accuracy: errors of a few milliseconds are acceptable when assessing 997 a composed distribution quantile. 999 Also, summary statistics cannot describe the subtleties of an 1000 empirical distribution exactly, especially when the distribution is 1001 very different from a classical form. Any procedure that uses these 1002 statistics alone may incur error. 1004 7.1.9. Specific cases where the conjecture might fail 1006 If the delay distributions of the sub-paths are somehow correlated, 1007 then neither of these composition functions will be reliable 1008 estimators of the complete path distribution. 1010 In practice, sub-path delay distributions with extreme outliers have 1011 increased the error of the composed metric estimate. 1013 7.1.10. Application of Measurement Methodology 1015 See the common section. 1017 8. Security Considerations 1019 8.1. Denial of Service Attacks 1021 This metric requires a stream of packets sent from one host (source) 1022 to another host (destination) through intervening networks. This 1023 method could be abused for denial of service attacks directed at 1024 destination and/or the intervening network(s). 1026 Administrators of source, destination, and the intervening network(s) 1027 should establish bilateral or multi-lateral agreements regarding the 1028 timing, size, and frequency of collection of sample metrics. Use of 1029 this method in excess of the terms agreed between the participants 1030 may be cause for immediate rejection or discard of packets or other 1031 escalation procedures defined between the affected parties. 1033 8.2. User Data Confidentiality 1035 Active use of this method generates packets for a sample, rather than 1036 taking samples based on user data, and does not threaten user data 1037 confidentiality. Passive measurement must restrict attention to the 1038 headers of interest. Since user payloads may be temporarily stored 1039 for length analysis, suitable precautions MUST be taken to keep this 1040 information safe and confidential. In most cases, a hashing function 1041 will produce a value suitable for payload comparisons. 1043 8.3. Interference with the metrics 1045 It may be possible to identify that a certain packet or stream of 1046 packets is part of a sample. With that knowledge at the destination 1047 and/or the intervening networks, it is possible to change the 1048 processing of the packets (e.g. increasing or decreasing delay) that 1049 may distort the measured performance. It may also be possible to 1050 generate additional packets that appear to be part of the sample 1051 metric. These additional packets are likely to perturb the results 1052 of the sample measurement. 1054 To discourage the kind of interference mentioned above, packet 1055 interference checks, such as cryptographic hash, may be used. 1057 9. IANA Considerations 1059 Metrics defined in this memo will be registered in the IANA IPPM 1060 METRICS REGISTRY as described in initial version of the registry 1061 [RFC4148]. 1063 10. Acknowlegements 1065 A long time ago, in a galaxy far, far away (Minneapolis), Will Leland 1066 suggested the simple and elegant Type-P-Finite-One-way-Delay concept. 1067 Thanks Will. 1069 11. Issues (Open and Closed) 1071 >>>>>>>>>>>>Issue: 1073 Is Section 4.1.8.4 really describing a new error case, about 1074 Alternate Routing? Or does Section 4.1.8.1 on sub-path differences 1075 cover it all? 1077 >>>>>>>>>>>>Issue: 1079 What is the relationship between the decomposition and composition 1080 metrics? Should we put both kinds in one draft to make up a 1081 framework? The motivation of decomposition is as follows: 1083 The One-way measurement can provide result to show what the network 1084 performance between two end hosts is and whether it meets operator 1085 expectations or not. It cannot provide further information to 1086 engineers where and how to improve the performance between the source 1087 and the destination. For instance, if the network performance is not 1088 acceptable in terms of the One-way measurement, in which part of the 1089 network the engineers should put their efforts. This question can to 1090 be answered by decompose the One-way measurement to sub-path 1091 measurement to investigate the performance of different part of the 1092 network. 1094 Editor's Questions for clarification: What additional information 1095 would be provided to the decomposition process, beyond the 1096 measurement of the complete path? 1098 Is the decomposition described above intended to estimate a metric 1099 for some/all disjoint sub-paths involved in the complete path? 1101 >>>>>>>>>>>>>>>>>>RESOLUTION: treat this topic in a separate memo 1103 >>>>>>>>>>>>>>>>>>> 1105 >>>>>>>>>>>>>>>>>>>Issue 1107 Section 7 defines a new type of metric, a "combination" of metrics 1108 for one-way delay and packet loss. The purpose of this metric is to 1109 link these two primary metrics in a convenient way. 1111 Readers are asked to comment on the efficiency of the combination 1112 metric. 1114 >>>>>>>>>>>>>>>>>RESOLUTION: If a delay singleton is recorded as 1115 having "undefined" delay when the packet does not arrive within the 1116 waiting time Tmax, then this information is sufficient to determine 1117 the fraction of lost packets in the sample, and the additional loss 1118 indication of this combo is not needed. 1120 >>>>>>>>>>>>>>>>>> 1122 >>>>>>>>>>>>>>>>> Issue 1124 Can we introduce multicast metrics here, without causing too much 1125 confusion? Should the multicast version of this draft wait until the 1126 Unicast concepts are stable (or maybe appear in a separate draft)? 1128 >>>>>>>>>>>>>>>>RESOLUTION: No and Yes. 1130 12. Acknowledgements 1132 13. References 1134 13.1. Normative References 1136 [I-D.ietf-ippm-framework-compagg] 1137 Morton, A., "Framework for Metric Composition", 1138 draft-ietf-ippm-framework-compagg-07 (work in progress), 1139 October 2008. 1141 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1142 Requirement Levels", BCP 14, RFC 2119, March 1997. 1144 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1145 "Framework for IP Performance Metrics", RFC 2330, 1146 May 1998. 1148 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1149 Delay Metric for IPPM", RFC 2679, September 1999. 1151 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1152 Packet Loss Metric for IPPM", RFC 2680, September 1999. 1154 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1155 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1156 November 2002. 1158 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 1159 Registry", BCP 108, RFC 4148, August 2005. 1161 13.2. Informative References 1163 [I-D.ietf-ippm-multimetrics] 1164 Stephan, E., Liang, L., and A. Morton, "IP Performance 1165 Metrics (IPPM) for spatial and multicast", 1166 draft-ietf-ippm-multimetrics-11 (work in progress), 1167 April 2009. 1169 [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data 1170 communication service - IP packet transfer and 1171 availability performance parameters", December 2002. 1173 [Y.1541] ITU-T Recommendation Y.1541, "Network Performance 1174 Objectives for IP-based Services", February 2006. 1176 Index 1178 ? 1179 ??? 14 1181 Authors' Addresses 1183 Al Morton 1184 AT&T Labs 1185 200 Laurel Avenue South 1186 Middletown,, NJ 07748 1187 USA 1189 Phone: +1 732 420 1571 1190 Fax: +1 732 368 1192 1191 Email: acmorton@att.com 1192 URI: http://home.comcast.net/~acmacm/ 1194 Emile Stephan 1195 France Telecom Division R&D 1196 2 avenue Pierre Marzin 1197 Lannion, F-22307 1198 France 1200 Phone: 1201 Fax: +33 2 96 05 18 52 1202 Email: emile.stephan@orange-ftgroup.com 1203 URI: