idnits 2.17.1 draft-ietf-ippm-spatial-composition-04.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 1099. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1110. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1117. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1123. 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 (July 7, 2007) is 6131 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 875, but not defined == Missing Reference: 'Tf' is mentioned on line 875, but not defined == Missing Reference: 'TBP' is mentioned on line 847, but not defined == Unused Reference: 'RFC3432' is defined on line 1041, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ippm-multimetrics' is defined on line 1050, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-ippm-framework-compagg-03 ** 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-04 Summary: 6 errors (**), 0 flaws (~~), 8 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: January 8, 2008 France Telecom Division R&D 6 July 7, 2007 8 Spatial Composition of Metrics 9 draft-ietf-ippm-spatial-composition-04 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 January 8, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 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 . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . 15 116 6.1.7. Justification of the Composition Function . . . . . . 15 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 . . . . 17 126 7.1.5. Composition Functions: . . . . . . . . . . . . . . . . 18 127 7.1.6. Statement of Conjecture . . . . . . . . . . . . . . . 19 128 7.1.7. Justification of the Composition Function . . . . . . 19 129 7.1.8. Sources of Deviation from the Ground Truth . . . . . . 19 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 . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 22 140 12.1. Normative References . . . . . . . . . . . . . . . . . . . 22 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, 190 o a justification of the practical utility of the composition in 191 terms of making accurate measurements of the metric on the path, 193 o a justification of the usefulness of the composition in terms of 194 making analysis of the path using A-frame concepts more effective, 195 and 197 o an analysis of how the conjecture could be incorrect. 199 Also, [RFC2330] gives an example where a conjecture that the delay of 200 a path is very nearly the sum of the delays of the exchanges and 201 clouds of the corresponding path digest. This example is 202 particularly relevant to those who wish to assess the performance of 203 an Inter-domain path without direct measurement, and the performance 204 estimate of the complete path is related to the measured results for 205 various sub-paths instead. 207 Approximate functions between the sub-path and complete path metrics 208 are useful, with knowledge of the circumstances where the 209 relationships are/are not applicable. For example, we would not 210 expect that delay singletons from each sub-path would sum to produce 211 an accurate estimate of a delay singleton for the complete path 212 (unless all the delays were essentially constant - very unlikely). 213 However, other delay statistics (based on a reasonable sample size) 214 may have a sufficiently large set of circumstances where they are 215 applicable. 217 2.1. Motivation 219 One-way metrics defined in other IPPM RFCs all assume that the 220 measurement can be practically carried out between the source and the 221 destination of the interest. Sometimes there are reasons that the 222 measurement can not be executed from the source to the destination. 223 For instance, the measurement path may cross several independent 224 domains that have conflicting policies, measurement tools and 225 methods, and measurement time assignment. The solution then may be 226 the composition of several sub-path measurements. This means each 227 domain performs the One-way measurement on a sub path between two 228 nodes that are involved in the complete path following its own 229 policy, using its own measurement tools and methods, and using its 230 own measurement timing. Under the appropriate conditions, one can 231 combine the sub-path One-way metric results to estimate the complete 232 path One-way measurement metric with some degree of accuracy. 234 3. Scope and Application 235 3.1. Scope of work 237 For the primary IPPM metrics of Loss, Delay, and Delay Variation, 238 this memo gives a set of metrics for that can be composed from the 239 same or similar sub-path metrics. This means that the composition 240 function may utilize: 242 o the same metric for each sub-path; 244 o multiple metrics for each sub-path (possibly one that is the same 245 as the complete path metric); 247 o a single sub-path metrics that is different from the complete path 248 metric; 250 o different measurement techniques like active and passive 251 (recognizing that PSAMP WG will define capabilities to sample 252 packets to support measurement). 254 3.2. Application 256 The new composition framework [I-D.ietf-ippm-framework-compagg] 257 requires the specification of the applicable circumstances for each 258 metric. In particular, each section addresses whether the metric: 260 Requires the same test packets to traverse all sub-paths, or may use 261 similar packets sent and collected separately in each sub-path. 263 Requires homogeneity of measurement methodologies, or can allow a 264 degree of flexibility (e.g., active or passive methods produce the 265 "same" metric). Also, the applicable sending streams will be 266 specified, such as Poisson, Periodic, or both. 268 Needs information or access that will only be available within an 269 operator's domain, or is applicable to Inter-domain composition. 271 Requires synchronized measurement time intervals in all sub-paths, or 272 largely overlapping, or no timing requirements. 274 Requires assumption of sub-path independence w.r.t. the metric being 275 defined/composed, or other assumptions. 277 Has known sources of inaccuracy/error, and identifies the sources. 279 3.3. Incomplete Information 281 In practice, when measurements cannot be initiated on a sub-path (and 282 perhaps the measurement system gives up during the test interval), 283 then there will not be a value for the sub-path reported, and the 284 entire test result SHOULD be recorded as "undefined". This case 285 should be distinguished from the case where the measurement system 286 continued to send packets throughout the test interval, but all were 287 declared lost. 289 When a composed metric requires measurements from sub paths A, B, and 290 C, and one or more of the sub-path results are undefined, then the 291 composed metric SHOULD also be recorded as undefined. 293 4. Common Specifications for Composed Metrics 295 To reduce the redundant information presented in the detailed metrics 296 sections that follow, this section presents the specifications that 297 are common to two or more metrics. The section is organized using 298 the same subsections as the individual metrics, to simplify 299 comparisons. 301 4.1. Name: Type-P 303 All metrics use the Type-P convention as described in [RFC2330]. The 304 rest of the name is unique to each metric. 306 4.1.1. Metric Parameters 308 o Src, the IP address of a host 310 o Dst, the IP address of a host 312 o T, a time (start of test interval) 314 o Tf, a time (end of test interval) 316 o lambda, a rate in reciprocal seconds (for Poisson Streams) 318 o incT, the nominal duration of inter-packet interval, first bit to 319 first bit (for Periodic Streams) 321 o T0, a time that MUST be selected at random from the interval [T, 322 T+dT] to start generating packets and taking measurements (for 323 Periodic Streams) 325 o TstampSrc, the wire time of the packet as measured at MP(Src) 327 o TstampDst, the wire time of the packet as measured at MP(Dst), 328 assigned to packets that arrive within a "reasonable" time. 330 o Tmax, a maximum waiting time for packets at the destination, set 331 sufficiently long to disambiguate packets with long delays from 332 packets that are discarded (lost), thus the distribution of delay 333 is not truncated. 335 o M, the total number of packets sent between T0 and Tf 337 o N, the total number of packets received at Dst (sent between T0 338 and Tf) 340 o S, the number of sub-paths involved in the complete Src-Dst path 342 4.1.2. Definition and Metric Units 344 This section is unique for every metric. 346 4.1.3. Discussion and other details 348 This section is unique for every metric. 350 4.1.4. Statistic: 352 This section is unique for every metric. 354 4.1.5. Composition Function 356 This section is unique for every metric. 358 4.1.6. Statement of Conjecture 360 This section is unique for each metric. 362 4.1.7. Justification of the Composition Function 364 It is sometimes impractical to conduct active measurements between 365 every Src-Dst pair. Since the full mesh of N measurement points 366 grows as N x N, the scope of measurement may be limited by testing 367 resources. 369 There may be varying limitations on active testing in different parts 370 of the network. For example, it may not be possible to collect the 371 desired sample size in each test interval when access link speed is 372 limited, because of the potential for measurement traffic to degrade 373 the user traffic performance. The conditions on a low-speed access 374 link may be understood well-enough to permit use of a small sample 375 size/rate, while a larger sample size/rate may be used on other sub- 376 paths. 378 Also, since measurement operations have a real monetary cost, there 379 is value in re-using measurements where they are applicable, rather 380 than launching new measurements for every possible source-destination 381 pair. 383 4.1.8. Sources of Deviation from the Ground Truth 385 The measurement packets, each having source and destination addresses 386 intended for collection at edges of the sub-path, may take a 387 different specific path through the network equipment and parallel 388 links when compared to packets with the source and destination 389 addresses of the complete path. Therefore, the composition of sub- 390 path measurements may differ from the performance experienced by 391 packets on the complete path. Multiple measurements employing 392 sufficient sub-path address pairs might produce bounds on the extent 393 of this error. 395 Related to the case of an alternate path described above is the case 396 where elements in the measured path are unique to measurement system 397 connectivity. For example, a measurement system may use a dedicated 398 link to a LAN switch, and packets on the complete path do not 399 traverse that link. The performance of such a dedicated link would 400 be measured continuously, and its contribution to the sub-path 401 metrics SHOULD be minimized as a source of error. 403 others??? 405 4.1.9. Specific cases where the conjecture might fail 407 This section is unique for each metric. 409 4.1.10. Application of Measurement Methodology 411 The methodology: 413 SHOULD use similar packets sent and collected separately in each sub- 414 path. 416 Allows a degree of flexibility (e.g., active or passive methods can 417 produce the "same" metric, but timing and correlation of passive 418 measurements is much more challenging). 420 Poisson and/or Periodic streams are RECOMMENDED. 422 Applies to both Inter-domain and Intra-domain composition. 424 SHOULD have synchronized measurement time intervals in all sub-paths, 425 but largely overlapping intervals MAY suffice. 427 REQUIRES assumption of sub-path independence w.r.t. the metric being 428 defined/composed. 430 5. One-way Delay Composed Metrics and Statistics 432 5.1. Name: Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream 434 This metric is a necessary element of Delay Composition metrics, and 435 its definition does not formally exist elsewhere in IPPM literature. 437 5.1.1. Metric Parameters 439 See the common parameters section above. 441 5.1.2. Definition and Metric Units 443 Using the parameters above, we obtain the value of Type-P-One-way- 444 Delay singleton as per [RFC2679]. 446 For each packet [i] that has a finite One-way Delay (in other words, 447 excluding packets which have undefined one-way delay): 449 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i] = 451 FiniteDelay[i] = TstampDst - TstampSrc 453 The units of measure for this metric are time in seconds, expressed 454 in sufficiently low resolution to convey meaningful quantitative 455 information. For example, resolution of microseconds is usually 456 sufficient. 458 5.1.3. Discussion and other details 460 The "Type-P-Finite-One-way-Delay" metric permits calculation of the 461 sample mean statistic. This resolves the problem of including lost 462 packets in the sample (whose delay is undefined), and the issue with 463 the informal assignment of infinite delay to lost packets (practical 464 systems can only assign some very large value). 466 The Finite-One-way-Delay approach handles the problem of lost packets 467 by reducing the event space. We consider conditional statistics, and 468 estimate the mean one-way delay conditioned on the event that all 469 packets in the sample arrive at the destination (within the specified 470 waiting time, Tmax). This offers a way to make some valid statements 471 about one-way delay, and at the same time avoiding events with 472 undefined outcomes. This approach is derived from the treatment of 473 lost packets in [RFC3393], and is similar to [Y.1540] . 475 5.2. Name: Type-P-Finite-Composite-One-way-Delay-Mean 477 This section describes a statistic based on the Type-P-Finite-One- 478 way-Delay-Poisson/Periodic-Stream metric. 480 5.2.1. Metric Parameters 482 See the common parameters section above. 484 5.2.2. Definition and Metric Units of the Mean Statistic 486 We define 488 Type-P-Finite-One-way-Delay-Mean = 489 N 490 --- 491 1 \ 492 MeanDelay = - * > (FiniteDelay [i]) 493 N / 494 --- 495 i = 1 497 where all packets i= 1 through N have finite singleton delays. 499 The units of measure for this metric are time in seconds, expressed 500 in sufficiently low resolution to convey meaningful quantitative 501 information. For example, resolution of microseconds is usually 502 sufficient. 504 5.2.3. Discussion and other details 506 The Type-P-Finite-One-way-Delay-Mean metric requires the conditional 507 delay distribution described in section 5.1. 509 5.2.4. Composition Function: Sum of Means 511 The Type-P-Finite--Composite-One-way-Delay-Mean, or CompMeanDelay, 512 for the complete Source to Destination path can be calculated from 513 sum of the Mean Delays of all its S constituent sub-paths. 515 Then the 516 Type-P-Finite-Composite-One-way-Delay-Mean = 517 S 518 --- 519 \ 520 CompMeanDelay = > (MeanDelay [i]) 521 / 522 --- 523 i = 1 525 5.2.5. Statement of Conjecture 527 The mean of a sufficiently large stream of packets measured on each 528 sub-path during the interval [T, Tf] will be representative of the 529 true mean of the delay distribution (and the distributions themselves 530 are sufficiently independent), such that the means may be added to 531 produce an estimate of the complete path mean delay. 533 5.2.6. Justification of the Composition Function 535 See the common section. 537 5.2.7. Sources of Deviation from the Ground Truth 539 See the common section. 541 5.2.8. Specific cases where the conjecture might fail 543 If any of the sub-path distributions are bimodal, then the measured 544 means may not be stable, and in this case the mean will not be a 545 particularly useful statistic when describing the delay distribution 546 of the complete path. 548 The mean may not be sufficiently robust statistic to produce a 549 reliable estimate, or to be useful even if it can be measured. 551 others... 553 5.2.9. Application of Measurement Methodology 555 The requirements of the common section apply here as well. 557 5.3. Name: Type-P-Finite-Composite-One-way-Delay-Minimum 559 This section describes is a statistic based on the Type-P-Finite-One- 560 way-Delay-Poisson/Periodic-Stream metric, and the composed metric 561 based on that statistic. 563 5.3.1. Metric Parameters 565 See the common parameters section above. 567 5.3.2. Definition and Metric Units of the Mean Statistic 569 We define 571 Type-P-Finite-One-way-Delay-Minimum = 572 = MinDelay = (FiniteDelay [j]) 574 such that for some index, j, where 1<= j <= N 575 FiniteDelay[j] <= FiniteDelay[i] for all i 577 where all packets i= 1 through N have finite singleton delays. 579 The units of measure for this metric are time in seconds, expressed 580 in sufficiently low resolution to convey meaningful quantitative 581 information. For example, resolution of microseconds is usually 582 sufficient. 584 5.3.3. Discussion and other details 586 The Type-P-Finite-One-way-Delay-Minimum metric requires the 587 conditional delay distribution described in section 5.1.3. 589 5.3.4. Composition Function: Sum of Means 591 The Type-P-Finite--Composite-One-way-Delay-Minimum, or CompMinDelay, 592 for the complete Source to Destination path can be calculated from 593 sum of the Minimum Delays of all its S constituent sub-paths. 595 Then the 597 Type-P-Finite-Composite-One-way-Delay-Minimum = 598 S 599 --- 600 \ 601 CompMinDelay = > (MinDelay [i]) 602 / 603 --- 604 i = 1 606 5.3.5. Statement of Conjecture 608 The minimum of a sufficiently large stream of packets measured on 609 each sub-path during the interval [T, Tf] will be representative of 610 the true minimum of the delay distribution (and the distributions 611 themselves are sufficiently independent), such that the minima may be 612 added to produce an estimate of the complete path minimum delay. 614 5.3.6. Justification of the Composition Function 616 See the common section. 618 5.3.7. Sources of Deviation from the Ground Truth 620 See the common section. 622 5.3.8. Specific cases where the conjecture might fail 624 If the routing on any of the sub-paths is not stable, then the 625 measured minimum may not be stable. In this case the composite 626 minimum would tend to produce an estimate for the complete path that 627 may be too low for the current path. 629 others??? 631 5.3.9. Application of Measurement Methodology 633 The requirements of the common section apply here as well. 635 6. Loss Metrics and Statistics 637 6.1. Type-P-Composite-One-way-Packet-Loss-Empirical-Probability 639 6.1.1. Metric Parameters: 641 Same as section 4.1.1. 643 6.1.2. Definition and Metric Units 645 Using the parameters above, we obtain the value of Type-P-One-way- 646 Packet-Loss singleton and stream as per [RFC2680]. 648 We obtain a sequence of pairs with elements as follows: 650 o TstampSrc, as above 652 o L, either zero or one, where L=1 indicates loss and L=0 indicates 653 arrival at the destination within TstampSrc + Tmax. 655 6.1.3. Discussion and other details 657 6.1.4. Statistic: Type-P-One-way-Packet-Loss-Empirical-Probability 659 Given the stream parameter M, the number of packets sent, we can 660 define the Empirical Probability of Loss Statistic (Ep), consistent 661 with Average Loss in [RFC2680], as follows: 663 Type-P-One-way-Packet-Loss-Empirical-Probability = 664 M 665 --- 666 1 \ 667 Ep = - * > (L[i]) 668 M / 669 --- 670 i = 1 672 where all packets i= 1 through M have a value for L. 674 6.1.5. Composition Function: Composition of Empirical Probabilities 676 The Type-P-One-way-Composite-Packet-Loss-Empirical-Probability, or 677 CompEp for the complete Source to Destination path can be calculated 678 by combining Ep of all its constituent sub-paths (Ep1, Ep2, Ep3, ... 679 Epn) as 681 Type-P-Composite-One-way-Packet-Loss-Empirical-Probability = 682 CompEp = 1 - {(1 - Ep1) x (1 - Ep2) x (1 - Ep3) x ... x (1 - Epn)} 684 If any Epn is undefined in a particular measurement interval, 685 possibly because a measurement system failed to report a value, then 686 any CompEp that uses sub-path n for that measurement interval is 687 undefined. 689 6.1.6. Statement of Conjecture 691 The empirical probability of loss calculated on a sufficiently large 692 stream of packets measured on each sub-path during the interval [T, 693 Tf] will be representative of the true loss probability (and the 694 probabilities themselves are sufficiently independent), such that the 695 sub-path probabilities may be combined to produce an estimate of the 696 complete path loss probability. 698 6.1.7. Justification of the Composition Function 700 See the common section. 702 6.1.8. Sources of Deviation from the Ground Truth 704 See the common section. 706 6.1.9. Specific cases where the conjecture might fail 708 A concern for loss measurements combined in this way is that root 709 causes may be correlated to some degree. 711 For example, if the links of different networks follow the same 712 physical route, then a single catastrophic event like a fire in a 713 tunnel could cause an outage or congestion on remaining paths in 714 multiple networks. Here it is important to ensure that measurements 715 before the event and after the event are not combined to estimate the 716 composite performance. 718 Or, when traffic volumes rise due to the rapid spread of an email- 719 born worm, loss due to queue overflow in one network may help another 720 network to carry its traffic without loss. 722 others... 724 6.1.10. Application of Measurement Methodology 726 See the common section. 728 7. Delay Variation Metrics and Statistics 730 7.1. Name: Type-P-One-way-pdv-refmin-Poisson/Periodic-Stream 732 This packet delay variation (PDV) metric is a necessary element of 733 Composed Delay Variation metrics, and its definition does not 734 formally exist elsewhere in IPPM literature. 736 7.1.1. Metric Parameters: 738 In addition to the parameters of section 4.1.1: 740 o TstampSrc[i], the wire time of packet[i] as measured at MP(Src) 741 (measurement point at the source) 743 o TstampDst[i], the wire time of packet[i] as measured at MP(Dst), 744 assigned to packets that arrive within a "reasonable" time. 746 o B, a packet length in bits 747 o F, a selection function unambiguously defining the packets from 748 the stream that are selected for the packet-pair computation of 749 this metric. F(first packet), the first packet of the pair, MUST 750 have a valid Type-P-Finite-One-way-Delay less than Tmax (in other 751 words, excluding packets which have undefined one-way delay) and 752 MUST have been transmitted during the interval T, Tf. The second 753 packet in the pair, F(second packet) MUST be the packet with the 754 minimum valid value of Type-P-Finite-One-way-Delay for the stream, 755 in addition to the criteria for F(first packet). If multiple 756 packets have equal minimum Type-P-Finite-One-way-Delay values, 757 then the value for the earliest arriving packet SHOULD be used. 759 o MinDelay, the Type-P-Finite-One-way-Delay value for F(second 760 packet) given above. 762 o N, the number of packets received at the Destination meeting the 763 F(first packet) criteria. 765 7.1.2. Definition and Metric Units 767 Using the definition above in section 5.1.2, we obtain the value of 768 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i], the singleton 769 for each packet[i] in the stream (a.k.a. FiniteDelay[i]). 771 For each packet[i] that meets the F(first packet) criteria given 772 above: Type-P-One-way-pdv-refmin-Poisson/Periodic-Stream[i] = 774 PDV[i] = FiniteDelay[i] - MinDelay 776 where PDV[i] is in units of time in seconds, expressed in 777 sufficiently low resolution to convey meaningful quantitative 778 information. For example, resolution of microseconds is usually 779 sufficient. 781 7.1.3. Discussion and other details 783 This metric produces a sample of delay variation normalized to the 784 minimum delay of the sample. The resulting delay variation 785 distribution is independent of the sending sequence (although 786 specific FiniteDelay values within the distribution may be 787 correlated, depending on various stream parameters such as packet 788 spacing). This metric is equivalent to the IP Packet Delay Variation 789 parameter defined in [Y.1540]. 791 7.1.4. Statistics: Mean, Variance, Skewness, Quanitle 793 We define the mean PDV as follows (where all packets i= 1 through N 794 have a value for PDV[i]): 796 Type-P-One-way-pdv-refmin-Mean = MeanPDV = 797 N 798 --- 799 1 \ 800 - * > (PDV[i]) 801 N / 802 --- 803 i = 1 805 We define the variance of PDV as follows: 807 Type-P-One-way-pdv-refmin-Variance = VarPDV = 808 N 809 --- 810 1 \ 2 811 ------- > (PDV[i] - MeanPDV) 812 (N - 1) / 813 --- 814 i = 1 816 We define the skewness of PDV as follows: 818 Type-P-One-way-pdv-refmin-Skewness = SkewPDV = 819 N 820 --- 3 821 \ / \ 822 > | PDV[i]- MeanPDV | 823 / \ / 824 --- 825 i = 1 826 ----------------------------------- 827 / \ 828 | ( 3/2 ) | 829 \ (N - 1) * VarPDV / 831 We define the Quantile of the IPDVRefMin sample as the value where 832 the specified fraction of singletons is less than the given value. 834 7.1.5. Composition Functions: 836 This section gives two alternative composition functions. The 837 objective is to estimate a quantile of the complete path delay 838 variation distribution. The composed quantile will be estimated 839 using information from the sub-path delay variation distributions. 841 7.1.5.1. Approximate Convolution 843 The Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream samples from 844 each sub-path are summarized as a histogram with 1 ms bins 845 representing the one-way delay distribution. 847 From [TBP], the distribution of the sum of independent random 848 variables can be derived using the relation: 850 Type-P-Composite-One-way-pdv-refmin-quantile-a = 851 / / 852 P(X + Y + Z <= a) = | | P(X <= a-y-z) * P(Y = y) * P(Z = z) dy dz 853 / / 854 z y 855 where X, Y, and Z are random variables representing the delay 856 variation distributions of the sub-paths of the complete path (in 857 this case, there are three sub-paths), and a is the quantile of 858 interest. Note dy and dz indicate partial integration here.This 859 relation can be used to compose a quantile of interest for the 860 complete path from the sub-path delay distributions. The histograms 861 with 1 ms bins are discrete approximations of the delay 862 distributions. 864 7.1.5.2. Normal Power Approximation 866 Type-P-One-way-Composite-pdv-refmin-NPA for the complete Source to 867 Destination path can be calculated by combining statistics of all the 868 constituent sub-paths in the following process: 870 < see [Y.1541] clause 8 and Appendix X > 872 7.1.6. Statement of Conjecture 874 The delay distribution of a sufficiently large stream of packets 875 measured on each sub-path during the interval [T, Tf] will be 876 sufficiently stationary and the sub-path distributions themselves are 877 sufficiently independent, so that summary information describing the 878 sub-path distributions can be combined to estimate the delay 879 distribution of complete path. 881 7.1.7. Justification of the Composition Function 883 See the common section. 885 7.1.8. Sources of Deviation from the Ground Truth 887 In addition to the common deviations, a few additional sources exist 888 here. For one, very tight distributions with range on the order of a 889 few milliseconds are not accurately represented by a histogram with 1 890 ms bins. This size was chosen assuming an implicit requirement on 891 accuracy: errors of a few milliseconds are acceptable when assessing 892 a composed distribution quantile. 894 Also, summary statistics cannot describe the subtleties of an 895 empirical distribution exactly, especially when the distribution is 896 very different from a classical form. Any procedure that uses these 897 statistics alone may incur error. 899 7.1.9. Specific cases where the conjecture might fail 901 If the delay distributions of the sub-paths are somehow correlated, 902 then neither of these composition functions will be reliable 903 estimators of the complete path distribution. 905 In practice, sub-path delay distributions with extreme outliers have 906 increased the error of the composed metric estimate. 908 7.1.10. Application of Measurement Methodology 910 See the common section. 912 8. Security Considerations 914 8.1. Denial of Service Attacks 916 This metric requires a stream of packets sent from one host (source) 917 to another host (destination) through intervening networks. This 918 method could be abused for denial of service attacks directed at 919 destination and/or the intervening network(s). 921 Administrators of source, destination, and the intervening network(s) 922 should establish bilateral or multi-lateral agreements regarding the 923 timing, size, and frequency of collection of sample metrics. Use of 924 this method in excess of the terms agreed between the participants 925 may be cause for immediate rejection or discard of packets or other 926 escalation procedures defined between the affected parties. 928 8.2. User Data Confidentiality 930 Active use of this method generates packets for a sample, rather than 931 taking samples based on user data, and does not threaten user data 932 confidentiality. Passive measurement must restrict attention to the 933 headers of interest. Since user payloads may be temporarily stored 934 for length analysis, suitable precautions MUST be taken to keep this 935 information safe and confidential. In most cases, a hashing function 936 will produce a value suitable for payload comparisons. 938 8.3. Interference with the metrics 940 It may be possible to identify that a certain packet or stream of 941 packets is part of a sample. With that knowledge at the destination 942 and/or the intervening networks, it is possible to change the 943 processing of the packets (e.g. increasing or decreasing delay) that 944 may distort the measured performance. It may also be possible to 945 generate additional packets that appear to be part of the sample 946 metric. These additional packets are likely to perturb the results 947 of the sample measurement. 949 To discourage the kind of interference mentioned above, packet 950 interference checks, such as cryptographic hash, may be used. 952 9. IANA Considerations 954 Metrics defined in this memo will be registered in the IANA IPPM 955 METRICS REGISTRY as described in initial version of the registry 956 [RFC4148]. 958 10. Issues (Open and Closed) 960 >>>>>>>>>>>>Issue: 962 What is the relationship between the decomposition and composition 963 metrics? Should we put both kinds in one draft to make up a 964 framework? The motivation of decomposition is as follows: 966 The One-way measurement can provide result to show what the network 967 performance between two end hosts is and whether it meets operator 968 expectations or not. It cannot provide further information to 969 engineers where and how to improve the performance between the source 970 and the destination. For instance, if the network performance is not 971 acceptable in terms of the One-way measurement, in which part of the 972 network the engineers should put their efforts. This question can to 973 be answered by decompose the One-way measurement to sub-path 974 measurement to investigate the performance of different part of the 975 network. 977 Editor's Questions for clarification: What additional information 978 would be provided to the decomposition process, beyond the 979 measurement of the complete path? 981 Is the decomposition described above intended to estimate a metric 982 for some/all disjoint sub-paths involved in the complete path? 984 >>>>>>>>>>>>>>>>>>RESOLUTION: treat this topic in a separate memo 986 >>>>>>>>>>>>>>>>>>> 988 >>>>>>>>>>>>>>>>>>>Issue 990 Section 7 defines a new type of metric, a "combination" of metrics 991 for one-way delay and packet loss. The purpose of this metric is to 992 link these two primary metrics in a convenient way. 994 Readers are asked to comment on the efficiency of the combination 995 metric. 997 >>>>>>>>>>>>>>>>>RESOLUTION: If a delay singleton is recorded as 998 having "undefined" delay when the packet does not arrive within the 999 waiting time Tmax, then this information is sufficient to determine 1000 the fraction of lost packets in the sample, and the additional loss 1001 indication of this combo is not needed. 1003 >>>>>>>>>>>>>>>>>> 1005 >>>>>>>>>>>>>>>>> Issue 1007 Can we introduce multicast metrics here, without causing too much 1008 confusion? Should the multicast version of this draft wait until the 1009 Unicast concepts are stable (or maybe appear in a separate draft)? 1011 >>>>>>>>>>>>>>>>RESOLUTION: No and Yes. 1013 11. Acknowledgements 1015 12. References 1017 12.1. Normative References 1019 [I-D.ietf-ippm-framework-compagg] 1020 Morton, A. and S. Berghe, "Framework for Metric 1021 Composition", draft-ietf-ippm-framework-compagg-03 (work 1022 in progress), March 2007. 1024 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1025 Requirement Levels", BCP 14, RFC 2119, March 1997. 1027 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1028 "Framework for IP Performance Metrics", RFC 2330, 1029 May 1998. 1031 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1032 Delay Metric for IPPM", RFC 2679, September 1999. 1034 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1035 Packet Loss Metric for IPPM", RFC 2680, September 1999. 1037 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1038 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1039 November 2002. 1041 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 1042 performance measurement with periodic streams", RFC 3432, 1043 November 2002. 1045 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 1046 Registry", BCP 108, RFC 4148, August 2005. 1048 12.2. Informative References 1050 [I-D.ietf-ippm-multimetrics] 1051 Stephan, E., "IP Performance Metrics (IPPM) for spatial 1052 and multicast", draft-ietf-ippm-multimetrics-04 (work in 1053 progress), July 2007. 1055 [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data 1056 communication service - IP packet transfer and 1057 availability performance parameters", December 2002. 1059 [Y.1541] ITU-T Recommendation Y.1541, "Network Performance 1060 Objectives for IP-based Services", February 2006. 1062 Authors' Addresses 1064 Al Morton 1065 AT&T Labs 1066 200 Laurel Avenue South 1067 Middletown,, NJ 07748 1068 USA 1070 Phone: +1 732 420 1571 1071 Fax: +1 732 368 1192 1072 Email: acmorton@att.com 1073 URI: http://home.comcast.net/~acmacm/ 1074 Emile Stephan 1075 France Telecom Division R&D 1076 2 avenue Pierre Marzin 1077 Lannion, F-22307 1078 France 1080 Phone: 1081 Fax: +33 2 96 05 18 52 1082 Email: emile.stephan@orange-ftgroup.com 1083 URI: 1085 Full Copyright Statement 1087 Copyright (C) The IETF Trust (2007). 1089 This document is subject to the rights, licenses and restrictions 1090 contained in BCP 78, and except as set forth therein, the authors 1091 retain all their rights. 1093 This document and the information contained herein are provided on an 1094 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1095 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1096 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1097 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1098 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1099 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1101 Intellectual Property 1103 The IETF takes no position regarding the validity or scope of any 1104 Intellectual Property Rights or other rights that might be claimed to 1105 pertain to the implementation or use of the technology described in 1106 this document or the extent to which any license under such rights 1107 might or might not be available; nor does it represent that it has 1108 made any independent effort to identify any such rights. Information 1109 on the procedures with respect to rights in RFC documents can be 1110 found in BCP 78 and BCP 79. 1112 Copies of IPR disclosures made to the IETF Secretariat and any 1113 assurances of licenses to be made available, or the result of an 1114 attempt made to obtain a general license or permission for the use of 1115 such proprietary rights by implementers or users of this 1116 specification can be obtained from the IETF on-line IPR repository at 1117 http://www.ietf.org/ipr. 1119 The IETF invites any interested party to bring to its attention any 1120 copyrights, patents or patent applications, or other proprietary 1121 rights that may cover technology that may be required to implement 1122 this standard. Please address the information to the IETF at 1123 ietf-ipr@ietf.org. 1125 Acknowledgment 1127 Funding for the RFC Editor function is provided by the IETF 1128 Administrative Support Activity (IASA).