idnits 2.17.1 draft-ietf-ippm-framework-compagg-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 681. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 692. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 699. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 705. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 5, 2007) is 6011 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-ippm-multimetrics' is defined on line 623, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-ippm-multimetrics-04 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Morton, Ed. 3 Internet-Draft AT&T Labs 4 Intended status: Informational S. Van den Berghe, Ed. 5 Expires: May 8, 2008 Ghent University - IBBT 6 November 5, 2007 8 Framework for Metric Composition 9 draft-ietf-ippm-framework-compagg-05 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 8, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This memo describes a framework for composing and aggregating metrics 43 (both in time and in space) defined by RFC 2330 and developed by the 44 IPPM working group. The framework describes the generic composition 45 and aggregation mechanisms. It provides a basis for additional 46 documents that implement this framework for detailed, and practically 47 useful, compositions and aggregations of metrics. 49 Requirements Language 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC 2119 [RFC2119]. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1.1. Reducing Measurement Overhead . . . . . . . . . . . . 3 60 1.1.2. Measurement Re-use . . . . . . . . . . . . . . . . . . 4 61 1.1.3. Data Reduction and Consolidation . . . . . . . . . . . 4 62 1.1.4. Implications on Measurement Design and Reporting . . . 5 63 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Measurement Point . . . . . . . . . . . . . . . . . . . . 5 66 3.2. Complete path . . . . . . . . . . . . . . . . . . . . . . 6 67 3.3. Complete path metric . . . . . . . . . . . . . . . . . . . 6 68 3.4. Composed Metric . . . . . . . . . . . . . . . . . . . . . 6 69 3.5. Composition Function . . . . . . . . . . . . . . . . . . . 6 70 3.6. Index . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.7. Ground Truth . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.8. Sub-interval . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.9. Sub-path . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.10. Sub-path metrics . . . . . . . . . . . . . . . . . . . . . 7 75 4. Description of Metric Types . . . . . . . . . . . . . . . . . 7 76 4.1. Temporal Aggregation Description . . . . . . . . . . . . . 7 77 4.2. Spatial Aggregation Description . . . . . . . . . . . . . 8 78 4.3. Spatial Composition Description . . . . . . . . . . . . . 8 79 4.4. Help Metrics . . . . . . . . . . . . . . . . . . . . . . . 9 80 4.5. Higher Order Composition . . . . . . . . . . . . . . . . . 9 81 5. Requirements for Composed Metrics . . . . . . . . . . . . . . 9 82 6. Guidelines for Defining Composed Metrics . . . . . . . . . . . 10 83 6.1. Ground Truth: Comparison with other IPPM Metrics . . . . . 10 84 6.1.1. Ground Truth for Temporal Aggregation . . . . . . . . 12 85 6.1.2. Ground Truth for Spatial Aggregation . . . . . . . . . 13 86 6.2. Deviation from the Ground Truth . . . . . . . . . . . . . 13 87 6.3. Incomplete Information . . . . . . . . . . . . . . . . . . 13 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 90 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 93 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 95 Intellectual Property and Copyright Statements . . . . . . . . . . 16 97 1. Introduction 99 The IPPM framework [RFC2330] describes two forms of metric 100 composition, spatial and temporal. Also, the text suggests that the 101 concepts of the analytical framework (or A-frame) would help to 102 develop useful relationships to derive the composed metrics from real 103 metrics. The effectiveness of composed metrics is dependent on their 104 usefulness in analysis and applicability to practical measurement 105 circumstances. 107 This memo expands on the notion of composition, and provides a 108 detailed framework for several classes of metrics that were mentioned 109 in the original IPPM framework. The classes include temporal 110 aggregation, spatial aggregation, and spatial composition. 112 1.1. Motivation 114 Network operators have deployed measurement systems to serve many 115 purposes, including performance monitoring, maintenance support, 116 network engineering, and customer reporting. The collection of 117 elementary measurements alone is not enough to understand a network's 118 behaviour. In general, measurements need to be post-processed to 119 present the most relevant information for each purpose. The first 120 step is often a process of "composition" of single measurements or 121 measurement sets into other forms. Composition and aggregation 122 present several more post-processing opportunities to the network 123 operator, and we describe the key motivations below. 125 1.1.1. Reducing Measurement Overhead 127 A network's measurement possibilities scale upward with the square of 128 the number of nodes. But each measurement implies overhead, in terms 129 of the storage for the results, the traffic on the network (assuming 130 active methods), and the OA&M for the measurement system itself. In 131 a large network, it is impossible to perform measurements from each 132 node to all others. 134 An individual network operator should be able to organize their 135 measurement paths along the lines of physical topology, or routing 136 areas/Autonomous Systems, and thus minimize dependencies and overlap 137 between different measurement paths. This way, the sheer number of 138 measurements can be reduced, as long as the operator has a set of 139 methods to estimate performance between any particular nodes when 140 needed. 142 Composition and aggregation play a key role when the path of interest 143 spans multiple networks, and where each operator conducts their own 144 measurements. Here, the complete path performance may be estimated 145 from measurements on the component parts. 147 Operators that take advantage of the composition and aggregation 148 methods recognize that the estimates may exhibit some additional 149 error beyond that inherent in the measurements themselves, and so 150 they are making a trade-off to achieve reasonable measurement system 151 overhead. 153 1.1.2. Measurement Re-use 155 There are many different measurement users, each bringing specific 156 requirements for the reporting timescale. Network managers and 157 maintenance forces prefer to see results presented very rapidly, to 158 detect problems quickly or see if their action has corrected a 159 problem. On the other hand, network capacity planners and even 160 network users sometimes prefer a long-term view of performance, for 161 example to check trends. How can one set of measurements serve both 162 needs? 164 The answer lies in temporal aggregation, where the short-term 165 measurements needed by the operations community are combined to 166 estimate a longer-term result for others. Also, problems with the 167 measurement system itself may be isolated to one or more of the 168 short-term measurements, rather than possibly invalidating an entire 169 long-term measurement if the problem was undetected. 171 1.1.3. Data Reduction and Consolidation 173 Another motivation is data reduction. Assume there is a network 174 domain in which delay measurements are performed among a subset of 175 its nodes. A network manager might ask whether there is a problem 176 with the network delay in general. It would be desirable to obtain a 177 single value that gives an indication of the overall network delay. 178 Spatial aggregation methods would address this need, and can produce 179 the desired "single figure of merit" asked for, one that may also be 180 useful in trend analysis. 182 The overall value would be calculated from the elementary delay 183 measurements, but it not obvious how: for example, it may not to be 184 reasonable to average all delay measurements, as some paths (e.g. 185 having a higher bandwidth or more important customers) might be 186 considered more critical than others. 188 Metric composition can help to provide, from raw measurement data, 189 some tangible, well-understood and agreed upon information about the 190 service guarantees provided by a network. Such information can be 191 used in the Service Level Agreement/Service Level Specification (SLA/ 192 SLS) contracts between a service provider and its customers. 194 1.1.4. Implications on Measurement Design and Reporting 196 If a network measurement system operator anticipates needing to 197 produce overall metrics by composition, then it is prudent to keep 198 that requirement in mind when considering the measurement design and 199 sampling plan. Also, certain summary statistics are more conducive 200 to composition than others, and this figures prominently in the 201 design of measurements and when reporting the results. 203 2. Purpose and Scope 205 The purpose of this memo is provide a common framework for the 206 various classes of metrics based on composition of primary metrics. 207 The scope is limited to the definitions of metrics that are composed 208 from primary metrics using a deterministic function. Key information 209 about each metric, such as the assumptions under which the 210 relationship holds and possible sources of error/circumstances where 211 the composition may fail, are included. 213 At this time, the scope of effort is limited to the metrics for 214 packet loss, delay, and delay variation. Composition of packet 215 reordering metrics is considered a research topic at the time this 216 memo was prepared, and beyond its scope. 218 This memo will retain the terminology of the IPPM Framework 219 [RFC2330]as much as possible, but will extend the terminology when 220 necessary. It is assumed that the reader is familiar with the 221 concepts introduced in [RFC2330], as they will not be repeated here. 223 3. Terminology 225 This section defines the terminology applicable to the processes of 226 Metric Composition and Aggregation. 228 3.1. Measurement Point 230 The logical or physical location where packet observations are made. 231 The term Measurement Point is synonymous with the term "observation 232 position" used in [RFC2330] when describing the notion of wire time. 233 A measurement point may be at the boundary between a host and an 234 adjacent link (physical), or it may be within a host (logical) that 235 performs measurements where the difference between host time and wire 236 time is understood. 238 3.2. Complete path 240 The complete path is the true path that a packet would follow as it 241 traverses from the packet's Source to its Destination. 243 3.3. Complete path metric 245 The complete path metric is the Source to Destination metric that a 246 composed metric is estimating. A complete path metric represents the 247 ground-truth for a composed metric. 249 3.4. Composed Metric 251 A composed metric is an estimate of an actual metric describing the 252 performance of a path over some time interval. A composed metric is 253 derived from other metrics by applying a deterministic process or 254 function (e.g., a composition function). The process may use metrics 255 that are identical to the metric being composed, or metrics that are 256 dissimilar, or some combination of both types. 258 3.5. Composition Function 260 A composition function is a deterministic process applied to 261 individual metrics to derive another metric (such as a Composed 262 metric). 264 3.6. Index 266 An Index is a composed metric for which the output value range has 267 been selected for convenience or clarity, and the behavior of which 268 is selected to support ease of understanding. The composition 269 function for an index is often developed after the index range and 270 index behavior have been determined. Examples include the R factor, 271 as described in [G.107]. 273 3.7. Ground Truth 275 As applied here, the notion of ground truth is defined as the actual 276 performance of a network path over some time interval. The ground 277 truth is metric based on the (unavailable) measurement that a 278 composed metric seeks to estimate. 280 3.8. Sub-interval 282 A Sub-interval is a time interval that is included in another 283 interval. 285 3.9. Sub-path 287 A Sub-path is a portion of the complete path where at least the Sub- 288 path Source and Destination hosts are constituents of the complete 289 path. We say that this sub-path is "involved" in the complete path. 291 3.10. Sub-path metrics 293 A sub-path path metric is an element of the process to derive a 294 Composite metric, quantifying some aspect of the performance a 295 particular sub-path from its Source to Destination. 297 4. Description of Metric Types 299 This section defines the various classes of Composition. There are 300 two classes more accurately described as aggregation over time and 301 space, and the third involves concatenation in space. 303 4.1. Temporal Aggregation Description 305 Aggregation in time is defined as the composition of metrics with the 306 same type and scope obtained in different time instants or time 307 windows. For example, starting from a time series of the 308 measurements of maximum and minimum One-Way Delay on a certain 309 network path obtained over 5-minute intervals, we obtain a time 310 series measurement with a coarser resolution (60 minutes) by taking 311 the max of 12 consecutive 5-minute maxima and the min of 12 312 consecutive 5-minute minima. 314 The main reason for doing time aggregation is to reduce the amount of 315 data that has to be stored, and make the visualization/spotting of 316 regular cycles and/or growing or decreasing trends easier. Another 317 useful application is to detect anomalies or abnormal changes in the 318 network characteristics. 320 In RFC 2330, the term "temporal composition" is introduced and 321 differs from temporal aggregation in that it refers to methodologies 322 to predict future metrics on the basis of past observations, 323 exploiting the time correlation that certain metrics can exhibit. We 324 do not consider this type of composition here. 326 >>>>>>>>Comment: Why no forecasting? This was apparently a limit on 327 the Geant2 project, but may not apply here. 329 4.2. Spatial Aggregation Description 331 Aggregation in space is defined as the combination of metrics of the 332 same type and different scope, in order to estimate the overall 333 performance of a larger domain. This combination may involve 334 weighing the contributions of the input metrics. 336 Suppose we want to compose the average One-Way-Delay (OWD) 337 experienced by flows traversing all the Origin-Destination (OD) pairs 338 of a network domain (where the inputs are already metric 339 "statistics"). Since we wish to include the effect of the traffic 340 matrix on the result, it makes sense to weight each metric according 341 to the traffic carried on the corresponding OD pair: 343 OWD_sum=f1*OWD_1+f2*OWD_2+...+fn*OWD_n 345 where fi=load_OD_i/total_load. 347 A simple average OWD across all network OD pairs would not use the 348 traffic weighting. 350 Another example metric that is "aggregated in space", is the maximum 351 edge-to-edge delay across a single domain. Assume that a Service 352 Provider wants to advertise the maximum delay that transit traffic 353 will experience while passing through his/her domain. There can be 354 multiple edge-to-edge paths across a domain, and the Service Provider 355 chooses either to publish a list of delays (each corresponding to a 356 specific edge-to-edge path), or publish a single maximum value. The 357 latter approach simplifies the publication of measurement 358 information, and may be sufficient for some purposes. Similar 359 operations can be provided to other metrics, e.g. "maximum edge-to- 360 edge packet loss", etc. 362 We suggest that space aggregation is generally useful to obtain a 363 summary view of the behaviour of large network portions, or in 364 general of coarser aggregates. The metric collection time instant, 365 i.e. the metric collection time window of measured metrics is not 366 considered in space aggregation. We assume that either it is 367 consistent for all the composed metrics, e.g. compose a set of 368 average delays all referred to the same time window, or the time 369 window of each composed metric does not affect aggregated metric. 371 4.3. Spatial Composition Description 373 Concatenation in space is defined as the composition of metrics of 374 same type and (ideally) different spatial scope, so that the 375 resulting metric is representative of what the metric would be if 376 obtained with a direct measurement over the sequence of the several 377 spatial scopes. An example is the sum of OWDs of different edge-to- 378 edge domain's delays, where the intermediate edge points are close to 379 each other or happen to be the same. In this way, we can for example 380 estimate OWD_AC starting from the knowledge of OWD_AB and OWD_BC. 381 Note that there may be small gaps in measurement coverage, likewise 382 there may be small overlaps (e.g., the link where test equipment 383 connects to the network). 385 One key difference from examples of aggregation in space is that all 386 sub-paths contribute equally to the composed metric, independent of 387 the traffic load present. 389 4.4. Help Metrics 391 Finally, note that in practice there is often the need of extracting 392 a new metric making some computation over one or more metrics with 393 the same spatial and time scope. For example, the composed metric 394 rtt_sample_variance may be composed from two different metrics: the 395 help metric rtt_square_sum and the statistical metric rtt_sum. This 396 operation is however more a simple calculation and not an aggregation 397 or a concatenation, and we'll not investigate it further in this 398 memo. 400 4.5. Higher Order Composition 402 Composed metrics might themselves be subject to further steps of 403 composition or aggregation. An example would be a the delay of a 404 maximal domain obtained through the spatial composition of several 405 composed end-to-end delays (obtained through spatial composition). 406 All requirements for first order composition metrics apply to higher 407 order composition. 409 >>>>> Comment Response: are more examples needed here? 411 5. Requirements for Composed Metrics 413 The definitions for all composed metrics MUST include sections to 414 treat the following topics. 416 The description of each metric will clearly state: 418 1. the definition (and statistic, where appropriate); 420 2. the composition or aggregation relationship; 422 3. the specific conjecture on which the relationship is based and 423 assumptions of the statistical model of the process being 424 measured, if any (see [RFC2330] section 12); 426 4. a justification of practical utility or usefulness for analysis 427 using the A-frame concepts; 429 5. one or more examples of how the conjecture could be incorrect and 430 lead to inaccuracy; 432 6. the information to be reported. 434 For each metric, the applicable circumstances will be defined, in 435 terms of whether the composition or aggregation: 437 o Requires homogeneity of measurement methodologies, or can allow a 438 degree of flexibility (e.g., active or passive methods produce the 439 "same" metric). Also, the applicable sending streams will be 440 specified, such as Poisson, Periodic, or both. 442 o Needs information or access that will only be available within an 443 operator's domain, or is applicable to Inter-domain composition. 445 o Requires precisely synchronized measurement time intervals in all 446 component metrics, or loosely synchronized, or no timing 447 requirements. 449 o Requires assumption of component metric independence w.r.t. the 450 metric being defined/composed, or other assumptions. 452 o Has known sources of inaccuracy/error, and identifies the sources. 454 6. Guidelines for Defining Composed Metrics 456 6.1. Ground Truth: Comparison with other IPPM Metrics 458 Figure 1 illustrates the process to derive a metric using spatial 459 composition, and compares the composed metric to other IPPM metrics. 461 Metrics describe the performance of sub-paths between 462 the Source and Destination of interest during time interval . 463 These metrics are the inputs for a Composition Function that produces 464 a Composed Metric. 466 Sub-Path Metrics 467 ++ M1 ++ ++ M2 ++ ++ M3 ++ 468 Src ||.......|| ||.......|| ||.......|| Dst 469 ++ `. ++ ++ | ++ ++ .' ++ 470 `. | .-' 471 `-. | .' 472 `._..|.._.' 473 ,-' `-. 474 ,' `. 475 | Composition | 476 \ Function ' 477 `._ _,' 478 `--.....--' 479 | 480 ++ | ++ 481 Src ||...............................|| Dst 482 ++ Composed Metric ++ 484 ++ Complete Path Metric ++ 485 Src ||...............................|| Dst 486 ++ ++ 487 Spatial Metric 488 ++ S1 ++ S2 ++ S3 ++ 489 Src ||........||.........||..........|| Dst 490 ++ ++ ++ ++ 492 Figure 1: Comparison with other IPPM metrics 494 The Composed Metric is an estimate of an actual metric collected over 495 the complete Source to Destination path. We say that the Complete 496 Path Metric represents the "Ground Truth" for the Composed Metric. 497 In other words, Composed Metrics seek to minimize error w.r.t. the 498 Complete Path Metric. 500 Further, we observe that a Spatial Metric I-D.ietf-ippm-multimetrics 501 [I-D.ietf-ippm-multimetrics]collected for packets traveling over the 502 same set of sub-paths provide a basis for the Ground Truth of the 503 individual Sub-Path metrics. We note that mathematical operations 504 may be necessary to isolate the performance of each sub-path. 506 Next, we consider multiparty metrics as defined in [I-D.ietf-ippm- 507 multimetrics], and their spatial composition. Measurements to each 508 of the Receivers produce an element of the one-to-group metric. 509 These elements can be composed from sub-path metrics and the composed 510 metrics can be combined to create a composed one-to-group metric. 511 Figure 2 illustrates this process. 513 Sub-Path Metrics 514 ++ M1 ++ ++ M2 ++ ++ M3 ++ 515 Src ||.......|| ||.......|| ||.......||Rcvr1 516 ++ ++ ++`. ++ ++ ++ 517 `-. 518 M4`.++ ++ M5 ++ 519 || ||.......||Rcvr2 520 ++ ++`. ++ 521 `-. 522 M6`.++ 523 ||Rcvr3 524 ++ 526 One-to-Group Metric 527 ++ ++ ++ ++ 528 Src ||........||.........||..........||Rcvr1 529 ++ ++. ++ ++ 530 `-. 531 `-. ++ ++ 532 `-||..........||Rcvr2 533 ++. ++ 534 `-. 535 `-. ++ 536 `-.||Rcvr3 537 ++ 539 Figure 2: Composition of One-to-Group Metrics 541 Here, Sub-path Metrics M1, M2, and M3 are combined using a 542 relationship to compose the metric applicable to the Src-Rcvr1 path. 543 Similarly, M1, M4, and M5 are used to compose the Src-Rcvr2 metric 544 and M1, M4, and M6 compose the Src-Rcvr3 metric. 546 The Composed One-to-Group Metric would list the Src-Rcvr metrics for 547 each Receiver in the Group: 549 (Composed-Rcvr1, Composed-Rcvr2, Composed-Rcvr3) 551 The "Ground Truth" for this composed metric is of course an actual 552 One-to-Group metric, where a single source packet has been measured 553 after traversing the Complete Paths to the various receivers. 555 6.1.1. Ground Truth for Temporal Aggregation 557 Temporal Aggregation involves measurements made over sub-intervals of 558 the desired test interval between the same Source and Destination. 559 Therefore, the "Ground Truth" is the metric measured over the desired 560 interval. 562 6.1.2. Ground Truth for Spatial Aggregation 564 Spatial Aggregation combines many measurements using a weighting 565 function to provide the same emphasis as though the measurements were 566 based on actual traffic, with inherent weights. Therefore, the 567 "Ground Truth" is the metric measured on the actual traffic instead 568 of the active streams that sample the performance. 570 6.2. Deviation from the Ground Truth 572 A metric composition can deviate from the ground truth for several 573 reasons. Two main aspects are: 575 o The propagation of the inaccuracies of the underlying measurements 576 when composing the metric. As part of the composition function, 577 errors of measurements might propagate. Where possible, this 578 analysis should be made and included with the description of each 579 metric. 581 o A difference in scope. When concatenating hop-by-hop active 582 measurement results to obtain the end-to-end metric, the actual 583 measured path will not be identical to the end-to-end path. It is 584 in general difficult to quantify this deviation, but a metric 585 definition might identify guidelines for keeping the deviation as 586 small as possible. 588 The description of the metric composition MUST include an section 589 identifying the deviation from the ground truth. 591 6.3. Incomplete Information 593 In practice, when measurements cannot be initiated on a sub-path or 594 during a particular measurement interval (and perhaps the measurement 595 system gives up during the test interval), then there will not be a 596 value for the subpath reported, and the result SHOULD be recorded as 597 "undefined". 599 7. IANA Considerations 601 This document makes no request of IANA. 603 Note to RFC Editor: this section may be removed on publication as an 604 RFC. 606 8. Security Considerations 608 The security considerations that apply to any active measurement of 609 live networks are relevant here as well. See [RFC4656]. 611 9. Acknowledgements 613 The authors would like to thank Maurizio Molina, Andy Van Maele, 614 Andreas Haneman, Igor Velimirovic, Andreas Solberg, Athanassios 615 Liakopulos, David Schitz, Nicolas Simar and the Geant2 Project. We 616 also acknowledge comments and suggestions from Phil Chimento, Emile 617 Stephan, Lei Liang, Stephen Wolff, and Alan Clark. 619 10. References 621 10.1. Normative References 623 [I-D.ietf-ippm-multimetrics] 624 Stephan, E., "IP Performance Metrics (IPPM) for spatial 625 and multicast", draft-ietf-ippm-multimetrics-04 (work in 626 progress), July 2007. 628 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 629 Requirement Levels", BCP 14, RFC 2119, March 1997. 631 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 632 "Framework for IP Performance Metrics", RFC 2330, 633 May 1998. 635 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 636 Zekauskas, "A One-way Active Measurement Protocol 637 (OWAMP)", RFC 4656, September 2006. 639 10.2. Informative References 641 [G.107] ITU-T Recommendation G.107, ""The E-model, a computational 642 model for use in transmission planning"", March 2005. 644 Authors' Addresses 646 Al Morton (editor) 647 AT&T Labs 648 200 Laurel Avenue South 649 Middletown,, NJ 07748 650 USA 652 Phone: +1 732 420 1571 653 Fax: +1 732 368 1192 654 Email: acmorton@att.com 655 URI: http://home.comcast.net/~acmacm/ 657 Steven Van den Berghe (editor) 658 Ghent University - IBBT 659 G. Crommenlaan 8 bus 201 660 Gent 9050 661 Belgium 663 Phone: +32 9 331 49 73 664 Email: steven.vandenberghe@intec.ugent.be 665 URI: http://www.ibcn.intec.ugent.be 667 Full Copyright Statement 669 Copyright (C) The IETF Trust (2007). 671 This document is subject to the rights, licenses and restrictions 672 contained in BCP 78, and except as set forth therein, the authors 673 retain all their rights. 675 This document and the information contained herein are provided on an 676 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 677 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 678 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 679 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 680 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 681 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 683 Intellectual Property 685 The IETF takes no position regarding the validity or scope of any 686 Intellectual Property Rights or other rights that might be claimed to 687 pertain to the implementation or use of the technology described in 688 this document or the extent to which any license under such rights 689 might or might not be available; nor does it represent that it has 690 made any independent effort to identify any such rights. Information 691 on the procedures with respect to rights in RFC documents can be 692 found in BCP 78 and BCP 79. 694 Copies of IPR disclosures made to the IETF Secretariat and any 695 assurances of licenses to be made available, or the result of an 696 attempt made to obtain a general license or permission for the use of 697 such proprietary rights by implementers or users of this 698 specification can be obtained from the IETF on-line IPR repository at 699 http://www.ietf.org/ipr. 701 The IETF invites any interested party to bring to its attention any 702 copyrights, patents or patent applications, or other proprietary 703 rights that may cover technology that may be required to implement 704 this standard. Please address the information to the IETF at 705 ietf-ipr@ietf.org. 707 Acknowledgment 709 Funding for the RFC Editor function is provided by the IETF 710 Administrative Support Activity (IASA).