idnits 2.17.1 draft-ietf-ippm-spatial-composition-15.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 (July 2, 2010) is 5040 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 964, but not defined == Missing Reference: 'Tf' is mentioned on line 964, but not defined == Unused Reference: 'RFC5644' is defined on line 1246, but no explicit reference was found in the text ** 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 (~~), 4 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: January 3, 2011 France Telecom Division R&D 6 July 2, 2010 8 Spatial Composition of Metrics 9 draft-ietf-ippm-spatial-composition-15 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 January 3, 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: 96 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream . . . 12 97 4.1.1. Metric Parameters . . . . . . . . . . . . . . . . . . 12 98 4.1.2. Definition and Metric Units . . . . . . . . . . . . . 12 99 4.1.3. Discussion and other details . . . . . . . . . . . . . 12 100 4.1.4. Statistic: . . . . . . . . . . . . . . . . . . . . . . 13 101 4.2. Name: Type-P-Finite-Composite-One-way-Delay-Mean . . . . . 13 102 4.2.1. Metric Parameters . . . . . . . . . . . . . . . . . . 13 103 4.2.2. Definition and Metric Units of the Mean Statistic . . 13 104 4.2.3. Discussion and other details . . . . . . . . . . . . . 13 105 4.2.4. Statistic: . . . . . . . . . . . . . . . . . . . . . . 13 106 4.2.5. Composition Function: Sum of Means . . . . . . . . . . 13 107 4.2.6. Statement of Conjecture and Assumptions . . . . . . . 14 108 4.2.7. Justification of the Composition Function . . . . . . 14 109 4.2.8. Sources of Deviation from the Ground Truth . . . . . . 14 110 4.2.9. Specific cases where the conjecture might fail . . . . 14 111 4.2.10. Application of Measurement Methodology . . . . . . . . 15 112 4.3. Name: Type-P-Finite-Composite-One-way-Delay-Minimum . . . 15 113 4.3.1. Metric Parameters . . . . . . . . . . . . . . . . . . 15 114 4.3.2. Definition and Metric Units of the Minimum 115 Statistic . . . . . . . . . . . . . . . . . . . . . . 15 116 4.3.3. Discussion and other details . . . . . . . . . . . . . 15 117 4.3.4. Statistic: . . . . . . . . . . . . . . . . . . . . . . 15 118 4.3.5. Composition Function: Sum of Minima . . . . . . . . . 15 119 4.3.6. Statement of Conjecture and Assumptions . . . . . . . 16 120 4.3.7. Justification of the Composition Function . . . . . . 16 121 4.3.8. Sources of Deviation from the Ground Truth . . . . . . 16 122 4.3.9. Specific cases where the conjecture might fail . . . . 16 123 4.3.10. Application of Measurement Methodology . . . . . . . . 16 124 5. Loss Metrics and Statistics . . . . . . . . . . . . . . . . . 16 125 5.1. Type-P-Composite-One-way-Packet-Loss-Empirical-Probability 16 126 5.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 17 127 5.1.2. Definition and Metric Units . . . . . . . . . . . . . 17 128 5.1.3. Discussion and other details . . . . . . . . . . . . . 17 129 5.1.4. Statistic: 130 Type-P-One-way-Packet-Loss-Empirical-Probability . . . 17 131 5.1.5. Composition Function: Composition of Empirical 132 Probabilities . . . . . . . . . . . . . . . . . . . . 17 133 5.1.6. Statement of Conjecture and Assumptions . . . . . . . 18 134 5.1.7. Justification of the Composition Function . . . . . . 18 135 5.1.8. Sources of Deviation from the Ground Truth . . . . . . 18 136 5.1.9. Specific cases where the conjecture might fail . . . . 18 137 5.1.10. Application of Measurement Methodology . . . . . . . . 18 138 6. Delay Variation Metrics and Statistics . . . . . . . . . . . . 18 139 6.1. Name: Type-P-One-way-pdv-refmin-Poisson/Periodic-Stream . 18 140 6.1.1. Metric Parameters: . . . . . . . . . . . . . . . . . . 19 141 6.1.2. Definition and Metric Units . . . . . . . . . . . . . 19 142 6.1.3. Discussion and other details . . . . . . . . . . . . . 20 143 6.1.4. Statistics: Mean, Variance, Skewness, Quantile . . . . 20 144 6.1.5. Composition Functions: . . . . . . . . . . . . . . . . 21 145 6.1.6. Statement of Conjecture and Assumptions . . . . . . . 22 146 6.1.7. Justification of the Composition Function . . . . . . 22 147 6.1.8. Sources of Deviation from the Ground Truth . . . . . . 22 148 6.1.9. Specific cases where the conjecture might fail . . . . 22 149 6.1.10. Application of Measurement Methodology . . . . . . . . 23 150 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 151 7.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 23 152 7.2. User Data Confidentiality . . . . . . . . . . . . . . . . 23 153 7.3. Interference with the metrics . . . . . . . . . . . . . . 23 154 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 155 9. Contributors and Acknowledgements . . . . . . . . . . . . . . 27 156 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 157 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 158 10.2. Informative References . . . . . . . . . . . . . . . . . . 28 159 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 160 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 162 1. Introduction 164 The IP Performance Metrics (IPPM) framework [RFC2330] describes two 165 forms of metric composition, spatial and temporal. The composition 166 framework [RFC5835] expands and further qualifies these original 167 forms into three categories. This memo describes Spatial 168 Composition, one of the categories of metrics under the umbrella of 169 the composition framework. 171 Spatial composition encompasses the definition of performance metrics 172 that are applicable to a complete path, based on metrics collected on 173 various sub-paths. 175 The main purpose of this memo is to define the deterministic 176 functions that yield the complete path metrics using metrics of the 177 sub-paths. The effectiveness of such metrics is dependent on their 178 usefulness in analysis and applicability with practical measurement 179 methods. 181 The relationships may involve conjecture, and [RFC2330] lists four 182 points that the metric definitions should include: 184 o the specific conjecture applied to the metric and assumptions of 185 the statistical model of the process being measured (if any, see 186 [RFC2330] section 12), 188 o a justification of the practical utility of the composition in 189 terms of making accurate measurements of the metric on the path, 191 o a justification of the usefulness of the composition in terms of 192 making analysis of the path using A-frame concepts more effective, 193 and 195 o an analysis of how the conjecture could be incorrect. 197 Also, [RFC2330] gives an example using the conjecture that the delay 198 of a path is very nearly the sum of the delays of the exchanges and 199 clouds of the corresponding path digest. This example is 200 particularly relevant to those who wish to assess the performance of 201 an Inter-domain path without direct measurement, and the performance 202 estimate of the complete path is related to the measured results for 203 various sub-paths instead. 205 Approximate functions between the sub-path and complete path metrics 206 are useful, with knowledge of the circumstances where the 207 relationships are/are not applicable. For example, we would not 208 expect that delay singletons from each sub-path would sum to produce 209 an accurate estimate of a delay singleton for the complete path 210 (unless all the delays were essentially constant - very unlikely). 211 However, other delay statistics (based on a reasonable sample size) 212 may have a sufficiently large set of circumstances where they are 213 applicable. 215 1.1. Motivation 217 One-way metrics defined in other RFCs (such as [RFC2679] and 218 [RFC2680]) all assume that the measurement can be practically carried 219 out between the source and the destination of interest. Sometimes 220 there are reasons that the measurement cannot be executed from the 221 source to the destination. For instance, the measurement path may 222 cross several independent domains that have conflicting policies, 223 measurement tools and methods, and measurement time assignment. The 224 solution then may be the composition of several sub-path 225 measurements. This means each domain performs the One-way 226 measurement on a sub path between two nodes that are involved in the 227 complete path following its own policy, using its own measurement 228 tools and methods, and using its own measurement timing. Under the 229 appropriate conditions, one can combine the sub-path One-way metric 230 results to estimate the complete path One-way measurement metric with 231 some degree of accuracy. 233 2. Scope and Application 235 2.1. Scope of work 237 For the primary IPPM metrics of Loss [RFC2680], Delay [RFC2679], and 238 Delay Variation [RFC3393], this memo gives a set of metrics that can 239 be composed from the same or similar sub-path metrics. This means 240 that the composition function may utilize: 242 o the same metric for each sub-path; 244 o multiple metrics for each sub-path (possibly one that is the same 245 as the complete path metric); 247 o a single sub-path metric that is different from the complete path 248 metric; 250 o different measurement techniques like active [RFC2330], [RFC3432] 251 and passive [RFC5474]. 253 We note a possibility: Using a complete path metric and all but one 254 sub-path metric to infer the performance of the missing sub-path, 255 especially when the "last" sub-path metric is missing. However, such 256 de-composition calculations, and the corresponding set of issues they 257 raise, are beyond the scope of this memo. 259 2.2. Application 261 The composition framework [RFC5835] requires the specification of the 262 applicable circumstances for each metric. In particular, each 263 section addresses whether the metric: 265 Requires the same test packets to traverse all sub-paths, or may use 266 similar packets sent and collected separately in each sub-path. 268 Requires homogeneity of measurement methodologies, or can allow a 269 degree of flexibility (e.g., active or passive methods produce the 270 "same" metric). Also, the applicable sending streams will be 271 specified, such as Poisson, Periodic, or both. 273 Needs information or access that will only be available within an 274 operator's domain, or is applicable to Inter-domain composition. 276 Requires synchronized measurement time intervals in all sub-paths, or 277 largely overlapping, or no timing requirements. 279 Requires assumption of sub-path independence w.r.t. the metric being 280 defined/composed, or other assumptions. 282 Has known sources of inaccuracy/error, and identifies the sources. 284 2.3. Incomplete Information 286 In practice, when measurements cannot be initiated on a sub-path (and 287 perhaps the measurement system gives up during the test interval), 288 then there will not be a value for the sub-path reported, and the 289 entire test result SHOULD be recorded as "undefined". This case 290 should be distinguished from the case where the measurement system 291 continued to send packets throughout the test interval, but all were 292 declared lost. 294 When a composed metric requires measurements from sub paths A, B, and 295 C, and one or more of the sub-path results are undefined, then the 296 composed metric SHOULD also be recorded as undefined. 298 3. Common Specifications for Composed Metrics 300 To reduce the redundant information presented in the detailed metrics 301 sections that follow, this section presents the specifications that 302 are common to two or more metrics. The section is organized using 303 the same subsections as the individual metrics, to simplify 304 comparisons. 306 Also, the following index variables represent the following: 308 o m = index for packets sent 310 o n = index for packets received 312 o s = index for involved sub-paths 314 3.1. Name: Type-P 316 All metrics use the Type-P convention as described in [RFC2330]. The 317 rest of the name is unique to each metric. 319 3.1.1. Metric Parameters 321 o Src, the IP address of a host 323 o Dst, the IP address of a host 325 o T, a time (start of test interval) 327 o Tf, a time (end of test interval) 329 o lambda, a rate in reciprocal seconds (for Poisson Streams) 331 o incT, the nominal duration of inter-packet interval, first bit to 332 first bit (for Periodic Streams) 334 o T0, a time that MUST be selected at random from the interval [T, 335 T+dT] to start generating packets and taking measurements (for 336 Periodic Streams) 338 o TstampSrc, the wire time of the packet as measured at MP(Src) 340 o TstampDst, the wire time of the packet as measured at MP(Dst), 341 assigned to packets that arrive within a "reasonable" time. 343 o Tmax, a maximum waiting time for packets at the destination, set 344 sufficiently long to disambiguate packets with long delays from 345 packets that are discarded (lost), thus the distribution of delay 346 is not truncated. 348 o M, the total number of packets sent between T0 and Tf 350 o N, the total number of packets received at Dst (sent between T0 351 and Tf) 353 o S, the number of sub-paths involved in the complete Src-Dst path 355 o Type-P, as defined in [RFC2330], which includes any field that may 356 affect a packet's treatment as it traverses the network 358 3.1.2. Definition and Metric Units 360 This section is unique for every metric. 362 3.1.3. Discussion and other details 364 This section is unique for every metric. 366 3.1.4. Statistic: 368 This section is unique for every metric. 370 3.1.5. Composition Function 372 This section is unique for every metric. 374 3.1.6. Statement of Conjecture and Assumptions 376 This section is unique for each metric. 378 3.1.7. Justification of the Composition Function 380 It is sometimes impractical to conduct active measurements between 381 every Src-Dst pair. Since the full mesh of N measurement points 382 grows as N x N, the scope of measurement may be limited by testing 383 resources. 385 There may be varying limitations on active testing in different parts 386 of the network. For example, it may not be possible to collect the 387 desired sample size in each test interval when access link speed is 388 limited, because of the potential for measurement traffic to degrade 389 the user traffic performance. The conditions on a low-speed access 390 link may be understood well-enough to permit use of a small sample 391 size/rate, while a larger sample size/rate may be used on other sub- 392 paths. 394 Also, since measurement operations have a real monetary cost, there 395 is value in re-using measurements where they are applicable, rather 396 than launching new measurements for every possible source-destination 397 pair. 399 3.1.8. Sources of Deviation from the Ground Truth 401 3.1.8.1. Sub-path List Differs from Complete Path 403 The measurement packets, each having source and destination addresses 404 intended for collection at edges of the sub-path, may take a 405 different specific path through the network equipment and links when 406 compared to packets with the source and destination addresses of the 407 complete path. Examples sources of parallel paths include Equal Cost 408 Multi-Path and parallel (or bundled) links. Therefore, the 409 performance estimated from the composition of sub-path measurements 410 may differ from the performance experienced by packets on the 411 complete path. Multiple measurements employing sufficient sub-path 412 address pairs might produce bounds on the extent of this error. 414 We also note the possibility of re-routing during a measurement 415 interval, as it may affect the correspondence between packets 416 traversing the complete path and the sub-paths that were "involved" 417 prior to the re-route. 419 3.1.8.2. Sub-path Contains Extra Network Elements 421 Related to the case of an alternate path described above is the case 422 where elements in the measured path are unique to measurement system 423 connectivity. For example, a measurement system may use a dedicated 424 link to a LAN switch, and packets on the complete path do not 425 traverse that link. The performance of such a dedicated link would 426 be measured continuously, and its contribution to the sub-path 427 metrics SHOULD be minimized as a source of error. 429 3.1.8.3. Sub-paths Have Incomplete Coverage 431 Measurements of sub-path performance may not cover all the network 432 elements on the complete path. For example, the network exchange 433 points might be excluded unless a cooperative measurement is 434 conducted. In this example, test packets on the previous sub-path 435 are received just before the exchange point and test packets on the 436 next sub-path are injected just after the same exchange point. 437 Clearly, the set of sub-path measurements SHOULD cover all critical 438 network elements in the complete path. 440 3.1.8.4. Absence of route 442 At a specific point in time, no viable route exists between the 443 complete path source and destination. The routes selected for one or 444 more sub-paths therefore differs from the complete path. 445 Consequently, spatial composition may produce finite estimation of a 446 ground truth metric between a source and a destination, even when the 447 route between them is undefined. 449 3.1.9. Specific cases where the conjecture might fail 451 This section is unique for most metrics (see the metric-specific 452 sections). 454 For delay-related metrics, One-way delay always depends on packet 455 size and link capacity, since it is measured in [RFC2679] from first 456 bit to last bit. If the size of an IP packet changes on route (due 457 to encapsulation), this can influence delay performance. However, 458 the main error source may be the additional processing associated 459 with encapsulation and encryption/decryption if not experienced or 460 accounted for in sub-path measurements. 462 Fragmentation is a major issue for composition accuracy, since all 463 metrics require all fragments to arrive before proceeding, and 464 fragmented complete path performance is likely to be different from 465 performance with non-fragmented packets and composed metrics based on 466 non-fragmented sub-path measurements. 468 Highly manipulated routing can cause measurement error if not 469 expected and compensated. For example, policy-based MPLS routing 470 could modify the class of service for the sub-paths and complete 471 path. 473 3.1.10. Application of Measurement Methodology 475 The methodology: 477 SHOULD use similar packets sent and collected separately in each sub- 478 path, where "similar" in this case means that the Type-P contains as 479 many equal attributes as possible, while recognizing that there will 480 be differences. Note that Type-P includes stream characteristics 481 (e.g., Poisson, Periodic). 483 Allows a degree of flexibility regarding test stream generation 484 (e.g., active or passive methods can produce an equivalent result, 485 but the lack of control over the source, timing and correlation of 486 passive measurements is much more challenging). 488 Poisson and/or Periodic streams are RECOMMENDED. 490 Applies to both Inter-domain and Intra-domain composition. 492 SHOULD have synchronized measurement time intervals in all sub-paths, 493 but largely overlapping intervals MAY suffice. 495 Assumption of sub-path independence w.r.t. the metric being defined/ 496 composed is REQUIRED. 498 4. One-way Delay Composed Metrics and Statistics 500 4.1. Name: Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream 502 This metric is a necessary element of Delay Composition metrics, and 503 its definition does not formally exist elsewhere in IPPM literature. 505 4.1.1. Metric Parameters 507 See the common parameters section above. 509 4.1.2. Definition and Metric Units 511 Using the parameters above, we obtain the value of Type-P-One-way- 512 Delay singleton as per [RFC2679]. 514 For each packet [i] that has a finite One-way Delay (in other words, 515 excluding packets which have undefined one-way delay): 517 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i] = 519 FiniteDelay[i] = TstampDst - TstampSrc 521 The units of measure for this metric are time in seconds, expressed 522 in sufficiently low resolution to convey meaningful quantitative 523 information. For example, resolution of microseconds is usually 524 sufficient. 526 4.1.3. Discussion and other details 528 The "Type-P-Finite-One-way-Delay" metric permits calculation of the 529 sample mean statistic. This resolves the problem of including lost 530 packets in the sample (whose delay is undefined), and the issue with 531 the informal assignment of infinite delay to lost packets (practical 532 systems can only assign some very large value). 534 The Finite-One-way-Delay approach handles the problem of lost packets 535 by reducing the event space. We consider conditional statistics, and 536 estimate the mean one-way delay conditioned on the event that all 537 packets in the sample arrive at the destination (within the specified 538 waiting time, Tmax). This offers a way to make some valid statements 539 about one-way delay, and at the same time avoiding events with 540 undefined outcomes. This approach is derived from the treatment of 541 lost packets in [RFC3393], and is similar to [Y.1540] . 543 4.1.4. Statistic: 545 All statistics defined in [RFC2679] are applicable to the finite one- 546 way delay,and additional metrics are possible, such as the mean (see 547 below). 549 4.2. Name: Type-P-Finite-Composite-One-way-Delay-Mean 551 This section describes a statistic based on the Type-P-Finite-One- 552 way-Delay-Poisson/Periodic-Stream metric. 554 4.2.1. Metric Parameters 556 See the common parameters section above. 558 4.2.2. Definition and Metric Units of the Mean Statistic 560 We define 562 Type-P-Finite-One-way-Delay-Mean = 563 N 564 --- 565 1 \ 566 MeanDelay = - * > (FiniteDelay [n]) 567 N / 568 --- 569 n = 1 571 where all packets n= 1 through N have finite singleton delays. 573 The units of measure for this metric are time in seconds, expressed 574 in sufficiently fine resolution to convey meaningful quantitative 575 information. For example, resolution of microseconds is usually 576 sufficient. 578 4.2.3. Discussion and other details 580 The Type-P-Finite-One-way-Delay-Mean metric requires the conditional 581 delay distribution described in section 5.1. 583 4.2.4. Statistic: 585 This metric, a mean, does not require additional statistics. 587 4.2.5. Composition Function: Sum of Means 589 The Type-P-Finite--Composite-One-way-Delay-Mean, or CompMeanDelay, 590 for the complete Source to Destination path can be calculated from 591 sum of the Mean Delays of all its S constituent sub-paths. 593 Then the 595 Type-P-Finite-Composite-One-way-Delay-Mean = 596 S 597 --- 598 \ 599 CompMeanDelay = > (MeanDelay [s]) 600 / 601 --- 602 s = 1 603 where sub-paths s = 1 to S are involved in the complete path. 605 4.2.6. Statement of Conjecture and Assumptions 607 The mean of a sufficiently large stream of packets measured on each 608 sub-path during the interval [T, Tf] will be representative of the 609 ground truth mean of the delay distribution (and the distributions 610 themselves are sufficiently independent), such that the means may be 611 added to produce an estimate of the complete path mean delay. 613 It is assumed that the one-way delay distributions of the sub-paths 614 and the complete path are continuous. The mean of multi-modal 615 distributions have the unfortunate property that such a value may 616 never occur. 618 4.2.7. Justification of the Composition Function 620 See the common section. 622 4.2.8. Sources of Deviation from the Ground Truth 624 See the common section. 626 4.2.9. Specific cases where the conjecture might fail 628 If any of the sub-path distributions are multi-modal, then the 629 measured means may not be stable, and in this case the mean will not 630 be a particularly useful statistic when describing the delay 631 distribution of the complete path. 633 The mean may not be a sufficiently robust statistic to produce a 634 reliable estimate, or to be useful even if it can be measured. 636 If a link contributing non-negligible delay is erroneously included 637 or excluded, the composition will be in error. 639 4.2.10. Application of Measurement Methodology 641 The requirements of the common section apply here as well. 643 4.3. Name: Type-P-Finite-Composite-One-way-Delay-Minimum 645 This section describes is a statistic based on the Type-P-Finite-One- 646 way-Delay-Poisson/Periodic-Stream metric, and the composed metric 647 based on that statistic. 649 4.3.1. Metric Parameters 651 See the common parameters section above. 653 4.3.2. Definition and Metric Units of the Minimum Statistic 655 We define 657 Type-P-Finite-One-way-Delay-Minimum = 658 = MinDelay = (FiniteDelay [j]) 660 such that for some index, j, where 1<= j <= N 661 FiniteDelay[j] <= FiniteDelay[n] for all n 663 where all packets n = 1 through N have finite singleton delays. 665 The units of measure for this metric are time in seconds, expressed 666 in sufficiently fine resolution to convey meaningful quantitative 667 information. For example, resolution of microseconds is usually 668 sufficient. 670 4.3.3. Discussion and other details 672 The Type-P-Finite-One-way-Delay-Minimum metric requires the 673 conditional delay distribution described in section 5.1.3. 675 4.3.4. Statistic: 677 This metric, a minimum, does not require additional statistics. 679 4.3.5. Composition Function: Sum of Minima 681 The Type-P-Finite--Composite-One-way-Delay-Minimum, or CompMinDelay, 682 for the complete Source to Destination path can be calculated from 683 sum of the Minimum Delays of all its S constituent sub-paths. 685 Then the 686 Type-P-Finite-Composite-One-way-Delay-Minimum = 687 S 688 --- 689 \ 690 CompMinDelay = > (MinDelay [s]) 691 / 692 --- 693 s = 1 695 4.3.6. Statement of Conjecture and Assumptions 697 The minimum of a sufficiently large stream of packets measured on 698 each sub-path during the interval [T, Tf] will be representative of 699 the ground truth minimum of the delay distribution (and the 700 distributions themselves are sufficiently independent), such that the 701 minima may be added to produce an estimate of the complete path 702 minimum delay. 704 It is assumed that the one-way delay distributions of the sub-paths 705 and the complete path are continuous. 707 4.3.7. Justification of the Composition Function 709 See the common section. 711 4.3.8. Sources of Deviation from the Ground Truth 713 See the common section. 715 4.3.9. Specific cases where the conjecture might fail 717 If the routing on any of the sub-paths is not stable, then the 718 measured minimum may not be stable. In this case the composite 719 minimum would tend to produce an estimate for the complete path that 720 may be too low for the current path. 722 4.3.10. Application of Measurement Methodology 724 The requirements of the common section apply here as well. 726 5. Loss Metrics and Statistics 728 5.1. Type-P-Composite-One-way-Packet-Loss-Empirical-Probability 729 5.1.1. Metric Parameters: 731 Same as section 4.1.1. 733 5.1.2. Definition and Metric Units 735 Using the parameters above, we obtain the value of Type-P-One-way- 736 Packet-Loss singleton and stream as per [RFC2680]. 738 We obtain a sequence of pairs with elements as follows: 740 o TstampSrc, as above 742 o L, either zero or one, where L=1 indicates loss and L=0 indicates 743 arrival at the destination within TstampSrc + Tmax. 745 5.1.3. Discussion and other details 747 5.1.4. Statistic: Type-P-One-way-Packet-Loss-Empirical-Probability 749 Given the stream parameter M, the number of packets sent, we can 750 define the Empirical Probability of Loss Statistic (Ep), consistent 751 with Average Loss in [RFC2680], as follows: 753 Type-P-One-way-Packet-Loss-Empirical-Probability = 754 M 755 --- 756 1 \ 757 Ep = - * > (L[m]) 758 M / 759 --- 760 m = 1 762 where all packets m = 1 through M have a value for L. 764 5.1.5. Composition Function: Composition of Empirical Probabilities 766 The Type-P-One-way-Composite-Packet-Loss-Empirical-Probability, or 767 CompEp for the complete Source to Destination path can be calculated 768 by combining Ep of all its constituent sub-paths (Ep1, Ep2, Ep3, ... 769 Epn) as 771 Type-P-Composite-One-way-Packet-Loss-Empirical-Probability = 772 CompEp = 1 - {(1 - Ep1) x (1 - Ep2) x (1 - Ep3) x ... x (1 - EpS)} 774 If any Eps is undefined in a particular measurement interval, 775 possibly because a measurement system failed to report a value, then 776 any CompEp that uses sub-path s for that measurement interval is 777 undefined. 779 5.1.6. Statement of Conjecture and Assumptions 781 The empirical probability of loss calculated on a sufficiently large 782 stream of packets measured on each sub-path during the interval [T, 783 Tf] will be representative of the ground truth empirical loss 784 probability (and the probabilities themselves are sufficiently 785 independent), such that the sub-path probabilities may be combined to 786 produce an estimate of the complete path empirical loss probability. 788 5.1.7. Justification of the Composition Function 790 See the common section. 792 5.1.8. Sources of Deviation from the Ground Truth 794 See the common section. 796 5.1.9. Specific cases where the conjecture might fail 798 A concern for loss measurements combined in this way is that root 799 causes may be correlated to some degree. 801 For example, if the links of different networks follow the same 802 physical route, then a single catastrophic event like a fire in a 803 tunnel could cause an outage or congestion on remaining paths in 804 multiple networks. Here it is important to ensure that measurements 805 before the event and after the event are not combined to estimate the 806 composite performance. 808 Or, when traffic volumes rise due to the rapid spread of an email- 809 borne worm, loss due to queue overflow in one network may help 810 another network to carry its traffic without loss. 812 5.1.10. Application of Measurement Methodology 814 See the common section. 816 6. Delay Variation Metrics and Statistics 818 6.1. Name: Type-P-One-way-pdv-refmin-Poisson/Periodic-Stream 820 This packet delay variation (PDV) metric is a necessary element of 821 Composed Delay Variation metrics, and its definition does not 822 formally exist elsewhere in IPPM literature. 824 6.1.1. Metric Parameters: 826 In addition to the parameters of section 4.1.1: 828 o TstampSrc[i], the wire time of packet[i] as measured at MP(Src) 829 (measurement point at the source) 831 o TstampDst[i], the wire time of packet[i] as measured at MP(Dst), 832 assigned to packets that arrive within a "reasonable" time. 834 o B, a packet length in bits 836 o F, a selection function unambiguously defining the packets from 837 the stream that are selected for the packet-pair computation of 838 this metric. F(current packet), the first packet of the pair, 839 MUST have a valid Type-P-Finite-One-way-Delay less than Tmax (in 840 other words, excluding packets which have undefined one-way delay) 841 and MUST have been transmitted during the interval T, Tf. The 842 second packet in the pair, F(min_delay packet) MUST be the packet 843 with the minimum valid value of Type-P-Finite-One-way-Delay for 844 the stream, in addition to the criteria for F(current packet). If 845 multiple packets have equal minimum Type-P-Finite-One-way-Delay 846 values, then the value for the earliest arriving packet SHOULD be 847 used. 849 o MinDelay, the Type-P-Finite-One-way-Delay value for F(min_delay 850 packet) given above. 852 o N, the number of packets received at the Destination meeting the 853 F(current packet) criteria. 855 6.1.2. Definition and Metric Units 857 Using the definition above in section 5.1.2, we obtain the value of 858 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[n], the singleton 859 for each packet[i] in the stream (a.k.a. FiniteDelay[i]). 861 For each packet[n] that meets the F(first packet) criteria given 862 above: Type-P-One-way-pdv-refmin-Poisson/Periodic-Stream[n] = 864 PDV[n] = FiniteDelay[n] - MinDelay 866 where PDV[i] is in units of time in seconds, expressed in 867 sufficiently fine resolution to convey meaningful quantitative 868 information. For example, resolution of microseconds is usually 869 sufficient. 871 6.1.3. Discussion and other details 873 This metric produces a sample of delay variation normalized to the 874 minimum delay of the sample. The resulting delay variation 875 distribution is independent of the sending sequence (although 876 specific FiniteDelay values within the distribution may be 877 correlated, depending on various stream parameters such as packet 878 spacing). This metric is equivalent to the IP Packet Delay Variation 879 parameter defined in [Y.1540]. 881 6.1.4. Statistics: Mean, Variance, Skewness, Quantile 883 We define the mean PDV as follows (where all packets n = 1 through N 884 have a value for PDV[n]): 886 Type-P-One-way-pdv-refmin-Mean = MeanPDV = 887 N 888 --- 889 1 \ 890 - * > (PDV[n]) 891 N / 892 --- 893 n = 1 895 We define the variance of PDV as follows: 897 Type-P-One-way-pdv-refmin-Variance = VarPDV = 898 N 899 --- 900 1 \ 2 901 ------- > (PDV[n] - MeanPDV) 902 (N - 1) / 903 --- 904 n = 1 906 We define the skewness of PDV as follows: 908 Type-P-One-way-pdv-refmin-Skewness = SkewPDV = 909 N 910 --- 3 911 \ / \ 912 > | PDV[n]- MeanPDV | 913 / \ / 914 --- 915 n = 1 916 ----------------------------------- 917 / \ 918 | ( 3/2 ) | 919 \ (N - 1) * VarPDV / 921 We define the Quantile of the PDVRefMin sample as the value where the 922 specified fraction of singletons is less than the given value. 924 6.1.5. Composition Functions: 926 This section gives two alternative composition functions. The 927 objective is to estimate a quantile of the complete path delay 928 variation distribution. The composed quantile will be estimated 929 using information from the sub-path delay variation distributions. 931 6.1.5.1. Approximate Convolution 933 The Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream samples from 934 each sub-path are summarized as a histogram with 1 ms bins 935 representing the one-way delay distribution. 937 From [Stats], the distribution of the sum of independent random 938 variables can be derived using the relation: 940 Type-P-Composite-One-way-pdv-refmin-quantile-a = 941 / / 942 P(X + Y + Z <= a) = | | P(X <= a-y-z) * P(Y = y) * P(Z = z) dy dz 943 / / 944 z y 945 where X, Y, and Z are random variables representing the delay 946 variation distributions of the sub-paths of the complete path (in 947 this case, there are three sub-paths), and a is the quantile of 948 interest. Note dy and dz indicate partial integration here.This 949 relation can be used to compose a quantile of interest for the 950 complete path from the sub-path delay distributions. The histograms 951 with 1 ms bins are discrete approximations of the delay 952 distributions. 954 6.1.5.2. Normal Power Approximation 956 Type-P-One-way-Composite-pdv-refmin-NPA for the complete Source to 957 Destination path can be calculated by combining statistics of all the 958 constituent sub-paths in the process described in [Y.1541] clause 8 959 and Appendix X. 961 6.1.6. Statement of Conjecture and Assumptions 963 The delay distribution of a sufficiently large stream of packets 964 measured on each sub-path during the interval [T, Tf] will be 965 sufficiently stationary and the sub-path distributions themselves are 966 sufficiently independent, so that summary information describing the 967 sub-path distributions can be combined to estimate the delay 968 distribution of complete path. 970 It is assumed that the one-way delay distributions of the sub-paths 971 and the complete path are continuous. 973 6.1.7. Justification of the Composition Function 975 See the common section. 977 6.1.8. Sources of Deviation from the Ground Truth 979 In addition to the common deviations, a few additional sources exist 980 here. For one, very tight distributions with range on the order of a 981 few milliseconds are not accurately represented by a histogram with 1 982 ms bins. This size was chosen assuming an implicit requirement on 983 accuracy: errors of a few milliseconds are acceptable when assessing 984 a composed distribution quantile. 986 Also, summary statistics cannot describe the subtleties of an 987 empirical distribution exactly, especially when the distribution is 988 very different from a classical form. Any procedure that uses these 989 statistics alone may incur error. 991 6.1.9. Specific cases where the conjecture might fail 993 If the delay distributions of the sub-paths are somehow correlated, 994 then neither of these composition functions will be reliable 995 estimators of the complete path distribution. 997 In practice, sub-path delay distributions with extreme outliers have 998 increased the error of the composed metric estimate. 1000 6.1.10. Application of Measurement Methodology 1002 See the common section. 1004 7. Security Considerations 1006 7.1. Denial of Service Attacks 1008 This metric requires a stream of packets sent from one host (source) 1009 to another host (destination) through intervening networks. This 1010 method could be abused for denial of service attacks directed at the 1011 destination and/or the intervening network(s). 1013 Administrators of source, destination, and the intervening network(s) 1014 should establish bilateral or multi-lateral agreements regarding the 1015 timing, size, and frequency of collection of sample metrics. Use of 1016 this method in excess of the terms agreed between the participants 1017 may be cause for immediate rejection or discard of packets or other 1018 escalation procedures defined between the affected parties. 1020 7.2. User Data Confidentiality 1022 Active use of this method generates packets for a sample, rather than 1023 taking samples based on user data, and does not threaten user data 1024 confidentiality. Passive measurement must restrict attention to the 1025 headers of interest. Since user payloads may be temporarily stored 1026 for length analysis, suitable precautions MUST be taken to keep this 1027 information safe and confidential. In most cases, a hashing function 1028 will produce a value suitable for payload comparisons. 1030 7.3. Interference with the metrics 1032 It may be possible to identify that a certain packet or stream of 1033 packets is part of a sample. With that knowledge at the destination 1034 and/or the intervening networks, it is possible to change the 1035 processing of the packets (e.g. increasing or decreasing delay) that 1036 may distort the measured performance. It may also be possible to 1037 generate additional packets that appear to be part of the sample 1038 metric. These additional packets are likely to perturb the results 1039 of the sample measurement. 1041 To discourage the kind of interference mentioned above, packet 1042 interference checks, such as cryptographic hash, may be used. 1044 8. IANA Considerations 1046 Metrics defined in IETF are typically registered in the IANA IPPM 1047 METRICS REGISTRY as described in initial version of the registry 1048 [RFC4148]. 1050 IANA is asked to register the following metrics in the IANA-IPPM- 1051 METRICS-REGISTRY-MIB: 1053 ietfFiniteOneWayDelayStream OBJECT-IDENTITY 1054 STATUS current 1055 DESCRIPTION 1056 "Type-P-Finite-One-way-Delay-Stream" 1057 REFERENCE 1058 "Reference "RFCyyyy, section 5.1." 1059 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1060 note 1061 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1063 ietfFiniteOneWayDelayMean OBJECT-IDENTITY 1064 STATUS current 1065 DESCRIPTION 1066 "Type-P-Finite-One-way-Delay-Mean" 1067 REFERENCE 1068 "Reference "RFCyyyy, section 5.2." 1069 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1070 note 1071 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1073 ietfCompositeOneWayDelayMean OBJECT-IDENTITY 1074 STATUS current 1075 DESCRIPTION 1076 "Type-P-Finite-Composite-One-way-Delay-Mean" 1077 REFERENCE 1078 "Reference "RFCyyyy, section 5.2.5." 1079 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1080 note 1081 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1083 ietfFiniteOneWayDelayMinimum OBJECT-IDENTITY 1084 STATUS current 1085 DESCRIPTION 1086 "Type-P-Finite-One-way-Delay-Minimum" 1088 REFERENCE 1089 "Reference "RFCyyyy, section 5.3.2." 1090 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1091 note 1092 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1094 ietfCompositeOneWayDelayMinimum OBJECT-IDENTITY 1095 STATUS current 1096 DESCRIPTION 1097 "Type-P-Finite-Composite-One-way-Delay-Minimum" 1098 REFERENCE 1099 "Reference "RFCyyyy, section 5.3.5." 1100 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1101 note 1102 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1104 ietfOneWayPktLossEmpiricProb OBJECT-IDENTITY 1105 STATUS current 1106 DESCRIPTION 1107 "Type-P-One-way-Packet-Loss-Empirical-Probability" 1108 REFERENCE 1109 "Reference "RFCyyyy, section 6.1.4." 1110 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1111 note 1112 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1114 ietfCompositeOneWayPktLossEmpiricProb OBJECT-IDENTITY 1115 STATUS current 1116 DESCRIPTION 1117 "Type-P-Composite-One-way-Packet-Loss-Empirical-Probability" 1118 REFERENCE 1119 "Reference "RFCyyyy, section 6.1.5." 1120 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1121 note 1122 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1124 ietfOneWayPdvRefminStream OBJECT-IDENTITY 1125 STATUS current 1126 DESCRIPTION 1127 "Type-P-One-way-pdv-refmin-Stream" 1128 REFERENCE 1129 "Reference "RFCyyyy, section 7.1." 1130 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1131 note 1132 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1134 ietfOneWayPdvRefminMean OBJECT-IDENTITY 1135 STATUS current 1136 DESCRIPTION 1137 "Type-P-One-way-pdv-refmin-Mean" 1138 REFERENCE 1139 "Reference "RFCyyyy, section 7.1.4." 1140 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1141 note 1142 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1144 ietfOneWayPdvRefminVariance OBJECT-IDENTITY 1145 STATUS current 1146 DESCRIPTION 1147 "Type-P-One-way-pdv-refmin-Variance" 1148 REFERENCE 1149 "Reference "RFCyyyy, section 7.1.4." 1150 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1151 note 1152 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1154 ietfOneWayPdvRefminSkewness OBJECT-IDENTITY 1155 STATUS current 1156 DESCRIPTION 1157 "Type-P-One-way-pdv-refmin-Skewness" 1158 REFERENCE 1159 "Reference "RFCyyyy, section 7.1.4." 1160 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1161 note 1162 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1164 ietfCompositeOneWayPdvRefminQtil OBJECT-IDENTITY 1165 STATUS current 1166 DESCRIPTION 1167 "Type-P-Composite-One-way-pdv-refmin-quantile-a" 1168 REFERENCE 1169 "Reference "RFCyyyy, section 7.1.5.1." 1170 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1171 note 1173 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1175 ietfCompositeOneWayPdvRefminNPA OBJECT-IDENTITY 1176 STATUS current 1177 DESCRIPTION 1178 "Type-P-One-way-Composite-pdv-refmin-NPA" 1179 REFERENCE 1180 "Reference "RFCyyyy, section 7.1.5.2." 1181 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1182 note 1183 ::= { ianaIppmMetrics nn } -- IANA assigns nn 1185 9. Contributors and Acknowledgements 1187 The following people have contributed useful ideas, suggestions, or 1188 the text of sections that have been incorporated into this memo: 1190 - Phil Chimento 1192 - Reza Fardid 1194 - Roman Krzanowski 1196 - Maurizio Molina 1198 - Lei Liang 1200 - Dave Hoeflin 1202 A long time ago, in a galaxy far, far away (Minneapolis), Will Leland 1203 suggested the simple and elegant Type-P-Finite-One-way-Delay concept. 1204 Thanks Will. 1206 Yaakov Stein and Donald McLachlan also provided useful comments along 1207 the way. 1209 10. References 1211 10.1. Normative References 1213 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1214 Requirement Levels", BCP 14, RFC 2119, March 1997. 1216 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1217 "Framework for IP Performance Metrics", RFC 2330, 1218 May 1998. 1220 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1221 Delay Metric for IPPM", RFC 2679, September 1999. 1223 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1224 Packet Loss Metric for IPPM", RFC 2680, September 1999. 1226 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1227 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1228 November 2002. 1230 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 1231 performance measurement with periodic streams", RFC 3432, 1232 November 2002. 1234 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 1235 Registry", BCP 108, RFC 4148, August 2005. 1237 [RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric 1238 Composition", RFC 5835, April 2010. 1240 10.2. Informative References 1242 [RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A., 1243 Grossglauser, M., and J. Rexford, "A Framework for Packet 1244 Selection and Reporting", RFC 5474, March 2009. 1246 [RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance 1247 Metrics (IPPM): Spatial and Multicast", RFC 5644, 1248 October 2009. 1250 [Stats] McGraw-Hill NY NY, "Introduction to the Theory of 1251 Statistics, 3rd Edition,", 1974. 1253 [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data 1254 communication service - IP packet transfer and 1255 availability performance parameters", November 2007. 1257 [Y.1541] ITU-T Recommendation Y.1541, "Network Performance 1258 Objectives for IP-based Services", February 2006. 1260 Index 1262 ? 1263 ??? 14 1265 Authors' Addresses 1267 Al Morton 1268 AT&T Labs 1269 200 Laurel Avenue South 1270 Middletown,, NJ 07748 1271 USA 1273 Phone: +1 732 420 1571 1274 Fax: +1 732 368 1192 1275 Email: acmorton@att.com 1276 URI: http://home.comcast.net/~acmacm/ 1278 Emile Stephan 1279 France Telecom Division R&D 1280 2 avenue Pierre Marzin 1281 Lannion, F-22307 1282 France 1284 Phone: 1285 Fax: +33 2 96 05 18 52 1286 Email: emile.stephan@orange-ftgroup.com 1287 URI: