idnits 2.17.1 draft-ietf-ippm-spatial-composition-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (May 30, 2010) is 5079 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 980, but not defined == Missing Reference: 'Tf' is mentioned on line 980, but not defined == Unused Reference: 'RFC5644' is defined on line 1181, 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) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) ** Obsolete normative reference: RFC 4148 (Obsoleted by RFC 6248) ** Downref: Normative reference to an Informational RFC: RFC 5474 ** Downref: Normative reference to an Informational RFC: RFC 5835 Summary: 6 errors (**), 0 flaws (~~), 4 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 1, 2010 France Telecom Division R&D 6 May 30, 2010 8 Spatial Composition of Metrics 9 draft-ietf-ippm-spatial-composition-12 11 Abstract 13 This memo utilizes IP Performance Metrics that are applicable to both 14 complete paths and sub-paths, and defines relationships to compose a 15 complete path metric from the sub-path metrics with some accuracy 16 w.r.t. the actual metrics. This is called Spatial Composition in RFC 17 2330. The memo refers to the Framework for Metric Composition, and 18 provides background and motivation for combining metrics to derive 19 others. The descriptions of several composed metrics and statistics 20 follow. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 In this memo, the characters "<=" should be read as "less than or 29 equal to" and ">=" as "greater than or equal to". 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on December 1, 2010. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 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 . . . . . . . . . . . . . . . . . . 27 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 [RFC5835] expands and further qualifies these original forms into 188 three categories. This memo describes Spatial Composition, one of 189 the categories of metrics under the umbrella of the composition 190 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 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 [RFC2330], [RFC3432] 270 and passive [RFC5474]. 272 We note a possibility: Using a complete path metric and all but one 273 sub-path metric to infer the performance of the missing sub-path, 274 especially when the "last" sub-path metric is missing. However, such 275 de-composition calculations, and the corresponding set of issues they 276 raise, are beyond the scope of this memo. 278 3.2. Application 280 The new composition framework [RFC5835] requires the specification of 281 the applicable circumstances for each metric. In particular, each 282 section addresses whether the metric: 284 Requires the same test packets to traverse all sub-paths, or may use 285 similar packets sent and collected separately in each sub-path. 287 Requires homogeneity of measurement methodologies, or can allow a 288 degree of flexibility (e.g., active or passive methods produce the 289 "same" metric). Also, the applicable sending streams will be 290 specified, such as Poisson, Periodic, or both. 292 Needs information or access that will only be available within an 293 operator's domain, or is applicable to Inter-domain composition. 295 Requires synchronized measurement time intervals in all sub-paths, or 296 largely overlapping, or no timing requirements. 298 Requires assumption of sub-path independence w.r.t. the metric being 299 defined/composed, or other assumptions. 301 Has known sources of inaccuracy/error, and identifies the sources. 303 3.3. Incomplete Information 305 In practice, when measurements cannot be initiated on a sub-path (and 306 perhaps the measurement system gives up during the test interval), 307 then there will not be a value for the sub-path reported, and the 308 entire test result SHOULD be recorded as "undefined". This case 309 should be distinguished from the case where the measurement system 310 continued to send packets throughout the test interval, but all were 311 declared lost. 313 When a composed metric requires measurements from sub paths A, B, and 314 C, and one or more of the sub-path results are undefined, then the 315 composed metric SHOULD also be recorded as undefined. 317 4. Common Specifications for Composed Metrics 319 To reduce the redundant information presented in the detailed metrics 320 sections that follow, this section presents the specifications that 321 are common to two or more metrics. The section is organized using 322 the same subsections as the individual metrics, to simplify 323 comparisons. 325 Also, the following index variables represent the following: 327 o m = index for packets sent 329 o n = index for packets received 331 o s = index for involved sub-paths 333 4.1. Name: Type-P 335 All metrics use the Type-P convention as described in [RFC2330]. The 336 rest of the name is unique to each metric. 338 4.1.1. Metric Parameters 340 o Src, the IP address of a host 342 o Dst, the IP address of a host 344 o T, a time (start of test interval) 346 o Tf, a time (end of test interval) 348 o lambda, a rate in reciprocal seconds (for Poisson Streams) 349 o incT, the nominal duration of inter-packet interval, first bit to 350 first bit (for Periodic Streams) 352 o T0, a time that MUST be selected at random from the interval [T, 353 T+dT] to start generating packets and taking measurements (for 354 Periodic Streams) 356 o TstampSrc, the wire time of the packet as measured at MP(Src) 358 o TstampDst, the wire time of the packet as measured at MP(Dst), 359 assigned to packets that arrive within a "reasonable" time. 361 o Tmax, a maximum waiting time for packets at the destination, set 362 sufficiently long to disambiguate packets with long delays from 363 packets that are discarded (lost), thus the distribution of delay 364 is not truncated. 366 o M, the total number of packets sent between T0 and Tf 368 o N, the total number of packets received at Dst (sent between T0 369 and Tf) 371 o S, the number of sub-paths involved in the complete Src-Dst path 373 o Type-P, as defined in [RFC2330], which includes any field that may 374 affect a packet's treatment as it traverses network 376 4.1.2. Definition and Metric Units 378 This section is unique for every metric. 380 4.1.3. Discussion and other details 382 This section is unique for every metric. 384 4.1.4. Statistic: 386 This section is unique for every metric. 388 4.1.5. Composition Function 390 This section is unique for every metric. 392 4.1.6. Statement of Conjecture and Assumptions 394 This section is unique for each metric. 396 4.1.7. Justification of the Composition Function 398 It is sometimes impractical to conduct active measurements between 399 every Src-Dst pair. Since the full mesh of N measurement points 400 grows as N x N, the scope of measurement may be limited by testing 401 resources. 403 There may be varying limitations on active testing in different parts 404 of the network. For example, it may not be possible to collect the 405 desired sample size in each test interval when access link speed is 406 limited, because of the potential for measurement traffic to degrade 407 the user traffic performance. The conditions on a low-speed access 408 link may be understood well-enough to permit use of a small sample 409 size/rate, while a larger sample size/rate may be used on other sub- 410 paths. 412 Also, since measurement operations have a real monetary cost, there 413 is value in re-using measurements where they are applicable, rather 414 than launching new measurements for every possible source-destination 415 pair. 417 4.1.8. Sources of Deviation from the Ground Truth 419 4.1.8.1. Sub-path List Differs from Complete Path 421 The measurement packets, each having source and destination addresses 422 intended for collection at edges of the sub-path, may take a 423 different specific path through the network equipment and links when 424 compared to packets with the source and destination addresses of the 425 complete path. Examples sources of parallel paths include Equal Cost 426 Multi-Path and parallel (or bundled) links. Therefore, the 427 performance estimated from the composition of sub-path measurements 428 may differ from the performance experienced by packets on the 429 complete path. Multiple measurements employing sufficient sub-path 430 address pairs might produce bounds on the extent of this error. 432 We also note the possibility of re-routing during a measurement 433 interval, as it may affect the correspondence between packets 434 traversing the complete path and the sub-paths that were "involved" 435 prior to the re-route. 437 4.1.8.2. Sub-path Contains Extra Network Elements 439 Related to the case of an alternate path described above is the case 440 where elements in the measured path are unique to measurement system 441 connectivity. For example, a measurement system may use a dedicated 442 link to a LAN switch, and packets on the complete path do not 443 traverse that link. The performance of such a dedicated link would 444 be measured continuously, and its contribution to the sub-path 445 metrics SHOULD be minimized as a source of error. 447 4.1.8.3. Sub-paths Have Incomplete Coverage 449 Measurements of sub-path performance may not cover all the network 450 elements on the complete path. For example, the network exchange 451 points might be excluded unless a cooperative measurement is 452 conducted. In this example, test packets on the previous sub-path 453 are received just before the exchange point and test packets on the 454 next sub-path are injected just after the same exchange point. 455 Clearly, the set of sub-path measurements SHOULD cover all critical 456 network elements in the complete path. 458 4.1.8.4. Absence of route 460 At a specific point in time, no viable route exists between the 461 complete path source and destination. The routes selected for one or 462 more sub-paths therefore differs from the complete path. 463 Consequently, spatial composition may produce finite estimation of a 464 ground truth metric between a source and a destination, even when the 465 route between them is undefined. 467 4.1.9. Specific cases where the conjecture might fail 469 This section is unique for most metrics (see the metric-specific 470 sections). 472 For delay-related metrics, One-way delay always depends on packet 473 size and link capacity, since it is measured in [RFC2679] from first 474 bit to last bit. If the size of an IP packet changes on route (due 475 to encapsulation), this can influence delay performance. However, 476 the main error source may be the additional processing associated 477 with encapsulation and encryption/decryption if not experienced or 478 accounted for in sub-path measurements. 480 Fragmentation is a major issue for composition accuracy, since all 481 metrics require all fragments to arrive before proceeding, and 482 fragmented complete path performance is likely to be different from 483 performance with non-fragmented packets and composed metrics based on 484 non-fragmented sub-path measurements. 486 Highly manipulated routing can cause measurement error if not 487 expected and compensated. For example, policy-based MPLS routing 488 could modify the class of service for the sub-paths and complete 489 path. 491 4.1.10. Application of Measurement Methodology 493 The methodology: 495 SHOULD use similar packets sent and collected separately in each sub- 496 path, where "similar" in this case means that the Type-P contains as 497 many equal attributes as possible, while recognizing that there will 498 be differences. Note that Type-P includes stream characteristics 499 (e.g., Poisson, Periodic). 501 Allows a degree of flexibility regarding test stream generation 502 (e.g., active or passive methods can produce an equivalent result, 503 but the lack of control over the source, timing and correlation of 504 passive measurements is much more challenging). 506 Poisson and/or Periodic streams are RECOMMENDED. 508 Applies to both Inter-domain and Intra-domain composition. 510 SHOULD have synchronized measurement time intervals in all sub-paths, 511 but largely overlapping intervals MAY suffice. 513 REQUIRES assumption of sub-path independence w.r.t. the metric being 514 defined/composed. 516 5. One-way Delay Composed Metrics and Statistics 518 5.1. Name: Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream 520 This metric is a necessary element of Delay Composition metrics, and 521 its definition does not formally exist elsewhere in IPPM literature. 523 5.1.1. Metric Parameters 525 See the common parameters section above. 527 5.1.2. Definition and Metric Units 529 Using the parameters above, we obtain the value of Type-P-One-way- 530 Delay singleton as per [RFC2679]. 532 For each packet [i] that has a finite One-way Delay (in other words, 533 excluding packets which have undefined one-way delay): 535 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i] = 537 FiniteDelay[i] = TstampDst - TstampSrc 538 The units of measure for this metric are time in seconds, expressed 539 in sufficiently low resolution to convey meaningful quantitative 540 information. For example, resolution of microseconds is usually 541 sufficient. 543 5.1.3. Discussion and other details 545 The "Type-P-Finite-One-way-Delay" metric permits calculation of the 546 sample mean statistic. This resolves the problem of including lost 547 packets in the sample (whose delay is undefined), and the issue with 548 the informal assignment of infinite delay to lost packets (practical 549 systems can only assign some very large value). 551 The Finite-One-way-Delay approach handles the problem of lost packets 552 by reducing the event space. We consider conditional statistics, and 553 estimate the mean one-way delay conditioned on the event that all 554 packets in the sample arrive at the destination (within the specified 555 waiting time, Tmax). This offers a way to make some valid statements 556 about one-way delay, and at the same time avoiding events with 557 undefined outcomes. This approach is derived from the treatment of 558 lost packets in [RFC3393], and is similar to [Y.1540] . 560 5.1.4. Statistic: 562 All statistics defined in [RFC2679] are applicable to the finite one- 563 way delay,and additional metrics are possible, such as the mean (see 564 below). 566 5.2. Name: Type-P-Finite-Composite-One-way-Delay-Mean 568 This section describes a statistic based on the Type-P-Finite-One- 569 way-Delay-Poisson/Periodic-Stream metric. 571 5.2.1. Metric Parameters 573 See the common parameters section above. 575 5.2.2. Definition and Metric Units of the Mean Statistic 577 We define 578 Type-P-Finite-One-way-Delay-Mean = 579 N 580 --- 581 1 \ 582 MeanDelay = - * > (FiniteDelay [n]) 583 N / 584 --- 585 n = 1 587 where all packets n= 1 through N have finite singleton delays. 589 The units of measure for this metric are time in seconds, expressed 590 in sufficiently fine resolution to convey meaningful quantitative 591 information. For example, resolution of microseconds is usually 592 sufficient. 594 5.2.3. Discussion and other details 596 The Type-P-Finite-One-way-Delay-Mean metric requires the conditional 597 delay distribution described in section 5.1. 599 5.2.4. Statistic: 601 This metric, a mean, does not require additional statistics. 603 5.2.5. Composition Function: Sum of Means 605 The Type-P-Finite--Composite-One-way-Delay-Mean, or CompMeanDelay, 606 for the complete Source to Destination path can be calculated from 607 sum of the Mean Delays of all its S constituent sub-paths. 609 Then the 611 Type-P-Finite-Composite-One-way-Delay-Mean = 612 S 613 --- 614 \ 615 CompMeanDelay = > (MeanDelay [s]) 616 / 617 --- 618 s = 1 619 where sub-paths s = 1 to S are involved in the complete path. 621 5.2.6. Statement of Conjecture and Assumptions 623 The mean of a sufficiently large stream of packets measured on each 624 sub-path during the interval [T, Tf] will be representative of the 625 ground truth mean of the delay distribution (and the distributions 626 themselves are sufficiently independent), such that the means may be 627 added to produce an estimate of the complete path mean delay. 629 It is assumed that the one-way delay distributions of the sub-paths 630 and the complete path are continuous. The mean of multi-modal 631 distributions have the unfortunate property that such a value may 632 never occur. 634 5.2.7. Justification of the Composition Function 636 See the common section. 638 5.2.8. Sources of Deviation from the Ground Truth 640 See the common section. 642 5.2.9. Specific cases where the conjecture might fail 644 If any of the sub-path distributions are multi-modal, then the 645 measured means may not be stable, and in this case the mean will not 646 be a particularly useful statistic when describing the delay 647 distribution of the complete path. 649 The mean may not be sufficiently robust statistic to produce a 650 reliable estimate, or to be useful even if it can be measured. 652 If a link contributing non-negligible delay is erroneously included 653 or excluded, the composition will be in error. 655 5.2.10. Application of Measurement Methodology 657 The requirements of the common section apply here as well. 659 5.3. Name: Type-P-Finite-Composite-One-way-Delay-Minimum 661 This section describes is a statistic based on the Type-P-Finite-One- 662 way-Delay-Poisson/Periodic-Stream metric, and the composed metric 663 based on that statistic. 665 5.3.1. Metric Parameters 667 See the common parameters section above. 669 5.3.2. Definition and Metric Units of the Minimum Statistic 671 We define 672 Type-P-Finite-One-way-Delay-Minimum = 673 = MinDelay = (FiniteDelay [j]) 675 such that for some index, j, where 1<= j <= N 676 FiniteDelay[j] <= FiniteDelay[n] for all n 678 where all packets n = 1 through N have finite singleton delays. 680 The units of measure for this metric are time in seconds, expressed 681 in sufficiently fine resolution to convey meaningful quantitative 682 information. For example, resolution of microseconds is usually 683 sufficient. 685 5.3.3. Discussion and other details 687 The Type-P-Finite-One-way-Delay-Minimum metric requires the 688 conditional delay distribution described in section 5.1.3. 690 5.3.4. Statistic: 692 This metric, a minimum, does not require additional statistics. 694 5.3.5. Composition Function: Sum of Minima 696 The Type-P-Finite--Composite-One-way-Delay-Minimum, or CompMinDelay, 697 for the complete Source to Destination path can be calculated from 698 sum of the Minimum Delays of all its S constituent sub-paths. 700 Then the 702 Type-P-Finite-Composite-One-way-Delay-Minimum = 703 S 704 --- 705 \ 706 CompMinDelay = > (MinDelay [s]) 707 / 708 --- 709 s = 1 711 5.3.6. Statement of Conjecture and Assumptions 713 The minimum of a sufficiently large stream of packets measured on 714 each sub-path during the interval [T, Tf] will be representative of 715 the ground truth minimum of the delay distribution (and the 716 distributions themselves are sufficiently independent), such that the 717 minima may be added to produce an estimate of the complete path 718 minimum delay. 720 It is assumed that the one-way delay distributions of the sub-paths 721 and the complete path are continuous. 723 5.3.7. Justification of the Composition Function 725 See the common section. 727 5.3.8. Sources of Deviation from the Ground Truth 729 See the common section. 731 5.3.9. Specific cases where the conjecture might fail 733 If the routing on any of the sub-paths is not stable, then the 734 measured minimum may not be stable. In this case the composite 735 minimum would tend to produce an estimate for the complete path that 736 may be too low for the current path. 738 5.3.10. Application of Measurement Methodology 740 The requirements of the common section apply here as well. 742 6. Loss Metrics and Statistics 744 6.1. Type-P-Composite-One-way-Packet-Loss-Empirical-Probability 746 6.1.1. Metric Parameters: 748 Same as section 4.1.1. 750 6.1.2. Definition and Metric Units 752 Using the parameters above, we obtain the value of Type-P-One-way- 753 Packet-Loss singleton and stream as per [RFC2680]. 755 We obtain a sequence of pairs with elements as follows: 757 o TstampSrc, as above 759 o L, either zero or one, where L=1 indicates loss and L=0 indicates 760 arrival at the destination within TstampSrc + Tmax. 762 6.1.3. Discussion and other details 763 6.1.4. Statistic: Type-P-One-way-Packet-Loss-Empirical-Probability 765 Given the stream parameter M, the number of packets sent, we can 766 define the Empirical Probability of Loss Statistic (Ep), consistent 767 with Average Loss in [RFC2680], as follows: 769 Type-P-One-way-Packet-Loss-Empirical-Probability = 770 M 771 --- 772 1 \ 773 Ep = - * > (L[m]) 774 M / 775 --- 776 m = 1 778 where all packets m = 1 through M have a value for L. 780 6.1.5. Composition Function: Composition of Empirical Probabilities 782 The Type-P-One-way-Composite-Packet-Loss-Empirical-Probability, or 783 CompEp for the complete Source to Destination path can be calculated 784 by combining Ep of all its constituent sub-paths (Ep1, Ep2, Ep3, ... 785 Epn) as 787 Type-P-Composite-One-way-Packet-Loss-Empirical-Probability = 788 CompEp = 1 - {(1 - Ep1) x (1 - Ep2) x (1 - Ep3) x ... x (1 - EpS)} 790 If any Eps is undefined in a particular measurement interval, 791 possibly because a measurement system failed to report a value, then 792 any CompEp that uses sub-path s for that measurement interval is 793 undefined. 795 6.1.6. Statement of Conjecture and Assumptions 797 The empirical probability of loss calculated on a sufficiently large 798 stream of packets measured on each sub-path during the interval [T, 799 Tf] will be representative of the ground truth empirical loss 800 probability (and the probabilities themselves are sufficiently 801 independent), such that the sub-path probabilities may be combined to 802 produce an estimate of the complete path empirical loss probability. 804 6.1.7. Justification of the Composition Function 806 See the common section. 808 6.1.8. Sources of Deviation from the Ground Truth 810 See the common section. 812 6.1.9. Specific cases where the conjecture might fail 814 A concern for loss measurements combined in this way is that root 815 causes may be correlated to some degree. 817 For example, if the links of different networks follow the same 818 physical route, then a single catastrophic event like a fire in a 819 tunnel could cause an outage or congestion on remaining paths in 820 multiple networks. Here it is important to ensure that measurements 821 before the event and after the event are not combined to estimate the 822 composite performance. 824 Or, when traffic volumes rise due to the rapid spread of an email- 825 born worm, loss due to queue overflow in one network may help another 826 network to carry its traffic without loss. 828 6.1.10. Application of Measurement Methodology 830 See the common section. 832 7. Delay Variation Metrics and Statistics 834 7.1. Name: Type-P-One-way-pdv-refmin-Poisson/Periodic-Stream 836 This packet delay variation (PDV) metric is a necessary element of 837 Composed Delay Variation metrics, and its definition does not 838 formally exist elsewhere in IPPM literature. 840 7.1.1. Metric Parameters: 842 In addition to the parameters of section 4.1.1: 844 o TstampSrc[i], the wire time of packet[i] as measured at MP(Src) 845 (measurement point at the source) 847 o TstampDst[i], the wire time of packet[i] as measured at MP(Dst), 848 assigned to packets that arrive within a "reasonable" time. 850 o B, a packet length in bits 852 o F, a selection function unambiguously defining the packets from 853 the stream that are selected for the packet-pair computation of 854 this metric. F(current packet), the first packet of the pair, 855 MUST have a valid Type-P-Finite-One-way-Delay less than Tmax (in 856 other words, excluding packets which have undefined one-way delay) 857 and MUST have been transmitted during the interval T, Tf. The 858 second packet in the pair, F(min_delay packet) MUST be the packet 859 with the minimum valid value of Type-P-Finite-One-way-Delay for 860 the stream, in addition to the criteria for F(current packet). If 861 multiple packets have equal minimum Type-P-Finite-One-way-Delay 862 values, then the value for the earliest arriving packet SHOULD be 863 used. 865 o MinDelay, the Type-P-Finite-One-way-Delay value for F(min_delay 866 packet) given above. 868 o N, the number of packets received at the Destination meeting the 869 F(current packet) criteria. 871 7.1.2. Definition and Metric Units 873 Using the definition above in section 5.1.2, we obtain the value of 874 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[n], the singleton 875 for each packet[i] in the stream (a.k.a. FiniteDelay[i]). 877 For each packet[n] that meets the F(first packet) criteria given 878 above: Type-P-One-way-pdv-refmin-Poisson/Periodic-Stream[n] = 880 PDV[n] = FiniteDelay[n] - MinDelay 882 where PDV[i] is in units of time in seconds, expressed in 883 sufficiently fine resolution to convey meaningful quantitative 884 information. For example, resolution of microseconds is usually 885 sufficient. 887 7.1.3. Discussion and other details 889 This metric produces a sample of delay variation normalized to the 890 minimum delay of the sample. The resulting delay variation 891 distribution is independent of the sending sequence (although 892 specific FiniteDelay values within the distribution may be 893 correlated, depending on various stream parameters such as packet 894 spacing). This metric is equivalent to the IP Packet Delay Variation 895 parameter defined in [Y.1540]. 897 7.1.4. Statistics: Mean, Variance, Skewness, Quanitle 899 We define the mean PDV as follows (where all packets n = 1 through N 900 have a value for PDV[n]): 902 Type-P-One-way-pdv-refmin-Mean = MeanPDV = 903 N 904 --- 905 1 \ 906 - * > (PDV[n]) 907 N / 908 --- 909 n = 1 911 We define the variance of PDV as follows: 913 Type-P-One-way-pdv-refmin-Variance = VarPDV = 914 N 915 --- 916 1 \ 2 917 ------- > (PDV[n] - MeanPDV) 918 (N - 1) / 919 --- 920 n = 1 922 We define the skewness of PDV as follows: 924 Type-P-One-way-pdv-refmin-Skewness = SkewPDV = 925 N 926 --- 3 927 \ / \ 928 > | PDV[n]- MeanPDV | 929 / \ / 930 --- 931 n = 1 932 ----------------------------------- 933 / \ 934 | ( 3/2 ) | 935 \ (N - 1) * VarPDV / 937 We define the Quantile of the PDVRefMin sample as the value where the 938 specified fraction of singletons is less than the given value. 940 7.1.5. Composition Functions: 942 This section gives two alternative composition functions. The 943 objective is to estimate a quantile of the complete path delay 944 variation distribution. The composed quantile will be estimated 945 using information from the sub-path delay variation distributions. 947 7.1.5.1. Approximate Convolution 949 The Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream samples from 950 each sub-path are summarized as a histogram with 1 ms bins 951 representing the one-way delay distribution. 953 From [Stats], the distribution of the sum of independent random 954 variables can be derived using the relation: 956 Type-P-Composite-One-way-pdv-refmin-quantile-a = 957 / / 958 P(X + Y + Z <= a) = | | P(X <= a-y-z) * P(Y = y) * P(Z = z) dy dz 959 / / 960 z y 961 where X, Y, and Z are random variables representing the delay 962 variation distributions of the sub-paths of the complete path (in 963 this case, there are three sub-paths), and a is the quantile of 964 interest. Note dy and dz indicate partial integration here.This 965 relation can be used to compose a quantile of interest for the 966 complete path from the sub-path delay distributions. The histograms 967 with 1 ms bins are discrete approximations of the delay 968 distributions. 970 7.1.5.2. Normal Power Approximation 972 Type-P-One-way-Composite-pdv-refmin-NPA for the complete Source to 973 Destination path can be calculated by combining statistics of all the 974 constituent sub-paths in the process described in [Y.1541] clause 8 975 and Appendix X. 977 7.1.6. Statement of Conjecture and Assumptions 979 The delay distribution of a sufficiently large stream of packets 980 measured on each sub-path during the interval [T, Tf] will be 981 sufficiently stationary and the sub-path distributions themselves are 982 sufficiently independent, so that summary information describing the 983 sub-path distributions can be combined to estimate the delay 984 distribution of complete path. 986 It is assumed that the one-way delay distributions of the sub-paths 987 and the complete path are continuous. 989 7.1.7. Justification of the Composition Function 991 See the common section. 993 7.1.8. Sources of Deviation from the Ground Truth 995 In addition to the common deviations, a few additional sources exist 996 here. For one, very tight distributions with range on the order of a 997 few milliseconds are not accurately represented by a histogram with 1 998 ms bins. This size was chosen assuming an implicit requirement on 999 accuracy: errors of a few milliseconds are acceptable when assessing 1000 a composed distribution quantile. 1002 Also, summary statistics cannot describe the subtleties of an 1003 empirical distribution exactly, especially when the distribution is 1004 very different from a classical form. Any procedure that uses these 1005 statistics alone may incur error. 1007 7.1.9. Specific cases where the conjecture might fail 1009 If the delay distributions of the sub-paths are somehow correlated, 1010 then neither of these composition functions will be reliable 1011 estimators of the complete path distribution. 1013 In practice, sub-path delay distributions with extreme outliers have 1014 increased the error of the composed metric estimate. 1016 7.1.10. Application of Measurement Methodology 1018 See the common section. 1020 8. Security Considerations 1022 8.1. Denial of Service Attacks 1024 This metric requires a stream of packets sent from one host (source) 1025 to another host (destination) through intervening networks. This 1026 method could be abused for denial of service attacks directed at 1027 destination and/or the intervening network(s). 1029 Administrators of source, destination, and the intervening network(s) 1030 should establish bilateral or multi-lateral agreements regarding the 1031 timing, size, and frequency of collection of sample metrics. Use of 1032 this method in excess of the terms agreed between the participants 1033 may be cause for immediate rejection or discard of packets or other 1034 escalation procedures defined between the affected parties. 1036 8.2. User Data Confidentiality 1038 Active use of this method generates packets for a sample, rather than 1039 taking samples based on user data, and does not threaten user data 1040 confidentiality. Passive measurement must restrict attention to the 1041 headers of interest. Since user payloads may be temporarily stored 1042 for length analysis, suitable precautions MUST be taken to keep this 1043 information safe and confidential. In most cases, a hashing function 1044 will produce a value suitable for payload comparisons. 1046 8.3. Interference with the metrics 1048 It may be possible to identify that a certain packet or stream of 1049 packets is part of a sample. With that knowledge at the destination 1050 and/or the intervening networks, it is possible to change the 1051 processing of the packets (e.g. increasing or decreasing delay) that 1052 may distort the measured performance. It may also be possible to 1053 generate additional packets that appear to be part of the sample 1054 metric. These additional packets are likely to perturb the results 1055 of the sample measurement. 1057 To discourage the kind of interference mentioned above, packet 1058 interference checks, such as cryptographic hash, may be used. 1060 9. IANA Considerations 1062 Metrics defined in this memo will be registered in the IANA IPPM 1063 METRICS REGISTRY as described in initial version of the registry 1064 [RFC4148]. 1066 10. Acknowlegements 1068 A long time ago, in a galaxy far, far away (Minneapolis), Will Leland 1069 suggested the simple and elegant Type-P-Finite-One-way-Delay concept. 1070 Thanks Will. 1072 Yaakov Stein and Donald McLachlan also provided useful comments along 1073 the way. 1075 11. Issues (Open and Closed) 1077 This section to be removed at publication. 1079 >>>>>>>>>>>>Issue: 1081 Is Section 4.1.8.4 really describing a new error case, about 1082 Alternate Routing? Or does Section 4.1.8.1 on sub-path differences 1083 cover it all? 1084 RESOLUTION: The section was re-worded in -10 version to make the 1085 topic, Absence of a real Route between the Src and Dst, more clear. 1087 >>>>>>>>>>>> 1089 >>>>>>>>>>>>Issue: 1091 What is the relationship between the decomposition and composition 1092 metrics? Should we put both kinds in one draft to make up a 1093 framework? The motivation of decomposition is as follows: 1095 The One-way measurement can provide result to show what the network 1096 performance between two end hosts is and whether it meets operator 1097 expectations or not. It cannot provide further information to 1098 engineers where and how to improve the performance between the source 1099 and the destination. For instance, if the network performance is not 1100 acceptable in terms of the One-way measurement, in which part of the 1101 network the engineers should put their efforts. This question can to 1102 be answered by decompose the One-way measurement to sub-path 1103 measurement to investigate the performance of different part of the 1104 network. 1106 Editor's Questions for clarification: What additional information 1107 would be provided to the decomposition process, beyond the 1108 measurement of the complete path? 1110 Is the decomposition described above intended to estimate a metric 1111 for some/all disjoint sub-paths involved in the complete path? 1113 >>>>>>>>>>>>>>>>>>RESOLUTION: treat this topic in a separate memo 1115 >>>>>>>>>>>>>>>>>>> 1117 >>>>>>>>>>>>>>>>>>>Issue 1119 Section 7 defines a new type of metric, a "combination" of metrics 1120 for one-way delay and packet loss. The purpose of this metric is to 1121 link these two primary metrics in a convenient way. 1123 Readers are asked to comment on the efficiency of the combination 1124 metric. 1126 >>>>>>>>>>>>>>>>>RESOLUTION: If a delay singleton is recorded as 1127 having "undefined" delay when the packet does not arrive within the 1128 waiting time Tmax, then this information is sufficient to determine 1129 the fraction of lost packets in the sample, and the additional loss 1130 indication of this combo is not needed. 1132 >>>>>>>>>>>>>>>>>> 1134 >>>>>>>>>>>>>>>>> Issue 1136 Can we introduce multicast metrics here, without causing too much 1137 confusion? Should the multicast version of this draft wait until the 1138 Unicast concepts are stable (or maybe appear in a separate draft)? 1140 >>>>>>>>>>>>>>>>RESOLUTION: No and Yes. 1142 12. Acknowledgements 1144 13. References 1146 13.1. Normative References 1148 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1149 Requirement Levels", BCP 14, RFC 2119, March 1997. 1151 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1152 "Framework for IP Performance Metrics", RFC 2330, 1153 May 1998. 1155 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1156 Delay Metric for IPPM", RFC 2679, September 1999. 1158 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1159 Packet Loss Metric for IPPM", RFC 2680, September 1999. 1161 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1162 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1163 November 2002. 1165 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 1166 performance measurement with periodic streams", RFC 3432, 1167 November 2002. 1169 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 1170 Registry", BCP 108, RFC 4148, August 2005. 1172 [RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A., 1173 Grossglauser, M., and J. Rexford, "A Framework for Packet 1174 Selection and Reporting", RFC 5474, March 2009. 1176 [RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric 1177 Composition", RFC 5835, April 2010. 1179 13.2. Informative References 1181 [RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance 1182 Metrics (IPPM): Spatial and Multicast", RFC 5644, 1183 October 2009. 1185 [Stats] McGraw-Hill NY NY, "Introduction to the Theory of 1186 Statistics, 3rd Edition,", 1974. 1188 [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data 1189 communication service - IP packet transfer and 1190 availability performance parameters", November 2007. 1192 [Y.1541] ITU-T Recommendation Y.1541, "Network Performance 1193 Objectives for IP-based Services", February 2006. 1195 Index 1197 ? 1198 ??? 14 1200 Authors' Addresses 1202 Al Morton 1203 AT&T Labs 1204 200 Laurel Avenue South 1205 Middletown,, NJ 07748 1206 USA 1208 Phone: +1 732 420 1571 1209 Fax: +1 732 368 1192 1210 Email: acmorton@att.com 1211 URI: http://home.comcast.net/~acmacm/ 1213 Emile Stephan 1214 France Telecom Division R&D 1215 2 avenue Pierre Marzin 1216 Lannion, F-22307 1217 France 1219 Phone: 1220 Fax: +33 2 96 05 18 52 1221 Email: emile.stephan@orange-ftgroup.com 1222 URI: