idnits 2.17.1 draft-ietf-ippm-spatial-composition-03.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 968. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 979. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 986. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 992. 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 (March 15, 2007) is 6252 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 744, but not defined == Missing Reference: 'Tf' is mentioned on line 744, but not defined == Missing Reference: 'TBP' is mentioned on line 717, but not defined == Unused Reference: 'RFC3432' is defined on line 910, but no explicit reference was found in the text == Unused Reference: 'I-D.stephan-ippm-multimetrics' is defined on line 919, 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) Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Morton 3 Internet-Draft AT&T Labs 4 Intended status: Standards Track E. Stephan 5 Expires: September 16, 2007 France Telecom Division R&D 6 March 15, 2007 8 Spatial Composition of Metrics 9 draft-ietf-ippm-spatial-composition-03 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 September 16, 2007. 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 . . . . . . . . . . . . . . . . . . 7 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: Sum of Means . . . . . . . . . . 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 . . . . . . . . 9 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.1.4. Mean Statistic . . . . . . . . . . . . . . . . . . . . 10 87 5.1.5. Composition Function: Sum of Means . . . . . . . . . . 11 88 5.1.6. Statement of Conjecture . . . . . . . . . . . . . . . 11 89 5.1.7. Justification of the Composition Function . . . . . . 11 90 5.1.8. Sources of Deviation from the Ground Truth . . . . . . 11 91 5.1.9. Specific cases where the conjecture might fail . . . . 11 92 5.1.10. Application of Measurement Methodology . . . . . . . . 12 93 6. Loss Metrics and Statistics . . . . . . . . . . . . . . . . . 12 94 6.1. Name: 95 Type-P-One-way-Packet-Loss-Poisson/Periodic-Stream . . . . 12 96 6.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 12 97 6.1.2. Definition and Metric Units . . . . . . . . . . . . . 12 98 6.1.3. Discussion and other details . . . . . . . . . . . . . 12 99 6.1.4. Statistic: 100 Type-P-One-way-Packet-Loss-Empirical-Probability . . . 12 101 6.1.5. Composition Function: Composition of Empirical 102 Probabilities . . . . . . . . . . . . . . . . . . . . 13 103 6.1.6. Statement of Conjecture . . . . . . . . . . . . . . . 13 104 6.1.7. Justification of the Composition Function . . . . . . 13 105 6.1.8. Sources of Deviation from the Ground Truth . . . . . . 13 106 6.1.9. Specific cases where the conjecture might fail . . . . 13 107 6.1.10. Application of Measurement Methodology . . . . . . . . 14 108 7. Delay Variation Metrics and Statistics . . . . . . . . . . . . 14 109 7.1. Name: 110 Type-P-One-way-ipdv-refmin-Poisson/Periodic-Stream . . . . 14 111 7.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 14 112 7.1.2. Definition and Metric Units . . . . . . . . . . . . . 15 113 7.1.3. Discussion and other details . . . . . . . . . . . . . 15 114 7.1.4. Statistics: Mean, Variance, Skewness, Quanitle . . . . 15 115 7.1.5. Composition Functions: . . . . . . . . . . . . . . . . 16 116 7.1.6. Statement of Conjecture . . . . . . . . . . . . . . . 17 117 7.1.7. Justification of the Composition Function . . . . . . 17 118 7.1.8. Sources of Deviation from the Ground Truth . . . . . . 17 119 7.1.9. Specific cases where the conjecture might fail . . . . 18 120 7.1.10. Application of Measurement Methodology . . . . . . . . 18 121 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 122 8.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 18 123 8.2. User Data Confidentiality . . . . . . . . . . . . . . . . 18 124 8.3. Interference with the metrics . . . . . . . . . . . . . . 18 125 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 126 10. Issues (Open and Closed) . . . . . . . . . . . . . . . . . . . 19 127 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 128 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 129 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 130 12.2. Informative References . . . . . . . . . . . . . . . . . . 21 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 132 Intellectual Property and Copyright Statements . . . . . . . . . . 23 134 1. Contributors 136 Thus far, the following people have contributed useful ideas, 137 suggestions, or the text of sections that have been incorporated into 138 this memo: 140 - Phil Chimento 142 - Reza Fardid 144 - Roman Krzanowski 146 - Maurizio Molina 148 - Al Morton 150 - Emile Stephan 152 - Lei Liang 154 - Dave Hoeflin 156 2. Introduction 158 The IPPM framework [RFC2330] describes two forms of metric 159 composition, spatial and temporal. The new composition framework 160 [I-D.ietf-ippm-framework-compagg] expands and further qualifies these 161 original forms into three categories. This memo describes Spatial 162 Composition, one of the categories of metrics under the umbrella of 163 the composition framework. 165 Spatial composition encompasses the definition of performance metrics 166 that are applicable to a complete path, based on metrics collected on 167 various sub-paths. 169 The main purpose of this memo is to define the deterministic 170 functions that yield the complete path metrics using metrics of the 171 sub-paths. The effectiveness of such metrics is dependent on their 172 usefulness in analysis and applicability with practical measurement 173 methods. 175 The relationships may involve conjecture, and [RFC2330] lists four 176 points that the metric definitions should include: 178 o the specific conjecture applied to the metric, 179 o a justification of the practical utility of the composition in 180 terms of making accurate measurements of the metric on the path, 182 o a justification of the usefulness of the composition in terms of 183 making analysis of the path using A-frame concepts more effective, 184 and 186 o an analysis of how the conjecture could be incorrect. 188 Also, [RFC2330] gives an example where a conjecture that the delay of 189 a path is very nearly the sum of the delays of the exchanges and 190 clouds of the corresponding path digest. This example is 191 particularly relevant to those who wish to assess the performance of 192 an Inter-domain path without direct measurement, and the performance 193 estimate of the complete path is related to the measured results for 194 various sub-paths instead. 196 Approximate functions between the sub-path and complete path metrics 197 are useful, with knowledge of the circumstances where the 198 relationships are/are not applicable. For example, we would not 199 expect that delay singletons from each sub-path would sum to produce 200 an accurate estimate of a delay singleton for the complete path 201 (unless all the delays were essentially constant - very unlikely). 202 However, other delay statistics (based on a reasonable sample size) 203 may have a sufficiently large set of circumstances where they are 204 applicable. 206 2.1. Motivation 208 One-way metrics defined in other IPPM RFCs all assume that the 209 measurement can be practically carried out between the source and the 210 destination of the interest. Sometimes there are reasons that the 211 measurement can not be executed from the source to the destination. 212 For instance, the measurement path may cross several independent 213 domains that have conflicting policies, measurement tools and 214 methods, and measurement time assignment. The solution then may be 215 the composition of several sub-path measurements. This means each 216 domain performs the One-way measurement on a sub path between two 217 nodes that are involved in the complete path following its own 218 policy, using its own measurement tools and methods, and using its 219 own measurement timing. Under the appropriate conditions, one can 220 combine the sub-path One-way metric results to estimate the complete 221 path One-way measurement metric with some degree of accuracy. 223 3. Scope and Application 224 3.1. Scope of work 226 For the primary IPPM metrics of Loss, Delay, and Delay Variation, 227 this memo gives a set of metrics for that can be composed from the 228 same or similar sub-path metrics. This means that the composition 229 function may utilize: 231 o the same metric for each sub-path; 233 o multiple metrics for each sub-path (possibly one that is the same 234 as the complete path metric); 236 o a single sub-path metrics that is different from the complete path 237 metric; 239 o different measurement techniques like active and passive 240 (recognizing that PSAMP WG will define capabilities to sample 241 packets to support measurement). 243 3.2. Application 245 The new composition framework [I-D.ietf-ippm-framework-compagg] 246 requires the specification of the applicable circumstances for each 247 metric. In particular, the application of Spatial Composition 248 metrics are addressed as to whether the metric: 250 Requires the same test packets to traverse all sub-paths, or may use 251 similar packets sent and collected separately in each sub-path. 253 Requires homogeneity of measurement methodologies, or can allow a 254 degree of flexibility (e.g., active or passive methods produce the 255 "same" metric). Also, the applicable sending streams will be 256 specified, such as Poisson, Periodic, or both. 258 Needs information or access that will only be available within an 259 operator's domain, or is applicable to Inter-domain composition. 261 Requires synchronized measurement time intervals in all sub-paths, or 262 largely overlapping, or no timing requirements. 264 Requires assumption of sub-path independence w.r.t. the metric being 265 defined/composed, or other assumptions. 267 Has known sources of inaccuracy/error, and identifies the sources. 269 3.3. Incomplete Information 271 In practice, when measurements cannot be initiated on a sub-path (and 272 perhaps the measurement system gives up during the test interval), 273 then there will not be a value for the sub-path reported, and the 274 result SHOULD be recorded as "undefined". This case should be 275 distinguished from the case where the measurement system continued to 276 send packets throughout the test interval, but all were declared 277 lost. 279 When a composed metric requires measurements from sub paths A, B, and 280 C, and one or more of the sub-path results are undefined, then the 281 composed metric SHOULD also be recorded as undefined. 283 4. Common Specifications for Composed Metrics 285 To reduce the redundant information presented in the detailed metrics 286 sections that follow, this section presents the specifications that 287 are common to two or more metrics. The section is organized using 288 the same subsections as the individual metrics, to simplify 289 comparisons. 291 4.1. Name: Type-P 293 All metrics use the Type-P convention as described in [RFC2330]. The 294 rest of the name is unique to each metric. 296 4.1.1. Metric Parameters 298 o Src, the IP address of a host 300 o Dst, the IP address of a host 302 o T, a time (start of test interval) 304 o Tf, a time (end of test interval) 306 o lambda, a rate in reciprocal seconds (for Poisson Streams) 308 o incT, the nominal duration of inter-packet interval, first bit to 309 first bit (for Periodic Streams) 311 o T0, a time that MUST be selected at random from the interval [T, 312 T+dT] to start generating packets and taking measurements (for 313 Periodic Streams) 315 o TstampSrc, the wire time of the packet as measured at MP(Src) 317 o TstampDst, the wire time of the packet as measured at MP(Dst), 318 assigned to packets that arrive within a "reasonable" time. 320 o Tmax, a maximum waiting time for packets at the destination, set 321 sufficiently long to disambiguate packets with long delays from 322 packets that are discarded (lost), thus the distribution of delay 323 is not truncated. 325 o M, the total number of packets sent between T0 and Tf 327 o N, the total number of packets received at Dst (sent between T0 328 and Tf) 330 o S, the number of sub-paths involved in the complete Src-Dst path 332 4.1.2. Definition and Metric Units 334 This section is unique for every metric. 336 4.1.3. Discussion and other details 338 This section is unique for every metric. 340 4.1.4. Statistic: 342 This section is unique for every metric. 344 4.1.5. Composition Function: Sum of Means 346 This section is unique for every metric. 348 4.1.6. Statement of Conjecture 350 This section is unique for each metric. 352 4.1.7. Justification of the Composition Function 354 It is sometimes impractical to conduct active measurements between 355 every Src-Dst pair. For example, it may not be possible to collect 356 the desired sample size in each test interval when access link speed 357 is limited, because of the potential for measurement traffic to 358 degrade the user traffic performance. The conditions on a low-speed 359 access link may be understood well-enough to permit use of a small 360 sample size/rate, while a larger sample size/rate may be used on 361 other sub-paths. 363 Also, since measurement operations have a real monetary cost, there 364 is value in re-using measurements where they are applicable, rather 365 than launching new measurements for every possible source-destination 366 pair. 368 4.1.8. Sources of Deviation from the Ground Truth 370 The measurement packets, each having source and destination addresses 371 intended for collection at edges of the sub-path, may take a 372 different specific path through the network equipment and parallel 373 exchanges than packets with the source and destination addresses of 374 the complete path. Therefore, the sub-path measurements may differ 375 from the performance experienced by packets on the complete path. 376 Multiple measurements employing sufficient sub-path address pairs 377 might produce bounds on the extent of this error. 379 others... 381 4.1.9. Specific cases where the conjecture might fail 383 This section is unique for each metric. 385 4.1.10. Application of Measurement Methodology 387 The methodology: 389 SHOULD use similar packets sent and collected separately in each sub- 390 path. 392 Allows a degree of flexibility (e.g., active or passive methods can 393 produce the "same" metric, but timing and correlation of passive 394 measurements is much more challenging). 396 Poisson and/or Periodic streams are RECOMMENDED. 398 Applicable to both Inter-domain and Intra-domain composition. 400 SHOULD have synchronized measurement time intervals in all sub-paths, 401 but largely overlapping intervals MAY suffice. 403 REQUIRES assumption of sub-path independence w.r.t. the metric being 404 defined/composed. 406 5. One-way Delay Composed Metrics and Statistics 407 5.1. Name: Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream 409 This metric is a necessary element of Delay Composition metrics, and 410 its definition does not formally exist elsewhere in IPPM literature. 412 5.1.1. Metric Parameters 414 See the common parameters section above. 416 5.1.2. Definition and Metric Units 418 Using the parameters above, we obtain the value of Type-P-One-way- 419 Delay singleton as per [RFC2679]. 421 For each packet [i] that has a finite One-way Delay (in other words, 422 excluding packets which have undefined one-way delay): 424 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i] = 426 FiniteDelay[i] = TstampDst - TstampSrc 428 5.1.3. Discussion and other details 430 The "Type-P-Finite-One-way-Delay" metric permits calculation of the 431 sample mean statistic. This resolves the problem of including lost 432 packets in the sample (whose delay is undefined), and the issue with 433 the informal assignment of infinite delay to lost packets (practical 434 systems can only assign some very large value). 436 The Finite-One-way-Delay approach handles the problem of lost packets 437 by reducing the event space. We consider conditional statistics, and 438 estimate the mean one-way delay conditioned on the event that all 439 packets in the sample arrive at the destination (within the specified 440 waiting time, Tmax). This offers a way to make some valid statements 441 about one-way delay, and at the same time avoiding events with 442 undefined outcomes. This approach is derived from the treatment of 443 lost packets in [RFC3393], and is similar to [Y.1540] . 445 5.1.4. Mean Statistic 447 We define 448 Type-P-Finite-One-way-Delay-Mean = 449 N 450 --- 451 1 \ 452 - * > (FiniteDelay [i]) 453 N / 454 --- 455 i = 1 457 where all packets i= 1 through N have finite singleton delays. 459 5.1.5. Composition Function: Sum of Means 461 The Type-P-Finite--Composite-One-way-Delay-Mean, or CompMeanDelay for 462 the complete Source to Destination path can be calculated from sum of 463 the Mean Delays of all its S constituent sub-paths. 465 Then the 467 Type-P-Finite-Composite-One-way-Delay-Mean = 468 S 469 --- 470 \ 471 CompMeanDelay = > (MeanDelay [i]) 472 / 473 --- 474 i = 1 476 5.1.6. Statement of Conjecture 478 The mean of a sufficiently large stream of packets measured on each 479 sub-path during the interval [T, Tf] will be representative of the 480 true mean of the delay distribution (and the distributions themselves 481 are sufficiently independent), such that the means may be added to 482 produce an estimate of the complete path mean delay. 484 5.1.7. Justification of the Composition Function 486 See the common section. 488 5.1.8. Sources of Deviation from the Ground Truth 490 See the common section. 492 5.1.9. Specific cases where the conjecture might fail 494 If any of the sub-path distributions are bimodal, then the measured 495 means may not be stable, and in this case the mean will not be a 496 particularly useful statistic when describing the delay distribution 497 of the complete path. 499 The mean may not be sufficiently robust statistic to produce a 500 reliable estimate, or to be useful even if it can be measured. 502 others... 504 5.1.10. Application of Measurement Methodology 506 The requirements of the common section apply here as well. 508 6. Loss Metrics and Statistics 510 6.1. Name: Type-P-One-way-Packet-Loss-Poisson/Periodic-Stream 512 6.1.1. Metric Parameters: 514 Same as section 4.1.1. 516 6.1.2. Definition and Metric Units 518 Using the parameters above, we obtain the value of Type-P-One-way- 519 Packet-Loss singleton and stream as per [RFC2680]. 521 We obtain a sequence of pairs with elements as follows: 523 o TstampSrc, as above 525 o L, either zero or one, where L=1 indicates loss and L=0 indicates 526 arrival at the destination within TstampSrc + Tmax. 528 6.1.3. Discussion and other details 530 6.1.4. Statistic: Type-P-One-way-Packet-Loss-Empirical-Probability 532 Given the stream parameter M, the number of packets sent, we can 533 define the Empirical Probability of Loss Statistic (Ep), consistent 534 with Average Loss in [RFC2680], as follows: 536 Type-P-One-way-Packet-Loss-Empirical-Probability = 537 M 538 --- 539 1 \ 540 Ep = - * > (L[i]) 541 M / 542 --- 543 i = 1 545 where all packets i= 1 through M have a value for L. 547 6.1.5. Composition Function: Composition of Empirical Probabilities 549 The Type-P-One-way-Composite-Packet-Loss-Empirical-Probability, or 550 CompEp for the complete Source to Destination path can be calculated 551 by combining Ep of all its constituent sub-paths (Ep1, Ep2, Ep3, ... 552 Epn) as 554 Type-P-One-way-Composite-Packet-Loss-Empirical-Probability = 555 CompEp = 1 ? {(1 - Ep1) x (1 ? Ep2) x (1 ? Ep3) x ... x (1 ? Epn)} 557 If any EpN is undefined in a particular measurement interval, 558 possibly because a measurement system failed to report a value, then 559 any CompEp that uses sub-path N for that measurement interval is 560 undefined. 562 6.1.6. Statement of Conjecture 564 The empirical probability of loss calculated on a sufficiently large 565 stream of packets measured on each sub-path during the interval [T, 566 Tf] will be representative of the true loss probability (and the 567 probabilities themselves are sufficiently independent), such that the 568 sub-path probabilities may be combined to produce an estimate of the 569 complete path loss probability. 571 6.1.7. Justification of the Composition Function 573 See the common section. 575 6.1.8. Sources of Deviation from the Ground Truth 577 See the common section. 579 6.1.9. Specific cases where the conjecture might fail 581 A concern for loss measurements combined in this way is that root 582 causes may be correlated to some degree. 584 For example, if the links of different networks follow the same 585 physical route, then a single event like a tunnel fire could cause an 586 outage or congestion on remaining paths in multiple networks. Here 587 it is important to ensure that measurements before the event and 588 after the event are not combined to estimate the composite 589 performance. 591 Or, when traffic volumes rise due to the rapid spread of an email- 592 born worm, loss due to queue overflow in one network may help another 593 network to carry its traffic without loss. 595 others... 597 6.1.10. Application of Measurement Methodology 599 See the common section. 601 7. Delay Variation Metrics and Statistics 603 7.1. Name: Type-P-One-way-ipdv-refmin-Poisson/Periodic-Stream 605 This metric is a necessary element of Composed Delay Variation 606 metrics, and its definition does not formally exist elsewhere in IPPM 607 literature. 609 7.1.1. Metric Parameters: 611 In addition to the parameters of section 4.1.1: 613 o TstampSrc[i], the wire time of packet[i] as measured at MP(Src) 615 o TstampDst[i], the wire time of packet[i] as measured at MP(Dst), 616 assigned to packets that arrive within a "reasonable" time. 618 o B, a packet length in bits 620 o F, a selection function unambiguously defining the packets from 621 the stream that are selected for the packet-pair computation of 622 this metric. F(first packet), the first packet of the pair, MUST 623 have a valid Type-P-Finite-One-way-Delay less than Tmax (in other 624 words, excluding packets which have undefined, or infinite one-way 625 delay) and MUST have been transmitted during the interval T, Tf. 626 The second packet in the pair MUST be the packet with the minimum 627 valid value of Type-P-Finite-One-way-Delay for the stream, in 628 addition to the criteria for F(first packet). If multiple packets 629 have equal minimum Type-P-Finite-One-way-Delay values, then the 630 value for the earliest arriving packet SHOULD be used. 632 o MinDelay, the Type-P-Finite-One-way-Delay value for F(second 633 packet) given above. 635 o N, the number of packets received at the Destination meeting the 636 F(first packet) criteria. 638 7.1.2. Definition and Metric Units 640 Using the definition above in section 4.1.2, we obtain the value of 641 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i], the singleton 642 for each packet[i] in the stream (a.k.a. FiniteDelay[i]). 644 For each packet[i] that meets the F(first packet) criteria given 645 above: Type-P-One-way-ipdv-refmin-Poisson/Periodic-Stream[i] = 647 IPDVRefMin[i] = FiniteDelay[i] - MinDelay 649 where IPDVRefMin[i] is in units of time (seconds, milliseconds). 651 7.1.3. Discussion and other details 653 This metric produces a sample of delay variation normalized to the 654 minimum delay of the sample. The resulting delay variation 655 distribution is independent of the sending sequence (although 656 specific FiniteDelay values within the distribution may be 657 correlated, depending on various stream parameters such as packet 658 spacing). This metric is equivalent to the IP Packet Delay Variation 659 parameter defined in [Y.1540]. 661 7.1.4. Statistics: Mean, Variance, Skewness, Quanitle 663 We define the mean IPDVRefMin as follows (where all packets i= 1 664 through N have a value for IPDVRefMin): 666 Type-P-One-way-ipdv-refmin-Mean = MeanIPDVRefMin = 667 N 668 --- 669 1 \ 670 - * > (IPDVRefMin [i]) 671 N / 672 --- 673 i = 1 675 We define the variance of IPDVRefMin as follows: 677 Type-P-One-way-ipdv-refmin-Variance = VarIPDVRefMin = 678 N 679 --- 680 1 \ 2 681 ------- > (IPDVRefMin [i] - MeanIPDVRefMin) 682 (N - 1) / 683 --- 684 i = 1 686 We define the skewness of IPDVRefMin as follows: 688 Type-P-One-way-ipdv-refmin-Skewness = SkewIPDVRefMin = 689 N 690 --- 3 691 \ / \ 692 > | IPDVRefMin[i]- MeanIPDVRefMin | 693 / \ / 694 --- 695 i = 1 696 ------------------------------------------- 697 / \ 698 | ( 3/2 ) | 699 \ (N - 1) * VarIPDVRefMin / 701 We define the Quantile of the IPDVRefMin sample as the value where 702 the specified fraction of points is less than the given value. 704 7.1.5. Composition Functions: 706 This section gives two alternative composition functions. The 707 objective is to estimate a quantile of the complete path delay 708 variation distribution. The composed quantile will be estimated 709 using information from the sub-path delay variation distributions. 711 7.1.5.1. Approximate Convolution 713 The Type-P-One-way-Delay-Poisson/Periodic-Stream samples from each 714 sub-path are summarized as a histogram with 1 ms bins representing 715 the one-way delay distribution. 717 From [TBP], the distribution of the sum of independent random 718 variables can be derived using the relation: 720 Type-P-One-way-Composite-ipdv-refmin-quantile-a = 721 / / 722 P(X + Y + Z <= a) = | | P(X <= a-y-z) * P(Y = y) * P(Z = z) dy dz 723 / / 724 z y 725 where X, Y, and Z are random variables representing the delay 726 variation distributions of the sub-paths of the complete path, and a 727 is the quantile of interest. Note dy and dz indicate partial 728 integration here.This relation can be used to compose a quantile of 729 interest for the complete path from the sub-path delay distributions. 730 The histograms with 1 ms bins are discrete approximations of the 731 delay distributions. 733 7.1.5.2. new section 735 Type-P-One-way-Composite-ipdv-refmin- for the complete 736 Source to Destination path can be calculated by combining statistics 737 of all the constituent sub-paths in the following process: 739 < see [Y.1541] section 8 > 741 7.1.6. Statement of Conjecture 743 The delay distribution of a sufficiently large stream of packets 744 measured on each sub-path during the interval [T, Tf] will be 745 sufficiently stationary and the sub-path distributions themselves are 746 sufficiently independent, so that summary information describing the 747 sub-path distributions can be combined to estimate the delay 748 distribution of complete path. 750 7.1.7. Justification of the Composition Function 752 See the common section. 754 7.1.8. Sources of Deviation from the Ground Truth 756 In addition to the common deviations, the a few additional sources 757 exist here. For one, very tight distributions with range on the 758 order of a few milliseconds are not accurately represented by a 759 histogram with 1 ms bins. This size was chosen assuming an implicit 760 requirement on accuracy: errors of a few milliseconds are acceptable 761 when assessing a composed distribution quantile. 763 Also, summary statistics cannot describe the subtleties of an 764 empirical distribution exactly, especially when the distribution is 765 very different from a classical form. Any procedure that uses these 766 statistics alone may incur error. 768 7.1.9. Specific cases where the conjecture might fail 770 If the delay distributions of the sub-paths are somehow correlated, 771 then neither of these composition functions will be reliable 772 estimators of the complete path distribution. 774 In practice, sub-path delay distributions with extreme outliers have 775 increased the error of the composed metric estimate. 777 7.1.10. Application of Measurement Methodology 779 See the common section. 781 8. Security Considerations 783 8.1. Denial of Service Attacks 785 This metric requires a stream of packets sent from one host (source) 786 to another host (destination) through intervening networks. This 787 method could be abused for denial of service attacks directed at 788 destination and/or the intervening network(s). 790 Administrators of source, destination, and the intervening network(s) 791 should establish bilateral or multi-lateral agreements regarding the 792 timing, size, and frequency of collection of sample metrics. Use of 793 this method in excess of the terms agreed between the participants 794 may be cause for immediate rejection or discard of packets or other 795 escalation procedures defined between the affected parties. 797 8.2. User Data Confidentiality 799 Active use of this method generates packets for a sample, rather than 800 taking samples based on user data, and does not threaten user data 801 confidentiality. Passive measurement must restrict attention to the 802 headers of interest. Since user payloads may be temporarily stored 803 for length analysis, suitable precautions MUST be taken to keep this 804 information safe and confidential. In most cases, a hashing function 805 will produce a value suitable for payload comparisons. 807 8.3. Interference with the metrics 809 It may be possible to identify that a certain packet or stream of 810 packets is part of a sample. With that knowledge at the destination 811 and/or the intervening networks, it is possible to change the 812 processing of the packets (e.g. increasing or decreasing delay) that 813 may distort the measured performance. It may also be possible to 814 generate additional packets that appear to be part of the sample 815 metric. These additional packets are likely to perturb the results 816 of the sample measurement. 818 To discourage the kind of interference mentioned above, packet 819 interference checks, such as cryptographic hash, may be used. 821 9. IANA Considerations 823 Metrics defined in this memo will be registered in the IANA IPPM 824 METRICS REGISTRY as described in initial version of the registry 825 [RFC4148]. 827 10. Issues (Open and Closed) 829 >>>>>>>>>>>>Issue: 831 What is the relationship between the decomposition and composition 832 metrics? Should we put both kinds in one draft to make up a 833 framework? The motivation of decomposition is as follows: 835 The One-way measurement can provide result to show what the network 836 performance between two end hosts is and whether it meets operator 837 expectations or not. It cannot provide further information to 838 engineers where and how to improve the performance between the source 839 and the destination. For instance, if the network performance is not 840 acceptable in terms of the One-way measurement, in which part of the 841 network the engineers should put their efforts. This question can to 842 be answered by decompose the One-way measurement to sub-path 843 measurement to investigate the performance of different part of the 844 network. 846 Editor's Questions for clarification: What additional information 847 would be provided to the decomposition process, beyond the 848 measurement of the complete path? 850 Is the decomposition described above intended to estimate a metric 851 for some/all disjoint sub-paths involved in the complete path? 853 >>>>>>>>>>>>>>>>>>RESOLUTION: treat this topic in a separate memo 855 >>>>>>>>>>>>>>>>>>> 857 >>>>>>>>>>>>>>>>>>>Issue 859 Section 7 defines a new type of metric, a "combination" of metrics 860 for one-way delay and packet loss. The purpose of this metric is to 861 link these two primary metrics in a convenient way. 863 Readers are asked to comment on the efficiency of the combination 864 metric. 866 >>>>>>>>>>>>>>>>>RESOLUTION: If a delay singleton is recorded as 867 having "undefined" delay when the packet does not arrive within the 868 waiting time Tmax, then this information is sufficient to determine 869 the fraction of lost packets in the sample, and the additional loss 870 indication of this combo is not needed. 872 >>>>>>>>>>>>>>>>>> 874 >>>>>>>>>>>>>>>>> Issue 876 Can we introduce multicast metrics here, without causing too much 877 confusion? Should the multicast version of this draft wait until the 878 Unicast concepts are stable (or maybe appear in a separate draft)? 880 >>>>>>>>>>>>>>>>RESOLUTION: No and Yes. 882 11. Acknowledgements 884 12. References 886 12.1. Normative References 888 [I-D.ietf-ippm-framework-compagg] 889 Morton, A. and S. Berghe, "Framework for Metric 890 Composition", draft-ietf-ippm-framework-compagg-03 (work 891 in progress), March 2007. 893 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 894 Requirement Levels", BCP 14, RFC 2119, March 1997. 896 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 897 "Framework for IP Performance Metrics", RFC 2330, 898 May 1998. 900 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 901 Delay Metric for IPPM", RFC 2679, September 1999. 903 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 904 Packet Loss Metric for IPPM", RFC 2680, September 1999. 906 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 907 Metric for IP Performance Metrics (IPPM)", RFC 3393, 908 November 2002. 910 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 911 performance measurement with periodic streams", RFC 3432, 912 November 2002. 914 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 915 Registry", BCP 108, RFC 4148, August 2005. 917 12.2. Informative References 919 [I-D.stephan-ippm-multimetrics] 920 Stephan, E., "IP Performance Metrics (IPPM) for spatial 921 and multicast", draft-stephan-ippm-multimetrics-02 (work 922 in progress), October 2005. 924 [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data 925 communication service - IP packet transfer and 926 availability performance parameters", December 2002. 928 [Y.1541] ITU-T Recommendation Y.1540, "Network Performance 929 Objectives for IP-based Services", February 2006. 931 Authors' Addresses 933 Al Morton 934 AT&T Labs 935 200 Laurel Avenue South 936 Middletown,, NJ 07748 937 USA 939 Phone: +1 732 420 1571 940 Fax: +1 732 368 1192 941 Email: acmorton@att.com 942 URI: http://home.comcast.net/~acmacm/ 943 Emile Stephan 944 France Telecom Division R&D 945 2 avenue Pierre Marzin 946 Lannion, F-22307 947 France 949 Phone: 950 Fax: +33 2 96 05 18 52 951 Email: emile.stephan@orange-ftgroup.com 952 URI: 954 Full Copyright Statement 956 Copyright (C) The IETF Trust (2007). 958 This document is subject to the rights, licenses and restrictions 959 contained in BCP 78, and except as set forth therein, the authors 960 retain all their rights. 962 This document and the information contained herein are provided on an 963 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 964 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 965 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 966 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 967 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 968 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 970 Intellectual Property 972 The IETF takes no position regarding the validity or scope of any 973 Intellectual Property Rights or other rights that might be claimed to 974 pertain to the implementation or use of the technology described in 975 this document or the extent to which any license under such rights 976 might or might not be available; nor does it represent that it has 977 made any independent effort to identify any such rights. Information 978 on the procedures with respect to rights in RFC documents can be 979 found in BCP 78 and BCP 79. 981 Copies of IPR disclosures made to the IETF Secretariat and any 982 assurances of licenses to be made available, or the result of an 983 attempt made to obtain a general license or permission for the use of 984 such proprietary rights by implementers or users of this 985 specification can be obtained from the IETF on-line IPR repository at 986 http://www.ietf.org/ipr. 988 The IETF invites any interested party to bring to its attention any 989 copyrights, patents or patent applications, or other proprietary 990 rights that may cover technology that may be required to implement 991 this standard. Please address the information to the IETF at 992 ietf-ipr@ietf.org. 994 Acknowledgment 996 Funding for the RFC Editor function is provided by the IETF 997 Administrative Support Activity (IASA).