Internet DRAFT - draft-svdberg-ippm-temporal
draft-svdberg-ippm-temporal
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 <time,
value> with values <T_i, M_i>. 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 <T_0,...,T_9>. 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]
