idnits 2.17.1 draft-ietf-ippm-spatial-composition-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 13, 2010) is 4977 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 993, but not defined == Missing Reference: 'Tf' is mentioned on line 993, but not defined ** 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) ** Downref: Normative reference to an Informational RFC: RFC 5835 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 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: February 14, 2011 France Telecom Division R&D 6 August 13, 2010 8 Spatial Composition of Metrics 9 draft-ietf-ippm-spatial-composition-16 11 Abstract 13 This memo utilizes IP Performance Metrics that are applicable to both 14 complete paths and sub-paths, and defines relationships to compose a 15 complete path metric from the sub-path metrics with some accuracy 16 w.r.t. the actual metrics. This is called Spatial Composition in RFC 17 2330. The memo refers to the Framework for Metric Composition, and 18 provides background and motivation for combining metrics to derive 19 others. The descriptions of several composed metrics and statistics 20 follow. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 In this memo, the characters "<=" should be read as "less than or 29 equal to" and ">=" as "greater than or equal to". 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on February 14, 2011. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6 78 2. Scope and Application . . . . . . . . . . . . . . . . . . . . 6 79 2.1. Scope of work . . . . . . . . . . . . . . . . . . . . . . 6 80 2.2. Application . . . . . . . . . . . . . . . . . . . . . . . 7 81 2.3. Incomplete Information . . . . . . . . . . . . . . . . . . 7 82 3. Common Specifications for Composed Metrics . . . . . . . . . . 7 83 3.1. Name: Type-P . . . . . . . . . . . . . . . . . . . . . . . 8 84 3.1.1. Metric Parameters . . . . . . . . . . . . . . . . . . 8 85 3.1.2. Definition and Metric Units . . . . . . . . . . . . . 9 86 3.1.3. Discussion and other details . . . . . . . . . . . . . 9 87 3.1.4. Statistic: . . . . . . . . . . . . . . . . . . . . . . 9 88 3.1.5. Composition Function . . . . . . . . . . . . . . . . . 9 89 3.1.6. Statement of Conjecture and Assumptions . . . . . . . 9 90 3.1.7. Justification of the Composition Function . . . . . . 9 91 3.1.8. Sources of Deviation from the Ground Truth . . . . . . 10 92 3.1.9. Specific cases where the conjecture might fail . . . . 11 93 3.1.10. Application of Measurement Methodology . . . . . . . . 11 94 4. One-way Delay Composed Metrics and Statistics . . . . . . . . 12 95 4.1. Name: Type-P-Finite-One-way-Delay--Stream . . . . 12 96 4.1.1. Metric Parameters . . . . . . . . . . . . . . . . . . 12 97 4.1.2. Definition and Metric Units . . . . . . . . . . . . . 12 98 4.1.3. Discussion and other details . . . . . . . . . . . . . 12 99 4.1.4. Statistic: . . . . . . . . . . . . . . . . . . . . . . 13 100 4.2. Name: Type-P-Finite-Composite-One-way-Delay-Mean . . . . . 13 101 4.2.1. Metric Parameters . . . . . . . . . . . . . . . . . . 13 102 4.2.2. Definition and Metric Units of the Mean Statistic . . 13 103 4.2.3. Discussion and other details . . . . . . . . . . . . . 14 104 4.2.4. Statistic: . . . . . . . . . . . . . . . . . . . . . . 14 105 4.2.5. Composition Function: Sum of Means . . . . . . . . . . 14 106 4.2.6. Statement of Conjecture and Assumptions . . . . . . . 14 107 4.2.7. Justification of the Composition Function . . . . . . 14 108 4.2.8. Sources of Deviation from the Ground Truth . . . . . . 14 109 4.2.9. Specific cases where the conjecture might fail . . . . 15 110 4.2.10. Application of Measurement Methodology . . . . . . . . 15 111 4.3. Name: Type-P-Finite-Composite-One-way-Delay-Minimum . . . 15 112 4.3.1. Metric Parameters . . . . . . . . . . . . . . . . . . 15 113 4.3.2. Definition and Metric Units of the Minimum 114 Statistic . . . . . . . . . . . . . . . . . . . . . . 15 115 4.3.3. Discussion and other details . . . . . . . . . . . . . 16 116 4.3.4. Statistic: . . . . . . . . . . . . . . . . . . . . . . 16 117 4.3.5. Composition Function: Sum of Minima . . . . . . . . . 16 118 4.3.6. Statement of Conjecture and Assumptions . . . . . . . 16 119 4.3.7. Justification of the Composition Function . . . . . . 16 120 4.3.8. Sources of Deviation from the Ground Truth . . . . . . 16 121 4.3.9. Specific cases where the conjecture might fail . . . . 17 122 4.3.10. Application of Measurement Methodology . . . . . . . . 17 123 5. Loss Metrics and Statistics . . . . . . . . . . . . . . . . . 17 124 5.1. Type-P-Composite-One-way-Packet-Loss-Empirical-Probability 17 125 5.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 17 126 5.1.2. Definition and Metric Units . . . . . . . . . . . . . 17 127 5.1.3. Discussion and other details . . . . . . . . . . . . . 17 128 5.1.4. Statistic: 129 Type-P-One-way-Packet-Loss-Empirical-Probability . . . 17 130 5.1.5. Composition Function: Composition of Empirical 131 Probabilities . . . . . . . . . . . . . . . . . . . . 18 132 5.1.6. Statement of Conjecture and Assumptions . . . . . . . 18 133 5.1.7. Justification of the Composition Function . . . . . . 18 134 5.1.8. Sources of Deviation from the Ground Truth . . . . . . 18 135 5.1.9. Specific cases where the conjecture might fail . . . . 18 136 5.1.10. Application of Measurement Methodology . . . . . . . . 19 137 6. Delay Variation Metrics and Statistics . . . . . . . . . . . . 19 138 6.1. Name: Type-P-One-way-pdv-refmin--Stream . . . . . 19 139 6.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 19 140 6.1.2. Definition and Metric Units . . . . . . . . . . . . . 20 141 6.1.3. Discussion and other details . . . . . . . . . . . . . 20 142 6.1.4. Statistics: Mean, Variance, Skewness, Quantile . . . . 20 143 6.1.5. Composition Functions: . . . . . . . . . . . . . . . . 21 144 6.1.6. Statement of Conjecture and Assumptions . . . . . . . 22 145 6.1.7. Justification of the Composition Function . . . . . . 23 146 6.1.8. Sources of Deviation from the Ground Truth . . . . . . 23 147 6.1.9. Specific cases where the conjecture might fail . . . . 23 148 6.1.10. Application of Measurement Methodology . . . . . . . . 23 149 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 150 7.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 23 151 7.2. User Data Confidentiality . . . . . . . . . . . . . . . . 24 152 7.3. Interference with the metrics . . . . . . . . . . . . . . 24 153 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 154 9. Contributors and Acknowledgements . . . . . . . . . . . . . . 27 155 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 156 10.1. Normative References . . . . . . . . . . . . . . . . . . . 28 157 10.2. Informative References . . . . . . . . . . . . . . . . . . 29 158 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 159 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 161 1. Introduction 163 The IP Performance Metrics (IPPM) framework [RFC2330] describes two 164 forms of metric composition, spatial and temporal. The composition 165 framework [RFC5835] expands and further qualifies these original 166 forms into three categories. This memo describes Spatial 167 Composition, one of the categories of metrics under the umbrella of 168 the composition framework. 170 Spatial composition encompasses the definition of performance metrics 171 that are applicable to a complete path, based on metrics collected on 172 various sub-paths. 174 The main purpose of this memo is to define the deterministic 175 functions that yield the complete path metrics using metrics of the 176 sub-paths. The effectiveness of such metrics is dependent on their 177 usefulness in analysis and applicability with practical measurement 178 methods. 180 The relationships may involve conjecture, and [RFC2330] lists four 181 points that the metric definitions should include: 183 o the specific conjecture applied to the metric and assumptions of 184 the statistical model of the process being measured (if any, see 185 [RFC2330] section 12), 187 o a justification of the practical utility of the composition in 188 terms of making accurate measurements of the metric on the path, 190 o a justification of the usefulness of the composition in terms of 191 making analysis of the path using A-frame concepts more effective, 192 and 194 o an analysis of how the conjecture could be incorrect. 196 Also, [RFC2330] gives an example using the conjecture that the delay 197 of a path is very nearly the sum of the delays of the exchanges and 198 clouds of the corresponding path digest. This example is 199 particularly relevant to those who wish to assess the performance of 200 an Inter-domain path without direct measurement, and the performance 201 estimate of the complete path is related to the measured results for 202 various sub-paths instead. 204 Approximate functions between the sub-path and complete path metrics 205 are useful, with knowledge of the circumstances where the 206 relationships are/are not applicable. For example, we would not 207 expect that delay singletons from each sub-path would sum to produce 208 an accurate estimate of a delay singleton for the complete path 209 (unless all the delays were essentially constant - very unlikely). 210 However, other delay statistics (based on a reasonable sample size) 211 may have a sufficiently large set of circumstances where they are 212 applicable. 214 1.1. Motivation 216 One-way metrics defined in other RFCs (such as [RFC2679] and 217 [RFC2680]) all assume that the measurement can be practically carried 218 out between the source and the destination of interest. Sometimes 219 there are reasons that the measurement cannot be executed from the 220 source to the destination. For instance, the measurement path may 221 cross several independent domains that have conflicting policies, 222 measurement tools and methods, and measurement time assignment. The 223 solution then may be the composition of several sub-path 224 measurements. This means each domain performs the One-way 225 measurement on a sub path between two nodes that are involved in the 226 complete path following its own policy, using its own measurement 227 tools and methods, and using its own measurement timing. Under the 228 appropriate conditions, one can combine the sub-path One-way metric 229 results to estimate the complete path One-way measurement metric with 230 some degree of accuracy. 232 2. Scope and Application 234 2.1. Scope of work 236 For the primary IPPM metrics of Loss [RFC2680], Delay [RFC2679], and 237 Delay Variation [RFC3393], this memo gives a set of metrics that can 238 be composed from the same or similar sub-path metrics. This means 239 that the composition function may utilize: 241 o the same metric for each sub-path; 243 o multiple metrics for each sub-path (possibly one that is the same 244 as the complete path metric); 246 o a single sub-path metric that is different from the complete path 247 metric; 249 o different measurement techniques like active [RFC2330], [RFC3432] 250 and passive [RFC5474]. 252 We note a possibility: Using a complete path metric and all but one 253 sub-path metric to infer the performance of the missing sub-path, 254 especially when the "last" sub-path metric is missing. However, such 255 de-composition calculations, and the corresponding set of issues they 256 raise, are beyond the scope of this memo. 258 2.2. Application 260 The composition framework [RFC5835] requires the specification of the 261 applicable circumstances for each metric. In particular, each 262 section addresses whether the metric: 264 Requires the same test packets to traverse all sub-paths, or may use 265 similar packets sent and collected separately in each sub-path. 267 Requires homogeneity of measurement methodologies, or can allow a 268 degree of flexibility (e.g., active or passive methods produce the 269 "same" metric). Also, the applicable sending streams will be 270 specified, such as Poisson, Periodic, or both. 272 Needs information or access that will only be available within an 273 operator's domain, or is applicable to Inter-domain composition. 275 Requires synchronized measurement start and stop times in all sub- 276 paths, or largely overlapping, or no timing requirements. 278 Requires assumption of sub-path independence w.r.t. the metric being 279 defined/composed, or other assumptions. 281 Has known sources of inaccuracy/error, and identifies the sources. 283 2.3. Incomplete Information 285 In practice, when measurements cannot be initiated on a sub-path (and 286 perhaps the measurement system gives up during the test interval), 287 then there will not be a value for the sub-path reported, and the 288 entire test result SHOULD be recorded as "undefined". This case 289 should be distinguished from the case where the measurement system 290 continued to send packets throughout the test interval, but all were 291 declared lost. 293 When a composed metric requires measurements from sub paths A, B, and 294 C, and one or more of the sub-path results are undefined, then the 295 composed metric SHOULD also be recorded as undefined. 297 3. Common Specifications for Composed Metrics 299 To reduce the redundant information presented in the detailed metrics 300 sections that follow, this section presents the specifications that 301 are common to two or more metrics. The section is organized using 302 the same subsections as the individual metrics, to simplify 303 comparisons. 305 Also, the following index variables represent the following: 307 o m = index for packets sent 309 o n = index for packets received 311 o s = index for involved sub-paths 313 3.1. Name: Type-P 315 All metrics use the Type-P convention as described in [RFC2330]. The 316 rest of the name is unique to each metric. 318 3.1.1. Metric Parameters 320 o Src, the IP address of a host 322 o Dst, the IP address of a host 324 o T, a time (start of test interval) 326 o Tf, a time (end of test interval) 328 o lambda, a rate in reciprocal seconds (for Poisson Streams) 330 o incT, the nominal duration of inter-packet interval, first bit to 331 first bit (for Periodic Streams) 333 o T0, a time that MUST be selected at random from the interval [T, 334 T+dT] to start generating packets and taking measurements (for 335 Periodic Streams) 337 o TstampSrc, the wire time of the packet as measured at MP(Src) 339 o TstampDst, the wire time of the packet as measured at MP(Dst), 340 assigned to packets that arrive within a "reasonable" time. 342 o Tmax, a maximum waiting time for packets at the destination, set 343 sufficiently long to disambiguate packets with long delays from 344 packets that are discarded (lost), thus the distribution of delay 345 is not truncated. 347 o M, the total number of packets sent between T0 and Tf 349 o N, the total number of packets received at Dst (sent between T0 350 and Tf) 352 o S, the number of sub-paths involved in the complete Src-Dst path 354 o Type-P, as defined in [RFC2330], which includes any field that may 355 affect a packet's treatment as it traverses the network 357 In metric names, the term is intended to be replaced by the 358 name of the method used to define a sample of values of parameter 359 TstampSrc. This can be done in several ways, including: 361 1. Poisson: a pseudo-random Poisson process of rate lambda, whose 362 values fall between T and Tf. The time interval between 363 successive values of TstampSrc will then average 1/lambda, as per 364 [RFC2330]. 366 2. Periodic: a periodic stream process with pseudo-random start time 367 T0 between T and dT, and nominal inter-packet interval incT, as 368 per [RFC3432]. 370 3.1.2. Definition and Metric Units 372 This section is unique for every metric. 374 3.1.3. Discussion and other details 376 This section is unique for every metric. 378 3.1.4. Statistic: 380 This section is unique for every metric. 382 3.1.5. Composition Function 384 This section is unique for every metric. 386 3.1.6. Statement of Conjecture and Assumptions 388 This section is unique for each metric. The term "ground truth" 389 frequently used in these sections and it is defined in section 4.7 of 390 [RFC5835]. 392 3.1.7. Justification of the Composition Function 394 It is sometimes impractical to conduct active measurements between 395 every Src-Dst pair. Since the full mesh of N measurement points 396 grows as N x N, the scope of measurement may be limited by testing 397 resources. 399 There may be varying limitations on active testing in different parts 400 of the network. For example, it may not be possible to collect the 401 desired sample size in each test interval when access link speed is 402 limited, because of the potential for measurement traffic to degrade 403 the user traffic performance. The conditions on a low-speed access 404 link may be understood well-enough to permit use of a small sample 405 size/rate, while a larger sample size/rate may be used on other sub- 406 paths. 408 Also, since measurement operations have a real monetary cost, there 409 is value in re-using measurements where they are applicable, rather 410 than launching new measurements for every possible source-destination 411 pair. 413 3.1.8. Sources of Deviation from the Ground Truth 415 3.1.8.1. Sub-path List Differs from Complete Path 417 The measurement packets, each having source and destination addresses 418 intended for collection at edges of the sub-path, may take a 419 different specific path through the network equipment and links when 420 compared to packets with the source and destination addresses of the 421 complete path. Examples sources of parallel paths include Equal Cost 422 Multi-Path and parallel (or bundled) links. Therefore, the 423 performance estimated from the composition of sub-path measurements 424 may differ from the performance experienced by packets on the 425 complete path. Multiple measurements employing sufficient sub-path 426 address pairs might produce bounds on the extent of this error. 428 We also note the possibility of re-routing during a measurement 429 interval, as it may affect the correspondence between packets 430 traversing the complete path and the sub-paths that were "involved" 431 prior to the re-route. 433 3.1.8.2. Sub-path Contains Extra Network Elements 435 Related to the case of an alternate path described above is the case 436 where elements in the measured path are unique to measurement system 437 connectivity. For example, a measurement system may use a dedicated 438 link to a LAN switch, and packets on the complete path do not 439 traverse that link. The performance of such a dedicated link would 440 be measured continuously, and its contribution to the sub-path 441 metrics SHOULD be minimized as a source of error. 443 3.1.8.3. Sub-paths Have Incomplete Coverage 445 Measurements of sub-path performance may not cover all the network 446 elements on the complete path. For example, the network exchange 447 points might be excluded unless a cooperative measurement is 448 conducted. In this example, test packets on the previous sub-path 449 are received just before the exchange point and test packets on the 450 next sub-path are injected just after the same exchange point. 451 Clearly, the set of sub-path measurements SHOULD cover all critical 452 network elements in the complete path. 454 3.1.8.4. Absence of route 456 At a specific point in time, no viable route exists between the 457 complete path source and destination. The routes selected for one or 458 more sub-paths therefore differs from the complete path. 459 Consequently, spatial composition may produce finite estimation of a 460 ground truth metric (see section 4.7 of [RFC5835]) between a source 461 and a destination, even when the route between them is undefined. 463 3.1.9. Specific cases where the conjecture might fail 465 This section is unique for most metrics (see the metric-specific 466 sections). 468 For delay-related metrics, One-way delay always depends on packet 469 size and link capacity, since it is measured in [RFC2679] from first 470 bit to last bit. If the size of an IP packet changes on route (due 471 to encapsulation), this can influence delay performance. However, 472 the main error source may be the additional processing associated 473 with encapsulation and encryption/decryption if not experienced or 474 accounted for in sub-path measurements. 476 Fragmentation is a major issue for composition accuracy, since all 477 metrics require all fragments to arrive before proceeding, and 478 fragmented complete path performance is likely to be different from 479 performance with non-fragmented packets and composed metrics based on 480 non-fragmented sub-path measurements. 482 Highly manipulated routing can cause measurement error if not 483 expected and compensated. For example, policy-based MPLS routing 484 could modify the class of service for the sub-paths and complete 485 path. 487 3.1.10. Application of Measurement Methodology 489 The methodology: 491 SHOULD use similar packets sent and collected separately in each sub- 492 path, where "similar" in this case means that the Type-P contains as 493 many equal attributes as possible, while recognizing that there will 494 be differences. Note that Type-P includes stream characteristics 495 (e.g., Poisson, Periodic). 497 Allows a degree of flexibility regarding test stream generation 498 (e.g., active or passive methods can produce an equivalent result, 499 but the lack of control over the source, timing and correlation of 500 passive measurements is much more challenging). 502 Poisson and/or Periodic streams are RECOMMENDED. 504 Applies to both Inter-domain and Intra-domain composition. 506 SHOULD have synchronized measurement time intervals in all sub-paths, 507 but largely overlapping intervals MAY suffice. 509 Assumption of sub-path independence w.r.t. the metric being defined/ 510 composed is REQUIRED. 512 4. One-way Delay Composed Metrics and Statistics 514 4.1. Name: Type-P-Finite-One-way-Delay--Stream 516 This metric is a necessary element of Delay Composition metrics, and 517 its definition does not formally exist elsewhere in IPPM literature. 519 4.1.1. Metric Parameters 521 See the common parameters section above. 523 4.1.2. Definition and Metric Units 525 Using the parameters above, we obtain the value of Type-P-One-way- 526 Delay singleton as per [RFC2679]. 528 For each packet [i] that has a finite One-way Delay (in other words, 529 excluding packets which have undefined one-way delay): 531 Type-P-Finite-One-way-Delay--Stream[i] = 533 FiniteDelay[i] = TstampDst - TstampSrc 535 The units of measure for this metric are time in seconds, expressed 536 in sufficiently low resolution to convey meaningful quantitative 537 information. For example, resolution of microseconds is usually 538 sufficient. 540 4.1.3. Discussion and other details 542 The "Type-P-Finite-One-way-Delay" metric permits calculation of the 543 sample mean statistic. This resolves the problem of including lost 544 packets in the sample (whose delay is undefined), and the issue with 545 the informal assignment of infinite delay to lost packets (practical 546 systems can only assign some very large value). 548 The Finite-One-way-Delay approach handles the problem of lost packets 549 by reducing the event space. We consider conditional statistics, and 550 estimate the mean one-way delay conditioned on the event that all 551 packets in the sample arrive at the destination (within the specified 552 waiting time, Tmax). This offers a way to make some valid statements 553 about one-way delay, and at the same time avoiding events with 554 undefined outcomes. This approach is derived from the treatment of 555 lost packets in [RFC3393], and is similar to [Y.1540] . 557 4.1.4. Statistic: 559 All statistics defined in [RFC2679] are applicable to the finite one- 560 way delay,and additional metrics are possible, such as the mean (see 561 below). 563 4.2. Name: Type-P-Finite-Composite-One-way-Delay-Mean 565 This section describes a statistic based on the Type-P-Finite-One- 566 way-Delay--Stream metric. 568 4.2.1. Metric Parameters 570 See the common parameters section above. 572 4.2.2. Definition and Metric Units of the Mean Statistic 574 We define 576 Type-P-Finite-One-way-Delay-Mean = 577 N 578 --- 579 1 \ 580 = MeanDelay = - * > (FiniteDelay [n]) 581 N / 582 --- 583 n = 1 585 where all packets n= 1 through N have finite singleton delays. 587 The units of measure for this metric are time in seconds, expressed 588 in sufficiently fine resolution to convey meaningful quantitative 589 information. For example, resolution of microseconds is usually 590 sufficient. 592 4.2.3. Discussion and other details 594 The Type-P-Finite-One-way-Delay-Mean metric requires the conditional 595 delay distribution described in section 5.1. 597 4.2.4. Statistic: 599 This metric, a mean, does not require additional statistics. 601 4.2.5. Composition Function: Sum of Means 603 The Type-P-Finite-Composite-One-way-Delay-Mean, or CompMeanDelay, for 604 the complete Source to Destination path can be calculated from sum of 605 the Mean Delays of all its S constituent sub-paths. 607 Then the 609 Type-P-Finite-Composite-One-way-Delay-Mean = 610 S 611 --- 612 \ 613 = CompMeanDelay = > (MeanDelay [s]) 614 / 615 --- 616 s = 1 617 where sub-paths s = 1 to S are involved in the complete path. 619 4.2.6. Statement of Conjecture and Assumptions 621 The mean of a sufficiently large stream of packets measured on each 622 sub-path during the interval [T, Tf] will be representative of the 623 ground truth mean of the delay distribution (and the distributions 624 themselves are sufficiently independent), such that the means may be 625 added to produce an estimate of the complete path mean delay. 627 It is assumed that the one-way delay distributions of the sub-paths 628 and the complete path are continuous. The mean of multi-modal 629 distributions have the unfortunate property that such a value may 630 never occur. 632 4.2.7. Justification of the Composition Function 634 See the common section. 636 4.2.8. Sources of Deviation from the Ground Truth 638 See the common section. 640 4.2.9. Specific cases where the conjecture might fail 642 If any of the sub-path distributions are multi-modal, then the 643 measured means may not be stable, and in this case the mean will not 644 be a particularly useful statistic when describing the delay 645 distribution of the complete path. 647 The mean may not be a sufficiently robust statistic to produce a 648 reliable estimate, or to be useful even if it can be measured. 650 If a link contributing non-negligible delay is erroneously included 651 or excluded, the composition will be in error. 653 4.2.10. Application of Measurement Methodology 655 The requirements of the common section apply here as well. 657 4.3. Name: Type-P-Finite-Composite-One-way-Delay-Minimum 659 This section describes is a statistic based on the Type-P-Finite-One- 660 way-Delay--Stream metric, and the composed metric based on 661 that statistic. 663 4.3.1. Metric Parameters 665 See the common parameters section above. 667 4.3.2. Definition and Metric Units of the Minimum Statistic 669 We define 671 Type-P-Finite-One-way-Delay-Minimum = 672 = MinDelay = (FiniteDelay [j]) 674 such that for some index, j, where 1<= j <= N 675 FiniteDelay[j] <= FiniteDelay[n] for all n 677 where all packets n = 1 through N have finite singleton delays. 679 The units of measure for this metric are time in seconds, expressed 680 in sufficiently fine resolution to convey meaningful quantitative 681 information. For example, resolution of microseconds is usually 682 sufficient. 684 4.3.3. Discussion and other details 686 The Type-P-Finite-One-way-Delay-Minimum metric requires the 687 conditional delay distribution described in section 5.1.3. 689 4.3.4. Statistic: 691 This metric, a minimum, does not require additional statistics. 693 4.3.5. Composition Function: Sum of Minima 695 The Type-P-Finite-Composite-One-way-Delay-Minimum, or CompMinDelay, 696 for the complete Source to Destination path can be calculated from 697 sum of the Minimum Delays of all its S constituent sub-paths. 699 Then the 701 Type-P-Finite-Composite-One-way-Delay-Minimum = 702 S 703 --- 704 \ 705 = CompMinDelay = > (MinDelay [s]) 706 / 707 --- 708 s = 1 710 4.3.6. Statement of Conjecture and Assumptions 712 The minimum of a sufficiently large stream of packets measured on 713 each sub-path during the interval [T, Tf] will be representative of 714 the ground truth minimum of the delay distribution (and the 715 distributions themselves are sufficiently independent), such that the 716 minima may be added to produce an estimate of the complete path 717 minimum delay. 719 It is assumed that the one-way delay distributions of the sub-paths 720 and the complete path are continuous. 722 4.3.7. Justification of the Composition Function 724 See the common section. 726 4.3.8. Sources of Deviation from the Ground Truth 728 See the common section. 730 4.3.9. Specific cases where the conjecture might fail 732 If the routing on any of the sub-paths is not stable, then the 733 measured minimum may not be stable. In this case the composite 734 minimum would tend to produce an estimate for the complete path that 735 may be too low for the current path. 737 4.3.10. Application of Measurement Methodology 739 The requirements of the common section apply here as well. 741 5. Loss Metrics and Statistics 743 5.1. Type-P-Composite-One-way-Packet-Loss-Empirical-Probability 745 5.1.1. Metric Parameters: 747 Same as section 4.1.1. 749 5.1.2. Definition and Metric Units 751 Using the parameters above, we obtain the value of Type-P-One-way- 752 Packet-Loss singleton and stream as per [RFC2680]. 754 We obtain a sequence of pairs with elements as follows: 756 o TstampSrc, as above 758 o L, either zero or one, where L=1 indicates loss and L=0 indicates 759 arrival at the destination within TstampSrc + Tmax. 761 5.1.3. Discussion and other details 763 None. 765 5.1.4. Statistic: Type-P-One-way-Packet-Loss-Empirical-Probability 767 Given the stream parameter M, the number of packets sent, we can 768 define the Empirical Probability of Loss Statistic (Ep), consistent 769 with Average Loss in [RFC2680], as follows: 771 Type-P-One-way-Packet-Loss-Empirical-Probability = 772 M 773 --- 774 1 \ 775 = Ep = - * > (L[m]) 776 M / 777 --- 778 m = 1 780 where all packets m = 1 through M have a value for L. 782 5.1.5. Composition Function: Composition of Empirical Probabilities 784 The Type-P-One-way-Composite-Packet-Loss-Empirical-Probability, or 785 CompEp for the complete Source to Destination path can be calculated 786 by combining Ep of all its constituent sub-paths (Ep1, Ep2, Ep3, ... 787 Epn) as 789 Type-P-Composite-One-way-Packet-Loss-Empirical-Probability = 790 = CompEp = 1 - {(1 - Ep1) x (1 - Ep2) x (1 - Ep3) x ... x (1 - EpS)} 792 If any Eps is undefined in a particular measurement interval, 793 possibly because a measurement system failed to report a value, then 794 any CompEp that uses sub-path s for that measurement interval is 795 undefined. 797 5.1.6. Statement of Conjecture and Assumptions 799 The empirical probability of loss calculated on a sufficiently large 800 stream of packets measured on each sub-path during the interval [T, 801 Tf] will be representative of the ground truth empirical loss 802 probability (and the probabilities themselves are sufficiently 803 independent), such that the sub-path probabilities may be combined to 804 produce an estimate of the complete path empirical loss probability. 806 5.1.7. Justification of the Composition Function 808 See the common section. 810 5.1.8. Sources of Deviation from the Ground Truth 812 See the common section. 814 5.1.9. Specific cases where the conjecture might fail 816 A concern for loss measurements combined in this way is that root 817 causes may be correlated to some degree. 819 For example, if the links of different networks follow the same 820 physical route, then a single catastrophic event like a fire in a 821 tunnel could cause an outage or congestion on remaining paths in 822 multiple networks. Here it is important to ensure that measurements 823 before the event and after the event are not combined to estimate the 824 composite performance. 826 Or, when traffic volumes rise due to the rapid spread of an email- 827 borne worm, loss due to queue overflow in one network may help 828 another network to carry its traffic without loss. 830 5.1.10. Application of Measurement Methodology 832 See the common section. 834 6. Delay Variation Metrics and Statistics 836 6.1. Name: Type-P-One-way-pdv-refmin--Stream 838 This packet delay variation (PDV) metric is a necessary element of 839 Composed Delay Variation metrics, and its definition does not 840 formally exist elsewhere in IPPM literature (with the exception of 841 [RFC5481] . 843 6.1.1. Metric Parameters: 845 In addition to the parameters of section 4.1.1: 847 o TstampSrc[i], the wire time of packet[i] as measured at MP(Src) 848 (measurement point at the source) 850 o TstampDst[i], the wire time of packet[i] as measured at MP(Dst), 851 assigned to packets that arrive within a "reasonable" time. 853 o B, a packet length in bits 855 o F, a selection function unambiguously defining the packets from 856 the stream that are selected for the packet-pair computation of 857 this metric. F(current packet), the first packet of the pair, 858 MUST have a valid Type-P-Finite-One-way-Delay less than Tmax (in 859 other words, excluding packets which have undefined one-way delay) 860 and MUST have been transmitted during the interval T, Tf. The 861 second packet in the pair, F(min_delay packet) MUST be the packet 862 with the minimum valid value of Type-P-Finite-One-way-Delay for 863 the stream, in addition to the criteria for F(current packet). If 864 multiple packets have equal minimum Type-P-Finite-One-way-Delay 865 values, then the value for the earliest arriving packet SHOULD be 866 used. 868 o MinDelay, the Type-P-Finite-One-way-Delay value for F(min_delay 869 packet) given above. 871 o N, the number of packets received at the Destination meeting the 872 F(current packet) criteria. 874 6.1.2. Definition and Metric Units 876 Using the definition above in section 5.1.2, we obtain the value of 877 Type-P-Finite-One-way-Delay--Stream[n], the singleton for 878 each packet[i] in the stream (a.k.a. FiniteDelay[i]). 880 For each packet[n] that meets the F(first packet) criteria given 881 above: Type-P-One-way-pdv-refmin--Stream[n] = 883 PDV[n] = FiniteDelay[n] - MinDelay 885 where PDV[i] is in units of time in seconds, expressed in 886 sufficiently fine resolution to convey meaningful quantitative 887 information. For example, resolution of microseconds is usually 888 sufficient. 890 6.1.3. Discussion and other details 892 This metric produces a sample of delay variation normalized to the 893 minimum delay of the sample. The resulting delay variation 894 distribution is independent of the sending sequence (although 895 specific FiniteDelay values within the distribution may be 896 correlated, depending on various stream parameters such as packet 897 spacing). This metric is equivalent to the IP Packet Delay Variation 898 parameter defined in [Y.1540]. 900 6.1.4. Statistics: Mean, Variance, Skewness, Quantile 902 We define the mean PDV as follows (where all packets n = 1 through N 903 have a value for PDV[n]): 905 Type-P-One-way-pdv-refmin-Mean = MeanPDV = 906 N 907 --- 908 1 \ 909 - * > (PDV[n]) 910 N / 911 --- 912 n = 1 914 We define the variance of PDV as follows: 916 Type-P-One-way-pdv-refmin-Variance = VarPDV = 917 N 918 --- 919 1 \ 2 920 ------- > (PDV[n] - MeanPDV) 921 (N - 1) / 922 --- 923 n = 1 925 We define the skewness of PDV as follows: 927 Type-P-One-way-pdv-refmin-Skewness = SkewPDV = 928 N 929 --- 3 930 \ / \ 931 > | PDV[n]- MeanPDV | 932 / \ / 933 --- 934 n = 1 935 ----------------------------------- 936 / \ 937 | ( 3/2 ) | 938 \ (N - 1) * VarPDV / 940 (see Appendix X of [Y.1541] for additional background information). 942 We define the Quantile of the PDVRefMin sample as the value where the 943 specified fraction of singletons is less than the given value. 945 6.1.5. Composition Functions: 947 This section gives two alternative composition functions. The 948 objective is to estimate a quantile of the complete path delay 949 variation distribution. The composed quantile will be estimated 950 using information from the sub-path delay variation distributions. 952 6.1.5.1. Approximate Convolution 954 The Type-P-Finite-One-way-Delay--Stream samples from each 955 sub-path are summarized as a histogram with 1 ms bins representing 956 the one-way delay distribution. 958 From [Stats], the distribution of the sum of independent random 959 variables can be derived using the relation: 961 Type-P-Composite-One-way-pdv-refmin-quantile-a = 963 . . 964 / / 965 P(X + Y + Z <= a) = | | P(X <= a-y-z) * P(Y = y) * P(Z = z) dy dz 966 / / 967 ` ` 968 z y 969 Note that dy and dz indicate partial integration above, and that y 970 and z are the integration variables. Also, the probablility of an 971 outcome is indicated by the symbol P(outcome). 973 where X, Y, and Z are random variables representing the delay 974 variation distributions of the sub-paths of the complete path (in 975 this case, there are three sub-paths), and a is the quantile of 976 interest. 978 This relation can be used to compose a quantile of interest for the 979 complete path from the sub-path delay distributions. The histograms 980 with 1 ms bins are discrete approximations of the delay 981 distributions. 983 6.1.5.2. Normal Power Approximation 985 Type-P-One-way-Composite-pdv-refmin-NPA for the complete Source to 986 Destination path can be calculated by combining statistics of all the 987 constituent sub-paths in the process described in [Y.1541] clause 8 988 and Appendix X. 990 6.1.6. Statement of Conjecture and Assumptions 992 The delay distribution of a sufficiently large stream of packets 993 measured on each sub-path during the interval [T, Tf] will be 994 sufficiently stationary and the sub-path distributions themselves are 995 sufficiently independent, so that summary information describing the 996 sub-path distributions can be combined to estimate the delay 997 distribution of complete path. 999 It is assumed that the one-way delay distributions of the sub-paths 1000 and the complete path are continuous. 1002 6.1.7. Justification of the Composition Function 1004 See the common section. 1006 6.1.8. Sources of Deviation from the Ground Truth 1008 In addition to the common deviations, a few additional sources exist 1009 here. For one, very tight distributions with range on the order of a 1010 few milliseconds are not accurately represented by a histogram with 1 1011 ms bins. This size was chosen assuming an implicit requirement on 1012 accuracy: errors of a few milliseconds are acceptable when assessing 1013 a composed distribution quantile. 1015 Also, summary statistics cannot describe the subtleties of an 1016 empirical distribution exactly, especially when the distribution is 1017 very different from a classical form. Any procedure that uses these 1018 statistics alone may incur error. 1020 6.1.9. Specific cases where the conjecture might fail 1022 If the delay distributions of the sub-paths are somehow correlated, 1023 then neither of these composition functions will be reliable 1024 estimators of the complete path distribution. 1026 In practice, sub-path delay distributions with extreme outliers have 1027 increased the error of the composed metric estimate. 1029 6.1.10. Application of Measurement Methodology 1031 See the common section. 1033 7. Security Considerations 1035 7.1. Denial of Service Attacks 1037 This metric requires a stream of packets sent from one host (source) 1038 to another host (destination) through intervening networks. This 1039 method could be abused for denial of service attacks directed at the 1040 destination and/or the intervening network(s). 1042 Administrators of source, destination, and the intervening network(s) 1043 should establish bilateral or multi-lateral agreements regarding the 1044 timing, size, and frequency of collection of sample metrics. Use of 1045 this method in excess of the terms agreed between the participants 1046 may be cause for immediate rejection or discard of packets or other 1047 escalation procedures defined between the affected parties. 1049 7.2. User Data Confidentiality 1051 Active use of this method generates packets for a sample, rather than 1052 taking samples based on user data, and does not threaten user data 1053 confidentiality. Passive measurement MUST restrict attention to the 1054 headers of interest. Since user payloads may be temporarily stored 1055 for length analysis, suitable precautions MUST be taken to keep this 1056 information safe and confidential. In most cases, a hashing function 1057 will produce a value suitable for payload comparisons. 1059 7.3. Interference with the metrics 1061 It may be possible to identify that a certain packet or stream of 1062 packets is part of a sample. With that knowledge at the destination 1063 and/or the intervening networks, it is possible to change the 1064 processing of the packets (e.g. increasing or decreasing delay) that 1065 may distort the measured performance. It may also be possible to 1066 generate additional packets that appear to be part of the sample 1067 metric. These additional packets are likely to perturb the results 1068 of the sample measurement. 1070 To discourage the kind of interference mentioned above, packet 1071 interference checks, such as cryptographic hash, may be used. 1073 8. IANA Considerations 1075 Metrics defined in IETF are typically registered in the IANA IPPM 1076 METRICS REGISTRY as described in initial version of the registry 1077 [RFC4148]. 1079 IANA is asked to register the following metrics in the IANA-IPPM- 1080 METRICS-REGISTRY-MIB: 1082 ietfFiniteOneWayDelayStream OBJECT-IDENTITY 1083 STATUS current 1084 DESCRIPTION 1085 "Type-P-Finite-One-way-Delay-Stream" 1086 REFERENCE 1087 "Reference "RFCyyyy, section 4.1." 1088 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1089 note 1090 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1092 ietfFiniteOneWayDelayMean OBJECT-IDENTITY 1093 STATUS current 1094 DESCRIPTION 1095 "Type-P-Finite-One-way-Delay-Mean" 1096 REFERENCE 1097 "Reference "RFCyyyy, section 4.2." 1098 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1099 note 1100 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1102 ietfCompositeOneWayDelayMean OBJECT-IDENTITY 1103 STATUS current 1104 DESCRIPTION 1105 "Type-P-Finite-Composite-One-way-Delay-Mean" 1106 REFERENCE 1107 "Reference "RFCyyyy, section 4.2.5." 1108 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1109 note 1110 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1112 ietfFiniteOneWayDelayMinimum OBJECT-IDENTITY 1113 STATUS current 1114 DESCRIPTION 1115 "Type-P-Finite-One-way-Delay-Minimum" 1116 REFERENCE 1117 "Reference "RFCyyyy, section 4.3.2." 1118 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1119 note 1120 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1122 ietfCompositeOneWayDelayMinimum OBJECT-IDENTITY 1123 STATUS current 1124 DESCRIPTION 1125 "Type-P-Finite-Composite-One-way-Delay-Minimum" 1126 REFERENCE 1127 "Reference "RFCyyyy, section 4.3." 1128 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1129 note 1130 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1132 ietfOneWayPktLossEmpiricProb OBJECT-IDENTITY 1133 STATUS current 1134 DESCRIPTION 1135 "Type-P-One-way-Packet-Loss-Empirical-Probability" 1136 REFERENCE 1137 "Reference "RFCyyyy, section 5.1.4" 1138 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1139 note 1140 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1142 ietfCompositeOneWayPktLossEmpiricProb OBJECT-IDENTITY 1143 STATUS current 1144 DESCRIPTION 1145 "Type-P-Composite-One-way-Packet-Loss-Empirical-Probability" 1146 REFERENCE 1147 "Reference "RFCyyyy, section 5.1." 1148 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1149 note 1150 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1152 ietfOneWayPdvRefminStream OBJECT-IDENTITY 1153 STATUS current 1154 DESCRIPTION 1155 "Type-P-One-way-pdv-refmin-Stream" 1156 REFERENCE 1157 "Reference "RFCyyyy, section 6.1." 1158 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1159 note 1160 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1162 ietfOneWayPdvRefminMean OBJECT-IDENTITY 1163 STATUS current 1164 DESCRIPTION 1165 "Type-P-One-way-pdv-refmin-Mean" 1166 REFERENCE 1167 "Reference "RFCyyyy, section 6.1.4." 1168 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1169 note 1170 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1172 ietfOneWayPdvRefminVariance OBJECT-IDENTITY 1173 STATUS current 1174 DESCRIPTION 1175 "Type-P-One-way-pdv-refmin-Variance" 1176 REFERENCE 1177 "Reference "RFCyyyy, section 6.1.4." 1178 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1179 note 1180 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1182 ietfOneWayPdvRefminSkewness OBJECT-IDENTITY 1183 STATUS current 1184 DESCRIPTION 1185 "Type-P-One-way-pdv-refmin-Skewness" 1186 REFERENCE 1187 "Reference "RFCyyyy, section 6.1.4." 1188 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1189 note 1190 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1192 ietfCompositeOneWayPdvRefminQtil OBJECT-IDENTITY 1193 STATUS current 1194 DESCRIPTION 1195 "Type-P-Composite-One-way-pdv-refmin-quantile-a" 1196 REFERENCE 1197 "Reference "RFCyyyy, section 6.1.5.1." 1198 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1199 note 1200 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1202 ietfCompositeOneWayPdvRefminNPA OBJECT-IDENTITY 1203 STATUS current 1204 DESCRIPTION 1205 "Type-P-One-way-Composite-pdv-refmin-NPA" 1206 REFERENCE 1207 "Reference "RFCyyyy, section 6.1.5.2." 1208 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1209 note 1210 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1212 9. Contributors and Acknowledgements 1214 The following people have contributed useful ideas, suggestions, or 1215 the text of sections that have been incorporated into this memo: 1217 - Phil Chimento 1219 - Reza Fardid 1221 - Roman Krzanowski 1223 - Maurizio Molina 1225 - Lei Liang 1227 - Dave Hoeflin 1229 A long time ago, in a galaxy far, far away (Minneapolis), Will Leland 1230 suggested the simple and elegant Type-P-Finite-One-way-Delay concept. 1231 Thanks Will. 1233 Yaakov Stein and Donald McLachlan also provided useful comments along 1234 the way. 1236 10. References 1238 10.1. Normative References 1240 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1241 Requirement Levels", BCP 14, RFC 2119, March 1997. 1243 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1244 "Framework for IP Performance Metrics", RFC 2330, 1245 May 1998. 1247 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1248 Delay Metric for IPPM", RFC 2679, September 1999. 1250 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1251 Packet Loss Metric for IPPM", RFC 2680, September 1999. 1253 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1254 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1255 November 2002. 1257 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 1258 performance measurement with periodic streams", RFC 3432, 1259 November 2002. 1261 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 1262 Registry", BCP 108, RFC 4148, August 2005. 1264 [RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric 1265 Composition", RFC 5835, April 2010. 1267 10.2. Informative References 1269 [RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A., 1270 Grossglauser, M., and J. Rexford, "A Framework for Packet 1271 Selection and Reporting", RFC 5474, March 2009. 1273 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 1274 Applicability Statement", RFC 5481, March 2009. 1276 [Stats] McGraw-Hill NY NY, "Introduction to the Theory of 1277 Statistics, 3rd Edition,", 1974. 1279 [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data 1280 communication service - IP packet transfer and 1281 availability performance parameters", November 2007. 1283 [Y.1541] ITU-T Recommendation Y.1541, "Network Performance 1284 Objectives for IP-based Services", February 2006. 1286 Index 1288 ? 1289 ??? 14 1291 Authors' Addresses 1293 Al Morton 1294 AT&T Labs 1295 200 Laurel Avenue South 1296 Middletown,, NJ 07748 1297 USA 1299 Phone: +1 732 420 1571 1300 Fax: +1 732 368 1192 1301 Email: acmorton@att.com 1302 URI: http://home.comcast.net/~acmacm/ 1303 Emile Stephan 1304 France Telecom Division R&D 1305 2 avenue Pierre Marzin 1306 Lannion, F-22307 1307 France 1309 Phone: 1310 Fax: +33 2 96 05 18 52 1311 Email: emile.stephan@orange-ftgroup.com 1312 URI: