IPPM Working Group S. Van den Berghe, Ed. Internet-Draft A. Van Maele Expires: May 20, 2006 IBBT- Ghent University M. Molina DANTE November 16, 2005 Temporal Aggregation of Metrics draft-svdberg-ippm-temporal-00 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 other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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 May 20, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo intends to define metrics that allow to aggregate metric samples over a time interval. Metrics that are identical in type and scope but collected at different times, or in different time windows, can be aggregated into a new metric that characterizes the full time interval. The document additionally introduces some comments on terminology and motivation that could be the basis for a more general Van den Berghe, et al. Expires May 20, 2006 [Page 1] Internet-Draft Temporal Aggregation November 2005 framework for metric composition. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Composition of network metrics - General . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2.1. Metrics . . . . . . . . . . . . . . . . . . . . . . . 4 1.2.2. Composition Methods . . . . . . . . . . . . . . . . . 6 2. Framework for Aggregation in Time . . . . . . . . . . . . . . 7 3. Example: One-Way Delay Temporal Composition Metrics and Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Type-P-mean-delta_T-mean-One-Way-Delay . . . . . . . . . . 8 3.1.1. Definition . . . . . . . . . . . . . . . . . . . . . . 8 3.1.2. Composition Relationship . . . . . . . . . . . . . . . 8 3.1.3. Statement of Conjecture . . . . . . . . . . . . . . . 8 3.1.4. Justification for the Composite Relationship . . . . . 8 3.1.5. Sources of Error . . . . . . . . . . . . . . . . . . . 8 3.2. Other Possibilities . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. Normative References . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Van den Berghe, et al. Expires May 20, 2006 [Page 2] Internet-Draft Temporal Aggregation November 2005 1. Composition of network metrics - General 1.1. Motivation The deployment of a measurement infrastructure and the collection of elementary measurements are not enough to understand and keep under control the network's behaviour. Network measurements need in general to be post-processed to be useful for the several tasks of network engineering and management. The first step of this post processing is often a process of "composition" of single measurements or measurement sets into other ones. The reasons for doing so are briefly introduced here. A first reason, mainly applicable to network engineering, is saleability. Due to the number of network elements in large networks, it is impossible to perform measurements from each element to all others. It is necessary to select a set of links of special interest and to perform the measurements there. Examples for this are active measurements of one-way delay, jitter, and loss. Another reason may be data reduction (opposite need with respect to the previous one, where more data is generated). This is of interest for network planners and managers. Let us assume that there is network domain in which delay measurements are performed among a subset of its elements. A network manager might ask whether there is a problem with the network delay in general. Therefore, it would be desirable to obtain a single value giving an indication of the general network delay. This value has to be calculated from the elementary delay measurements, but it not obvious how: for example, it does not seem to be reasonable to average all delay measurements, as some links (e.g. having a higher bandwidth or more important customers) might be considered more important than others. Moreover, metric manipulation (or "composition") can be helpful to provide, from raw measurement data, some tangible, well-understood and agreed upon information about the services guarantees provided by a network. Such information can be used in the SLA/SLS contracts among a Provide and its Customers Finally, another important reason for composing measurements is to perform trend analysis. For doing so, a single value for an hour, a day or, a month is computed from the basic measurements which are scheduled e.g. every five minutes. In doing so, trends can be more easily witnessed, like an increasing usage of a backbone link which might require the installation of alternative links or the rerouting of some network flows. 1.2. Terminology This section introduces the terminology used in this document. Our Van den Berghe, et al. Expires May 20, 2006 [Page 3] Internet-Draft Temporal Aggregation November 2005 principal goal is to extend the terminology defined in the RFC 2330 [RFC2330]. Therefore, we avoid repeating definitions given in RFC 2330, but usually we provide some comment in order to present metric composition concepts more clearly. In few cases, terms used in this document deviate from the terminology of RFC 2330. Differences are explicitly stated and justification of our choice is given. 1.2.1. Metrics A metric is a generic indicator of network performances. The metric nature broadly qualifies the metric. Examples of metric nature are One-Way Delay (OWD), Packet Loss, Round Trip Time (RTT), etc. According to the RFC 2330, a single observation of a metric is called a singleton metric, a group of singleton metrics is called a sample metric and a statistically computed metric over a sample metric is called a statistic metric. In network operations, there are however some metric post-processing practices that lead to intermediate or final results not falling in any of the categories listed above. According to RFC 2330, these would be just called derived metrics: "Derived metrics may be defined purely in terms of other metrics". In this document, we try to be more specific about what derived metrics have practical interest. Actually, we will use the term "composed" metrics, but in RFC 2330 derived and composed metrics appear as synonyms, so we're not introducing any new terminology for that: our use of the term "composed metric" is synonymous with the definition of "derived metric" in RFC 2330. In particular, we focus on the operation of obtaining several intermediate results out of several sample metrics (sets of singletons), and then further elaborate these intermediate results. Intermediate results may be obtained by applying a statistical operation to the elements of the samples, e.g. averaging them, and in this case they are clearly a statistics metric, with some intuitive significance, i.e. it can be useful to render it through a visualization system. However, the intermediate results could also be obtained through some operation (statistical or not) and not have any practical significance, but just be of help for a further operation. In this case, we call the intermediate results "help metrics". The operation of post-processing a set of intermediate results (alone or in conjunction with others) to get another result is called further composition of metrics. There are three types of composition that are considered in this document, but before that we need to introduce some more concepts. The metric scope qualifies the physical or logical entity to which a Van den Berghe, et al. Expires May 20, 2006 [Page 4] Internet-Draft Temporal Aggregation November 2005 metric refers to. Examples of physical metric scopes are: o the observation point if the measurements are taken on a single observation point, such a router interface; o the network path, if measurements are taken between different observation one or more hops away Examples of logical metric scopes are: o the IP level properties of the packets involved in the measurement (also defined as "packet type P distinguisher" in RFC 2330), like the IP addresses, the transport protocol, the ToS fields, the packet size, etc; o the transport level properties like the UDP or TCP ports; o the properties derived from the packet's treatment in a router, like the input and output interface, or the previous and next AS. In formal terms, metric scope is an unordered list of variables, called metric distinction tuple, that describes the measurement for which the metric refers to. Most measurement values are further defined with metadata, usually related to time. The metric collection time instant identifies a time which the metric can be attributed to. The metric collection time window identifies a time window, defined by specific starting/ ending instants, which a metric can be attributed to. Data of the same metric could either be time-normalized according to this time window or not. In any case it should be clear whether the metric value is time-normalized or not. An example is the number of total octets sent over a link during a certain time window, which can be given as an absolute value or as an average bit rate if divided by the time duration. Normally, the time-normalized value is presented to users (because it's more intuitive), while the non-time-normalized value is stored in tools for internal purposes. Note that if a metric is reported along with a collection time instant, it does not necessarily mean that it is the result of a single observation (singleton). It may also be a statistic metric computed over a sample for which the given collection time is used as a conventional reference. On the contrary, if a metric is reported along with a time window, it means that it is a statistic metric over the specified time window, or a singleton metric that is calculated over a time period, e.g. derived from a counter reading. The metric type fully qualifies the Van den Berghe, et al. Expires May 20, 2006 [Page 5] Internet-Draft Temporal Aggregation November 2005 metrics. That is, it indicates at least the metric nature, and then it can indicate one or more of the further attributes that the metric may have: if it is a singleton, sample or statistic (and which statistic, e.g. "mean", or "95th percentile"), what is its scope, what are the collection time instants or windows, and if it is a composed metric what the composition was applied. 1.2.2. Composition Methods There are three types of composition considered in this document. Firstly, 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 serie of One-Way Delay measurements on a certain network path obtained in 5-minute periods and averaging groups of 12 consecutive values, a time series measurement with a coarser resolution. 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. Note that in RFC 2330, the term temporal composition is introduced, but with a different meaning than the one given here to aggregation in time. The temporal composition considered there 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. Secondly, aggregation in space is defined as the composition of metrics of the same type but with different scope. This composition may involve weighing the contributions of the several input metrics. For example, if we want to compose together the average OWD of the several Origin- Destination pairs of a network domain (thus where the inputs are already "statistics" metrics) it makes sense to weight each metric according to the traffic carried on the relative OD pair: OWD_sum=f1*OWD_1+f2*OWD_2+...+fn*OWD_n where fi=load_OD_i/total_load. Another example of metric that could be "aggregated in space", is the maximum edge-to-edge delay across a single domain. Assume that a Service Provider wants to advertise the maximum delay that transit traffic will experience while passing through his/her domain. As there are multiple edge-to-edge paths across a domain, shown with different coloured arrows in the following figure, the Service Provider has to either advertise a list of delays each of them corresponding to a specific edge-to-edge path, or advertise a maximum value. The latter approach is more scalable and simplifies the advertisement of measurement information via interdomain protocols, such as BGP. Similar operations can be provided to other metrics, e.g. "maximum edge-to-edge packet loss", etc. We suggest that space Van den Berghe, et al. Expires May 20, 2006 [Page 6] Internet-Draft Temporal Aggregation November 2005 aggregation is generally useful to obtain a summary view of the behaviour of large network portions, or in general of coarser aggregates. The metric collection time instant, i.e. the metric collection time window of measured metrics is not considered in space aggregation. We assume that either it is consistent for all the composed metrics, e.g. compose a set of average delays all referred to the same time window, or the time window of each composed metric does not affect aggregated metric. Thirdly, the concatenation in space is defined as the composition of metrics of same type and different (physical and non-overlapping) spatial scope, so that the resulting metric is representative of what the metric would be if directly obtained with a direct measurement over the sequence of the several spatial scopes. An example is the sum of OWDs of different edge-to- edge domain's delays, where the intermediate edge points are close to each other or happen to be the same. In this way, we can for example estimate OWD_AC starting from the knowledge of OWD_AB and OWD_BC. Differently from aggregation in space, all path's portions contribute equivalently to the composed metric, independently of the load on them. Note that in RFC 2330 the term "concatenation in space" is called spatial composition. We think that our proposed term concatenation in space is a more intuitive description, and thus we'll use it throughout the document. We avoided on purpose to assign a meaning to spatial composition, to avoid confusion. Finally, note that in practice there is often the need of extracting a new metric making some computation over one or more metrics with the same spatial and time scope. For example, the composed metric rtt_sample_variance is composed from the two different metrics: the help metric rtt_square_sum and the statistical metric rtt_sum. This operation is however more a simple calculation and not an aggregation or a concatenation, and we'll not investigate it further in this document. 2. Framework for Aggregation in Time This section defines a framework for aggregation in time as defined in the previous section. Suppose that we have a sample S composed of two parameters with values . We assume that the set consists of N metrics (or metric statistics), taken in the time window [T, T+delta_T]. Given these assumption we define the metric type-P-F- delta_T-metric as F(M_i), with F being an aggregation function. Note that it is not required to have the underlying metric aligned to the interval [T, T+delta_T]. This can introduce a error in the composition. Take for example a one-way delay measurement, of which Van den Berghe, et al. Expires May 20, 2006 [Page 7] Internet-Draft Temporal Aggregation November 2005 the average is reported every minute. When aggregating this over a 10 minute period, the set of values will be . If however, the reporting interval is not aligned to the 10 minute period, the value reported in T_0 will actually take into account delay measurements of the previous time interval. In order to reduce the error caused by misaligned time-intervals, N should be sufficiently large. 3. Example: One-Way Delay Temporal Composition Metrics and Statistics 3.1. Type-P-mean-delta_T-mean-One-Way-Delay 3.1.1. Definition This metric defines the mean one-way delay observed over a delta_T interval by aggregating the metric statistic mean-one-way-delay. For a description of one-way delay metrics and statistics, see RFC 2679 [RFC2679] 3.1.2. Composition Relationship Given N Type-P-One-Way-Delay-Mean values M_i reported at time intervals T_i, Type-P-mean-delta_T-mean-One-Way-Delay = (1/N) Sum (i=1..N) M_i. 3.1.3. Statement of Conjecture TBD 3.1.4. Justification for the Composite Relationship It is sometimes practical to aggregate information delivered by a single one-way delay measurement session into different time scales (e.g. minutes, hours, days, months). 3.1.5. Sources of Error See error caused by misalignment between the underlying measurement interval and delta_T. 3.2. Other Possibilities Other applicable composition functions F include: Type-P-minimum- delta_T-minimum-One-Way-Delay, Type-P-maximum-delta_T-maximum-One- Way-Delay, Type-P-Deviation-delta_T-mean-One-Way-Delay, Type-P- square_sum-delta_T-square_sum-One-Way-Delay (which is not a direct Van den Berghe, et al. Expires May 20, 2006 [Page 8] Internet-Draft Temporal Aggregation November 2005 usable metric, but a helper metric that allows to aggregate the deviation). Other compositions are of course analytically possible, but do not always have a practical significance (e.g. aggregation of X-percentiles). Additionally, the result of the aggregation in time itself might again be subject to aggregation. This allows to have a stepwise aggregation (e.g. from 1 minute to 5 minute intervals to 30 minutes intervals etc.). 4. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 5. Security Considerations The temporal composition of a metric is an analytical function performed on an underlying metric. As such, it introduces no new security considerations. 6. Acknowledgements A temporary list of people would be: Andreas Hanemann, Igor Velimirovic, Andreas Solberg, Athanassios Liakopulos, David Schitz, Nicolas Simar, Al Morton and the Geant2 Project. 7. Normative References [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. [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. Van den Berghe, et al. Expires May 20, 2006 [Page 9] Internet-Draft Temporal Aggregation November 2005 Authors' Addresses Steven Van den Berghe (editor) IBBT- Ghent University G. Crommenlaan 8 bus 201 Gent 9050 Belgium Phone: +32 9 331 49 73 Email: steven.vandenberghe@intec.ugent.be Andy Van Maele IBBT- Ghent University G. Crommenlaan 8 bus 201 Gent 9050 Belgium Email: andy.vanmaele@intec.ugent.be Maurizio Molina DANTE City House 126-130 Hills Road Cambridge CB21PQ United Kingdom Phone: +44 1223 371 300 Email: Email: maurizio.molina@dante.org.uk Van den Berghe, et al. Expires May 20, 2006 [Page 10] Internet-Draft Temporal Aggregation November 2005 Intellectual Property Statement 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 on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity 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 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Van den Berghe, et al. Expires May 20, 2006 [Page 11]