idnits 2.17.1 draft-ietf-ippm-spatial-composition-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1111. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1122. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1129. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1135. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 24, 2008) is 5896 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 887, but not defined == Missing Reference: 'Tf' is mentioned on line 887, but not defined == Missing Reference: 'TBP' is mentioned on line 859, but not defined == Unused Reference: 'I-D.ietf-ippm-multimetrics' is defined on line 1060, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-ippm-framework-compagg-06 ** Downref: Normative reference to an Informational draft: draft-ietf-ippm-framework-compagg (ref. 'I-D.ietf-ippm-framework-compagg') ** Downref: Normative reference to an Informational RFC: RFC 2330 ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) ** Obsolete normative reference: RFC 4148 (Obsoleted by RFC 6248) == Outdated reference: A later version (-12) exists of draft-ietf-ippm-multimetrics-06 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 7 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: August 27, 2008 France Telecom Division R&D 6 February 24, 2008 8 Spatial Composition of Metrics 9 draft-ietf-ippm-spatial-composition-06 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 27, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This memo utilizes IPPM metrics that are applicable to both complete 43 paths and sub-paths, and defines relationships to compose a complete 44 path metric from the sub-path metrics with some accuracy w.r.t. the 45 actual metrics. This is called Spatial Composition in RFC 2330. The 46 memo refers to the Framework for Metric Composition, and provides 47 background and motivation for combining metrics to derive others. 48 The descriptions of several composed metrics and statistics follow. 50 Requirements Language 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC 2119 [RFC2119]. 56 In this memo, the characters "<=" should be read as "less than or 57 equal to" and ">=" as "greater than or equal to". 59 Table of Contents 61 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Scope and Application . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Scope of work . . . . . . . . . . . . . . . . . . . . . . 6 66 3.2. Application . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.3. Incomplete Information . . . . . . . . . . . . . . . . . . 6 68 4. Common Specifications for Composed Metrics . . . . . . . . . . 7 69 4.1. Name: Type-P . . . . . . . . . . . . . . . . . . . . . . . 7 70 4.1.1. Metric Parameters . . . . . . . . . . . . . . . . . . 7 71 4.1.2. Definition and Metric Units . . . . . . . . . . . . . 8 72 4.1.3. Discussion and other details . . . . . . . . . . . . . 8 73 4.1.4. Statistic: . . . . . . . . . . . . . . . . . . . . . . 8 74 4.1.5. Composition Function . . . . . . . . . . . . . . . . . 8 75 4.1.6. Statement of Conjecture and Assumptions . . . . . . . 8 76 4.1.7. Justification of the Composition Function . . . . . . 8 77 4.1.8. Sources of Deviation from the Ground Truth . . . . . . 9 78 4.1.9. Specific cases where the conjecture might fail . . . . 9 79 4.1.10. Application of Measurement Methodology . . . . . . . . 9 80 5. One-way Delay Composed Metrics and Statistics . . . . . . . . 10 81 5.1. Name: 82 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream . . . 10 83 5.1.1. Metric Parameters . . . . . . . . . . . . . . . . . . 10 84 5.1.2. Definition and Metric Units . . . . . . . . . . . . . 10 85 5.1.3. Discussion and other details . . . . . . . . . . . . . 10 86 5.2. Name: Type-P-Finite-Composite-One-way-Delay-Mean . . . . . 11 87 5.2.1. Metric Parameters . . . . . . . . . . . . . . . . . . 11 88 5.2.2. Definition and Metric Units of the Mean Statistic . . 11 89 5.2.3. Discussion and other details . . . . . . . . . . . . . 11 90 5.2.4. Composition Function: Sum of Means . . . . . . . . . . 11 91 5.2.5. Statement of Conjecture and Assumptions . . . . . . . 12 92 5.2.6. Justification of the Composition Function . . . . . . 12 93 5.2.7. Sources of Deviation from the Ground Truth . . . . . . 12 94 5.2.8. Specific cases where the conjecture might fail . . . . 12 95 5.2.9. Application of Measurement Methodology . . . . . . . . 12 96 5.3. Name: Type-P-Finite-Composite-One-way-Delay-Minimum . . . 12 97 5.3.1. Metric Parameters . . . . . . . . . . . . . . . . . . 13 98 5.3.2. Definition and Metric Units of the Mean Statistic . . 13 99 5.3.3. Discussion and other details . . . . . . . . . . . . . 13 100 5.3.4. Composition Function: Sum of Means . . . . . . . . . . 13 101 5.3.5. Statement of Conjecture and Assumptions . . . . . . . 14 102 5.3.6. Justification of the Composition Function . . . . . . 14 103 5.3.7. Sources of Deviation from the Ground Truth . . . . . . 14 104 5.3.8. Specific cases where the conjecture might fail . . . . 14 105 5.3.9. Application of Measurement Methodology . . . . . . . . 14 106 6. Loss Metrics and Statistics . . . . . . . . . . . . . . . . . 14 107 6.1. Type-P-Composite-One-way-Packet-Loss-Empirical-Probability 14 108 6.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 14 109 6.1.2. Definition and Metric Units . . . . . . . . . . . . . 14 110 6.1.3. Discussion and other details . . . . . . . . . . . . . 15 111 6.1.4. Statistic: 112 Type-P-One-way-Packet-Loss-Empirical-Probability . . . 15 113 6.1.5. Composition Function: Composition of Empirical 114 Probabilities . . . . . . . . . . . . . . . . . . . . 15 115 6.1.6. Statement of Conjecture and Assumptions . . . . . . . 15 116 6.1.7. Justification of the Composition Function . . . . . . 16 117 6.1.8. Sources of Deviation from the Ground Truth . . . . . . 16 118 6.1.9. Specific cases where the conjecture might fail . . . . 16 119 6.1.10. Application of Measurement Methodology . . . . . . . . 16 120 7. Delay Variation Metrics and Statistics . . . . . . . . . . . . 16 121 7.1. Name: Type-P-One-way-pdv-refmin-Poisson/Periodic-Stream . 16 122 7.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 16 123 7.1.2. Definition and Metric Units . . . . . . . . . . . . . 17 124 7.1.3. Discussion and other details . . . . . . . . . . . . . 17 125 7.1.4. Statistics: Mean, Variance, Skewness, Quanitle . . . . 18 126 7.1.5. Composition Functions: . . . . . . . . . . . . . . . . 18 127 7.1.6. Statement of Conjecture and Assumptions . . . . . . . 19 128 7.1.7. Justification of the Composition Function . . . . . . 20 129 7.1.8. Sources of Deviation from the Ground Truth . . . . . . 20 130 7.1.9. Specific cases where the conjecture might fail . . . . 20 131 7.1.10. Application of Measurement Methodology . . . . . . . . 20 132 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 133 8.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 20 134 8.2. User Data Confidentiality . . . . . . . . . . . . . . . . 21 135 8.3. Interference with the metrics . . . . . . . . . . . . . . 21 136 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 137 10. Issues (Open and Closed) . . . . . . . . . . . . . . . . . . . 21 138 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 139 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 140 12.1. Normative References . . . . . . . . . . . . . . . . . . . 23 141 12.2. Informative References . . . . . . . . . . . . . . . . . . 23 142 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 143 Intellectual Property and Copyright Statements . . . . . . . . . . 25 145 1. Contributors 147 Thus far, the following people have contributed useful ideas, 148 suggestions, or the text of sections that have been incorporated into 149 this memo: 151 - Phil Chimento 153 - Reza Fardid 155 - Roman Krzanowski 157 - Maurizio Molina 159 - Al Morton 161 - Emile Stephan 163 - Lei Liang 165 - Dave Hoeflin 167 2. Introduction 169 The IPPM framework [RFC2330] describes two forms of metric 170 composition, spatial and temporal. The new composition framework 171 [I-D.ietf-ippm-framework-compagg] expands and further qualifies these 172 original forms into three categories. This memo describes Spatial 173 Composition, one of the categories of metrics under the umbrella of 174 the composition framework. 176 Spatial composition encompasses the definition of performance metrics 177 that are applicable to a complete path, based on metrics collected on 178 various sub-paths. 180 The main purpose of this memo is to define the deterministic 181 functions that yield the complete path metrics using metrics of the 182 sub-paths. The effectiveness of such metrics is dependent on their 183 usefulness in analysis and applicability with practical measurement 184 methods. 186 The relationships may involve conjecture, and [RFC2330] lists four 187 points that the metric definitions should include: 189 o the specific conjecture applied to the metric and assumptions of 190 the statistical model of the process being measured (if any, see 191 [RFC2330] section 12), 193 o a justification of the practical utility of the composition in 194 terms of making accurate measurements of the metric on the path, 196 o a justification of the usefulness of the composition in terms of 197 making analysis of the path using A-frame concepts more effective, 198 and 200 o an analysis of how the conjecture could be incorrect. 202 Also, [RFC2330] gives an example where a conjecture that the delay of 203 a path is very nearly the sum of the delays of the exchanges and 204 clouds of the corresponding path digest. This example is 205 particularly relevant to those who wish to assess the performance of 206 an Inter-domain path without direct measurement, and the performance 207 estimate of the complete path is related to the measured results for 208 various sub-paths instead. 210 Approximate functions between the sub-path and complete path metrics 211 are useful, with knowledge of the circumstances where the 212 relationships are/are not applicable. For example, we would not 213 expect that delay singletons from each sub-path would sum to produce 214 an accurate estimate of a delay singleton for the complete path 215 (unless all the delays were essentially constant - very unlikely). 216 However, other delay statistics (based on a reasonable sample size) 217 may have a sufficiently large set of circumstances where they are 218 applicable. 220 2.1. Motivation 222 One-way metrics defined in other IPPM RFCs all assume that the 223 measurement can be practically carried out between the source and the 224 destination of the interest. Sometimes there are reasons that the 225 measurement can not be executed from the source to the destination. 226 For instance, the measurement path may cross several independent 227 domains that have conflicting policies, measurement tools and 228 methods, and measurement time assignment. The solution then may be 229 the composition of several sub-path measurements. This means each 230 domain performs the One-way measurement on a sub path between two 231 nodes that are involved in the complete path following its own 232 policy, using its own measurement tools and methods, and using its 233 own measurement timing. Under the appropriate conditions, one can 234 combine the sub-path One-way metric results to estimate the complete 235 path One-way measurement metric with some degree of accuracy. 237 3. Scope and Application 238 3.1. Scope of work 240 For the primary IPPM metrics of Loss, Delay, and Delay Variation, 241 this memo gives a set of metrics for that can be composed from the 242 same or similar sub-path metrics. This means that the composition 243 function may utilize: 245 o the same metric for each sub-path; 247 o multiple metrics for each sub-path (possibly one that is the same 248 as the complete path metric); 250 o a single sub-path metrics that is different from the complete path 251 metric; 253 o different measurement techniques like active and passive 254 (recognizing that PSAMP WG will define capabilities to sample 255 packets to support measurement). 257 3.2. Application 259 The new composition framework [I-D.ietf-ippm-framework-compagg] 260 requires the specification of the applicable circumstances for each 261 metric. In particular, each section addresses whether the metric: 263 Requires the same test packets to traverse all sub-paths, or may use 264 similar packets sent and collected separately in each sub-path. 266 Requires homogeneity of measurement methodologies, or can allow a 267 degree of flexibility (e.g., active or passive methods produce the 268 "same" metric). Also, the applicable sending streams will be 269 specified, such as Poisson, Periodic, or both. 271 Needs information or access that will only be available within an 272 operator's domain, or is applicable to Inter-domain composition. 274 Requires synchronized measurement time intervals in all sub-paths, or 275 largely overlapping, or no timing requirements. 277 Requires assumption of sub-path independence w.r.t. the metric being 278 defined/composed, or other assumptions. 280 Has known sources of inaccuracy/error, and identifies the sources. 282 3.3. Incomplete Information 284 In practice, when measurements cannot be initiated on a sub-path (and 285 perhaps the measurement system gives up during the test interval), 286 then there will not be a value for the sub-path reported, and the 287 entire test result SHOULD be recorded as "undefined". This case 288 should be distinguished from the case where the measurement system 289 continued to send packets throughout the test interval, but all were 290 declared lost. 292 When a composed metric requires measurements from sub paths A, B, and 293 C, and one or more of the sub-path results are undefined, then the 294 composed metric SHOULD also be recorded as undefined. 296 4. Common Specifications for Composed Metrics 298 To reduce the redundant information presented in the detailed metrics 299 sections that follow, this section presents the specifications that 300 are common to two or more metrics. The section is organized using 301 the same subsections as the individual metrics, to simplify 302 comparisons. 304 4.1. Name: Type-P 306 All metrics use the Type-P convention as described in [RFC2330]. The 307 rest of the name is unique to each metric. 309 4.1.1. Metric Parameters 311 o Src, the IP address of a host 313 o Dst, the IP address of a host 315 o T, a time (start of test interval) 317 o Tf, a time (end of test interval) 319 o lambda, a rate in reciprocal seconds (for Poisson Streams) 321 o incT, the nominal duration of inter-packet interval, first bit to 322 first bit (for Periodic Streams) 324 o T0, a time that MUST be selected at random from the interval [T, 325 T+dT] to start generating packets and taking measurements (for 326 Periodic Streams) 328 o TstampSrc, the wire time of the packet as measured at MP(Src) 330 o TstampDst, the wire time of the packet as measured at MP(Dst), 331 assigned to packets that arrive within a "reasonable" time. 333 o Tmax, a maximum waiting time for packets at the destination, set 334 sufficiently long to disambiguate packets with long delays from 335 packets that are discarded (lost), thus the distribution of delay 336 is not truncated. 338 o M, the total number of packets sent between T0 and Tf 340 o N, the total number of packets received at Dst (sent between T0 341 and Tf) 343 o S, the number of sub-paths involved in the complete Src-Dst path 345 4.1.2. Definition and Metric Units 347 This section is unique for every metric. 349 4.1.3. Discussion and other details 351 This section is unique for every metric. 353 4.1.4. Statistic: 355 This section is unique for every metric. 357 4.1.5. Composition Function 359 This section is unique for every metric. 361 4.1.6. Statement of Conjecture and Assumptions 363 This section is unique for each metric. 365 4.1.7. Justification of the Composition Function 367 It is sometimes impractical to conduct active measurements between 368 every Src-Dst pair. Since the full mesh of N measurement points 369 grows as N x N, the scope of measurement may be limited by testing 370 resources. 372 There may be varying limitations on active testing in different parts 373 of the network. For example, it may not be possible to collect the 374 desired sample size in each test interval when access link speed is 375 limited, because of the potential for measurement traffic to degrade 376 the user traffic performance. The conditions on a low-speed access 377 link may be understood well-enough to permit use of a small sample 378 size/rate, while a larger sample size/rate may be used on other sub- 379 paths. 381 Also, since measurement operations have a real monetary cost, there 382 is value in re-using measurements where they are applicable, rather 383 than launching new measurements for every possible source-destination 384 pair. 386 4.1.8. Sources of Deviation from the Ground Truth 388 The measurement packets, each having source and destination addresses 389 intended for collection at edges of the sub-path, may take a 390 different specific path through the network equipment and parallel 391 links when compared to packets with the source and destination 392 addresses of the complete path. Therefore, the composition of sub- 393 path measurements may differ from the performance experienced by 394 packets on the complete path. Multiple measurements employing 395 sufficient sub-path address pairs might produce bounds on the extent 396 of this error. 398 Related to the case of an alternate path described above is the case 399 where elements in the measured path are unique to measurement system 400 connectivity. For example, a measurement system may use a dedicated 401 link to a LAN switch, and packets on the complete path do not 402 traverse that link. The performance of such a dedicated link would 403 be measured continuously, and its contribution to the sub-path 404 metrics SHOULD be minimized as a source of error. 406 others??? 408 4.1.9. Specific cases where the conjecture might fail 410 This section is unique for each metric. 412 4.1.10. Application of Measurement Methodology 414 The methodology: 416 SHOULD use similar packets sent and collected separately in each sub- 417 path. 419 Allows a degree of flexibility regarding test stream generation 420 (e.g., active or passive methods can produce an equivalent result, 421 but the lack of control over the source, timing and correlation of 422 passive measurements is much more challenging). 424 Poisson and/or Periodic streams are RECOMMENDED. 426 Applies to both Inter-domain and Intra-domain composition. 428 SHOULD have synchronized measurement time intervals in all sub-paths, 429 but largely overlapping intervals MAY suffice. 431 REQUIRES assumption of sub-path independence w.r.t. the metric being 432 defined/composed. 434 5. One-way Delay Composed Metrics and Statistics 436 5.1. Name: Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream 438 This metric is a necessary element of Delay Composition metrics, and 439 its definition does not formally exist elsewhere in IPPM literature. 441 5.1.1. Metric Parameters 443 See the common parameters section above. 445 5.1.2. Definition and Metric Units 447 Using the parameters above, we obtain the value of Type-P-One-way- 448 Delay singleton as per [RFC2679]. 450 For each packet [i] that has a finite One-way Delay (in other words, 451 excluding packets which have undefined one-way delay): 453 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i] = 455 FiniteDelay[i] = TstampDst - TstampSrc 457 The units of measure for this metric are time in seconds, expressed 458 in sufficiently low resolution to convey meaningful quantitative 459 information. For example, resolution of microseconds is usually 460 sufficient. 462 5.1.3. Discussion and other details 464 The "Type-P-Finite-One-way-Delay" metric permits calculation of the 465 sample mean statistic. This resolves the problem of including lost 466 packets in the sample (whose delay is undefined), and the issue with 467 the informal assignment of infinite delay to lost packets (practical 468 systems can only assign some very large value). 470 The Finite-One-way-Delay approach handles the problem of lost packets 471 by reducing the event space. We consider conditional statistics, and 472 estimate the mean one-way delay conditioned on the event that all 473 packets in the sample arrive at the destination (within the specified 474 waiting time, Tmax). This offers a way to make some valid statements 475 about one-way delay, and at the same time avoiding events with 476 undefined outcomes. This approach is derived from the treatment of 477 lost packets in [RFC3393], and is similar to [Y.1540] . 479 5.2. Name: Type-P-Finite-Composite-One-way-Delay-Mean 481 This section describes a statistic based on the Type-P-Finite-One- 482 way-Delay-Poisson/Periodic-Stream metric. 484 5.2.1. Metric Parameters 486 See the common parameters section above. 488 5.2.2. Definition and Metric Units of the Mean Statistic 490 We define 492 Type-P-Finite-One-way-Delay-Mean = 493 N 494 --- 495 1 \ 496 MeanDelay = - * > (FiniteDelay [i]) 497 N / 498 --- 499 i = 1 501 where all packets i= 1 through N have finite singleton delays. 503 The units of measure for this metric are time in seconds, expressed 504 in sufficiently low resolution to convey meaningful quantitative 505 information. For example, resolution of microseconds is usually 506 sufficient. 508 5.2.3. Discussion and other details 510 The Type-P-Finite-One-way-Delay-Mean metric requires the conditional 511 delay distribution described in section 5.1. 513 5.2.4. Composition Function: Sum of Means 515 The Type-P-Finite--Composite-One-way-Delay-Mean, or CompMeanDelay, 516 for the complete Source to Destination path can be calculated from 517 sum of the Mean Delays of all its S constituent sub-paths. 519 Then the 520 Type-P-Finite-Composite-One-way-Delay-Mean = 521 S 522 --- 523 \ 524 CompMeanDelay = > (MeanDelay [i]) 525 / 526 --- 527 i = 1 529 5.2.5. Statement of Conjecture and Assumptions 531 The mean of a sufficiently large stream of packets measured on each 532 sub-path during the interval [T, Tf] will be representative of the 533 ground truth mean of the delay distribution (and the distributions 534 themselves are sufficiently independent), such that the means may be 535 added to produce an estimate of the complete path mean delay. 537 It is assumed that the one-way delay distributions of the sub-paths 538 and the complete path are continuous. 540 5.2.6. Justification of the Composition Function 542 See the common section. 544 5.2.7. Sources of Deviation from the Ground Truth 546 See the common section. 548 5.2.8. Specific cases where the conjecture might fail 550 If any of the sub-path distributions are bimodal, then the measured 551 means may not be stable, and in this case the mean will not be a 552 particularly useful statistic when describing the delay distribution 553 of the complete path. 555 The mean may not be sufficiently robust statistic to produce a 556 reliable estimate, or to be useful even if it can be measured. 558 others... 560 5.2.9. Application of Measurement Methodology 562 The requirements of the common section apply here as well. 564 5.3. Name: Type-P-Finite-Composite-One-way-Delay-Minimum 566 This section describes is a statistic based on the Type-P-Finite-One- 567 way-Delay-Poisson/Periodic-Stream metric, and the composed metric 568 based on that statistic. 570 5.3.1. Metric Parameters 572 See the common parameters section above. 574 5.3.2. Definition and Metric Units of the Mean Statistic 576 We define 578 Type-P-Finite-One-way-Delay-Minimum = 579 = MinDelay = (FiniteDelay [j]) 581 such that for some index, j, where 1<= j <= N 582 FiniteDelay[j] <= FiniteDelay[i] for all i 584 where all packets i= 1 through N have finite singleton delays. 586 The units of measure for this metric are time in seconds, expressed 587 in sufficiently low resolution to convey meaningful quantitative 588 information. For example, resolution of microseconds is usually 589 sufficient. 591 5.3.3. Discussion and other details 593 The Type-P-Finite-One-way-Delay-Minimum metric requires the 594 conditional delay distribution described in section 5.1.3. 596 5.3.4. Composition Function: Sum of Means 598 The Type-P-Finite--Composite-One-way-Delay-Minimum, or CompMinDelay, 599 for the complete Source to Destination path can be calculated from 600 sum of the Minimum Delays of all its S constituent sub-paths. 602 Then the 604 Type-P-Finite-Composite-One-way-Delay-Minimum = 605 S 606 --- 607 \ 608 CompMinDelay = > (MinDelay [i]) 609 / 610 --- 611 i = 1 613 5.3.5. Statement of Conjecture and Assumptions 615 The minimum of a sufficiently large stream of packets measured on 616 each sub-path during the interval [T, Tf] will be representative of 617 the ground truth minimum of the delay distribution (and the 618 distributions themselves are sufficiently independent), such that the 619 minima may be added to produce an estimate of the complete path 620 minimum delay. 622 It is assumed that the one-way delay distributions of the sub-paths 623 and the complete path are continuous. 625 5.3.6. Justification of the Composition Function 627 See the common section. 629 5.3.7. Sources of Deviation from the Ground Truth 631 See the common section. 633 5.3.8. Specific cases where the conjecture might fail 635 If the routing on any of the sub-paths is not stable, then the 636 measured minimum may not be stable. In this case the composite 637 minimum would tend to produce an estimate for the complete path that 638 may be too low for the current path. 640 others??? 642 5.3.9. Application of Measurement Methodology 644 The requirements of the common section apply here as well. 646 6. Loss Metrics and Statistics 648 6.1. Type-P-Composite-One-way-Packet-Loss-Empirical-Probability 650 6.1.1. Metric Parameters: 652 Same as section 4.1.1. 654 6.1.2. Definition and Metric Units 656 Using the parameters above, we obtain the value of Type-P-One-way- 657 Packet-Loss singleton and stream as per [RFC2680]. 659 We obtain a sequence of pairs with elements as follows: 661 o TstampSrc, as above 663 o L, either zero or one, where L=1 indicates loss and L=0 indicates 664 arrival at the destination within TstampSrc + Tmax. 666 6.1.3. Discussion and other details 668 6.1.4. Statistic: Type-P-One-way-Packet-Loss-Empirical-Probability 670 Given the stream parameter M, the number of packets sent, we can 671 define the Empirical Probability of Loss Statistic (Ep), consistent 672 with Average Loss in [RFC2680], as follows: 674 Type-P-One-way-Packet-Loss-Empirical-Probability = 675 M 676 --- 677 1 \ 678 Ep = - * > (L[i]) 679 M / 680 --- 681 i = 1 683 where all packets i= 1 through M have a value for L. 685 6.1.5. Composition Function: Composition of Empirical Probabilities 687 The Type-P-One-way-Composite-Packet-Loss-Empirical-Probability, or 688 CompEp for the complete Source to Destination path can be calculated 689 by combining Ep of all its constituent sub-paths (Ep1, Ep2, Ep3, ... 690 Epn) as 692 Type-P-Composite-One-way-Packet-Loss-Empirical-Probability = 693 CompEp = 1 - {(1 - Ep1) x (1 - Ep2) x (1 - Ep3) x ... x (1 - Epn)} 695 If any Epn is undefined in a particular measurement interval, 696 possibly because a measurement system failed to report a value, then 697 any CompEp that uses sub-path n for that measurement interval is 698 undefined. 700 6.1.6. Statement of Conjecture and Assumptions 702 The empirical probability of loss calculated on a sufficiently large 703 stream of packets measured on each sub-path during the interval [T, 704 Tf] will be representative of the ground truth empirical loss 705 probability (and the probabilities themselves are sufficiently 706 independent), such that the sub-path probabilities may be combined to 707 produce an estimate of the complete path empirical loss probability. 709 6.1.7. Justification of the Composition Function 711 See the common section. 713 6.1.8. Sources of Deviation from the Ground Truth 715 See the common section. 717 6.1.9. Specific cases where the conjecture might fail 719 A concern for loss measurements combined in this way is that root 720 causes may be correlated to some degree. 722 For example, if the links of different networks follow the same 723 physical route, then a single catastrophic event like a fire in a 724 tunnel could cause an outage or congestion on remaining paths in 725 multiple networks. Here it is important to ensure that measurements 726 before the event and after the event are not combined to estimate the 727 composite performance. 729 Or, when traffic volumes rise due to the rapid spread of an email- 730 born worm, loss due to queue overflow in one network may help another 731 network to carry its traffic without loss. 733 others... 735 6.1.10. Application of Measurement Methodology 737 See the common section. 739 7. Delay Variation Metrics and Statistics 741 7.1. Name: Type-P-One-way-pdv-refmin-Poisson/Periodic-Stream 743 This packet delay variation (PDV) metric is a necessary element of 744 Composed Delay Variation metrics, and its definition does not 745 formally exist elsewhere in IPPM literature. 747 7.1.1. Metric Parameters: 749 In addition to the parameters of section 4.1.1: 751 o TstampSrc[i], the wire time of packet[i] as measured at MP(Src) 752 (measurement point at the source) 754 o TstampDst[i], the wire time of packet[i] as measured at MP(Dst), 755 assigned to packets that arrive within a "reasonable" time. 757 o B, a packet length in bits 759 o F, a selection function unambiguously defining the packets from 760 the stream that are selected for the packet-pair computation of 761 this metric. F(first packet), the first packet of the pair, MUST 762 have a valid Type-P-Finite-One-way-Delay less than Tmax (in other 763 words, excluding packets which have undefined one-way delay) and 764 MUST have been transmitted during the interval T, Tf. The second 765 packet in the pair, F(second packet) MUST be the packet with the 766 minimum valid value of Type-P-Finite-One-way-Delay for the stream, 767 in addition to the criteria for F(first packet). If multiple 768 packets have equal minimum Type-P-Finite-One-way-Delay values, 769 then the value for the earliest arriving packet SHOULD be used. 771 o MinDelay, the Type-P-Finite-One-way-Delay value for F(second 772 packet) given above. 774 o N, the number of packets received at the Destination meeting the 775 F(first packet) criteria. 777 7.1.2. Definition and Metric Units 779 Using the definition above in section 5.1.2, we obtain the value of 780 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i], the singleton 781 for each packet[i] in the stream (a.k.a. FiniteDelay[i]). 783 For each packet[i] that meets the F(first packet) criteria given 784 above: Type-P-One-way-pdv-refmin-Poisson/Periodic-Stream[i] = 786 PDV[i] = FiniteDelay[i] - MinDelay 788 where PDV[i] is in units of time in seconds, expressed in 789 sufficiently low resolution to convey meaningful quantitative 790 information. For example, resolution of microseconds is usually 791 sufficient. 793 7.1.3. Discussion and other details 795 This metric produces a sample of delay variation normalized to the 796 minimum delay of the sample. The resulting delay variation 797 distribution is independent of the sending sequence (although 798 specific FiniteDelay values within the distribution may be 799 correlated, depending on various stream parameters such as packet 800 spacing). This metric is equivalent to the IP Packet Delay Variation 801 parameter defined in [Y.1540]. 803 7.1.4. Statistics: Mean, Variance, Skewness, Quanitle 805 We define the mean PDV as follows (where all packets i= 1 through N 806 have a value for PDV[i]): 808 Type-P-One-way-pdv-refmin-Mean = MeanPDV = 809 N 810 --- 811 1 \ 812 - * > (PDV[i]) 813 N / 814 --- 815 i = 1 817 We define the variance of PDV as follows: 819 Type-P-One-way-pdv-refmin-Variance = VarPDV = 820 N 821 --- 822 1 \ 2 823 ------- > (PDV[i] - MeanPDV) 824 (N - 1) / 825 --- 826 i = 1 828 We define the skewness of PDV as follows: 830 Type-P-One-way-pdv-refmin-Skewness = SkewPDV = 831 N 832 --- 3 833 \ / \ 834 > | PDV[i]- MeanPDV | 835 / \ / 836 --- 837 i = 1 838 ----------------------------------- 839 / \ 840 | ( 3/2 ) | 841 \ (N - 1) * VarPDV / 843 We define the Quantile of the IPDVRefMin sample as the value where 844 the specified fraction of singletons is less than the given value. 846 7.1.5. Composition Functions: 848 This section gives two alternative composition functions. The 849 objective is to estimate a quantile of the complete path delay 850 variation distribution. The composed quantile will be estimated 851 using information from the sub-path delay variation distributions. 853 7.1.5.1. Approximate Convolution 855 The Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream samples from 856 each sub-path are summarized as a histogram with 1 ms bins 857 representing the one-way delay distribution. 859 From [TBP], the distribution of the sum of independent random 860 variables can be derived using the relation: 862 Type-P-Composite-One-way-pdv-refmin-quantile-a = 863 / / 864 P(X + Y + Z <= a) = | | P(X <= a-y-z) * P(Y = y) * P(Z = z) dy dz 865 / / 866 z y 867 where X, Y, and Z are random variables representing the delay 868 variation distributions of the sub-paths of the complete path (in 869 this case, there are three sub-paths), and a is the quantile of 870 interest. Note dy and dz indicate partial integration here.This 871 relation can be used to compose a quantile of interest for the 872 complete path from the sub-path delay distributions. The histograms 873 with 1 ms bins are discrete approximations of the delay 874 distributions. 876 7.1.5.2. Normal Power Approximation 878 Type-P-One-way-Composite-pdv-refmin-NPA for the complete Source to 879 Destination path can be calculated by combining statistics of all the 880 constituent sub-paths in the following process: 882 < see [Y.1541] clause 8 and Appendix X > 884 7.1.6. Statement of Conjecture and Assumptions 886 The delay distribution of a sufficiently large stream of packets 887 measured on each sub-path during the interval [T, Tf] will be 888 sufficiently stationary and the sub-path distributions themselves are 889 sufficiently independent, so that summary information describing the 890 sub-path distributions can be combined to estimate the delay 891 distribution of complete path. 893 It is assumed that the one-way delay distributions of the sub-paths 894 and the complete path are continuous. 896 7.1.7. Justification of the Composition Function 898 See the common section. 900 7.1.8. Sources of Deviation from the Ground Truth 902 In addition to the common deviations, a few additional sources exist 903 here. For one, very tight distributions with range on the order of a 904 few milliseconds are not accurately represented by a histogram with 1 905 ms bins. This size was chosen assuming an implicit requirement on 906 accuracy: errors of a few milliseconds are acceptable when assessing 907 a composed distribution quantile. 909 Also, summary statistics cannot describe the subtleties of an 910 empirical distribution exactly, especially when the distribution is 911 very different from a classical form. Any procedure that uses these 912 statistics alone may incur error. 914 7.1.9. Specific cases where the conjecture might fail 916 If the delay distributions of the sub-paths are somehow correlated, 917 then neither of these composition functions will be reliable 918 estimators of the complete path distribution. 920 In practice, sub-path delay distributions with extreme outliers have 921 increased the error of the composed metric estimate. 923 7.1.10. Application of Measurement Methodology 925 See the common section. 927 8. Security Considerations 929 8.1. Denial of Service Attacks 931 This metric requires a stream of packets sent from one host (source) 932 to another host (destination) through intervening networks. This 933 method could be abused for denial of service attacks directed at 934 destination and/or the intervening network(s). 936 Administrators of source, destination, and the intervening network(s) 937 should establish bilateral or multi-lateral agreements regarding the 938 timing, size, and frequency of collection of sample metrics. Use of 939 this method in excess of the terms agreed between the participants 940 may be cause for immediate rejection or discard of packets or other 941 escalation procedures defined between the affected parties. 943 8.2. User Data Confidentiality 945 Active use of this method generates packets for a sample, rather than 946 taking samples based on user data, and does not threaten user data 947 confidentiality. Passive measurement must restrict attention to the 948 headers of interest. Since user payloads may be temporarily stored 949 for length analysis, suitable precautions MUST be taken to keep this 950 information safe and confidential. In most cases, a hashing function 951 will produce a value suitable for payload comparisons. 953 8.3. Interference with the metrics 955 It may be possible to identify that a certain packet or stream of 956 packets is part of a sample. With that knowledge at the destination 957 and/or the intervening networks, it is possible to change the 958 processing of the packets (e.g. increasing or decreasing delay) that 959 may distort the measured performance. It may also be possible to 960 generate additional packets that appear to be part of the sample 961 metric. These additional packets are likely to perturb the results 962 of the sample measurement. 964 To discourage the kind of interference mentioned above, packet 965 interference checks, such as cryptographic hash, may be used. 967 9. IANA Considerations 969 Metrics defined in this memo will be registered in the IANA IPPM 970 METRICS REGISTRY as described in initial version of the registry 971 [RFC4148]. 973 10. Issues (Open and Closed) 975 >>>>>>>>>>>>Issue: 977 What is the relationship between the decomposition and composition 978 metrics? Should we put both kinds in one draft to make up a 979 framework? The motivation of decomposition is as follows: 981 The One-way measurement can provide result to show what the network 982 performance between two end hosts is and whether it meets operator 983 expectations or not. It cannot provide further information to 984 engineers where and how to improve the performance between the source 985 and the destination. For instance, if the network performance is not 986 acceptable in terms of the One-way measurement, in which part of the 987 network the engineers should put their efforts. This question can to 988 be answered by decompose the One-way measurement to sub-path 989 measurement to investigate the performance of different part of the 990 network. 992 Editor's Questions for clarification: What additional information 993 would be provided to the decomposition process, beyond the 994 measurement of the complete path? 996 Is the decomposition described above intended to estimate a metric 997 for some/all disjoint sub-paths involved in the complete path? 999 >>>>>>>>>>>>>>>>>>RESOLUTION: treat this topic in a separate memo 1001 >>>>>>>>>>>>>>>>>>> 1003 >>>>>>>>>>>>>>>>>>>Issue 1005 Section 7 defines a new type of metric, a "combination" of metrics 1006 for one-way delay and packet loss. The purpose of this metric is to 1007 link these two primary metrics in a convenient way. 1009 Readers are asked to comment on the efficiency of the combination 1010 metric. 1012 >>>>>>>>>>>>>>>>>RESOLUTION: If a delay singleton is recorded as 1013 having "undefined" delay when the packet does not arrive within the 1014 waiting time Tmax, then this information is sufficient to determine 1015 the fraction of lost packets in the sample, and the additional loss 1016 indication of this combo is not needed. 1018 >>>>>>>>>>>>>>>>>> 1020 >>>>>>>>>>>>>>>>> Issue 1022 Can we introduce multicast metrics here, without causing too much 1023 confusion? Should the multicast version of this draft wait until the 1024 Unicast concepts are stable (or maybe appear in a separate draft)? 1026 >>>>>>>>>>>>>>>>RESOLUTION: No and Yes. 1028 11. Acknowledgements 1030 12. References 1031 12.1. Normative References 1033 [I-D.ietf-ippm-framework-compagg] 1034 Morton, A., "Framework for Metric Composition", 1035 draft-ietf-ippm-framework-compagg-06 (work in progress), 1036 February 2008. 1038 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1039 Requirement Levels", BCP 14, RFC 2119, March 1997. 1041 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1042 "Framework for IP Performance Metrics", RFC 2330, 1043 May 1998. 1045 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1046 Delay Metric for IPPM", RFC 2679, September 1999. 1048 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1049 Packet Loss Metric for IPPM", RFC 2680, September 1999. 1051 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1052 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1053 November 2002. 1055 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 1056 Registry", BCP 108, RFC 4148, August 2005. 1058 12.2. Informative References 1060 [I-D.ietf-ippm-multimetrics] 1061 Stephan, E., Liang, L., and A. Morton, "IP Performance 1062 Metrics (IPPM) for spatial and multicast", 1063 draft-ietf-ippm-multimetrics-06 (work in progress), 1064 February 2008. 1066 [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data 1067 communication service - IP packet transfer and 1068 availability performance parameters", December 2002. 1070 [Y.1541] ITU-T Recommendation Y.1541, "Network Performance 1071 Objectives for IP-based Services", February 2006. 1073 Authors' Addresses 1075 Al Morton 1076 AT&T Labs 1077 200 Laurel Avenue South 1078 Middletown,, NJ 07748 1079 USA 1081 Phone: +1 732 420 1571 1082 Fax: +1 732 368 1192 1083 Email: acmorton@att.com 1084 URI: http://home.comcast.net/~acmacm/ 1086 Emile Stephan 1087 France Telecom Division R&D 1088 2 avenue Pierre Marzin 1089 Lannion, F-22307 1090 France 1092 Phone: 1093 Fax: +33 2 96 05 18 52 1094 Email: emile.stephan@orange-ftgroup.com 1095 URI: 1097 Full Copyright Statement 1099 Copyright (C) The IETF Trust (2008). 1101 This document is subject to the rights, licenses and restrictions 1102 contained in BCP 78, and except as set forth therein, the authors 1103 retain all their rights. 1105 This document and the information contained herein are provided on an 1106 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1107 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1108 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1109 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1110 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1111 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1113 Intellectual Property 1115 The IETF takes no position regarding the validity or scope of any 1116 Intellectual Property Rights or other rights that might be claimed to 1117 pertain to the implementation or use of the technology described in 1118 this document or the extent to which any license under such rights 1119 might or might not be available; nor does it represent that it has 1120 made any independent effort to identify any such rights. Information 1121 on the procedures with respect to rights in RFC documents can be 1122 found in BCP 78 and BCP 79. 1124 Copies of IPR disclosures made to the IETF Secretariat and any 1125 assurances of licenses to be made available, or the result of an 1126 attempt made to obtain a general license or permission for the use of 1127 such proprietary rights by implementers or users of this 1128 specification can be obtained from the IETF on-line IPR repository at 1129 http://www.ietf.org/ipr. 1131 The IETF invites any interested party to bring to its attention any 1132 copyrights, patents or patent applications, or other proprietary 1133 rights that may cover technology that may be required to implement 1134 this standard. Please address the information to the IETF at 1135 ietf-ipr@ietf.org. 1137 Acknowledgment 1139 Funding for the RFC Editor function is provided by the IETF 1140 Administrative Support Activity (IASA).