idnits 2.17.1 draft-ietf-ippm-spatial-composition-02.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 858. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 869. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 876. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 882. ** 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 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 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 (October 22, 2006) is 6393 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 356, but not defined == Missing Reference: 'Tf' is mentioned on line 356, but not defined == Unused Reference: 'RFC3432' is defined on line 799, but no explicit reference was found in the text == Unused Reference: 'I-D.stephan-ippm-multimetrics' is defined on line 808, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-ippm-framework-compagg-01 ** 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: 8 errors (**), 0 flaws (~~), 6 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: April 25, 2007 France Telecom Division R&D 6 October 22, 2006 8 Spatial Composition of Metrics 9 draft-ietf-ippm-spatial-composition-02 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 April 25, 2007. 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 and Application . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Scope of work . . . . . . . . . . . . . . . . . . . . . . 6 66 3.2. Application . . . . . . . . . . . . . . . . . . . . . . . 6 67 4. One-way Delay Composed Metrics and Statistics . . . . . . . . 7 68 4.1. Name: 69 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream . . . 7 70 4.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 7 71 4.1.2. Definition and Metric Units . . . . . . . . . . . . . 7 72 4.1.3. Discussion and other details . . . . . . . . . . . . . 8 73 4.1.4. Mean Statistic . . . . . . . . . . . . . . . . . . . . 8 74 4.1.5. Composition Function: Sum of Means . . . . . . . . . . 8 75 4.1.6. Statement of Conjecture . . . . . . . . . . . . . . . 9 76 4.1.7. Justification of the Composition Function . . . . . . 9 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 . . . . . . . . 10 80 5. Loss Metrics and Statistics . . . . . . . . . . . . . . . . . 10 81 5.1. Name: 82 Type-P-One-way-Packet-Loss-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 . . . . . . . . . . . . . 11 86 5.1.4. Statistic: 87 Type-P-One-way-Packet-Loss-Empirical-Probability . . . 11 88 5.1.5. Composition Function: Composition of Empirical 89 Probabilities . . . . . . . . . . . . . . . . . . . . 11 90 5.1.6. Statement of Conjecture . . . . . . . . . . . . . . . 11 91 5.1.7. Justification of the Composition Function . . . . . . 11 92 5.1.8. Sources of Deviation from the Ground Truth . . . . . . 12 93 5.1.9. Specific cases where the conjecture might fail . . . . 12 94 5.1.10. Application of Measurement Methodology . . . . . . . . 12 95 6. Delay Variation Metrics and Statistics . . . . . . . . . . . . 13 96 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 Functions: . . . . . . . . . . . . . . . . 15 104 6.1.6. Statement of Conjecture . . . . . . . . . . . . . . . 15 105 6.1.7. Justification of the Composition Function . . . . . . 15 106 6.1.8. Sources of Deviation from the Ground Truth . . . . . . 15 107 6.1.9. Specific cases where the conjecture might fail . . . . 15 108 6.1.10. Application of Measurement Methodology . . . . . . . . 15 109 7. Other Metrics and Statistics: One-way Combined Metric . . . . 16 110 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 111 8.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 16 112 8.2. User Data Confidentiality . . . . . . . . . . . . . . . . 16 113 8.3. Interference with the metrics . . . . . . . . . . . . . . 16 114 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 115 10. Issues (Open and Closed) . . . . . . . . . . . . . . . . . . . 17 116 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 117 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 118 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 119 12.2. Informative References . . . . . . . . . . . . . . . . . . 19 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 121 Intellectual Property and Copyright Statements . . . . . . . . . . 20 123 1. Contributors 125 Thus far, the following people have contributed useful ideas, 126 suggestions, or the text of sections that have been incorporated into 127 this memo: 129 - Phil Chimento 131 - Reza Fardid 133 - Roman Krzanowski 135 - Maurizio Molina 137 - Al Morton 139 - Emile Stephan 141 - Lei Liang 143 2. Introduction 145 The IPPM framework [RFC2330] describes two forms of metric 146 composition, spatial and temporal. The new composition framework 147 [I-D.ietf-ippm-framework-compagg] expands and further qualifies these 148 original forms into three categories. This memo describes Spatial 149 Composition, one of the categories of metrics under the umbrella of 150 the composition framework. 152 Spatial composition encompasses the definition of performance metrics 153 that are applicable to a complete path, based on metrics collected on 154 various sub-paths. 156 The main purpose of this memo is to define the deterministic 157 functions that yield the complete path metrics using metrics of the 158 sub-paths. The effectiveness of such metrics is dependent on their 159 usefulness in analysis and applicability with practical measurement 160 methods. 162 The relationships may involve conjecture, and [RFC2330] lists four 163 points that the metric definitions should include: 165 o the specific conjecture applied to the metric, 167 o a justification of the practical utility of the composition in 168 terms of making accurate measurements of the metric on the path, 170 o a justification of the usefulness of the composition in terms of 171 making analysis of the path using A-frame concepts more effective, 172 and 174 o an analysis of how the conjecture could be incorrect. 176 Also, [RFC2330] gives an example where a conjecture that the delay of 177 a path is very nearly the sum of the delays of the exchanges and 178 clouds of the corresponding path digest. This example is 179 particularly relevant to those who wish to assess the performance of 180 an Inter-domain path without direct measurement, and the performance 181 estimate of the complete path is related to the measured results for 182 various sub-paths instead. 184 Approximate functions between the sub-path and complete path metrics 185 are useful, with knowledge of the circumstances where the 186 relationships are/are not applicable. For example, we would not 187 expect that delay singletons from each sub-path would sum to produce 188 an accurate estimate of a delay singleton for the complete path 189 (unless all the delays were essentially constant - very unlikely). 190 However, other delay statistics (based on a reasonable sample size) 191 may have a sufficiently large set of circumstances where they are 192 applicable. 194 2.1. Motivation 196 One-way metrics defined in other IPPM RFCs all assume that the 197 measurement can be practically carried out between the source and the 198 destination of the interest. Sometimes there are reasons that the 199 measurement can not be executed from the source to the destination. 200 For instance, the measurement path may cross several independent 201 domains that have conflicting policies, measurement tools and 202 methods, and measurement time assignment. The solution then may be 203 the composition of several sub-path measurements. This means each 204 domain performs the One-way measurement on a sub path between two 205 nodes that are involved in the complete path following its own 206 policy, using its own measurement tools and methods, and using its 207 own measurement timing. Under the appropriate conditions, one can 208 combine the sub-path One-way metric results to estimate the complete 209 path One-way measurement metric with some degree of accuracy. 211 3. Scope and Application 212 3.1. Scope of work 214 For the primary IPPM metrics of Loss, Delay, and Delay Variation, 215 this memo gives a set of metrics for that can be composed from the 216 same or similar sub-path metrics. This means that the composition 217 function may utilize: 219 o the same metric for each sub-path; 221 o multiple metrics for each sub-path (possibly one that is the same 222 as the complete path metric); 224 o a single sub-path metrics that is different from the complete path 225 metric; 227 o different measurement techniques like active and passive 228 (recognizing that PSAMP WG will define capabilities to sample 229 packets to support measurement). 231 3.2. Application 233 The new composition framework [I-D.ietf-ippm-framework-compagg] 234 requires the specification of the applicable circumstances for each 235 metric. In particular, the application of Spatial Composition 236 metrics are addressed as to whether the metric: 238 Requires the same test packets to traverse all sub-paths, or may use 239 similar packets sent and collected separately in each sub-path. 241 Requires homogeneity of measurement methodologies, or can allow a 242 degree of flexibility (e.g., active or passive methods produce the 243 "same" metric). Also, the applicable sending streams will be 244 specified, such as Poisson, Periodic, or both. 246 Needs information or access that will only be available within an 247 operator's domain, or is applicable to Inter-domain composition. 249 Requires synchronized measurement time intervals in all sub-paths, or 250 largely overlapping, or no timing requirements. 252 Requires assumption of sub-path independence w.r.t. the metric being 253 defined/composed, or other assumptions. 255 Has known sources of inaccuracy/error, and identifies the sources. 257 4. One-way Delay Composed Metrics and Statistics 259 4.1. Name: Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream 261 This metric is a necessary element of Delay Composition metrics, and 262 its definition does not formally exist elsewhere in IPPM literature. 264 4.1.1. Metric Parameters: 266 o Src, the IP address of a host + Dst, the IP address of a host 268 o T, a time (start of test interval) 270 o Tf, a time (end of test interval) 272 o lambda, a rate in reciprocal seconds (for Poisson Streams) 274 o incT, the nominal duration of inter-packet interval, first bit to 275 first bit (for Periodic Streams) 277 o T0, a time that MUST be selected at random from the interval [T, 278 T+dT] to start generating packets and taking measurements (for 279 Periodic Streams) 281 o TstampSrc, the wire time of the packet as measured at MP(Src) 283 o TstampDst, the wire time of the packet as measured at MP(Dst), 284 assigned to packets that arrive within a "reasonable" time. 286 o Tmax, a maximum waiting time for packets at the destination, set 287 sufficiently long to disambiguate packets with long delays from 288 packets that are discarded (lost), thus the distribution of delay 289 is not truncated. 291 4.1.2. Definition and Metric Units 293 Using the parameters above, we obtain the value of Type-P-One-way- 294 Delay singleton as per [RFC2679]. 296 For each packet [i] that has a finite One-way Delay (in other words, 297 excluding packets which have undefined one-way delay): 299 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i] = 301 FiniteDelay[i] = TstampDst - TstampSrc 303 4.1.3. Discussion and other details 305 The "Type-P-Finite-One-way-Delay" metric permits calculation of the 306 sample mean statistic. This resolves the problem of including lost 307 packets in the sample (whose delay is undefined), and the issue with 308 the informal assignment of infinite delay to lost packets (practical 309 systems can only assign some very large value). 311 The Finite-One-way-Delay approach handles the problem of lost packets 312 by reducing the event space. We consider conditional statistics, and 313 estimate the mean one-way delay conditioned on the event that all 314 packets in the sample arrive at the destination (within the specified 315 waiting time, Tmax). This offers a way to make some valid statements 316 about one-way delay, and at the same time avoiding events with 317 undefined outcomes. This approach is derived from the treatment of 318 lost packets in [RFC3393], and is similar to [Y.1540] . 320 4.1.4. Mean Statistic 322 We add the following parameter: 324 o N, the total number of packets received at Dst (sent between T0 325 and Tf) 327 and define 329 Type-P-Finite-One-way-Delay-Mean = 330 N 331 --- 332 1 \ 333 - * > (FiniteDelay [i]) 334 N / 335 --- 336 i = 1 338 where all packets i= 1 through N have finite singleton delays. 340 4.1.5. Composition Function: Sum of Means 342 The Type-P-Finite--Composite-One-way-Delay-Mean, or CompMeanDelay for 343 the complete Source to Destination path can be calculated from sum of 344 the Mean Delays of all its S constituent sub-paths. 346 o S, the number of sub-paths involved in the complete Src-Dst path. 348 Then the 350 Type-P-Finite-Composite-One-way-Delay-Mean = 351 CompMeanDelay = (1/S)Sum(from i=1 to S, MeanDelay[i]) 353 4.1.6. Statement of Conjecture 355 The mean of a sufficiently large stream of packets measured on each 356 sub-path during the interval [T, Tf] will be representative of the 357 true mean of the delay distribution (and the distributions themselves 358 are sufficiently independent), such that the means may be added to 359 produce an estimate of the complete path mean delay. 361 4.1.7. Justification of the Composition Function 363 It is sometimes impractical to conduct active measurements between 364 every Src-Dst pair. For example, it may not be possible to collect 365 the desired sample size in each test interval when access link speed 366 is limited, because of the potential for measurement traffic to 367 degrade the user traffic performance. The conditions on a low-speed 368 access link may be understood well-enough to permit use of a small 369 sample size/rate, while a larger sample size/rate may be used on 370 other sub-paths. 372 Also, since measurement operations have a real monetary cost, there 373 is value in re-using measurements where they are applicable, rather 374 than launching new measurements for every possible source-destination 375 pair. 377 4.1.8. Sources of Deviation from the Ground Truth 379 The measurement packets, each having source and destination addresses 380 intended for collection at edges of the sub-path, may take a 381 different specific path through the network equipment and parallel 382 exchanges than packets with the source and destination addresses of 383 the complete path. Therefore, the sub-path measurements may differ 384 from the performance experienced by packets on the complete path. 385 Multiple measurements employing sufficient sub-path address pairs 386 might produce bounds on the extent of this error. 388 others... 390 4.1.9. Specific cases where the conjecture might fail 392 If any of the sub-path distributions are bimodal, then the measured 393 means may not be stable, and in this case the mean will not be a 394 particularly useful statistic when describing the delay distribution 395 of the complete path. 397 The mean may not be sufficiently robust statistic to produce a 398 reliable estimate, or to be useful even if it can be measured. 400 others... 402 4.1.10. Application of Measurement Methodology 404 The methodology: 406 SHOULD use similar packets sent and collected separately in each sub- 407 path. 409 Allows a degree of flexibility (e.g., active or passive methods can 410 produce the "same" metric, but timing and correlation of passive 411 measurements is much more challenging). 413 Poisson and/or Periodic streams are RECOMMENDED. 415 Applicable to both Inter-domain and Intra-domain composition. 417 SHOULD have synchronized measurement time intervals in all sub-paths, 418 but largely overlapping intervals MAY suffice. 420 REQUIRES assumption of sub-path independence w.r.t. the metric being 421 defined/composed. 423 5. Loss Metrics and Statistics 425 5.1. Name: Type-P-One-way-Packet-Loss-Poisson/Periodic-Stream 427 5.1.1. Metric Parameters: 429 Same as section 4.1.1. 431 5.1.2. Definition and Metric Units 433 Using the parameters above, we obtain the value of Type-P-One-way- 434 Packet-Loss singleton and stream as per [RFC2680]. 436 We obtain a sequence of pairs with elements as follows: 438 o TstampSrc, as above 440 o L, either zero or one, where L=1 indicates loss and L=0 indicates 441 arrival at the destination within TstampSrc + Tmax. 443 5.1.3. Discussion and other details 445 5.1.4. Statistic: Type-P-One-way-Packet-Loss-Empirical-Probability 447 Given the following stream parameter 449 o M, the total number of packets sent between T0 and Tf 451 We can define the Empirical Probability of Loss Statistic (Ep), 452 consistent with Average Loss in [RFC2680], as follows: 454 Type-P-One-way-Packet-Loss-Empirical-Probability = 456 Ep = (1/M)Sum(from i=1 to M, L[i]) 458 where all packets i= 1 through M have a value for L. 460 5.1.5. Composition Function: Composition of Empirical Probabilities 462 The Type-P-One-way-Composite-Packet-Loss-Empirical-Probability, or 463 CompEp for the complete Source to Destination path can be calculated 464 by combining Ep of all its constituent sub-paths (Ep1, Ep2, Ep3, ... 465 Epn) as 467 Type-P-One-way-Composite-Packet-Loss-Empirical-Probability = CompEp = 468 1 - {(1 - Ep1) x (1 - Ep2) x (1 - Ep3) x ... x (1 - Epn)} 470 5.1.6. Statement of Conjecture 472 The empirical probability of loss calculated on a sufficiently large 473 stream of packets measured on each sub-path during the interval [T, 474 Tf] will be representative of the true loss probability (and the 475 probabilities themselves are sufficiently independent), such that the 476 sub-path probabilities may be combined to produce an estimate of the 477 complete path loss probability. 479 5.1.7. Justification of the Composition Function 481 It is sometimes impractical to conduct active measurements between 482 every Src-Dst pair. For example, it may not be possible to collect 483 the desired sample size in each test interval when access link speed 484 is limited, because of the potential for measurement traffic to 485 degrade the user traffic performance. The conditions on a low-speed 486 access link may be understood well-enough to permit use of a small 487 sample size/rate, while a larger sample size/rate may be used on 488 other sub-paths. 490 Also, since measurement operations have a real monetary cost, there 491 is value in re-using measurements where they are applicable, rather 492 than launching new measurements for every possible source-destination 493 pair. 495 5.1.8. Sources of Deviation from the Ground Truth 497 The measurement packets, each having source and destination addresses 498 intended for collection at edges of the sub-path, may take a 499 different specific path through the network equipment and parallel 500 exchanges than packets with the source and destination addresses of 501 the complete path. Therefore, the sub-path measurements may differ 502 from the performance experienced by packets on the complete path. 503 Multiple measurements employing sufficient sub-path address pairs 504 might produce bounds on the extent of this error. 506 others... 508 5.1.9. Specific cases where the conjecture might fail 510 A concern for loss measurements combined in this way is that root 511 causes may be correlated to some degree. 513 For example, if the links of different networks follow the same 514 physical route, then a single event like a tunnel fire could cause an 515 outage or congestion on remaining paths in multiple networks. Here 516 it is important to ensure that measurements before the event and 517 after the event are not combined to estimate the composite 518 performance. 520 Or, when traffic volumes rise due to the rapid spread of an email- 521 born worm, loss due to queue overflow in one network may help another 522 network to carry its traffic without loss. 524 others... 526 5.1.10. Application of Measurement Methodology 528 The methodology: 530 SHOULD use similar packets sent and collected separately in each sub- 531 path. 533 Allows a degree of flexibility (e.g., active or passive methods can 534 produce the "same" metric, but timing and correlation of passive 535 measurements is much more challenging). 537 Poisson and/or Periodic streams are RECOMMENDED. 539 Applicable to both Inter-domain and Intra-domain composition. 541 SHOULD have synchronized measurement time intervals in all sub-paths, 542 but largely overlapping intervals MAY suffice. 544 REQUIRES assumption of sub-path independence w.r.t. the metric being 545 defined/composed. 547 6. Delay Variation Metrics and Statistics 549 6.1. Name: Type-P-One-way-ipdv-refmin-Poisson/Periodic-Stream 551 This metric is a necessary element of Composed Delay Variation 552 metrics, and its definition does not formally exist elsewhere in IPPM 553 literature. 555 6.1.1. Metric Parameters: 557 In addition to the parameters of section 4.1.1: 559 o TstampSrc[i], the wire time of packet[i] as measured at MP(Src) 561 o TstampDst[i], the wire time of packet[i] as measured at MP(Dst), 562 assigned to packets that arrive within a "reasonable" time. 564 o B, a packet length in bits 566 o F, a selection function unambiguously defining the packets from 567 the stream that are selected for the packet-pair computation of 568 this metric. F(first packet), the first packet of the pair, MUST 569 have a valid Type-P-Finite-One-way-Delay less than Tmax (in other 570 words, excluding packets which have undefined, or infinite one-way 571 delay) and MUST have been transmitted during the interval T, Tf. 572 The second packet in the pair MUST be the packet with the minimum 573 valid value of Type-P-Finite-One-way-Delay for the stream, in 574 addition to the criteria for F(first packet). If multiple packets 575 have equal minimum Type-P-Finite-One-way-Delay values, then the 576 value for the earliest arriving packet SHOULD be used. 578 o MinDelay, the Type-P-Finite-One-way-Delay value for F(second 579 packet) given above. 581 o N, the number of packets received at the Destination meeting the 582 F(first packet) criteria. 584 6.1.2. Definition and Metric Units 586 Using the definition above in section 4.1.2, we obtain the value of 587 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i], the singleton 588 for each packet[i] in the stream (a.k.a. FiniteDelay[i]). 590 For each packet[i] that meets the F(first packet) criteria given 591 above: Type-P-One-way-ipdv-refmin-Poisson/Periodic-Stream[i] = 593 IPDVRefMin[i] = FiniteDelay[i] - MinDelay 595 where IPDVRefMin[i] is in units of time (seconds, milliseconds). 597 6.1.3. Discussion and other details 599 This metric produces a sample of delay variation normalized to the 600 minimum delay of the sample. The resulting delay variation 601 distribution is independent of the sending sequence (although 602 specific FiniteDelay values within the distribution may be 603 correlated, depending on various stream parameters such as packet 604 spacing). This metric is equivalent to the IP Packet Delay Variation 605 parameter defined in [Y.1540]. 607 6.1.4. Statistics: Mean, Variance, Skewness, Quanitle 609 We define the mean IPDVRefMin as follows (where all packets i= 1 610 through N have a value for IPDVRefMin): 612 Type-P-One-way-ipdv-refmin-Mean = MeanIPDVRefMin = 613 N 614 --- 615 1 \ 616 - * > (IPDVRefMin [i]) 617 N / 618 --- 619 i = 1 621 We define the variance of IPDVRefMin as follows: 623 Type-P-One-way-ipdv-refmin-Variance = VarIPDVRefMin = 624 N 625 --- 626 1 \ 2 627 ------- > (IPDVRefMin [i] - MeanIPDVRefMin) 628 (N - 1) / 629 --- 630 i = 1 632 We define the skewness of IPDVRefMin as follows: 634 Type-P-One-way-ipdv-refmin-Skewness = SkewIPDVRefMin = 635 N 636 --- 3 637 \ / \ 638 > | IPDVRefMin[i]- MeanIPDVRefMin | 639 / \ / 640 --- 641 i = 1 642 ------------------------------------------- 643 / \ 644 | ( 3/2 ) | 645 \ (N - 1) * VarIPDVRefMin / 647 We define the Quantile of the IPDVRefMin sample as the value where 648 the specified fraction of points is less than the given value. 650 6.1.5. Composition Functions: 652 The Type-P-One-way-Composite-ipdv-refmin- for the complete 653 Source to Destination path can be calculated by combining statistics 654 of all the constituent sub-paths in the following process: 656 < see [Y.1541] > 658 6.1.6. Statement of Conjecture 660 6.1.7. Justification of the Composition Function 662 6.1.8. Sources of Deviation from the Ground Truth 664 6.1.9. Specific cases where the conjecture might fail 666 6.1.10. Application of Measurement Methodology 667 7. Other Metrics and Statistics: One-way Combined Metric 669 8. Security Considerations 671 8.1. Denial of Service Attacks 673 This metric requires a stream of packets sent from one host (source) 674 to another host (destination) through intervening networks. This 675 method could be abused for denial of service attacks directed at 676 destination and/or the intervening network(s). 678 Administrators of source, destination, and the intervening network(s) 679 should establish bilateral or multi-lateral agreements regarding the 680 timing, size, and frequency of collection of sample metrics. Use of 681 this method in excess of the terms agreed between the participants 682 may be cause for immediate rejection or discard of packets or other 683 escalation procedures defined between the affected parties. 685 8.2. User Data Confidentiality 687 Active use of this method generates packets for a sample, rather than 688 taking samples based on user data, and does not threaten user data 689 confidentiality. Passive measurement must restrict attention to the 690 headers of interest. Since user payloads may be temporarily stored 691 for length analysis, suitable precautions MUST be taken to keep this 692 information safe and confidential. In most cases, a hashing function 693 will produce a value suitable for payload comparisons. 695 8.3. Interference with the metrics 697 It may be possible to identify that a certain packet or stream of 698 packets is part of a sample. With that knowledge at the destination 699 and/or the intervening networks, it is possible to change the 700 processing of the packets (e.g. increasing or decreasing delay) that 701 may distort the measured performance. It may also be possible to 702 generate additional packets that appear to be part of the sample 703 metric. These additional packets are likely to perturb the results 704 of the sample measurement. 706 To discourage the kind of interference mentioned above, packet 707 interference checks, such as cryptographic hash, may be used. 709 9. IANA Considerations 711 Metrics defined in this memo will be registered in the IANA IPPM 712 METRICS REGISTRY as described in initial version of the registry 714 [RFC4148]. 716 10. Issues (Open and Closed) 718 >>>>>>>>>>>>Issue: 720 What is the relationship between the decomposition and composition 721 metrics? Should we put both kinds in one draft to make up a 722 framework? The motivation of decomposition is as follows: 724 The One-way measurement can provide result to show what the network 725 performance between two end hosts is and whether it meets operator 726 expectations or not. It cannot provide further information to 727 engineers where and how to improve the performance between the source 728 and the destination. For instance, if the network performance is not 729 acceptable in terms of the One-way measurement, in which part of the 730 network the engineers should put their efforts. This question can to 731 be answered by decompose the One-way measurement to sub-path 732 measurement to investigate the performance of different part of the 733 network. 735 Editor's Questions for clarification: What additional information 736 would be provided to the decomposition process, beyond the 737 measurement of the complete path? 739 Is the decomposition described above intended to estimate a metric 740 for some/all disjoint sub-paths involved in the complete path? 742 >>>>>>>>>>>>>>>>>>RESOLUTION: treat this topic in a seperate memo 744 >>>>>>>>>>>>>>>>>>> 746 >>>>>>>>>>>>>>>>>>>Issue 748 Section 7 defines a new type of metric, a "combination" of metrics 749 for one-way delay and packet loss. The purpose of this metric is to 750 link these two primary metrics in a convenient way. 752 Readers are asked to comment on the efficiency of the combination 753 metric. 755 >>>>>>>>>>>>>>>>>RESOLUTION: If a delay singleton is recorded as 756 having "undefined" delay when the packet does not arrive within the 757 waiting time Tmax, then this information is sufficient to determine 758 the fraction of lost packets in the sample, and the additional loss 759 indication of this combo is not needed. 761 >>>>>>>>>>>>>>>>>> 763 >>>>>>>>>>>>>>>>> Issue 765 Can we introduce multicast metrics here, without causing too much 766 confusion? Should the multicast version of this draft wait until the 767 Unicast concepts are stable (or maybe appear in a separate draft)? 769 >>>>>>>>>>>>>>>>RESOLUTION: No and Yes. 771 11. Acknowledgements 773 12. References 775 12.1. Normative References 777 [I-D.ietf-ippm-framework-compagg] 778 Morton, A. and S. Berghe, "Framework for Metric 779 Composition", draft-ietf-ippm-framework-compagg-01 (work 780 in progress), June 2006. 782 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 783 Requirement Levels", BCP 14, RFC 2119, March 1997. 785 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 786 "Framework for IP Performance Metrics", RFC 2330, 787 May 1998. 789 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 790 Delay Metric for IPPM", RFC 2679, September 1999. 792 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 793 Packet Loss Metric for IPPM", RFC 2680, September 1999. 795 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 796 Metric for IP Performance Metrics (IPPM)", RFC 3393, 797 November 2002. 799 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 800 performance measurement with periodic streams", RFC 3432, 801 November 2002. 803 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 804 Registry", BCP 108, RFC 4148, August 2005. 806 12.2. Informative References 808 [I-D.stephan-ippm-multimetrics] 809 Stephan, E., "IP Performance Metrics (IPPM) for spatial 810 and multicast", draft-stephan-ippm-multimetrics-02 (work 811 in progress), October 2005. 813 [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data 814 communication service - IP packet transfer and 815 availability performance parameters", December 2002. 817 [Y.1541] ITU-T Recommendation Y.1540, "Network Performance 818 Objectives for IP-based Services", February 2006. 820 Authors' Addresses 822 Al Morton 823 AT&T Labs 824 200 Laurel Avenue South 825 Middletown,, NJ 07748 826 USA 828 Phone: +1 732 420 1571 829 Fax: +1 732 368 1192 830 Email: acmorton@att.com 831 URI: http://home.comcast.net/~acmacm/ 833 Emile Stephan 834 France Telecom Division R&D 835 2 avenue Pierre Marzin 836 Lannion, F-22307 837 France 839 Phone: 840 Fax: +33 2 96 05 18 52 841 Email: emile.stephan@francetelecom.com 842 URI: 844 Full Copyright Statement 846 Copyright (C) The Internet Society (2006). 848 This document is subject to the rights, licenses and restrictions 849 contained in BCP 78, and except as set forth therein, the authors 850 retain all their rights. 852 This document and the information contained herein are provided on an 853 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 854 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 855 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 856 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 857 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 858 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 860 Intellectual Property 862 The IETF takes no position regarding the validity or scope of any 863 Intellectual Property Rights or other rights that might be claimed to 864 pertain to the implementation or use of the technology described in 865 this document or the extent to which any license under such rights 866 might or might not be available; nor does it represent that it has 867 made any independent effort to identify any such rights. Information 868 on the procedures with respect to rights in RFC documents can be 869 found in BCP 78 and BCP 79. 871 Copies of IPR disclosures made to the IETF Secretariat and any 872 assurances of licenses to be made available, or the result of an 873 attempt made to obtain a general license or permission for the use of 874 such proprietary rights by implementers or users of this 875 specification can be obtained from the IETF on-line IPR repository at 876 http://www.ietf.org/ipr. 878 The IETF invites any interested party to bring to its attention any 879 copyrights, patents or patent applications, or other proprietary 880 rights that may cover technology that may be required to implement 881 this standard. Please address the information to the IETF at 882 ietf-ipr@ietf.org. 884 Acknowledgment 886 Funding for the RFC Editor function is provided by the IETF 887 Administrative Support Activity (IASA).