--- 1/draft-ietf-ippm-framework-compagg-02.txt 2007-03-08 23:13:15.000000000 +0100 +++ 2/draft-ietf-ippm-framework-compagg-03.txt 2007-03-08 23:13:15.000000000 +0100 @@ -1,19 +1,19 @@ Network Working Group A. Morton, Ed. Internet-Draft AT&T Labs Intended status: Informational S. Van den Berghe, Ed. -Expires: April 25, 2007 Ghent University - IBBT - October 22, 2006 +Expires: September 5, 2007 Ghent University - IBBT + March 4, 2007 Framework for Metric Composition - draft-ietf-ippm-framework-compagg-01 + draft-ietf-ippm-framework-compagg-03 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -24,25 +24,25 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on April 25, 2007. + This Internet-Draft will expire on September 5, 2007. Copyright Notice - Copyright (C) The Internet Society (2006). + Copyright (C) The IETF Trust (2007). Abstract This memo describes a framework for composing and aggregating metrics (both in time and in space) defined by RFC 2330 and developed by the IPPM working group. The framework describes the generic composition and aggregation mechanisms. It provides a basis for additional documents that implement this framework for detailed, and practically useful, compositions and aggregations of metrics. @@ -76,23 +76,24 @@ 4.2. Spatial Aggregation Description . . . . . . . . . . . . . 7 4.3. Spatial Composition Description . . . . . . . . . . . . . 8 4.4. Help Metrics . . . . . . . . . . . . . . . . . . . . . . . 8 4.5. Higher Order Composition . . . . . . . . . . . . . . . . . 9 5. Requirements for Composed Metrics . . . . . . . . . . . . . . 9 6. Guidelines for Defining Composed Metrics . . . . . . . . . . . 10 6.1. Ground Truth: Comparison with other IPPM Metrics . . . . . 10 6.1.1. Ground Truth for Temporal Aggregation . . . . . . . . 12 6.1.2. Ground Truth for Spatial Aggregation . . . . . . . . . 13 6.2. Deviation from the Ground Truth . . . . . . . . . . . . . 13 + 6.3. Incomplete Information . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 16 1. Introduction The IPPM framework [RFC2330] describes two forms of metric composition, spatial and temporal. Also, the text suggests that the @@ -184,27 +185,26 @@ considered more critical than others. Metric composition can help to provide, from raw measurement data, some tangible, well-understood and agreed upon information about the service guarantees provided by a network. Such information can be used in the Service Level Agreement/Service Level Specification (SLA/ SLS) contracts between a service provider and its customers. 1.1.4. Implications on Measurement Design and Reporting - If a network operator can anticipate needing to aggregate or compose - overall metrics in the future, it is more efficient to start by - considering the tenants of these methods in the measurement design/ - sampling plan, and reporting the results. The Summary Statistics of - certain metrics are more conducive to composition than others. This - figures prominently in the design of measurements and the results - reports. + If a network measurement system operator anticipates needing to + produce overall metrics by composition, then it is prudent to keep + that requirement in mind when considering the measurement design and + sampling plan. Also, certain summary statistics are more conducive + to composition than others, and this figures prominently in the + design of measurements and when reporting the results. 2. Purpose and Scope The purpose of this memo is provide a common framework for the various classes of metrics based on composition of primary metrics. The scope is limited to the definitions of metrics that are composed from primary metrics using a deterministic function. Key information about each metric, such as its assumptions under which the relationship holds, and possible sources of error/circumstances where the composition may fail, are included. @@ -240,34 +240,37 @@ traverses from the packet's Source to its Destination. 3.3. Complete path metric The complete path metric is the Source to Destination metric that a composed metric is estimating. A complete path metric represents the ground-truth for a composed metric. 3.4. Composed Metric - A composed metric is derived from other metrics principally by - applying a composition function. + A composed metric is an estimate of an actual metric describing the + performance of a path over some time interval. A composed metric is + derived from other metrics by applying a deterministic process or + function (e.g., a composition function). 3.5. Composition Function - A composition function is a deterministic process applied to Sub-path - metrics to derive another metric (such as a Composed metric). + A composition function is a deterministic process applied to + individual metrics to derive another metric (such as a Composed + metric). 3.6. Ground Truth As applied here, the notion of ground truth is defined as the actual - performance of a network entity over some time interval. The ground - truth is the (unavailable) measurement that a composed metric seeks - to estimate. + performance of a network path over some time interval. The ground + truth is metric based on the (unavailable) measurement that a + composed metric seeks to estimate. 3.7. Sub-interval A Sub-interval is a time interval that is included in another interval. 3.8. Sub-path A Sub-path is a portion of the complete path where at least the Sub- path Source and Destination hosts are constituents of the complete @@ -275,36 +278,39 @@ 3.9. Sub-path metrics A sub-path path metric is an element of the process to derive a Composite metric, quantifying some aspect of the performance a particular sub-path from its Source to Destination. 4. Description of Metric Types This section defines the various classes of Composition. There are - two classes more accurately referred to as aggregation over time and - space, and the third is simply composition in space. + two classes more accurately described as aggregation over time and + space, and the third involves concatenation in space. 4.1. Temporal Aggregation Description Aggregation in time is defined as the composition of metrics with the same type and scope obtained in different time instants or time - windows. For example, starting from a time series of One-Way Delay - measurements on a certain network path obtained in 5-minute periods - and averaging groups of 12 consecutive values, we obtain a time - series measurement with a coarser resolution (60 minutes). The main - reason for doing time aggregation is to reduce the amount of data - that has to be stored, and make the visualization/spotting of regular - cycles and/or growing or decreasing trends easier. Another useful - application is to detect anomalies or abnormal changes in the network - characteristics. + windows. For example, starting from a time series of the + measurements of maximum and minimum One-Way Delay on a certain + network path obtained over 5-minute intervals, we obtain a time + series measurement with a coarser resolution (60 minutes) by taking + the max of 12 consecutive 5-minute maxima and the min of 12 + consecutive 5-minute minima. + + The main reason for doing time aggregation is to reduce the amount of + data that has to be stored, and make the visualization/spotting of + regular cycles and/or growing or decreasing trends easier. Another + useful application is to detect anomalies or abnormal changes in the + network characteristics. In RFC 2330, the term "temporal composition" is introduced and differs from temporal aggregation in that it refers to methodologies to predict future metrics on the basis of past observations, exploiting the time correlation that certain metrics can exhibit. We do not consider this type of composition here. >>>>>>>>Comment: Why no forecasting? This was apparently a limit on the Geant2 project, but may not apply here. @@ -576,48 +581,56 @@ o A difference in scope. When concatenating hop-by-hop active measurement results to obtain the end-to-end metric, the actual measured path will not be identical to the end-to-end path. It is in general difficult to quantify this deviation, but a metric definition might identify guidelines for keeping the deviation as small as possible. The description of the metric composition MUST include an section identifying the deviation from the ground truth. +6.3. Incomplete Information + + In practice, when measurements cannot be initiated on a sub-path or + during a particular measurement interval (and perhaps the measurement + system gives up during the test interval), then there will not be a + value for the subpath reported, and the result SHOULD be recorded as + "undefined". + 7. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 8. Security Considerations The security considerations that apply to any active measurement of live networks are relevant here as well. See [RFC4656]. 9. Acknowledgements The authors would like to thank Maurizio Molina, Andy Van Maele, Andreas Haneman, Igor Velimirovic, Andreas Solberg, Athanassios Liakopulos, David Schitz, Nicolas Simar and the Geant2 Project. We also acknowledge comments and suggestions from Phil Chimento, Emile - Stephan and Lei Liang. + Stephan, Lei Liang, and Stephen Wolff. 10. References 10.1. Normative References [I-D.ietf-ippm-multimetrics] Stephan, E., "IP Performance Metrics (IPPM) for spatial - and multicast", draft-ietf-ippm-multimetrics-01 (work in - progress), July 2006. + and multicast", draft-ietf-ippm-multimetrics-02 (work in + progress), October 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol @@ -642,32 +656,32 @@ G. Crommenlaan 8 bus 201 Gent 9050 Belgium Phone: +32 9 331 49 73 Email: steven.vandenberghe@intec.ugent.be URI: http://www.ibcn.intec.ugent.be Full Copyright Statement - Copyright (C) The Internet Society (2006). + Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information