idnits 2.17.1 draft-ietf-ippm-spatial-composition-07.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 1151. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1162. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1169. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1175. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 13, 2008) is 5759 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 914, but not defined == Missing Reference: 'Tf' is mentioned on line 914, but not defined == Missing Reference: 'TBP' is mentioned on line 886, but not defined == Unused Reference: 'I-D.ietf-ippm-multimetrics' is defined on line 1100, 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-07 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 14, 2009 France Telecom Division R&D 6 July 13, 2008 8 Spatial Composition of Metrics 9 draft-ietf-ippm-spatial-composition-07 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 14, 2009. 36 Abstract 38 This memo utilizes IPPM metrics that are applicable to both complete 39 paths and sub-paths, and defines relationships to compose a complete 40 path metric from the sub-path metrics with some accuracy w.r.t. the 41 actual metrics. This is called Spatial Composition in RFC 2330. The 42 memo refers to the Framework for Metric Composition, and provides 43 background and motivation for combining metrics to derive others. 44 The descriptions of several composed metrics and statistics follow. 46 Requirements Language 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in RFC 2119 [RFC2119]. 52 In this memo, the characters "<=" should be read as "less than or 53 equal to" and ">=" as "greater than or equal to". 55 Table of Contents 57 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Scope and Application . . . . . . . . . . . . . . . . . . . . 5 61 3.1. Scope of work . . . . . . . . . . . . . . . . . . . . . . 6 62 3.2. Application . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.3. Incomplete Information . . . . . . . . . . . . . . . . . . 6 64 4. Common Specifications for Composed Metrics . . . . . . . . . . 7 65 4.1. Name: Type-P . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.1.1. Metric Parameters . . . . . . . . . . . . . . . . . . 7 67 4.1.2. Definition and Metric Units . . . . . . . . . . . . . 8 68 4.1.3. Discussion and other details . . . . . . . . . . . . . 8 69 4.1.4. Statistic: . . . . . . . . . . . . . . . . . . . . . . 8 70 4.1.5. Composition Function . . . . . . . . . . . . . . . . . 8 71 4.1.6. Statement of Conjecture and Assumptions . . . . . . . 8 72 4.1.7. Justification of the Composition Function . . . . . . 8 73 4.1.8. Sources of Deviation from the Ground Truth . . . . . . 9 74 4.1.9. Specific cases where the conjecture might fail . . . . 10 75 4.1.10. Application of Measurement Methodology . . . . . . . . 10 76 5. One-way Delay Composed Metrics and Statistics . . . . . . . . 10 77 5.1. Name: 78 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream . . . 10 79 5.1.1. Metric Parameters . . . . . . . . . . . . . . . . . . 10 80 5.1.2. Definition and Metric Units . . . . . . . . . . . . . 11 81 5.1.3. Discussion and other details . . . . . . . . . . . . . 11 82 5.2. Name: Type-P-Finite-Composite-One-way-Delay-Mean . . . . . 11 83 5.2.1. Metric Parameters . . . . . . . . . . . . . . . . . . 11 84 5.2.2. Definition and Metric Units of the Mean Statistic . . 11 85 5.2.3. Discussion and other details . . . . . . . . . . . . . 12 86 5.2.4. Composition Function: Sum of Means . . . . . . . . . . 12 87 5.2.5. Statement of Conjecture and Assumptions . . . . . . . 12 88 5.2.6. Justification of the Composition Function . . . . . . 13 89 5.2.7. Sources of Deviation from the Ground Truth . . . . . . 13 90 5.2.8. Specific cases where the conjecture might fail . . . . 13 91 5.2.9. Application of Measurement Methodology . . . . . . . . 13 92 5.3. Name: Type-P-Finite-Composite-One-way-Delay-Minimum . . . 13 93 5.3.1. Metric Parameters . . . . . . . . . . . . . . . . . . 13 94 5.3.2. Definition and Metric Units of the Mean Statistic . . 13 95 5.3.3. Discussion and other details . . . . . . . . . . . . . 14 96 5.3.4. Composition Function: Sum of Means . . . . . . . . . . 14 97 5.3.5. Statement of Conjecture and Assumptions . . . . . . . 14 98 5.3.6. Justification of the Composition Function . . . . . . 14 99 5.3.7. Sources of Deviation from the Ground Truth . . . . . . 14 100 5.3.8. Specific cases where the conjecture might fail . . . . 15 101 5.3.9. Application of Measurement Methodology . . . . . . . . 15 102 6. Loss Metrics and Statistics . . . . . . . . . . . . . . . . . 15 103 6.1. Type-P-Composite-One-way-Packet-Loss-Empirical-Probability 15 104 6.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 15 105 6.1.2. Definition and Metric Units . . . . . . . . . . . . . 15 106 6.1.3. Discussion and other details . . . . . . . . . . . . . 15 107 6.1.4. Statistic: 108 Type-P-One-way-Packet-Loss-Empirical-Probability . . . 15 109 6.1.5. Composition Function: Composition of Empirical 110 Probabilities . . . . . . . . . . . . . . . . . . . . 16 111 6.1.6. Statement of Conjecture and Assumptions . . . . . . . 16 112 6.1.7. Justification of the Composition Function . . . . . . 16 113 6.1.8. Sources of Deviation from the Ground Truth . . . . . . 16 114 6.1.9. Specific cases where the conjecture might fail . . . . 16 115 6.1.10. Application of Measurement Methodology . . . . . . . . 17 116 7. Delay Variation Metrics and Statistics . . . . . . . . . . . . 17 117 7.1. Name: Type-P-One-way-pdv-refmin-Poisson/Periodic-Stream . 17 118 7.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 17 119 7.1.2. Definition and Metric Units . . . . . . . . . . . . . 18 120 7.1.3. Discussion and other details . . . . . . . . . . . . . 18 121 7.1.4. Statistics: Mean, Variance, Skewness, Quanitle . . . . 18 122 7.1.5. Composition Functions: . . . . . . . . . . . . . . . . 19 123 7.1.6. Statement of Conjecture and Assumptions . . . . . . . 20 124 7.1.7. Justification of the Composition Function . . . . . . 20 125 7.1.8. Sources of Deviation from the Ground Truth . . . . . . 21 126 7.1.9. Specific cases where the conjecture might fail . . . . 21 127 7.1.10. Application of Measurement Methodology . . . . . . . . 21 128 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 129 8.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 21 130 8.2. User Data Confidentiality . . . . . . . . . . . . . . . . 21 131 8.3. Interference with the metrics . . . . . . . . . . . . . . 22 132 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 133 10. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 22 134 11. Issues (Open and Closed) . . . . . . . . . . . . . . . . . . . 22 135 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 136 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 137 13.1. Normative References . . . . . . . . . . . . . . . . . . . 24 138 13.2. Informative References . . . . . . . . . . . . . . . . . . 24 139 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 140 Intellectual Property and Copyright Statements . . . . . . . . . . 26 142 1. Contributors 144 Thus far, the following people have contributed useful ideas, 145 suggestions, or the text of sections that have been incorporated into 146 this memo: 148 - Phil Chimento 150 - Reza Fardid 152 - Roman Krzanowski 154 - Maurizio Molina 156 - Al Morton 158 - Emile Stephan 160 - Lei Liang 162 - Dave Hoeflin 164 2. Introduction 166 The IPPM framework [RFC2330] describes two forms of metric 167 composition, spatial and temporal. The new composition framework 168 [I-D.ietf-ippm-framework-compagg] expands and further qualifies these 169 original forms into three categories. This memo describes Spatial 170 Composition, one of the categories of metrics under the umbrella of 171 the composition framework. 173 Spatial composition encompasses the definition of performance metrics 174 that are applicable to a complete path, based on metrics collected on 175 various sub-paths. 177 The main purpose of this memo is to define the deterministic 178 functions that yield the complete path metrics using metrics of the 179 sub-paths. The effectiveness of such metrics is dependent on their 180 usefulness in analysis and applicability with practical measurement 181 methods. 183 The relationships may involve conjecture, and [RFC2330] lists four 184 points that the metric definitions should include: 186 o the specific conjecture applied to the metric and assumptions of 187 the statistical model of the process being measured (if any, see 188 [RFC2330] section 12), 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 and Assumptions 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 4.1.8.1. Sub-path List Differs from Complete Path 387 The measurement packets, each having source and destination addresses 388 intended for collection at edges of the sub-path, may take a 389 different specific path through the network equipment and parallel 390 links when compared to packets with the source and destination 391 addresses of the complete path. Therefore, the performance estimated 392 from the composition of sub-path measurements may differ from the 393 performance experienced by packets on the complete path. Multiple 394 measurements employing sufficient sub-path address pairs might 395 produce bounds on the extent of this error. 397 4.1.8.2. Sub-path Contains Extra Network Elements 399 Related to the case of an alternate path described above is the case 400 where elements in the measured path are unique to measurement system 401 connectivity. For example, a measurement system may use a dedicated 402 link to a LAN switch, and packets on the complete path do not 403 traverse that link. The performance of such a dedicated link would 404 be measured continuously, and its contribution to the sub-path 405 metrics SHOULD be minimized as a source of error. 407 4.1.8.3. Sub-paths Have Incomplete Coverage 409 Measurements of sub-path performance may not cover all the network 410 elements on the complete path. For example, the network exchange 411 points might be excluded unless a cooperative measurement is 412 conducted. In this example, test packets on the previous sub-path 413 are received just before the exchange point and test packets on the 414 next sub-path are injected just after the same exchange point. 415 Clearly, the set of sub-path measurements SHOULD cover all critical 416 network elements in the complete path. 418 4.1.8.4. Absence of route 420 ******************** 422 Note: this section may be expressing the point of 4.1.8.1 in 423 different words - its status is TBD. 425 ******************** 426 Sub-path destination addresses and complete path addresses do not 427 belong to the same network. Therefore routes selected to reach each 428 sub-path destinations differ from the route that would be selected to 429 reach the destination address of the complete path. Consequently 430 spatial composition may produce finite estimation of a ground true 431 metric between a source Src and a destination Dst when the route 432 between Src and Dst is undefined. 434 4.1.9. Specific cases where the conjecture might fail 436 This section is unique for each metric (see the metric-specific 437 sections). 439 4.1.10. Application of Measurement Methodology 441 The methodology: 443 SHOULD use similar packets sent and collected separately in each sub- 444 path. 446 Allows a degree of flexibility regarding test stream generation 447 (e.g., active or passive methods can produce an equivalent result, 448 but the lack of control over the source, timing and correlation of 449 passive measurements is much more challenging). 451 Poisson and/or Periodic streams are RECOMMENDED. 453 Applies to both Inter-domain and Intra-domain composition. 455 SHOULD have synchronized measurement time intervals in all sub-paths, 456 but largely overlapping intervals MAY suffice. 458 REQUIRES assumption of sub-path independence w.r.t. the metric being 459 defined/composed. 461 5. One-way Delay Composed Metrics and Statistics 463 5.1. Name: Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream 465 This metric is a necessary element of Delay Composition metrics, and 466 its definition does not formally exist elsewhere in IPPM literature. 468 5.1.1. Metric Parameters 470 See the common parameters section above. 472 5.1.2. Definition and Metric Units 474 Using the parameters above, we obtain the value of Type-P-One-way- 475 Delay singleton as per [RFC2679]. 477 For each packet [i] that has a finite One-way Delay (in other words, 478 excluding packets which have undefined one-way delay): 480 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i] = 482 FiniteDelay[i] = TstampDst - TstampSrc 484 The units of measure for this metric are time in seconds, expressed 485 in sufficiently low resolution to convey meaningful quantitative 486 information. For example, resolution of microseconds is usually 487 sufficient. 489 5.1.3. Discussion and other details 491 The "Type-P-Finite-One-way-Delay" metric permits calculation of the 492 sample mean statistic. This resolves the problem of including lost 493 packets in the sample (whose delay is undefined), and the issue with 494 the informal assignment of infinite delay to lost packets (practical 495 systems can only assign some very large value). 497 The Finite-One-way-Delay approach handles the problem of lost packets 498 by reducing the event space. We consider conditional statistics, and 499 estimate the mean one-way delay conditioned on the event that all 500 packets in the sample arrive at the destination (within the specified 501 waiting time, Tmax). This offers a way to make some valid statements 502 about one-way delay, and at the same time avoiding events with 503 undefined outcomes. This approach is derived from the treatment of 504 lost packets in [RFC3393], and is similar to [Y.1540] . 506 5.2. Name: Type-P-Finite-Composite-One-way-Delay-Mean 508 This section describes a statistic based on the Type-P-Finite-One- 509 way-Delay-Poisson/Periodic-Stream metric. 511 5.2.1. Metric Parameters 513 See the common parameters section above. 515 5.2.2. Definition and Metric Units of the Mean Statistic 517 We define 518 Type-P-Finite-One-way-Delay-Mean = 519 N 520 --- 521 1 \ 522 MeanDelay = - * > (FiniteDelay [i]) 523 N / 524 --- 525 i = 1 527 where all packets i= 1 through N have finite singleton delays. 529 The units of measure for this metric are time in seconds, expressed 530 in sufficiently low resolution to convey meaningful quantitative 531 information. For example, resolution of microseconds is usually 532 sufficient. 534 5.2.3. Discussion and other details 536 The Type-P-Finite-One-way-Delay-Mean metric requires the conditional 537 delay distribution described in section 5.1. 539 5.2.4. Composition Function: Sum of Means 541 The Type-P-Finite--Composite-One-way-Delay-Mean, or CompMeanDelay, 542 for the complete Source to Destination path can be calculated from 543 sum of the Mean Delays of all its S constituent sub-paths. 545 Then the 547 Type-P-Finite-Composite-One-way-Delay-Mean = 548 S 549 --- 550 \ 551 CompMeanDelay = > (MeanDelay [i]) 552 / 553 --- 554 i = 1 556 5.2.5. Statement of Conjecture and Assumptions 558 The mean of a sufficiently large stream of packets measured on each 559 sub-path during the interval [T, Tf] will be representative of the 560 ground truth mean of the delay distribution (and the distributions 561 themselves are sufficiently independent), such that the means may be 562 added to produce an estimate of the complete path mean delay. 564 It is assumed that the one-way delay distributions of the sub-paths 565 and the complete path are continuous. 567 5.2.6. Justification of the Composition Function 569 See the common section. 571 5.2.7. Sources of Deviation from the Ground Truth 573 See the common section. 575 5.2.8. Specific cases where the conjecture might fail 577 If any of the sub-path distributions are bimodal, then the measured 578 means may not be stable, and in this case the mean will not be a 579 particularly useful statistic when describing the delay distribution 580 of the complete path. 582 The mean may not be sufficiently robust statistic to produce a 583 reliable estimate, or to be useful even if it can be measured. 585 others... 587 5.2.9. Application of Measurement Methodology 589 The requirements of the common section apply here as well. 591 5.3. Name: Type-P-Finite-Composite-One-way-Delay-Minimum 593 This section describes is a statistic based on the Type-P-Finite-One- 594 way-Delay-Poisson/Periodic-Stream metric, and the composed metric 595 based on that statistic. 597 5.3.1. Metric Parameters 599 See the common parameters section above. 601 5.3.2. Definition and Metric Units of the Mean Statistic 603 We define 605 Type-P-Finite-One-way-Delay-Minimum = 606 = MinDelay = (FiniteDelay [j]) 608 such that for some index, j, where 1<= j <= N 609 FiniteDelay[j] <= FiniteDelay[i] for all i 611 where all packets i= 1 through N have finite singleton delays. 613 The units of measure for this metric are time in seconds, expressed 614 in sufficiently low resolution to convey meaningful quantitative 615 information. For example, resolution of microseconds is usually 616 sufficient. 618 5.3.3. Discussion and other details 620 The Type-P-Finite-One-way-Delay-Minimum metric requires the 621 conditional delay distribution described in section 5.1.3. 623 5.3.4. Composition Function: Sum of Means 625 The Type-P-Finite--Composite-One-way-Delay-Minimum, or CompMinDelay, 626 for the complete Source to Destination path can be calculated from 627 sum of the Minimum Delays of all its S constituent sub-paths. 629 Then the 631 Type-P-Finite-Composite-One-way-Delay-Minimum = 632 S 633 --- 634 \ 635 CompMinDelay = > (MinDelay [i]) 636 / 637 --- 638 i = 1 640 5.3.5. Statement of Conjecture and Assumptions 642 The minimum of a sufficiently large stream of packets measured on 643 each sub-path during the interval [T, Tf] will be representative of 644 the ground truth minimum of the delay distribution (and the 645 distributions themselves are sufficiently independent), such that the 646 minima may be added to produce an estimate of the complete path 647 minimum delay. 649 It is assumed that the one-way delay distributions of the sub-paths 650 and the complete path are continuous. 652 5.3.6. Justification of the Composition Function 654 See the common section. 656 5.3.7. Sources of Deviation from the Ground Truth 658 See the common section. 660 5.3.8. Specific cases where the conjecture might fail 662 If the routing on any of the sub-paths is not stable, then the 663 measured minimum may not be stable. In this case the composite 664 minimum would tend to produce an estimate for the complete path that 665 may be too low for the current path. 667 others??? 669 5.3.9. Application of Measurement Methodology 671 The requirements of the common section apply here as well. 673 6. Loss Metrics and Statistics 675 6.1. Type-P-Composite-One-way-Packet-Loss-Empirical-Probability 677 6.1.1. Metric Parameters: 679 Same as section 4.1.1. 681 6.1.2. Definition and Metric Units 683 Using the parameters above, we obtain the value of Type-P-One-way- 684 Packet-Loss singleton and stream as per [RFC2680]. 686 We obtain a sequence of pairs with elements as follows: 688 o TstampSrc, as above 690 o L, either zero or one, where L=1 indicates loss and L=0 indicates 691 arrival at the destination within TstampSrc + Tmax. 693 6.1.3. Discussion and other details 695 6.1.4. Statistic: Type-P-One-way-Packet-Loss-Empirical-Probability 697 Given the stream parameter M, the number of packets sent, we can 698 define the Empirical Probability of Loss Statistic (Ep), consistent 699 with Average Loss in [RFC2680], as follows: 701 Type-P-One-way-Packet-Loss-Empirical-Probability = 702 M 703 --- 704 1 \ 705 Ep = - * > (L[i]) 706 M / 707 --- 708 i = 1 710 where all packets i= 1 through M have a value for L. 712 6.1.5. Composition Function: Composition of Empirical Probabilities 714 The Type-P-One-way-Composite-Packet-Loss-Empirical-Probability, or 715 CompEp for the complete Source to Destination path can be calculated 716 by combining Ep of all its constituent sub-paths (Ep1, Ep2, Ep3, ... 717 Epn) as 719 Type-P-Composite-One-way-Packet-Loss-Empirical-Probability = 720 CompEp = 1 - {(1 - Ep1) x (1 - Ep2) x (1 - Ep3) x ... x (1 - Epn)} 722 If any Epn is undefined in a particular measurement interval, 723 possibly because a measurement system failed to report a value, then 724 any CompEp that uses sub-path n for that measurement interval is 725 undefined. 727 6.1.6. Statement of Conjecture and Assumptions 729 The empirical probability of loss calculated on a sufficiently large 730 stream of packets measured on each sub-path during the interval [T, 731 Tf] will be representative of the ground truth empirical loss 732 probability (and the probabilities themselves are sufficiently 733 independent), such that the sub-path probabilities may be combined to 734 produce an estimate of the complete path empirical loss probability. 736 6.1.7. Justification of the Composition Function 738 See the common section. 740 6.1.8. Sources of Deviation from the Ground Truth 742 See the common section. 744 6.1.9. Specific cases where the conjecture might fail 746 A concern for loss measurements combined in this way is that root 747 causes may be correlated to some degree. 749 For example, if the links of different networks follow the same 750 physical route, then a single catastrophic event like a fire in a 751 tunnel could cause an outage or congestion on remaining paths in 752 multiple networks. Here it is important to ensure that measurements 753 before the event and after the event are not combined to estimate the 754 composite performance. 756 Or, when traffic volumes rise due to the rapid spread of an email- 757 born worm, loss due to queue overflow in one network may help another 758 network to carry its traffic without loss. 760 others... 762 6.1.10. Application of Measurement Methodology 764 See the common section. 766 7. Delay Variation Metrics and Statistics 768 7.1. Name: Type-P-One-way-pdv-refmin-Poisson/Periodic-Stream 770 This packet delay variation (PDV) metric is a necessary element of 771 Composed Delay Variation metrics, and its definition does not 772 formally exist elsewhere in IPPM literature. 774 7.1.1. Metric Parameters: 776 In addition to the parameters of section 4.1.1: 778 o TstampSrc[i], the wire time of packet[i] as measured at MP(Src) 779 (measurement point at the source) 781 o TstampDst[i], the wire time of packet[i] as measured at MP(Dst), 782 assigned to packets that arrive within a "reasonable" time. 784 o B, a packet length in bits 786 o F, a selection function unambiguously defining the packets from 787 the stream that are selected for the packet-pair computation of 788 this metric. F(first packet), the first packet of the pair, MUST 789 have a valid Type-P-Finite-One-way-Delay less than Tmax (in other 790 words, excluding packets which have undefined one-way delay) and 791 MUST have been transmitted during the interval T, Tf. The second 792 packet in the pair, F(second packet) MUST be the packet with the 793 minimum valid value of Type-P-Finite-One-way-Delay for the stream, 794 in addition to the criteria for F(first packet). If multiple 795 packets have equal minimum Type-P-Finite-One-way-Delay values, 796 then the value for the earliest arriving packet SHOULD be used. 798 o MinDelay, the Type-P-Finite-One-way-Delay value for F(second 799 packet) given above. 801 o N, the number of packets received at the Destination meeting the 802 F(first packet) criteria. 804 7.1.2. Definition and Metric Units 806 Using the definition above in section 5.1.2, we obtain the value of 807 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i], the singleton 808 for each packet[i] in the stream (a.k.a. FiniteDelay[i]). 810 For each packet[i] that meets the F(first packet) criteria given 811 above: Type-P-One-way-pdv-refmin-Poisson/Periodic-Stream[i] = 813 PDV[i] = FiniteDelay[i] - MinDelay 815 where PDV[i] is in units of time in seconds, expressed in 816 sufficiently low resolution to convey meaningful quantitative 817 information. For example, resolution of microseconds is usually 818 sufficient. 820 7.1.3. Discussion and other details 822 This metric produces a sample of delay variation normalized to the 823 minimum delay of the sample. The resulting delay variation 824 distribution is independent of the sending sequence (although 825 specific FiniteDelay values within the distribution may be 826 correlated, depending on various stream parameters such as packet 827 spacing). This metric is equivalent to the IP Packet Delay Variation 828 parameter defined in [Y.1540]. 830 7.1.4. Statistics: Mean, Variance, Skewness, Quanitle 832 We define the mean PDV as follows (where all packets i= 1 through N 833 have a value for PDV[i]): 835 Type-P-One-way-pdv-refmin-Mean = MeanPDV = 836 N 837 --- 838 1 \ 839 - * > (PDV[i]) 840 N / 841 --- 842 i = 1 844 We define the variance of PDV as follows: 846 Type-P-One-way-pdv-refmin-Variance = VarPDV = 847 N 848 --- 849 1 \ 2 850 ------- > (PDV[i] - MeanPDV) 851 (N - 1) / 852 --- 853 i = 1 855 We define the skewness of PDV as follows: 857 Type-P-One-way-pdv-refmin-Skewness = SkewPDV = 858 N 859 --- 3 860 \ / \ 861 > | PDV[i]- MeanPDV | 862 / \ / 863 --- 864 i = 1 865 ----------------------------------- 866 / \ 867 | ( 3/2 ) | 868 \ (N - 1) * VarPDV / 870 We define the Quantile of the IPDVRefMin sample as the value where 871 the specified fraction of singletons is less than the given value. 873 7.1.5. Composition Functions: 875 This section gives two alternative composition functions. The 876 objective is to estimate a quantile of the complete path delay 877 variation distribution. The composed quantile will be estimated 878 using information from the sub-path delay variation distributions. 880 7.1.5.1. Approximate Convolution 882 The Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream samples from 883 each sub-path are summarized as a histogram with 1 ms bins 884 representing the one-way delay distribution. 886 From [TBP], the distribution of the sum of independent random 887 variables can be derived using the relation: 889 Type-P-Composite-One-way-pdv-refmin-quantile-a = 890 / / 891 P(X + Y + Z <= a) = | | P(X <= a-y-z) * P(Y = y) * P(Z = z) dy dz 892 / / 893 z y 894 where X, Y, and Z are random variables representing the delay 895 variation distributions of the sub-paths of the complete path (in 896 this case, there are three sub-paths), and a is the quantile of 897 interest. Note dy and dz indicate partial integration here.This 898 relation can be used to compose a quantile of interest for the 899 complete path from the sub-path delay distributions. The histograms 900 with 1 ms bins are discrete approximations of the delay 901 distributions. 903 7.1.5.2. Normal Power Approximation 905 Type-P-One-way-Composite-pdv-refmin-NPA for the complete Source to 906 Destination path can be calculated by combining statistics of all the 907 constituent sub-paths in the following process: 909 < see [Y.1541] clause 8 and Appendix X > 911 7.1.6. Statement of Conjecture and Assumptions 913 The delay distribution of a sufficiently large stream of packets 914 measured on each sub-path during the interval [T, Tf] will be 915 sufficiently stationary and the sub-path distributions themselves are 916 sufficiently independent, so that summary information describing the 917 sub-path distributions can be combined to estimate the delay 918 distribution of complete path. 920 It is assumed that the one-way delay distributions of the sub-paths 921 and the complete path are continuous. 923 7.1.7. Justification of the Composition Function 925 See the common section. 927 7.1.8. Sources of Deviation from the Ground Truth 929 In addition to the common deviations, a few additional sources exist 930 here. For one, very tight distributions with range on the order of a 931 few milliseconds are not accurately represented by a histogram with 1 932 ms bins. This size was chosen assuming an implicit requirement on 933 accuracy: errors of a few milliseconds are acceptable when assessing 934 a composed distribution quantile. 936 Also, summary statistics cannot describe the subtleties of an 937 empirical distribution exactly, especially when the distribution is 938 very different from a classical form. Any procedure that uses these 939 statistics alone may incur error. 941 7.1.9. Specific cases where the conjecture might fail 943 If the delay distributions of the sub-paths are somehow correlated, 944 then neither of these composition functions will be reliable 945 estimators of the complete path distribution. 947 In practice, sub-path delay distributions with extreme outliers have 948 increased the error of the composed metric estimate. 950 7.1.10. Application of Measurement Methodology 952 See the common section. 954 8. Security Considerations 956 8.1. Denial of Service Attacks 958 This metric requires a stream of packets sent from one host (source) 959 to another host (destination) through intervening networks. This 960 method could be abused for denial of service attacks directed at 961 destination and/or the intervening network(s). 963 Administrators of source, destination, and the intervening network(s) 964 should establish bilateral or multi-lateral agreements regarding the 965 timing, size, and frequency of collection of sample metrics. Use of 966 this method in excess of the terms agreed between the participants 967 may be cause for immediate rejection or discard of packets or other 968 escalation procedures defined between the affected parties. 970 8.2. User Data Confidentiality 972 Active use of this method generates packets for a sample, rather than 973 taking samples based on user data, and does not threaten user data 974 confidentiality. Passive measurement must restrict attention to the 975 headers of interest. Since user payloads may be temporarily stored 976 for length analysis, suitable precautions MUST be taken to keep this 977 information safe and confidential. In most cases, a hashing function 978 will produce a value suitable for payload comparisons. 980 8.3. Interference with the metrics 982 It may be possible to identify that a certain packet or stream of 983 packets is part of a sample. With that knowledge at the destination 984 and/or the intervening networks, it is possible to change the 985 processing of the packets (e.g. increasing or decreasing delay) that 986 may distort the measured performance. It may also be possible to 987 generate additional packets that appear to be part of the sample 988 metric. These additional packets are likely to perturb the results 989 of the sample measurement. 991 To discourage the kind of interference mentioned above, packet 992 interference checks, such as cryptographic hash, may be used. 994 9. IANA Considerations 996 Metrics defined in this memo will be registered in the IANA IPPM 997 METRICS REGISTRY as described in initial version of the registry 998 [RFC4148]. 1000 10. Acknowlegements 1002 A long time ago, in a galaxy far, far away (Minneapolis), Will Leland 1003 suggested the simple and elegant Type-P-Finite-One-way-Delay concept. 1004 Thanks Will. 1006 11. Issues (Open and Closed) 1008 >>>>>>>>>>>>Issue: 1010 Is Section 4.1.8.4 really describing a new error case, about 1011 Alternate Routing? Or does Section 4.1.8.1 on sub-path differences 1012 cover it all? 1014 >>>>>>>>>>>>Issue: 1016 What is the relationship between the decomposition and composition 1017 metrics? Should we put both kinds in one draft to make up a 1018 framework? The motivation of decomposition is as follows: 1020 The One-way measurement can provide result to show what the network 1021 performance between two end hosts is and whether it meets operator 1022 expectations or not. It cannot provide further information to 1023 engineers where and how to improve the performance between the source 1024 and the destination. For instance, if the network performance is not 1025 acceptable in terms of the One-way measurement, in which part of the 1026 network the engineers should put their efforts. This question can to 1027 be answered by decompose the One-way measurement to sub-path 1028 measurement to investigate the performance of different part of the 1029 network. 1031 Editor's Questions for clarification: What additional information 1032 would be provided to the decomposition process, beyond the 1033 measurement of the complete path? 1035 Is the decomposition described above intended to estimate a metric 1036 for some/all disjoint sub-paths involved in the complete path? 1038 >>>>>>>>>>>>>>>>>>RESOLUTION: treat this topic in a separate memo 1040 >>>>>>>>>>>>>>>>>>> 1042 >>>>>>>>>>>>>>>>>>>Issue 1044 Section 7 defines a new type of metric, a "combination" of metrics 1045 for one-way delay and packet loss. The purpose of this metric is to 1046 link these two primary metrics in a convenient way. 1048 Readers are asked to comment on the efficiency of the combination 1049 metric. 1051 >>>>>>>>>>>>>>>>>RESOLUTION: If a delay singleton is recorded as 1052 having "undefined" delay when the packet does not arrive within the 1053 waiting time Tmax, then this information is sufficient to determine 1054 the fraction of lost packets in the sample, and the additional loss 1055 indication of this combo is not needed. 1057 >>>>>>>>>>>>>>>>>> 1059 >>>>>>>>>>>>>>>>> Issue 1061 Can we introduce multicast metrics here, without causing too much 1062 confusion? Should the multicast version of this draft wait until the 1063 Unicast concepts are stable (or maybe appear in a separate draft)? 1065 >>>>>>>>>>>>>>>>RESOLUTION: No and Yes. 1067 12. Acknowledgements 1069 13. References 1071 13.1. Normative References 1073 [I-D.ietf-ippm-framework-compagg] 1074 Morton, A., "Framework for Metric Composition", 1075 draft-ietf-ippm-framework-compagg-06 (work in progress), 1076 February 2008. 1078 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1079 Requirement Levels", BCP 14, RFC 2119, March 1997. 1081 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1082 "Framework for IP Performance Metrics", RFC 2330, 1083 May 1998. 1085 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1086 Delay Metric for IPPM", RFC 2679, September 1999. 1088 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1089 Packet Loss Metric for IPPM", RFC 2680, September 1999. 1091 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1092 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1093 November 2002. 1095 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 1096 Registry", BCP 108, RFC 4148, August 2005. 1098 13.2. Informative References 1100 [I-D.ietf-ippm-multimetrics] 1101 Stephan, E., Liang, L., and A. Morton, "IP Performance 1102 Metrics (IPPM) for spatial and multicast", 1103 draft-ietf-ippm-multimetrics-07 (work in progress), 1104 June 2008. 1106 [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data 1107 communication service - IP packet transfer and 1108 availability performance parameters", December 2002. 1110 [Y.1541] ITU-T Recommendation Y.1541, "Network Performance 1111 Objectives for IP-based Services", February 2006. 1113 Authors' Addresses 1115 Al Morton 1116 AT&T Labs 1117 200 Laurel Avenue South 1118 Middletown,, NJ 07748 1119 USA 1121 Phone: +1 732 420 1571 1122 Fax: +1 732 368 1192 1123 Email: acmorton@att.com 1124 URI: http://home.comcast.net/~acmacm/ 1126 Stephan Emile 1127 France Telecom Division R&D 1128 2 avenue Pierre Marzin 1129 Lannion, F-22307 1130 France 1132 Phone: 1133 Fax: +33 2 96 05 18 52 1134 Email: emile.stephan@orange-ftgroup.com 1135 URI: 1137 Full Copyright Statement 1139 Copyright (C) The IETF Trust (2008). 1141 This document is subject to the rights, licenses and restrictions 1142 contained in BCP 78, and except as set forth therein, the authors 1143 retain all their rights. 1145 This document and the information contained herein are provided on an 1146 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1147 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1148 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1149 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1150 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1151 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1153 Intellectual Property 1155 The IETF takes no position regarding the validity or scope of any 1156 Intellectual Property Rights or other rights that might be claimed to 1157 pertain to the implementation or use of the technology described in 1158 this document or the extent to which any license under such rights 1159 might or might not be available; nor does it represent that it has 1160 made any independent effort to identify any such rights. Information 1161 on the procedures with respect to rights in RFC documents can be 1162 found in BCP 78 and BCP 79. 1164 Copies of IPR disclosures made to the IETF Secretariat and any 1165 assurances of licenses to be made available, or the result of an 1166 attempt made to obtain a general license or permission for the use of 1167 such proprietary rights by implementers or users of this 1168 specification can be obtained from the IETF on-line IPR repository at 1169 http://www.ietf.org/ipr. 1171 The IETF invites any interested party to bring to its attention any 1172 copyrights, patents or patent applications, or other proprietary 1173 rights that may cover technology that may be required to implement 1174 this standard. Please address the information to the IETF at 1175 ietf-ipr@ietf.org.