idnits 2.17.1 draft-ietf-ippm-spatial-composition-11.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 (April 14, 2010) is 5125 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 972, but not defined == Missing Reference: 'Tf' is mentioned on line 972, but not defined == Unused Reference: 'RFC5644' is defined on line 1160, 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 5835 Summary: 5 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: October 16, 2010 France Telecom Division R&D 6 April 14, 2010 8 Spatial Composition of Metrics 9 draft-ietf-ippm-spatial-composition-11 11 Abstract 13 This memo utilizes IPPM metrics that are applicable to both complete 14 paths and sub-paths, and defines relationships to compose a complete 15 path metric from the sub-path metrics with some accuracy w.r.t. the 16 actual metrics. This is called Spatial Composition in RFC 2330. The 17 memo refers to the Framework for Metric Composition, and provides 18 background and motivation for combining metrics to derive others. 19 The descriptions of several composed metrics and statistics follow. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 In this memo, the characters "<=" should be read as "less than or 28 equal to" and ">=" as "greater than or equal to". 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on October 16, 2010. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6 78 3. Scope and Application . . . . . . . . . . . . . . . . . . . . 6 79 3.1. Scope of work . . . . . . . . . . . . . . . . . . . . . . 7 80 3.2. Application . . . . . . . . . . . . . . . . . . . . . . . 7 81 3.3. Incomplete Information . . . . . . . . . . . . . . . . . . 8 82 4. Common Specifications for Composed Metrics . . . . . . . . . . 8 83 4.1. Name: Type-P . . . . . . . . . . . . . . . . . . . . . . . 8 84 4.1.1. Metric Parameters . . . . . . . . . . . . . . . . . . 8 85 4.1.2. Definition and Metric Units . . . . . . . . . . . . . 9 86 4.1.3. Discussion and other details . . . . . . . . . . . . . 9 87 4.1.4. Statistic: . . . . . . . . . . . . . . . . . . . . . . 9 88 4.1.5. Composition Function . . . . . . . . . . . . . . . . . 9 89 4.1.6. Statement of Conjecture and Assumptions . . . . . . . 9 90 4.1.7. Justification of the Composition Function . . . . . . 10 91 4.1.8. Sources of Deviation from the Ground Truth . . . . . . 10 92 4.1.9. Specific cases where the conjecture might fail . . . . 11 93 4.1.10. Application of Measurement Methodology . . . . . . . . 11 94 5. One-way Delay Composed Metrics and Statistics . . . . . . . . 12 95 5.1. Name: 96 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream . . . 12 97 5.1.1. Metric Parameters . . . . . . . . . . . . . . . . . . 12 98 5.1.2. Definition and Metric Units . . . . . . . . . . . . . 12 99 5.1.3. Discussion and other details . . . . . . . . . . . . . 12 100 5.1.4. Statistic: . . . . . . . . . . . . . . . . . . . . . . 13 101 5.2. Name: Type-P-Finite-Composite-One-way-Delay-Mean . . . . . 13 102 5.2.1. Metric Parameters . . . . . . . . . . . . . . . . . . 13 103 5.2.2. Definition and Metric Units of the Mean Statistic . . 13 104 5.2.3. Discussion and other details . . . . . . . . . . . . . 14 105 5.2.4. Statistic: . . . . . . . . . . . . . . . . . . . . . . 14 106 5.2.5. Composition Function: Sum of Means . . . . . . . . . . 14 107 5.2.6. Statement of Conjecture and Assumptions . . . . . . . 14 108 5.2.7. Justification of the Composition Function . . . . . . 14 109 5.2.8. Sources of Deviation from the Ground Truth . . . . . . 14 110 5.2.9. Specific cases where the conjecture might fail . . . . 15 111 5.2.10. Application of Measurement Methodology . . . . . . . . 15 112 5.3. Name: Type-P-Finite-Composite-One-way-Delay-Minimum . . . 15 113 5.3.1. Metric Parameters . . . . . . . . . . . . . . . . . . 15 114 5.3.2. Definition and Metric Units of the Minimum 115 Statistic . . . . . . . . . . . . . . . . . . . . . . 15 116 5.3.3. Discussion and other details . . . . . . . . . . . . . 16 117 5.3.4. Statistic: . . . . . . . . . . . . . . . . . . . . . . 16 118 5.3.5. Composition Function: Sum of Minima . . . . . . . . . 16 119 5.3.6. Statement of Conjecture and Assumptions . . . . . . . 16 120 5.3.7. Justification of the Composition Function . . . . . . 16 121 5.3.8. Sources of Deviation from the Ground Truth . . . . . . 16 122 5.3.9. Specific cases where the conjecture might fail . . . . 17 123 5.3.10. Application of Measurement Methodology . . . . . . . . 17 124 6. Loss Metrics and Statistics . . . . . . . . . . . . . . . . . 17 125 6.1. Type-P-Composite-One-way-Packet-Loss-Empirical-Probability 17 126 6.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 17 127 6.1.2. Definition and Metric Units . . . . . . . . . . . . . 17 128 6.1.3. Discussion and other details . . . . . . . . . . . . . 17 129 6.1.4. Statistic: 130 Type-P-One-way-Packet-Loss-Empirical-Probability . . . 17 131 6.1.5. Composition Function: Composition of Empirical 132 Probabilities . . . . . . . . . . . . . . . . . . . . 18 133 6.1.6. Statement of Conjecture and Assumptions . . . . . . . 18 134 6.1.7. Justification of the Composition Function . . . . . . 18 135 6.1.8. Sources of Deviation from the Ground Truth . . . . . . 18 136 6.1.9. Specific cases where the conjecture might fail . . . . 18 137 6.1.10. Application of Measurement Methodology . . . . . . . . 19 138 7. Delay Variation Metrics and Statistics . . . . . . . . . . . . 19 139 7.1. Name: Type-P-One-way-pdv-refmin-Poisson/Periodic-Stream . 19 140 7.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 19 141 7.1.2. Definition and Metric Units . . . . . . . . . . . . . 20 142 7.1.3. Discussion and other details . . . . . . . . . . . . . 20 143 7.1.4. Statistics: Mean, Variance, Skewness, Quanitle . . . . 20 144 7.1.5. Composition Functions: . . . . . . . . . . . . . . . . 21 145 7.1.6. Statement of Conjecture and Assumptions . . . . . . . 22 146 7.1.7. Justification of the Composition Function . . . . . . 22 147 7.1.8. Sources of Deviation from the Ground Truth . . . . . . 23 148 7.1.9. Specific cases where the conjecture might fail . . . . 23 149 7.1.10. Application of Measurement Methodology . . . . . . . . 23 150 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 151 8.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 23 152 8.2. User Data Confidentiality . . . . . . . . . . . . . . . . 23 153 8.3. Interference with the metrics . . . . . . . . . . . . . . 24 154 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 155 10. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 24 156 11. Issues (Open and Closed) . . . . . . . . . . . . . . . . . . . 24 157 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 158 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 159 13.1. Normative References . . . . . . . . . . . . . . . . . . . 26 160 13.2. Informative References . . . . . . . . . . . . . . . . . . 26 161 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 162 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 164 1. Contributors 166 Thus far, the following people have contributed useful ideas, 167 suggestions, or the text of sections that have been incorporated into 168 this memo: 170 - Phil Chimento 172 - Reza Fardid 174 - Roman Krzanowski 176 - Maurizio Molina 178 - Lei Liang 180 - Dave Hoeflin 182 2. Introduction 184 The IPPM framework [RFC2330] describes two forms of metric 185 composition, spatial and temporal. The new composition framework 186 [RFC5835] expands and further qualifies these original forms into 187 three categories. This memo describes Spatial Composition, one of 188 the categories of metrics under the umbrella of the composition 189 framework. 191 Spatial composition encompasses the definition of performance metrics 192 that are applicable to a complete path, based on metrics collected on 193 various sub-paths. 195 The main purpose of this memo is to define the deterministic 196 functions that yield the complete path metrics using metrics of the 197 sub-paths. The effectiveness of such metrics is dependent on their 198 usefulness in analysis and applicability with practical measurement 199 methods. 201 The relationships may involve conjecture, and [RFC2330] lists four 202 points that the metric definitions should include: 204 o the specific conjecture applied to the metric and assumptions of 205 the statistical model of the process being measured (if any, see 206 [RFC2330] section 12), 208 o a justification of the practical utility of the composition in 209 terms of making accurate measurements of the metric on the path, 211 o a justification of the usefulness of the composition in terms of 212 making analysis of the path using A-frame concepts more effective, 213 and 215 o an analysis of how the conjecture could be incorrect. 217 Also, [RFC2330] gives an example using the conjecture that the delay 218 of a path is very nearly the sum of the delays of the exchanges and 219 clouds of the corresponding path digest. This example is 220 particularly relevant to those who wish to assess the performance of 221 an Inter-domain path without direct measurement, and the performance 222 estimate of the complete path is related to the measured results for 223 various sub-paths instead. 225 Approximate functions between the sub-path and complete path metrics 226 are useful, with knowledge of the circumstances where the 227 relationships are/are not applicable. For example, we would not 228 expect that delay singletons from each sub-path would sum to produce 229 an accurate estimate of a delay singleton for the complete path 230 (unless all the delays were essentially constant - very unlikely). 231 However, other delay statistics (based on a reasonable sample size) 232 may have a sufficiently large set of circumstances where they are 233 applicable. 235 2.1. Motivation 237 One-way metrics defined in other IPPM RFCs all assume that the 238 measurement can be practically carried out between the source and the 239 destination of the interest. Sometimes there are reasons that the 240 measurement can not be executed from the source to the destination. 241 For instance, the measurement path may cross several independent 242 domains that have conflicting policies, measurement tools and 243 methods, and measurement time assignment. The solution then may be 244 the composition of several sub-path measurements. This means each 245 domain performs the One-way measurement on a sub path between two 246 nodes that are involved in the complete path following its own 247 policy, using its own measurement tools and methods, and using its 248 own measurement timing. Under the appropriate conditions, one can 249 combine the sub-path One-way metric results to estimate the complete 250 path One-way measurement metric with some degree of accuracy. 252 3. Scope and Application 253 3.1. Scope of work 255 For the primary IPPM metrics of Loss, Delay, and Delay Variation, 256 this memo gives a set of metrics that can be composed from the same 257 or similar sub-path metrics. This means that the composition 258 function may utilize: 260 o the same metric for each sub-path; 262 o multiple metrics for each sub-path (possibly one that is the same 263 as the complete path metric); 265 o a single sub-path metric that is different from the complete path 266 metric; 268 o different measurement techniques like active and passive 269 (recognizing that PSAMP WG will define capabilities to sample 270 packets to support measurement). 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) 347 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 4.1.2. Definition and Metric Units 375 This section is unique for every metric. 377 4.1.3. Discussion and other details 379 This section is unique for every metric. 381 4.1.4. Statistic: 383 This section is unique for every metric. 385 4.1.5. Composition Function 387 This section is unique for every metric. 389 4.1.6. Statement of Conjecture and Assumptions 391 This section is unique for each metric. 393 4.1.7. Justification of the Composition Function 395 It is sometimes impractical to conduct active measurements between 396 every Src-Dst pair. Since the full mesh of N measurement points 397 grows as N x N, the scope of measurement may be limited by testing 398 resources. 400 There may be varying limitations on active testing in different parts 401 of the network. For example, it may not be possible to collect the 402 desired sample size in each test interval when access link speed is 403 limited, because of the potential for measurement traffic to degrade 404 the user traffic performance. The conditions on a low-speed access 405 link may be understood well-enough to permit use of a small sample 406 size/rate, while a larger sample size/rate may be used on other sub- 407 paths. 409 Also, since measurement operations have a real monetary cost, there 410 is value in re-using measurements where they are applicable, rather 411 than launching new measurements for every possible source-destination 412 pair. 414 4.1.8. Sources of Deviation from the Ground Truth 416 4.1.8.1. Sub-path List Differs from Complete Path 418 The measurement packets, each having source and destination addresses 419 intended for collection at edges of the sub-path, may take a 420 different specific path through the network equipment and links when 421 compared to packets with the source and destination addresses of the 422 complete path. Examples sources of parallel paths include Equal Cost 423 Multi-Path and parallel (or bundled) links. Therefore, the 424 performance estimated from the composition of sub-path measurements 425 may differ from the performance experienced by packets on the 426 complete path. Multiple measurements employing sufficient sub-path 427 address pairs might produce bounds on the extent of this error. 429 We also note the possibility of re-routing during a measurement 430 interval, as it may affect the correspondence between packets 431 traversing the complete path and the sub-paths that were "involved" 432 prior to the re-route. 434 4.1.8.2. Sub-path Contains Extra Network Elements 436 Related to the case of an alternate path described above is the case 437 where elements in the measured path are unique to measurement system 438 connectivity. For example, a measurement system may use a dedicated 439 link to a LAN switch, and packets on the complete path do not 440 traverse that link. The performance of such a dedicated link would 441 be measured continuously, and its contribution to the sub-path 442 metrics SHOULD be minimized as a source of error. 444 4.1.8.3. Sub-paths Have Incomplete Coverage 446 Measurements of sub-path performance may not cover all the network 447 elements on the complete path. For example, the network exchange 448 points might be excluded unless a cooperative measurement is 449 conducted. In this example, test packets on the previous sub-path 450 are received just before the exchange point and test packets on the 451 next sub-path are injected just after the same exchange point. 452 Clearly, the set of sub-path measurements SHOULD cover all critical 453 network elements in the complete path. 455 4.1.8.4. Absence of route 457 At a specific point in time, no viable route exists between the 458 complete path source and destination. The routes selected for one or 459 more sub-paths therefore differs from the complete path. 460 Consequently, spatial composition may produce finite estimation of a 461 ground truth metric between a source and a destination, even when the 462 route between them is undefined. 464 4.1.9. Specific cases where the conjecture might fail 466 This section is unique for most metrics (see the metric-specific 467 sections). 469 For delay-related metrics, One-way delay always depends on packet 470 size and link capacity, since it is measured in [RFC2679] from first 471 bit to last bit. If the size of an IP packet changes (due to 472 encapsulation for security reasons), this will influence delay 473 performance. 475 Fragmentation is a major issue for compostion accuracy, since all 476 metrics require all fragments to arrive before proceeding, and 477 fragmented complete path performance is likely to be different from 478 performance with non-fragmented packets and composed metrics based on 479 non-fragmented sub-path measurements. 481 4.1.10. Application of Measurement Methodology 483 The methodology: 485 SHOULD use similar packets sent and collected separately in each sub- 486 path. 488 Allows a degree of flexibility regarding test stream generation 489 (e.g., active or passive methods can produce an equivalent result, 490 but the lack of control over the source, timing and correlation of 491 passive measurements is much more challenging). 493 Poisson and/or Periodic streams are RECOMMENDED. 495 Applies to both Inter-domain and Intra-domain composition. 497 SHOULD have synchronized measurement time intervals in all sub-paths, 498 but largely overlapping intervals MAY suffice. 500 REQUIRES assumption of sub-path independence w.r.t. the metric being 501 defined/composed. 503 5. One-way Delay Composed Metrics and Statistics 505 5.1. Name: Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream 507 This metric is a necessary element of Delay Composition metrics, and 508 its definition does not formally exist elsewhere in IPPM literature. 510 5.1.1. Metric Parameters 512 See the common parameters section above. 514 5.1.2. Definition and Metric Units 516 Using the parameters above, we obtain the value of Type-P-One-way- 517 Delay singleton as per [RFC2679]. 519 For each packet [i] that has a finite One-way Delay (in other words, 520 excluding packets which have undefined one-way delay): 522 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i] = 524 FiniteDelay[i] = TstampDst - TstampSrc 526 The units of measure for this metric are time in seconds, expressed 527 in sufficiently low resolution to convey meaningful quantitative 528 information. For example, resolution of microseconds is usually 529 sufficient. 531 5.1.3. Discussion and other details 533 The "Type-P-Finite-One-way-Delay" metric permits calculation of the 534 sample mean statistic. This resolves the problem of including lost 535 packets in the sample (whose delay is undefined), and the issue with 536 the informal assignment of infinite delay to lost packets (practical 537 systems can only assign some very large value). 539 The Finite-One-way-Delay approach handles the problem of lost packets 540 by reducing the event space. We consider conditional statistics, and 541 estimate the mean one-way delay conditioned on the event that all 542 packets in the sample arrive at the destination (within the specified 543 waiting time, Tmax). This offers a way to make some valid statements 544 about one-way delay, and at the same time avoiding events with 545 undefined outcomes. This approach is derived from the treatment of 546 lost packets in [RFC3393], and is similar to [Y.1540] . 548 5.1.4. Statistic: 550 All statistics defined in [RFC2679] are applicable to the finite one- 551 way delay,and additional metrics are possible, such as the mean (see 552 below). 554 5.2. Name: Type-P-Finite-Composite-One-way-Delay-Mean 556 This section describes a statistic based on the Type-P-Finite-One- 557 way-Delay-Poisson/Periodic-Stream metric. 559 5.2.1. Metric Parameters 561 See the common parameters section above. 563 5.2.2. Definition and Metric Units of the Mean Statistic 565 We define 567 Type-P-Finite-One-way-Delay-Mean = 568 N 569 --- 570 1 \ 571 MeanDelay = - * > (FiniteDelay [n]) 572 N / 573 --- 574 n = 1 576 where all packets n= 1 through N have finite singleton delays. 578 The units of measure for this metric are time in seconds, expressed 579 in sufficiently fine resolution to convey meaningful quantitative 580 information. For example, resolution of microseconds is usually 581 sufficient. 583 5.2.3. Discussion and other details 585 The Type-P-Finite-One-way-Delay-Mean metric requires the conditional 586 delay distribution described in section 5.1. 588 5.2.4. Statistic: 590 This metric, a mean, does not require additional statistics. 592 5.2.5. Composition Function: Sum of Means 594 The Type-P-Finite--Composite-One-way-Delay-Mean, or CompMeanDelay, 595 for the complete Source to Destination path can be calculated from 596 sum of the Mean Delays of all its S constituent sub-paths. 598 Then the 600 Type-P-Finite-Composite-One-way-Delay-Mean = 601 S 602 --- 603 \ 604 CompMeanDelay = > (MeanDelay [s]) 605 / 606 --- 607 s = 1 608 where sub-paths s = 1 to S are invloved in the complete path. 610 5.2.6. Statement of Conjecture and Assumptions 612 The mean of a sufficiently large stream of packets measured on each 613 sub-path during the interval [T, Tf] will be representative of the 614 ground truth mean of the delay distribution (and the distributions 615 themselves are sufficiently independent), such that the means may be 616 added to produce an estimate of the complete path mean delay. 618 It is assumed that the one-way delay distributions of the sub-paths 619 and the complete path are continuous. The mean of bi-modal 620 distributions have the unfortunate property that such a value may 621 never occur. 623 5.2.7. Justification of the Composition Function 625 See the common section. 627 5.2.8. Sources of Deviation from the Ground Truth 629 See the common section. 631 5.2.9. Specific cases where the conjecture might fail 633 If any of the sub-path distributions are bimodal, then the measured 634 means may not be stable, and in this case the mean will not be a 635 particularly useful statistic when describing the delay distribution 636 of the complete path. 638 The mean may not be sufficiently robust statistic to produce a 639 reliable estimate, or to be useful even if it can be measured. 641 If a link contributing non-negligible delay is erroneously included 642 or excluded, the composition will be in error. 644 5.2.10. Application of Measurement Methodology 646 The requirements of the common section apply here as well. 648 5.3. Name: Type-P-Finite-Composite-One-way-Delay-Minimum 650 This section describes is a statistic based on the Type-P-Finite-One- 651 way-Delay-Poisson/Periodic-Stream metric, and the composed metric 652 based on that statistic. 654 5.3.1. Metric Parameters 656 See the common parameters section above. 658 5.3.2. Definition and Metric Units of the Minimum Statistic 660 We define 662 Type-P-Finite-One-way-Delay-Minimum = 663 = MinDelay = (FiniteDelay [j]) 665 such that for some index, j, where 1<= j <= N 666 FiniteDelay[j] <= FiniteDelay[n] for all n 668 where all packets n = 1 through N have finite singleton delays. 670 The units of measure for this metric are time in seconds, expressed 671 in sufficiently fine resolution to convey meaningful quantitative 672 information. For example, resolution of microseconds is usually 673 sufficient. 675 5.3.3. Discussion and other details 677 The Type-P-Finite-One-way-Delay-Minimum metric requires the 678 conditional delay distribution described in section 5.1.3. 680 5.3.4. Statistic: 682 This metric, a minimum, does not require additional statistics. 684 5.3.5. Composition Function: Sum of Minima 686 The Type-P-Finite--Composite-One-way-Delay-Minimum, or CompMinDelay, 687 for the complete Source to Destination path can be calculated from 688 sum of the Minimum Delays of all its S constituent sub-paths. 690 Then the 692 Type-P-Finite-Composite-One-way-Delay-Minimum = 693 S 694 --- 695 \ 696 CompMinDelay = > (MinDelay [s]) 697 / 698 --- 699 s = 1 701 5.3.6. Statement of Conjecture and Assumptions 703 The minimum of a sufficiently large stream of packets measured on 704 each sub-path during the interval [T, Tf] will be representative of 705 the ground truth minimum of the delay distribution (and the 706 distributions themselves are sufficiently independent), such that the 707 minima may be added to produce an estimate of the complete path 708 minimum delay. 710 It is assumed that the one-way delay distributions of the sub-paths 711 and the complete path are continuous. 713 5.3.7. Justification of the Composition Function 715 See the common section. 717 5.3.8. Sources of Deviation from the Ground Truth 719 See the common section. 721 5.3.9. Specific cases where the conjecture might fail 723 If the routing on any of the sub-paths is not stable, then the 724 measured minimum may not be stable. In this case the composite 725 minimum would tend to produce an estimate for the complete path that 726 may be too low for the current path. 728 5.3.10. Application of Measurement Methodology 730 The requirements of the common section apply here as well. 732 6. Loss Metrics and Statistics 734 6.1. Type-P-Composite-One-way-Packet-Loss-Empirical-Probability 736 6.1.1. Metric Parameters: 738 Same as section 4.1.1. 740 6.1.2. Definition and Metric Units 742 Using the parameters above, we obtain the value of Type-P-One-way- 743 Packet-Loss singleton and stream as per [RFC2680]. 745 We obtain a sequence of pairs with elements as follows: 747 o TstampSrc, as above 749 o L, either zero or one, where L=1 indicates loss and L=0 indicates 750 arrival at the destination within TstampSrc + Tmax. 752 6.1.3. Discussion and other details 754 6.1.4. Statistic: Type-P-One-way-Packet-Loss-Empirical-Probability 756 Given the stream parameter M, the number of packets sent, we can 757 define the Empirical Probability of Loss Statistic (Ep), consistent 758 with Average Loss in [RFC2680], as follows: 760 Type-P-One-way-Packet-Loss-Empirical-Probability = 761 M 762 --- 763 1 \ 764 Ep = - * > (L[m]) 765 M / 766 --- 767 m = 1 769 where all packets m = 1 through M have a value for L. 771 6.1.5. Composition Function: Composition of Empirical Probabilities 773 The Type-P-One-way-Composite-Packet-Loss-Empirical-Probability, or 774 CompEp for the complete Source to Destination path can be calculated 775 by combining Ep of all its constituent sub-paths (Ep1, Ep2, Ep3, ... 776 Epn) as 778 Type-P-Composite-One-way-Packet-Loss-Empirical-Probability = 779 CompEp = 1 - {(1 - Ep1) x (1 - Ep2) x (1 - Ep3) x ... x (1 - EpS)} 781 If any Eps is undefined in a particular measurement interval, 782 possibly because a measurement system failed to report a value, then 783 any CompEp that uses sub-path s for that measurement interval is 784 undefined. 786 6.1.6. Statement of Conjecture and Assumptions 788 The empirical probability of loss calculated on a sufficiently large 789 stream of packets measured on each sub-path during the interval [T, 790 Tf] will be representative of the ground truth empirical loss 791 probability (and the probabilities themselves are sufficiently 792 independent), such that the sub-path probabilities may be combined to 793 produce an estimate of the complete path empirical loss probability. 795 6.1.7. Justification of the Composition Function 797 See the common section. 799 6.1.8. Sources of Deviation from the Ground Truth 801 See the common section. 803 6.1.9. Specific cases where the conjecture might fail 805 A concern for loss measurements combined in this way is that root 806 causes may be correlated to some degree. 808 For example, if the links of different networks follow the same 809 physical route, then a single catastrophic event like a fire in a 810 tunnel could cause an outage or congestion on remaining paths in 811 multiple networks. Here it is important to ensure that measurements 812 before the event and after the event are not combined to estimate the 813 composite performance. 815 Or, when traffic volumes rise due to the rapid spread of an email- 816 born worm, loss due to queue overflow in one network may help another 817 network to carry its traffic without loss. 819 others... 821 6.1.10. Application of Measurement Methodology 823 See the common section. 825 7. Delay Variation Metrics and Statistics 827 7.1. Name: Type-P-One-way-pdv-refmin-Poisson/Periodic-Stream 829 This packet delay variation (PDV) metric is a necessary element of 830 Composed Delay Variation metrics, and its definition does not 831 formally exist elsewhere in IPPM literature. 833 7.1.1. Metric Parameters: 835 In addition to the parameters of section 4.1.1: 837 o TstampSrc[i], the wire time of packet[i] as measured at MP(Src) 838 (measurement point at the source) 840 o TstampDst[i], the wire time of packet[i] as measured at MP(Dst), 841 assigned to packets that arrive within a "reasonable" time. 843 o B, a packet length in bits 845 o F, a selection function unambiguously defining the packets from 846 the stream that are selected for the packet-pair computation of 847 this metric. F(first packet), the first packet of the pair, MUST 848 have a valid Type-P-Finite-One-way-Delay less than Tmax (in other 849 words, excluding packets which have undefined one-way delay) and 850 MUST have been transmitted during the interval T, Tf. The second 851 packet in the pair, F(second packet) MUST be the packet with the 852 minimum valid value of Type-P-Finite-One-way-Delay for the stream, 853 in addition to the criteria for F(first packet). If multiple 854 packets have equal minimum Type-P-Finite-One-way-Delay values, 855 then the value for the earliest arriving packet SHOULD be used. 857 o MinDelay, the Type-P-Finite-One-way-Delay value for F(second 858 packet) given above. 860 o N, the number of packets received at the Destination meeting the 861 F(first packet) criteria. 863 7.1.2. Definition and Metric Units 865 Using the definition above in section 5.1.2, we obtain the value of 866 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[n], the singleton 867 for each packet[i] in the stream (a.k.a. FiniteDelay[i]). 869 For each packet[n] that meets the F(first packet) criteria given 870 above: Type-P-One-way-pdv-refmin-Poisson/Periodic-Stream[n] = 872 PDV[n] = FiniteDelay[n] - MinDelay 874 where PDV[i] is in units of time in seconds, expressed in 875 sufficiently fine resolution to convey meaningful quantitative 876 information. For example, resolution of microseconds is usually 877 sufficient. 879 7.1.3. Discussion and other details 881 This metric produces a sample of delay variation normalized to the 882 minimum delay of the sample. The resulting delay variation 883 distribution is independent of the sending sequence (although 884 specific FiniteDelay values within the distribution may be 885 correlated, depending on various stream parameters such as packet 886 spacing). This metric is equivalent to the IP Packet Delay Variation 887 parameter defined in [Y.1540]. 889 7.1.4. Statistics: Mean, Variance, Skewness, Quanitle 891 We define the mean PDV as follows (where all packets n = 1 through N 892 have a value for PDV[n]): 894 Type-P-One-way-pdv-refmin-Mean = MeanPDV = 895 N 896 --- 897 1 \ 898 - * > (PDV[n]) 899 N / 900 --- 901 n = 1 903 We define the variance of PDV as follows: 905 Type-P-One-way-pdv-refmin-Variance = VarPDV = 906 N 907 --- 908 1 \ 2 909 ------- > (PDV[n] - MeanPDV) 910 (N - 1) / 911 --- 912 n = 1 914 We define the skewness of PDV as follows: 916 Type-P-One-way-pdv-refmin-Skewness = SkewPDV = 917 N 918 --- 3 919 \ / \ 920 > | PDV[n]- MeanPDV | 921 / \ / 922 --- 923 n = 1 924 ----------------------------------- 925 / \ 926 | ( 3/2 ) | 927 \ (N - 1) * VarPDV / 929 We define the Quantile of the IPDVRefMin sample as the value where 930 the specified fraction of singletons is less than the given value. 932 7.1.5. Composition Functions: 934 This section gives two alternative composition functions. The 935 objective is to estimate a quantile of the complete path delay 936 variation distribution. The composed quantile will be estimated 937 using information from the sub-path delay variation distributions. 939 7.1.5.1. Approximate Convolution 941 The Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream samples from 942 each sub-path are summarized as a histogram with 1 ms bins 943 representing the one-way delay distribution. 945 From [Stats], the distribution of the sum of independent random 946 variables can be derived using the relation: 948 Type-P-Composite-One-way-pdv-refmin-quantile-a = 949 / / 950 P(X + Y + Z <= a) = | | P(X <= a-y-z) * P(Y = y) * P(Z = z) dy dz 951 / / 952 z y 953 where X, Y, and Z are random variables representing the delay 954 variation distributions of the sub-paths of the complete path (in 955 this case, there are three sub-paths), and a is the quantile of 956 interest. Note dy and dz indicate partial integration here.This 957 relation can be used to compose a quantile of interest for the 958 complete path from the sub-path delay distributions. The histograms 959 with 1 ms bins are discrete approximations of the delay 960 distributions. 962 7.1.5.2. Normal Power Approximation 964 Type-P-One-way-Composite-pdv-refmin-NPA for the complete Source to 965 Destination path can be calculated by combining statistics of all the 966 constituent sub-paths in the process described in [Y.1541] clause 8 967 and Appendix X. 969 7.1.6. Statement of Conjecture and Assumptions 971 The delay distribution of a sufficiently large stream of packets 972 measured on each sub-path during the interval [T, Tf] will be 973 sufficiently stationary and the sub-path distributions themselves are 974 sufficiently independent, so that summary information describing the 975 sub-path distributions can be combined to estimate the delay 976 distribution of complete path. 978 It is assumed that the one-way delay distributions of the sub-paths 979 and the complete path are continuous. 981 7.1.7. Justification of the Composition Function 983 See the common section. 985 7.1.8. Sources of Deviation from the Ground Truth 987 In addition to the common deviations, a few additional sources exist 988 here. For one, very tight distributions with range on the order of a 989 few milliseconds are not accurately represented by a histogram with 1 990 ms bins. This size was chosen assuming an implicit requirement on 991 accuracy: errors of a few milliseconds are acceptable when assessing 992 a composed distribution quantile. 994 Also, summary statistics cannot describe the subtleties of an 995 empirical distribution exactly, especially when the distribution is 996 very different from a classical form. Any procedure that uses these 997 statistics alone may incur error. 999 7.1.9. Specific cases where the conjecture might fail 1001 If the delay distributions of the sub-paths are somehow correlated, 1002 then neither of these composition functions will be reliable 1003 estimators of the complete path distribution. 1005 In practice, sub-path delay distributions with extreme outliers have 1006 increased the error of the composed metric estimate. 1008 7.1.10. Application of Measurement Methodology 1010 See the common section. 1012 8. Security Considerations 1014 8.1. Denial of Service Attacks 1016 This metric requires a stream of packets sent from one host (source) 1017 to another host (destination) through intervening networks. This 1018 method could be abused for denial of service attacks directed at 1019 destination and/or the intervening network(s). 1021 Administrators of source, destination, and the intervening network(s) 1022 should establish bilateral or multi-lateral agreements regarding the 1023 timing, size, and frequency of collection of sample metrics. Use of 1024 this method in excess of the terms agreed between the participants 1025 may be cause for immediate rejection or discard of packets or other 1026 escalation procedures defined between the affected parties. 1028 8.2. User Data Confidentiality 1030 Active use of this method generates packets for a sample, rather than 1031 taking samples based on user data, and does not threaten user data 1032 confidentiality. Passive measurement must restrict attention to the 1033 headers of interest. Since user payloads may be temporarily stored 1034 for length analysis, suitable precautions MUST be taken to keep this 1035 information safe and confidential. In most cases, a hashing function 1036 will produce a value suitable for payload comparisons. 1038 8.3. Interference with the metrics 1040 It may be possible to identify that a certain packet or stream of 1041 packets is part of a sample. With that knowledge at the destination 1042 and/or the intervening networks, it is possible to change the 1043 processing of the packets (e.g. increasing or decreasing delay) that 1044 may distort the measured performance. It may also be possible to 1045 generate additional packets that appear to be part of the sample 1046 metric. These additional packets are likely to perturb the results 1047 of the sample measurement. 1049 To discourage the kind of interference mentioned above, packet 1050 interference checks, such as cryptographic hash, may be used. 1052 9. IANA Considerations 1054 Metrics defined in this memo will be registered in the IANA IPPM 1055 METRICS REGISTRY as described in initial version of the registry 1056 [RFC4148]. 1058 10. Acknowlegements 1060 A long time ago, in a galaxy far, far away (Minneapolis), Will Leland 1061 suggested the simple and elegant Type-P-Finite-One-way-Delay concept. 1062 Thanks Will. 1064 11. Issues (Open and Closed) 1066 >>>>>>>>>>>>Issue: 1068 Is Section 4.1.8.4 really describing a new error case, about 1069 Alternate Routing? Or does Section 4.1.8.1 on sub-path differences 1070 cover it all? 1072 RESOLUTION: The section was re-worded in -10 version to make the 1073 topic, Absence of a real Route between the Src and Dst, more clear. 1075 >>>>>>>>>>>> 1076 >>>>>>>>>>>>Issue: 1078 What is the relationship between the decomposition and composition 1079 metrics? Should we put both kinds in one draft to make up a 1080 framework? The motivation of decomposition is as follows: 1082 The One-way measurement can provide result to show what the network 1083 performance between two end hosts is and whether it meets operator 1084 expectations or not. It cannot provide further information to 1085 engineers where and how to improve the performance between the source 1086 and the destination. For instance, if the network performance is not 1087 acceptable in terms of the One-way measurement, in which part of the 1088 network the engineers should put their efforts. This question can to 1089 be answered by decompose the One-way measurement to sub-path 1090 measurement to investigate the performance of different part of the 1091 network. 1093 Editor's Questions for clarification: What additional information 1094 would be provided to the decomposition process, beyond the 1095 measurement of the complete path? 1097 Is the decomposition described above intended to estimate a metric 1098 for some/all disjoint sub-paths involved in the complete path? 1100 >>>>>>>>>>>>>>>>>>RESOLUTION: treat this topic in a separate memo 1102 >>>>>>>>>>>>>>>>>>> 1104 >>>>>>>>>>>>>>>>>>>Issue 1106 Section 7 defines a new type of metric, a "combination" of metrics 1107 for one-way delay and packet loss. The purpose of this metric is to 1108 link these two primary metrics in a convenient way. 1110 Readers are asked to comment on the efficiency of the combination 1111 metric. 1113 >>>>>>>>>>>>>>>>>RESOLUTION: If a delay singleton is recorded as 1114 having "undefined" delay when the packet does not arrive within the 1115 waiting time Tmax, then this information is sufficient to determine 1116 the fraction of lost packets in the sample, and the additional loss 1117 indication of this combo is not needed. 1119 >>>>>>>>>>>>>>>>>> 1121 >>>>>>>>>>>>>>>>> Issue 1123 Can we introduce multicast metrics here, without causing too much 1124 confusion? Should the multicast version of this draft wait until the 1125 Unicast concepts are stable (or maybe appear in a separate draft)? 1127 >>>>>>>>>>>>>>>>RESOLUTION: No and Yes. 1129 12. Acknowledgements 1131 13. References 1133 13.1. Normative References 1135 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1136 Requirement Levels", BCP 14, RFC 2119, March 1997. 1138 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1139 "Framework for IP Performance Metrics", RFC 2330, 1140 May 1998. 1142 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1143 Delay Metric for IPPM", RFC 2679, September 1999. 1145 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1146 Packet Loss Metric for IPPM", RFC 2680, September 1999. 1148 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1149 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1150 November 2002. 1152 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 1153 Registry", BCP 108, RFC 4148, August 2005. 1155 [RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric 1156 Composition", RFC 5835, April 2010. 1158 13.2. Informative References 1160 [RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance 1161 Metrics (IPPM): Spatial and Multicast", RFC 5644, 1162 October 2009. 1164 [Stats] McGraw-Hill NY NY, "Introduction to the Theory of 1165 Statistics, 3rd Edition,", 1974. 1167 [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data 1168 communication service - IP packet transfer and 1169 availability performance parameters", November 2007. 1171 [Y.1541] ITU-T Recommendation Y.1541, "Network Performance 1172 Objectives for IP-based Services", February 2006. 1174 Index 1176 ? 1177 ??? 14 1179 Authors' Addresses 1181 Al Morton 1182 AT&T Labs 1183 200 Laurel Avenue South 1184 Middletown,, NJ 07748 1185 USA 1187 Phone: +1 732 420 1571 1188 Fax: +1 732 368 1192 1189 Email: acmorton@att.com 1190 URI: http://home.comcast.net/~acmacm/ 1192 Emile Stephan 1193 France Telecom Division R&D 1194 2 avenue Pierre Marzin 1195 Lannion, F-22307 1196 France 1198 Phone: 1199 Fax: +33 2 96 05 18 52 1200 Email: emile.stephan@orange-ftgroup.com 1201 URI: