idnits 2.17.1 draft-ietf-ippm-spatial-composition-00.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 on line 1033. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1010. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1017. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1023. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 26, 2006) is 6633 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 398, but not defined == Missing Reference: 'Tf' is mentioned on line 398, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FRMWK' ** 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: 7 errors (**), 0 flaws (~~), 4 warnings (==), 8 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 Expires: August 30, 2006 E. Stephan 5 France Telecom Division R&D 6 February 26, 2006 8 Spatial Composition of Metrics 9 draft-ietf-ippm-spatial-composition-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 30, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 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, Application, and Terminology . . . . . . . . . . . . . 5 65 3.1. Scope of work . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2. Application . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 68 4. One-way Delay Composition Metrics and Statistics . . . . . . . 7 69 4.1. Name: 70 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream . . . 7 71 4.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 7 72 4.1.2. Definition and Metric Units . . . . . . . . . . . . . 8 73 4.1.3. Discussion and other details . . . . . . . . . . . . . 8 74 4.1.4. Mean Statistic . . . . . . . . . . . . . . . . . . . . 8 75 4.1.5. Composition Relationship: Sum of Means . . . . . . . . 9 76 4.1.6. Statement of Conjecture . . . . . . . . . . . . . . . 9 77 4.1.7. Justification of Composite Relationship . . . . . . . 9 78 4.1.8. Sources of Error . . . . . . . . . . . . . . . . . . . 10 79 4.1.9. Specific cases where the conjecture might fail . . . . 10 80 4.1.10. Application of Measurement Methodology . . . . . . . . 10 81 5. Loss Metrics and Statistics . . . . . . . . . . . . . . . . . 11 82 5.1. Name: 83 Type-P-One-way-Packet-Loss-Poisson/Periodic-Stream . . . . 11 84 5.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 11 85 5.1.2. Definition and Metric Units . . . . . . . . . . . . . 11 86 5.1.3. Discussion and other details . . . . . . . . . . . . . 11 87 5.1.4. Statistic: 88 Type-P-One-way-Packet-Loss-Empirical-Probability . . . 11 89 5.1.5. Composition Relationship: Composition of Empirical 90 Probabilities . . . . . . . . . . . . . . . . . . . . 11 91 5.1.6. Statement of Conjecture . . . . . . . . . . . . . . . 12 92 5.1.7. Justification of Composite Relationship . . . . . . . 12 93 5.1.8. Sources of Error . . . . . . . . . . . . . . . . . . . 12 94 5.1.9. Specific cases where the conjecture might fail . . . . 12 95 5.1.10. Application of Measurement Methodology . . . . . . . . 13 96 6. Delay Variation Metrics and Statistics . . . . . . . . . . . . 13 97 6.1. Name: 98 Type-P-One-way-ipdv-refmin-Poisson/Periodic-Stream . . . . 13 99 6.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 13 100 6.1.2. Definition and Metric Units . . . . . . . . . . . . . 14 101 6.1.3. Discussion and other details . . . . . . . . . . . . . 14 102 6.1.4. Statistics: Mean, Variance, Skewness, Quanitle . . . . 14 103 6.1.5. Composition Relationships: . . . . . . . . . . . . . . 15 104 6.1.6. Statement of Conjecture . . . . . . . . . . . . . . . 16 105 6.1.7. Justification of Composite Relationship . . . . . . . 16 106 6.1.8. Sources of Error . . . . . . . . . . . . . . . . . . . 16 107 6.1.9. Specific cases where the conjecture might fail . . . . 16 108 6.1.10. Application of Measurement Methodology . . . . . . . . 16 109 7. Other Metrics and Statistics: One-way Combined Metric . . . . 16 110 7.1. Metric Name: . . . . . . . . . . . . . . . . . . . . . . . 16 111 7.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 16 112 7.1.2. Definition and Metric Units . . . . . . . . . . . . . 16 113 7.1.3. Discussion and other details . . . . . . . . . . . . . 17 114 7.1.4. Type-P-One-way-Combo-subpathes-stream . . . . . . . . 17 115 7.1.5. Type-P-One-way-composition . . . . . . . . . . . . . . 17 116 7.1.6. Type-P-One-way-composition . . . . . . . . . . . . . . 17 117 7.1.7. Statement of Conjecture . . . . . . . . . . . . . . . 18 118 7.1.8. Justification of Composite Relationship . . . . . . . 18 119 7.1.9. Sources of Error . . . . . . . . . . . . . . . . . . . 18 120 7.1.10. Specific cases where the conjecture might fail . . . . 18 121 7.1.11. Application of Measurement Methodology . . . . . . . . 18 122 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 123 8.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 19 124 8.2. User Data Confidentiality . . . . . . . . . . . . . . . . 19 125 8.3. Interference with the metrics . . . . . . . . . . . . . . 19 126 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 127 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 128 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 20 129 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 130 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 131 13.1. Normative References . . . . . . . . . . . . . . . . . . . 21 132 13.2. Informative References . . . . . . . . . . . . . . . . . . 21 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 134 Intellectual Property and Copyright Statements . . . . . . . . . . 23 136 1. Contributors 138 Thus far, the following people have contributed useful ideas, 139 suggestions, or the text of sections that have been incorporated into 140 this memo: 142 - Phil Chimento 144 - Reza Fardid 146 - Roman Krzanowski 148 - Maurizio Molina 150 - Al Morton 152 - Emile Stephan 154 - Lei Liang 156 2. Introduction 158 The IPPM framework RFC 2330 [RFC2330] describes two forms of metric 159 composition, spatial and temporal. The new composition framework 160 [FRMWK] expands and further qualifies these original forms into three 161 categories. This memo describes Spatial Composition, one of the 162 categories of metrics under the umbrella of the composition 163 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 purpose of this memo is to define relationships that yield the 170 complete path metrics using metrics of the sub-paths. The 171 effectiveness of such metrics is dependent on their usefulness in 172 analysis and applicability with practical measurement methods. 174 The relationships may involve conjecture, and [RFC2330] lists four 175 points that the metric definitions should include: 177 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 RFC 2330 also gives an example where a conjecture that the delay of a 189 path is very nearly the sum of the delays of the exchanges and clouds 190 of the corresponding path digest. This example is particularly 191 relevant to those who wish to assess the performance of an Inter- 192 domain path without direct measurement, and the performance estimate 193 of the complete path is related to the measured results for various 194 sub-paths instead. 196 Approximate relationships between the sub-path and complete path 197 metrics 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 slot assignment. The solution then may 215 be the composition of several sub-path measurements. That 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 within its 219 own measurement time slot. 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 accuracy. 223 3. Scope, Application, and Terminology 225 3.1. Scope of work 227 For the primary IPPM metrics (currently Loss, Delay, and Delay 228 Variation), this memo gives a set of complete path metrics that can 229 be composed from the same or similar sub-path metrics. This means 230 that the complete path metric may be composed from: 232 o the same metric for each sub-path; 234 o multiple metrics for each sub-path (possibly one that is the same 235 as the complete path metric); 237 o a single sub-path metrics that is different from the complete path 238 metric; 240 o different measurement techniques like active and passive 241 (recognizing that PSAMP WG will define capabilities to sample 242 packets to support measurement). 244 3.2. Application 246 The new composition framework [FRMWK] requires the specification of 247 the applicable circumstances for each metric. In particular, the 248 application of Spatial Composition metrics are addressed as to 249 whether the metric: 251 Requires the same test packets to traverse all sub-paths, or may use 252 similar packets sent and collected separately in each sub-path. 254 Requires homogeneity of measurement methodologies, or can allow a 255 degree of flexibility (e.g., active or passive methods produce the 256 "same" metric). Also, the applicable sending streams will be 257 specified, such as Poisson, Periodic, or both. 259 Needs information or access that will only be available within an 260 operator's domain, or is applicable to Inter-domain composition. 262 Requires synchronized measurement time intervals in all sub-paths, or 263 largely overlapping, or no timing requirements. 265 Requires assumption of sub-path independence w.r.t. the metric being 266 defined/composed, or other assumptions. 268 Has known sources of inaccuracy/error, and identifies the sources. 270 3.3. Terminology 272 This section defines the terminology applicable to Spatial 273 Composition metrics. 275 Measurement Points: 277 279 Complete path: 281 The complete path is the true path that a packet would follow as it 282 traverses from the packet's Source to its Destination. 284 Complete path metric: 286 The complete path metric is the Source to Destination metric that a 287 composed metric is estimating. A complete path metric represents the 288 ground-truth for a composed metric. 290 Composite Metric (or Composed Metric): 292 A composite metric is type of metric that is derived from other 293 metrics principally by applying a composition relationship. 295 Composition Relationship: 297 A composition relationship is a deterministic process applied to Sub- 298 path metrics to derive another metric (such as a Composite metric). 300 Sub-path: 302 A Sub-path is a portion of the complete path where at least the Sub- 303 path Source and Destination hosts are constituents of the complete 304 path. We say that this sub-path is "involved" in the complete path. 306 Sub-path metrics: 308 A sub-path path metric is an element of the process to derive a 309 Composite metric, quantifying some aspect of the performance a 310 particular sub-path from its Source to Destination. 312 4. One-way Delay Composition Metrics and Statistics 314 4.1. Name: Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream 316 This metric is a necessary element of Delay Composition metrics, and 317 its definition does not formally exist elsewhere in IPPM literature. 319 4.1.1. Metric Parameters: 321 o Src, the IP address of a host + Dst, the IP address of a host 322 o T, a time (start of test interval) 324 o Tf, a time (end of test interval) 326 o lambda, a rate in reciprocal seconds (for Poisson Streams) 328 o incT, the nominal duration of inter-packet interval, first bit to 329 first bit (for Periodic Streams) 331 o T0, a time that MUST be selected at random from the interval [T, 332 T+dT] to start generating packets and taking measurements (for 333 Periodic Streams) 335 o TstampSrc, the wire time of the packet as measured at MP(Src) 337 o TstampDst, the wire time of the packet as measured at MP(Dst), 338 assigned to packets that arrive within a "reasonable" time. 340 o Tmax, a maximum waiting time for packets at the destination. 342 4.1.2. Definition and Metric Units 344 Using the parameters above, we obtain the value of Type-P-One-way- 345 Delay singleton as per RFC 2679 [RFC2679]. 347 For each packet [i] that has a finite One-way Delay (in other words, 348 excluding packets which have undefined, or infinite one-way delay): 350 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i] = 352 FiniteDelay[i] = TstampDst - TstampSrc 354 4.1.3. Discussion and other details 356 The "Type-P-Finite-One-way-Delay" metric allows calculation of the 357 mean statistic. This avoids the need to include lost packets in the 358 sample (whose delay is undefined), and the issue with the prescribed 359 assignment of infinite delay to lost packets when practical systems 360 can only assign some very large value. 362 4.1.4. Mean Statistic 364 We add the following parameter: 366 o N, the total number of packets received at Dst (sent between T0 367 and Tf) 369 and define 370 Type-P-Finite-One-way-Delay-Mean = 371 N 372 --- 373 1 \ 374 - * > (FiniteDelay [i]) 375 N / 376 --- 377 i = 1 379 where all packets i= 1 through N have finite singleton delays. 381 4.1.5. Composition Relationship: Sum of Means 383 The Type-P-Finite--Composite-One-way-Delay-Mean, or CompMeanDelay for 384 the complete Source to Destination path can be calculated from sum of 385 the Mean Delays of all its S constituent sub-paths. 387 o S, the number of sub-paths involved in the complete Src-Dst path. 389 Then the 391 Type-P-Finite-Composite-One-way-Delay-Mean = 393 CompMeanDelay = (1/S)Sum(from i=1 to S, MeanDelay[i]) 395 4.1.6. Statement of Conjecture 397 The mean of a sufficiently large stream of packets measured on each 398 sub-path during the interval [T, Tf] will be representative of the 399 true mean of the delay distribution (and the distributions themselves 400 are sufficiently independent), such that the means may be added to 401 produce an estimate of the complete path mean delay. 403 4.1.7. Justification of Composite Relationship 405 It is sometimes impractical to conduct active measurements between 406 every Src-Dst pair. For example, it may not be possible to collect 407 the desired sample size in each test interval when access link speed 408 is limited, because of the potential for measurement traffic to 409 degrade the user traffic performance. The conditions on a low-speed 410 access link may be understood well-enough to permit use of a small 411 sample size/rate, while a larger sample size/rate may be used on 412 other sub-paths. 414 Also, since measurement operations have a real monetary cost, there 415 is value in re-using measurements where they are applicable, rather 416 than launching new measurements for every possible source-destination 417 pair. 419 4.1.8. Sources of Error 421 The measurement packets, each having source and destination addresses 422 intended for collection at edges of the sub-path, may take a 423 different specific path through the network equipment and parallel 424 exchanges than packets with the source and destination addresses of 425 the complete path. Therefore, the sub-path measurements may differ 426 from the performance experienced by packets on the complete path. 427 Multiple measurements employing sufficient sub-path address pairs 428 might produce bounds on the extent of this error. 430 others... 432 4.1.9. Specific cases where the conjecture might fail 434 If any of the sub-path distributions are bimodal, then the measured 435 means may not be stable, and in this case the mean will not be a 436 particularly useful statistic when describing the delay distribution 437 of the complete path. 439 The mean may not be sufficiently robust statistic to produce a 440 reliable estimate, or to be useful even if it can be measured. 442 others... 444 4.1.10. Application of Measurement Methodology 446 The methodology: 448 SHOULD use similar packets sent and collected separately in each sub- 449 path. 451 Allows a degree of flexibility (e.g., active or passive methods can 452 produce the "same" metric, but timing and correlation of passive 453 measurements is much more challenging). 455 Poisson and/or Periodic streams are RECOMMENDED. 457 Applicable to both Inter-domain and Intra-domain composition. 459 SHOULD have synchronized measurement time intervals in all sub-paths, 460 but largely overlapping intervals MAY suffice. 462 REQUIRES assumption of sub-path independence w.r.t. the metric being 463 defined/composed. 465 5. Loss Metrics and Statistics 467 5.1. Name: Type-P-One-way-Packet-Loss-Poisson/Periodic-Stream 469 5.1.1. Metric Parameters: 471 Same as section 4.1.1. 473 5.1.2. Definition and Metric Units 475 Using the parameters above, we obtain the value of Type-P-One-way- 476 Packet-Loss singleton and stream as per RFC 2680 [RFC2680]. 478 We obtain a sequence of pairs with elements as follows: 480 o TstampSrc, as above 482 o L, either zero or one, where L=1 indicates loss and L=0 indicates 483 arrival at the destination within TstampSrc + Tmax. 485 5.1.3. Discussion and other details 487 5.1.4. Statistic: Type-P-One-way-Packet-Loss-Empirical-Probability 489 Given the following stream parameter 491 o N, the total number of packets sent between T0 and Tf 493 We can define the Empirical Probability of Loss Statistic (Ep), 494 consistent with Average Loss in [RFC2680], as follows: 496 Type-P-One-way-Packet-Loss-Empirical-Probability = 498 Ep = (1/N)Sum(from i=1 to N, L[i]) 500 where all packets i= 1 through N have a value for L. 502 5.1.5. Composition Relationship: Composition of Empirical Probabilities 504 The Type-P-One-way-Composite-Packet-Loss-Empirical-Probability, or 505 CompEp for the complete Source to Destination path can be calculated 506 by combining Ep of all its constituent sub-paths (Ep1, Ep2, Ep3, ... 507 Epn) as 509 Type-P-One-way-Composite-Packet-Loss-Empirical-Probability = CompEp = 510 1 - {(1 - Ep1) x (1 - Ep2) x (1 - Ep3) x ... x (1 - Epn)} 512 5.1.6. Statement of Conjecture 514 The empirical probability of loss calculated on a sufficiently large 515 stream of packets measured on each sub-path during the interval [T, 516 Tf] will be representative of the true loss probability (and the 517 probabilities themselves are sufficiently independent), such that the 518 sub-path probabilities may be combined to produce an estimate of the 519 complete path loss probability. 521 5.1.7. Justification of Composite Relationship 523 It is sometimes impractical to conduct active measurements between 524 every Src-Dst pair. For example, it may not be possible to collect 525 the desired sample size in each test interval when access link speed 526 is limited, because of the potential for measurement traffic to 527 degrade the user traffic performance. The conditions on a low-speed 528 access link may be understood well-enough to permit use of a small 529 sample size/rate, while a larger sample size/rate may be used on 530 other sub-paths. 532 Also, since measurement operations have a real monetary cost, there 533 is value in re-using measurements where they are applicable, rather 534 than launching new measurements for every possible source-destination 535 pair. 537 5.1.8. Sources of Error 539 The measurement packets, each having source and destination addresses 540 intended for collection at edges of the sub-path, may take a 541 different specific path through the network equipment and parallel 542 exchanges than packets with the source and destination addresses of 543 the complete path. Therefore, the sub-path measurements may differ 544 from the performance experienced by packets on the complete path. 545 Multiple measurements employing sufficient sub-path address pairs 546 might produce bounds on the extent of this error. 548 others... 550 5.1.9. Specific cases where the conjecture might fail 552 A concern for loss measurements combined in this way is that root 553 causes may be correlated to some degree. 555 For example, if the links of different networks follow the same 556 physical route, then a single event like a tunnel fire could cause an 557 outage or congestion on remaining paths in multiple networks. Here 558 it is important to ensure that measurements before the event and 559 after the event are not combined to estimate the composite 560 performance. 562 Or, when traffic volumes rise due to the rapid spread of an email- 563 born worm, loss due to queue overflow in one network may help another 564 network to carry its traffic without loss. 566 others... 568 5.1.10. Application of Measurement Methodology 570 The methodology: 572 SHOULD use similar packets sent and collected separately in each sub- 573 path. 575 Allows a degree of flexibility (e.g., active or passive methods can 576 produce the "same" metric, but timing and correlation of passive 577 measurements is much more challenging). 579 Poisson and/or Periodic streams are RECOMMENDED. 581 Applicable to both Inter-domain and Intra-domain composition. 583 SHOULD have synchronized measurement time intervals in all sub-paths, 584 but largely overlapping intervals MAY suffice. 586 REQUIRES assumption of sub-path independence w.r.t. the metric being 587 defined/composed. 589 6. Delay Variation Metrics and Statistics 591 6.1. Name: Type-P-One-way-ipdv-refmin-Poisson/Periodic-Stream 593 This metric is a necessary element of Composed Delay Variation 594 metrics, and its definition does not formally exist elsewhere in IPPM 595 literature. 597 6.1.1. Metric Parameters: 599 In addition to the parameters of section 4.1.1: 601 o TstampSrc[i], the wire time of packet[i] as measured at MP(Src) 603 o TstampDst[i], the wire time of packet[i] as measured at MP(Dst), 604 assigned to packets that arrive within a "reasonable" time. 606 o B, a packet length in bits 608 o F, a selection function unambiguously defining the packets from 609 the stream that are selected for the packet-pair computation of 610 this metric. F(first packet), the first packet of the pair, MUST 611 have a valid Type-P-Finite-One-way-Delay less than Tmax (in other 612 words, excluding packets which have undefined, or infinite one-way 613 delay) and MUST have been transmitted during the interval T, Tf. 614 The second packet in the pair MUST be the packet with the minimum 615 valid value of Type-P-Finite-One-way-Delay for the stream, in 616 addition to the criteria for F(first packet). If multiple packets 617 have equal minimum Type-P-Finite-One-way-Delay values, then the 618 value for the earliest arriving packet SHOULD be used. 620 o MinDelay, the Type-P-Finite-One-way-Delay value for F(second 621 packet) given above. 623 o N, the number of packets received at the Destination meeting the 624 F(first packet) criteria. 626 6.1.2. Definition and Metric Units 628 Using the definition above in section 4.1.2, we obtain the value of 629 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i], the singleton 630 for each packet[i] in the stream (a.k.a. FiniteDelay[i]). 632 For each packet[i] that meets the F(first packet) criteria given 633 above: Type-P-One-way-ipdv-refmin-Poisson/Periodic-Stream[i] = 635 IPDVRefMin[i] = FiniteDelay[i] - MinDelay 637 where IPDVRefMin[i] is in units of time (seconds, milliseconds). 639 6.1.3. Discussion and other details 641 This metric produces a sample of delay variation normalized to the 642 minimum delay of the sample. The resulting delay variation 643 distribution is independent of the sending sequence (although 644 specific FiniteDelay values within the distribution may be 645 correlated, depending on various stream parameters such as packet 646 spacing). This metric is equivalent to the IP Packet Delay Variation 647 parameter defined in [Y.1540]. 649 6.1.4. Statistics: Mean, Variance, Skewness, Quanitle 651 We define the mean IPDVRefMin as follows (where all packets i= 1 652 through N have a value for IPDVRefMin): 654 Type-P-One-way-ipdv-refmin-Mean = MeanIPDVRefMin = 655 N 656 --- 657 1 \ 658 - * > (IPDVRefMin [i]) 659 N / 660 --- 661 i = 1 663 We define the variance of IPDVRefMin as follows: 665 Type-P-One-way-ipdv-refmin-Variance = VarIPDVRefMin = 666 N 667 --- 668 1 \ 2 669 ------- > (IPDVRefMin [i] - MeanIPDVRefMin) 670 (N - 1) / 671 --- 672 i = 1 674 We define the skewness of IPDVRefMin as follows: 676 Type-P-One-way-ipdv-refmin-Skewness = SkewIPDVRefMin = 677 N 678 --- 3 679 \ / \ 680 > | IPDVRefMin[i]- MeanIPDVRefMin | 681 / \ / 682 --- 683 i = 1 684 ------------------------------------------- 685 / \ 686 | ( 3/2 ) | 687 \ (N - 1) * VarIPDVRefMin / 689 We define the Quantile of the IPDVRefMin sample as the value where 690 the specified fraction of points is less than the given value. 692 6.1.5. Composition Relationships: 694 The Type-P-One-way-Composite-ipdv-refmin- for the complete 695 Source to Destination path can be calculated by combining statistics 696 of all the constituent sub-paths in the following process: 698 < to be provided > 700 6.1.6. Statement of Conjecture 702 6.1.7. Justification of Composite Relationship 704 6.1.8. Sources of Error 706 6.1.9. Specific cases where the conjecture might fail 708 6.1.10. Application of Measurement Methodology 710 7. Other Metrics and Statistics: One-way Combined Metric 712 This definition may be the common part for the definition of "Loss 713 Metrics/Statistics" and for the definition of "One-way Delay 714 Composition Metrics and Statistics". 716 7.1. Metric Name: 718 Type-P-One-way-Combo-mean 720 7.1.1. Metric Parameters: 722 Editorial notes (ES): parameters list to be completed 724 ...: 726 It is a stream of One-way delay corresponding either to an end to end 727 measure of a sub-path, or to the spatial measure of the sub-path: 729 - Type-P-One-way-Delay-Poisson-Stream as per [RFC2679]; 731 - Type-P-One-way-Delay-Periodic-Stream a per RFC 3432 [RFC3432]; 733 - Type-P-One-way-Composition-Stream as defined below; 735 - Type-P-subpath-One-way-Delay-Stream as per 737 I-D.stephan-ippm-multimetrics [I-D.stephan-ippm-multimetrics]. 739 7.1.2. Definition and Metric Units 741 Using the value ... of one of the One-way delay 742 Stream listed above, we define Type-P-One-way-Combo as the couple 743 (D,L) where D is the mean of the delay of the packets that have a 744 finite One-way, and where L is the average of lost of packets (which 745 have undefined, or infinite one-way delay). 747 D corresponds to the Type-P-Finite-One-way-Delay-Mean defined above. 749 L corresponds to the Type-P-One-way-Packet-Loss-Empirical-Probability 750 defined above. 752 7.1.3. Discussion and other details 754 7.1.4. Type-P-One-way-Combo-subpathes-stream 756 Parameters: 758 + dT1,..., dTn a list of delay. 760 + , the equivalent path. 762 Definition: 764 Using Type-P-One-way-Combo-mean of each sub-path in the equivalent 765 path we define a Type-P-One-way-subpathes-stream as the list of 766 couples (D,L) of the sub-path list; 768 Results: {, , , ... } 770 7.1.5. Type-P-One-way-composition 772 The composition over a path gives D and L which give an estimation of 773 the end-to-end delay and end-to-end packet lost over this path. 775 Parameters: 777 + , the complete path. 779 + {, , , ... }, the composition stream of 780 the sub-paths of a path. 782 Definition: 784 Using Type-P-One-way-subpathes-stream we define Type-P-One-way- 785 composition as the couple where D is the mean of the delays Di 786 and where L is the average of lost of Li. 788 Results: , where D is a delay and L is the lost 790 7.1.6. Type-P-One-way-composition 792 The sample of Type-P-One-way-composition is defined to permit the 793 usage of the results of Type-P-One-way-composition measure in 794 computation of Type-P-One-way-Combo-mean composition. 796 Parameters: 798 + T1,..., Tn, a list of times; 800 + , the delay and the lost computed by composition. 802 Definition: 804 Using Type-P-One-way-composition we define Type-P-One-way- 805 composition-stream as the stream of couples over time. 807 Results: ... 809 7.1.7. Statement of Conjecture 811 7.1.8. Justification of Composite Relationship 813 Combo metric is very easy to measure and to compose. 815 It gives the delay and the lost, so most of the need. 817 Combo metric may be performed on com metric too. 819 7.1.9. Sources of Error 821 Packets may cross different sub path than the equivalent end-to-end 822 measure because Type-P differ. 824 Packets may experiment different behavior than the equivalent end-to- 825 end measure because of access classification based on packet 826 addresses. 828 7.1.10. Specific cases where the conjecture might fail 830 When 832 + Sum of sub-path differ from the equivalent path. 834 + Type-P differ. 836 + Size differ. 838 7.1.11. Application of Measurement Methodology 840 The methodology: Is applicable to Intra and interdomain; 842 SHOULD report the context of the measure; 844 8. Security Considerations 846 8.1. Denial of Service Attacks 848 This metric requires a stream of packets sent from one host (source) 849 to another host (destination) through intervening networks. This 850 method could be abused for denial of service attacks directed at 851 destination and/or the intervening network(s). 853 Administrators of source, destination, and the intervening network(s) 854 should establish bilateral or multi-lateral agreements regarding the 855 timing, size, and frequency of collection of sample metrics. Use of 856 this method in excess of the terms agreed between the participants 857 may be cause for immediate rejection or discard of packets or other 858 escalation procedures defined between the affected parties. 860 8.2. User Data Confidentiality 862 Active use of this method generates packets for a sample, rather than 863 taking samples based on user data, and does not threaten user data 864 confidentiality. Passive measurement must restrict attention to the 865 headers of interest. Since user payloads may be temporarily stored 866 for length analysis, suitable precautions MUST be taken to keep this 867 information safe and confidential. In most cases, a hashing function 868 will produce a value suitable for payload comparisons. 870 8.3. Interference with the metrics 872 It may be possible to identify that a certain packet or stream of 873 packets is part of a sample. With that knowledge at the destination 874 and/or the intervening networks, it is possible to change the 875 processing of the packets (e.g. increasing or decreasing delay) that 876 may distort the measured performance. It may also be possible to 877 generate additional packets that appear to be part of the sample 878 metric. These additional packets are likely to perturb the results 879 of the sample measurement. 881 To discourage the kind of interference mentioned above, packet 882 interference checks, such as cryptographic hash, may be used. 884 9. IANA Considerations 886 Metrics defined in this memo will be registered in the IANA IPPM 887 METRICS REGISTRY as described in initial version of the registry RFC 888 4148 [RFC4148]. 890 10. Security Considerations 892 11. Open Issues 894 >>>>>>>>>>>>Open issue: 896 What is the relationship between the decomposition and composition 897 metrics? Should we put both kinds in one draft to make up a 898 framework? The motivation of decomposition is as follows: 900 The One-way measurement can provide result to show what the network 901 performance between two end hosts is and whether it meets operator 902 expectations or not. It cannot provide further information to 903 engineers where and how to improve the performance between the source 904 and the destination. For instance, if the network performance is not 905 acceptable in terms of the One-way measurement, in which part of the 906 network the engineers should put their efforts. This question can to 907 be answered by decompose the One-way measurement to sub-path 908 measurement to investigate the performance of different part of the 909 network. 911 Editor's Questions for clarification: What additional information 912 would be provided to the decomposition process, beyond the 913 measurement of the complete path? 915 Is the decomposition described above intended to estimate a metric 916 for some/all disjoint sub-paths involved in the complete path? 918 >>>>>>>>>>>>>>>>>>> 920 >>>>>>>>>>>>>>>>>>>OPEN Issue 922 Section 7 defines a new type of metric, a "combination" of metrics 923 for one-way delay and packet loss. The purpose of this metric is to 924 link these two primary metrics in a convenient way. 926 Readers are asked to comment on the efficiency of the combination 927 metric. 929 >>>>>>>>>>>>>>>>>> 931 >>>>>>>>>>>>>>>>> OPEN Issue 933 How can we introduce multicast metrics here, without causing too much 934 confusion? Should the multicast version of this draft wait until the 935 Unicast concepts are stable (or maybe appear in a separate draft)? 937 12. Acknowledgements 939 13. References 941 13.1. Normative References 943 [FRMWK] Morton, A. and S.Van Den Berghe, "Framework for Metric 944 Composition", February 2006. 946 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 947 Requirement Levels", BCP 14, RFC 2119, March 1997. 949 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 950 "Framework for IP Performance Metrics", RFC 2330, 951 May 1998. 953 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 954 Delay Metric for IPPM", RFC 2679, September 1999. 956 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 957 Packet Loss Metric for IPPM", RFC 2680, September 1999. 959 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 960 performance measurement with periodic streams", RFC 3432, 961 November 2002. 963 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 964 Registry", BCP 108, RFC 4148, August 2005. 966 13.2. Informative References 968 [I-D.stephan-ippm-multimetrics] 969 Stephan, E., "IP Performance Metrics (IPPM) for spatial 970 and multicast", draft-stephan-ippm-multimetrics-02 (work 971 in progress), October 2005. 973 [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data 974 communication service - IP packet transfer and 975 availability performance parameters", December 2002. 977 Authors' Addresses 979 Al Morton 980 AT&T Labs 981 200 Laurel Avenue South 982 Middletown,, NJ 07748 983 USA 985 Phone: +1 732 420 1571 986 Fax: +1 732 368 1192 987 Email: acmorton@att.com 988 URI: http://home.comcast.net/~acmacm/ 990 Emile Stephan 991 France Telecom Division R&D 992 2 avenue Pierre Marzin 993 Lannion, F-22307 994 France 996 Phone: 997 Fax: +33 2 96 05 18 52 998 Email: emile.stephan@francetelecom.com 999 URI: 1001 Intellectual Property Statement 1003 The IETF takes no position regarding the validity or scope of any 1004 Intellectual Property Rights or other rights that might be claimed to 1005 pertain to the implementation or use of the technology described in 1006 this document or the extent to which any license under such rights 1007 might or might not be available; nor does it represent that it has 1008 made any independent effort to identify any such rights. Information 1009 on the procedures with respect to rights in RFC documents can be 1010 found in BCP 78 and BCP 79. 1012 Copies of IPR disclosures made to the IETF Secretariat and any 1013 assurances of licenses to be made available, or the result of an 1014 attempt made to obtain a general license or permission for the use of 1015 such proprietary rights by implementers or users of this 1016 specification can be obtained from the IETF on-line IPR repository at 1017 http://www.ietf.org/ipr. 1019 The IETF invites any interested party to bring to its attention any 1020 copyrights, patents or patent applications, or other proprietary 1021 rights that may cover technology that may be required to implement 1022 this standard. Please address the information to the IETF at 1023 ietf-ipr@ietf.org. 1025 Disclaimer of Validity 1027 This document and the information contained herein are provided on an 1028 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1029 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1030 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1031 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1032 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1033 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1035 Copyright Statement 1037 Copyright (C) The Internet Society (2006). This document is subject 1038 to the rights, licenses and restrictions contained in BCP 78, and 1039 except as set forth therein, the authors retain all their rights. 1041 Acknowledgment 1043 Funding for the RFC Editor function is currently provided by the 1044 Internet Society.