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