One document matched: draft-ietf-ippm-framework-compagg-00.html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>Framework for Metric
Composition</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="Framework for Metric
Composition">
<meta name="generator" content="xml2rfc v1.30 (http://xml.resource.org/)">
<style type='text/css'>
<!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
margin: 2em;
font-size: small ; color: #000000 ; background-color: #ffffff ; }
.title { color: #990000; font-size: x-large ;
font-weight: bold; text-align: right;
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
background-color: transparent; }
.filename { color: #666666; font-size: 18px; line-height: 28px;
font-weight: bold; text-align: right;
font-family: helvetica, arial, sans-serif;
background-color: transparent; }
td.rfcbug { background-color: #000000 ; width: 30px ; height: 30px ;
text-align: justify; vertical-align: middle ; padding-top: 2px ; }
td.rfcbug span.RFC { color: #666666; font-weight: bold; text-decoration: none;
background-color: #000000 ;
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-size: x-small ; }
td.rfcbug span.hotText { color: #ffffff; font-weight: normal; text-decoration: none;
text-align: center ;
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-size: x-small ; background-color: #000000; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
div#counter{margin-top: 100px}
a.info{
position:relative; /*this is the key*/
z-index:24;
text-decoration:none}
a.info:hover{z-index:25; background-color:#990000 ; color: #ffffff ;}
a.info span{display: none}
a.info:hover span.info{ /*the span will display just on :hover state*/
display:block;
position:absolute;
font-size: smaller ;
top:2em; left:2em; width:15em;
padding: 2px ;
border:1px solid #333333;
background-color:#eeeeee; color:#990000;
text-align: left ;}
A { font-weight: bold; }
A:link { color: #990000; background-color: transparent ; }
A:visited { color: #333333; background-color: transparent ; }
A:active { color: #333333; background-color: transparent ; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small ; }
p.toc { font-size: small ; font-weight: bold ; margin-left: 3em ;}
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
span.emph { font-style: italic; }
span.strong { font-weight: bold; }
span.verb, span.vbare { font-family: "Courier New", Courier, monospace ; }
span.vemph { font-style: italic; font-family: "Courier New", Courier, monospace ; }
span.vstrong { font-weight: bold; font-family: "Courier New", Courier, monospace ; }
span.vdeluxe { font-weight: bold; font-style: italic; font-family: "Courier New", Courier, monospace ; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
pre { margin-left: 3em; color: #333333; background-color: transparent;
font-family: "Courier New", Courier, monospace ; font-size: small ;
text-align: left;
}
h3 { color: #333333; font-size: medium ;
font-family: helvetica, arial, sans-serif ;
background-color: transparent; }
h4 { font-size: small; font-family: helvetica, arial, sans-serif ; }
table.bug { width: 30px ; height: 15px ; }
td.bug { color: #ffffff ; background-color: #990000 ;
text-align: center ; width: 30px ; height: 15px ;
}
td.bug A.link2 { color: #ffffff ; font-weight: bold;
text-decoration: none;
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-size: x-small ; background-color: transparent }
td.header { color: #ffffff; font-size: x-small ;
font-family: arial, helvetica, sans-serif; vertical-align: top;
background-color: #666666 ; width: 33% ; }
td.author { font-weight: bold; margin-left: 4em; font-size: x-small ; }
td.author-text { font-size: x-small; }
table.full { vertical-align: top ; border-collapse: collapse ;
border-style: solid solid solid solid ;
border-color: black black black black ;
font-size: small ; text-align: center ; }
table.headers, table.none { vertical-align: top ; border-collapse: collapse ;
border-style: none;
font-size: small ; text-align: center ; }
table.full th { font-weight: bold ;
border-style: solid ;
border-color: black black black black ; }
table.headers th { font-weight: bold ;
border-style: none none solid none;
border-color: black black black black ; }
table.none th { font-weight: bold ;
border-style: none; }
table.full td {
border-style: solid solid solid solid ;
border-color: #333333 #333333 #333333 #333333 ; }
table.headers td, table.none td { border-style: none; }
hr { height: 1px }
-->
</style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Network Working Group</td><td class="header">A. Morton, Ed.</td></tr>
<tr><td class="header">Internet-Draft</td><td class="header">AT&T Labs</td></tr>
<tr><td class="header">Expires: August 28, 2006</td><td class="header">S. Van den Berghe, Ed.</td></tr>
<tr><td class="header"> </td><td class="header">Ghent University - IBBT</td></tr>
<tr><td class="header"> </td><td class="header">February 24, 2006</td></tr>
</table></td></tr></table>
<div align="right"><span class="title"><br />Framework for Metric
Composition</span></div>
<div align="right"><span class="title"><br />draft-ietf-ippm-framework-compagg-00</span></div>
<h3>Status of this Memo</h3>
<p>
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.</p>
<p>
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.</p>
<p>
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.”</p>
<p>
The list of current Internet-Drafts can be accessed at
<a href='http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/ietf/1id-abstracts.txt</a>.</p>
<p>
The list of Internet-Draft Shadow Directories can be accessed at
<a href='http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html</a>.</p>
<p>
This Internet-Draft will expire on August 28, 2006.</p>
<h3>Copyright Notice</h3>
<p>
Copyright © The Internet Society (2006).</p>
<h3>Abstract</h3>
<p>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.
</p>
<h3>Requirements Language</h3>
<p>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 <a class="info" href="#RFC2119">RFC 2119<span> (</span><span class="info">Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a> [RFC2119].
</p><a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#anchor1">1.</a>
Introduction<br />
<a href="#anchor2">1.1.</a>
Motivation<br />
<a href="#anchor3">2.</a>
Purpose and Scope<br />
<a href="#anchor4">3.</a>
Description of Metric Types <br />
<a href="#anchor5">3.1.</a>
Time Aggregation Description<br />
<a href="#anchor6">3.2.</a>
Spatial Aggregation Description<br />
<a href="#anchor7">3.3.</a>
Spatial Composition Description<br />
<a href="#anchor8">3.4.</a>
Help Metrics<br />
<a href="#anchor9">3.5.</a>
Higher Order Composition<br />
<a href="#anchor10">4.</a>
Requirements for Composed Metrics<br />
<a href="#anchor11">5.</a>
Guidelines for Defining Composed Metrics<br />
<a href="#anchor12">5.1.</a>
Ground Truth: Comparison with other IPPM Metrics<br />
<a href="#anchor13">5.2.</a>
Deviation from the Ground Truth<br />
<a href="#IANA">6.</a>
IANA Considerations<br />
<a href="#Security">7.</a>
Security Considerations<br />
<a href="#Acknowledgements">8.</a>
Acknowledgements<br />
<a href="#rfc.references1">9.</a>
References<br />
<a href="#rfc.references1">9.1.</a>
Normative References<br />
<a href="#rfc.references2">9.2.</a>
Informative References<br />
<a href="#rfc.authors">§</a>
Authors' Addresses<br />
<a href="#rfc.copyright">§</a>
Intellectual Property and Copyright Statements<br />
</p>
<br clear="all" />
<a name="anchor1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1. Introduction</h3>
<p>The IPPM framework RFC 2330 [RFC2330] describes two forms of metric
composition, spatial and temporal. Also, the text suggests that the
concepts of the analytical framework (or A-frame) would help to develop
useful relationships to derive the composed metrics from real metrics.
The effectiveness of composed metrics is dependent on their usefulness
in analysis and applicability to practical measurement
circumstances.
</p>
<p>This memo expands on the notion of composition, and provides a
detailed framework for several classes of metrics that were mentioned in
the original IPPM framework. The classes include temporal aggregation,
spatial aggregation, and spatial composition.
</p>
<a name="anchor2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.1.1"></a><h3>1.1. Motivation</h3>
<p>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.
</p>
<p>A first reason, mainly applicable to network engineering, is
scaleability. 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.
</p>
<p>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.
</p>
<p>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
Provider 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.
</p>
<a name="anchor3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2. Purpose and Scope</h3>
<p>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 relationship. 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.
</p>
<p>This memo will retain the terminology of the IPPM Framework as much
as possible, but will extend the terminology when necessary.
</p>
<a name="anchor4"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3"></a><h3>3. Description of Metric Types </h3>
<p>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.
</p>
<a name="anchor5"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.1"></a><h3>3.1. Time Aggregation Description</h3>
<p>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 series 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. Another useful application is to
detect anomalies or abnormal changes in the network
characteristics.
</p>
<p>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.
</p>
<a name="anchor6"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.2"></a><h3>3.2. Spatial Aggregation Description</h3>
<p>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 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.
</p>
<a name="anchor7"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.3"></a><h3>3.3. Spatial Composition Description</h3>
<p>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.
</p>
<p>Different from aggregation in space, all path's portions contribute
equally to the composed metric, independent of the traffic load
present.
</p>
<a name="anchor8"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.4"></a><h3>3.4. Help Metrics</h3>
<p>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 may be composed from 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.
</p>
<a name="anchor9"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.5"></a><h3>3.5. Higher Order Composition</h3>
<p>Composed metrics might themselves be subject to further
concatenation or aggregation. An example would be a maximal domain
obtained through the spatial composition of end-to-end delays, that
are themselves obtained through spatial composition. All requirements
for first order composition metrics apply to higher order
composition.
</p>
<a name="anchor10"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4"></a><h3>4. Requirements for Composed Metrics</h3>
<p>The definitions for all composed metrics MUST include sections to
treat the following topics.
</p>
<p>The description of each metric will clearly state: </p>
<ol class="text">
<li>the definition (and statistic, where appropriate);
</li>
<li>the composition or aggregation relationship;
</li>
<li>the specific conjecture on which the relationship is based;
</li>
<li>a justification of practical utility or usefulness for analysis
using the A-frame concepts;
</li>
<li>one or more examples of how the conjecture could be incorrect and
lead to inaccuracy;
</li>
<li>the information to be reported.
</li>
</ol>
<p>Each metric will require a relationship to determine the aggregated
or composed metric. The relationships may involve conjecture, and
[RFC2330] lists four points that the metric definitions should
include:
</p>
<p></p>
<ul class="text">
<li>the specific conjecture applied to the metric,
</li>
<li>a justification of the practical utility of the composition, in
terms of making accurate measurements of the metric on the path,
</li>
<li>a justification of the usefulness of the aggregation or
composition in terms of making analysis of the path using A-frame
concepts more effective, and
</li>
<li>an analysis of how the conjecture could be incorrect.
</li>
</ul>
<p>For each metric, the applicable circumstances are defined, in terms
of whether the composition or aggregation: </p>
<ul class="text">
<li>Requires homogeneity of measurement methodologies, or can allow a
degree of flexibility (e.g., active or passive methods produce the
"same" metric). Also, the applicable sending streams will be
specified, such as Poisson, Periodic, or both.
</li>
<li>Needs information or access that will only be available within an
operator's domain, or is applicable to Inter-domain composition.
</li>
<li>Requires precisely synchronized measurement time intervals in all
component metrics, or loosely synchronized, or no timing
requirements.
</li>
<li>Requires assumption of component metric independence w.r.t. the
metric being defined/composed, or other assumptions.
</li>
<li>Has known sources of inaccuracy/error, and identifies the
sources.
</li>
</ul>
<a name="anchor11"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.5"></a><h3>5. Guidelines for Defining Composed Metrics</h3>
<p>
</p>
<a name="anchor12"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.5.1"></a><h3>5.1. Ground Truth: Comparison with other IPPM Metrics</h3>
<p>Figure 1 illustrates the process to derive a metric using spatial
composition, and compares the composed metric to other IPPM
metrics.
</p>
<p>Metrics <M1, M2, M3> describe the performance of sub-paths
between the Source and Destination of interest during time interval
<T, Tf>. These metrics are the inputs for a Composition
Relationship that produces a Composed Metric.
</p>
<p>
<p>
</p><pre> Sub-Path Metrics
++ M1 ++ ++ M2 ++ ++ M3 ++
Src ||.......|| ||.......|| ||.......|| Dst
++ `. ++ ++ | ++ ++ .' ++
`. | .-'
`-. | .'
`._..|.._.'
,-' `-.
,' `.
| Composition |
\ Relationship '
`._ _,'
`--.....--'
|
++ | ++
Src ||...............................|| Dst
++ Composed Metric ++
++ Complete Path Metric ++
Src ||...............................|| Dst
++ ++
Spatial Metric
++ S1 ++ S2 ++ S3 ++
Src ||........||.........||..........|| Dst
++ ++ ++ ++</pre>
<p>Figure 1 Comparison with other IPPM metrics
</p>
<p>The Composed Metric is an estimate of an actual metric collected
over the complete Source to Destination path. We say that the Complete
Path Metric represents the "Ground Truth" for the Composed Metric. In
other words, Composed Metrics seek to minimize error w.r.t. the
Complete Path Metric.
</p>
<p>Further, we observe that a Spatial Metric <a class="info" href="#I-D.ietf-ippm-multimetrics">I-D.ietf-ippm-multimetrics<span> (</span><span class="info">Stephan, E., “IP Performance Metrics (IPPM) for spatial and multicast,” January 2006.</span><span>)</span></a> [I-D.ietf-ippm-multimetrics]collected
for packets traveling over the same set of sub-paths provide a basis
for the Ground Truth of the individual Sub-Path metrics. We note that
mathematical operations may be necessary to isolate the performance of
each sub-path.
</p>
<p>Next, we consider multiparty metrics as defined in
[I-D.ietf-ippm-multimetrics], and their spatial composition.
Measurements to each of the Receivers produce an element of the
one-to-group metric. These elements can be composed from sub-path
metrics and the composed metrics can be combined to create a composed
one-to-group metric. Figure 2 illustrates this process.
</p>
<p>
</p><pre> Sub-Path Metrics
++ M1 ++ ++ M2 ++ ++ M3 ++
Src ||.......|| ||.......|| ||.......||Rcvr1
++ ++ ++`. ++ ++ ++
`-.
M4`.++ ++ M5 ++
|| ||.......||Rcvr2
++ ++`. ++
`-.
M6`.++
||Rcvr3
++
One-to-Group Metric
++ ++ ++ ++
Src ||........||.........||..........||Rcvr1
++ ++. ++ ++
`-.
`-. ++ ++
`-||..........||Rcvr2
++. ++
`-.
`-. ++
`-.||Rcvr3
++</pre>
<p>Figure 2 Composition of One-to-Group Metrics
</p>
<p>
</p>
<p>Here, Sub-path Metrics M1, M2, and M3 are combined using a
relationship to compose the metric applicable to the Src-Rcvr1 path.
Similarly, M1, M4, and M5 are used to compose the Src-Rcvr2 metric and
M1, M4, and M6 compose the Src-Rcvr3 metric.
</p>
<p>The Composed One-to-Group Metric would list the Src-Rcvr metrics
for each Receiver in the Group:
</p>
<p>(Composed-Rcvr1, Composed-Rcvr2, Composed-Rcvr3)
</p>
<p>The "Ground Truth" for this composed metric is of course an actual
One-to-Group metric, where a single source packet has been measured
after traversing the Complete Paths to the various receivers.
</p>
<a name="anchor13"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.5.2"></a><h3>5.2. Deviation from the Ground Truth</h3>
<p>A metric composition can deviate from the ground truth for several
reasons. Two main aspects are:
</p>
<p></p>
<ul class="text">
<li>The propagation of the inaccuracies of the underlying
measurements when composing the metric. As part of the composition
function, errors of measurements might propagate. Where possible,
this analysis should be made and included with the description of
each metric.
</li>
<li>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.
</li>
</ul><p> The description of the metric composition MUST include an
section identifying the deviation from the ground truth.
</p>
<a name="IANA"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.6"></a><h3>6. IANA Considerations</h3>
<p>This document makes no request of IANA.
</p>
<p>Note to RFC Editor: this section may be removed on publication as an
RFC.
</p>
<a name="Security"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.7"></a><h3>7. Security Considerations</h3>
<p>
</p>
<a name="Acknowledgements"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.8"></a><h3>8. Acknowledgements</h3>
<p>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 Emile Stephan and Lei
Liang.
</p>
<a name="rfc.references"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.9"></a><h3>9. References</h3>
<a name="rfc.references1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<h3>9.1. Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="I-D.ietf-ippm-multimetrics">[I-D.ietf-ippm-multimetrics]</a></td>
<td class="author-text">Stephan, E., “<a href="http://www.ietf.org/internet-drafts/draft-ietf-ippm-multimetrics-00.txt">IP Performance Metrics (IPPM) for spatial and multicast</a>,” draft-ietf-ippm-multimetrics-00 (work in progress), January 2006.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td>
<td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">Key words for use in RFCs to Indicate Requirement Levels</a>,” BCP 14, RFC 2119, March 1997 (<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).</td></tr>
</table>
<a name="rfc.references2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<h3>9.2. Informative References</h3>
<table width="99%" border="0">
</table>
<a name="rfc.authors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<h3>Authors' Addresses</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text"> </td>
<td class="author-text">Al Morton (editor)</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">AT&T Labs</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">200 Laurel Avenue South</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Middletown,, NJ 07748</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">USA</td></tr>
<tr><td class="author" align="right">Phone: </td>
<td class="author-text">+1 732 420 1571</td></tr>
<tr><td class="author" align="right">Fax: </td>
<td class="author-text">+1 732 368 1192</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:acmorton@att.com">acmorton@att.com</a></td></tr>
<tr><td class="author" align="right">URI: </td>
<td class="author-text"><a href="http://home.comcast.net/~acmacm/">http://home.comcast.net/~acmacm/</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Steven Van den Berghe (editor)</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Ghent University - IBBT</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">G. Crommenlaan 8 bus 201</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Gent 9050</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Belgium</td></tr>
<tr><td class="author" align="right">Phone: </td>
<td class="author-text">+32 9 331 49 73</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:steven.vandenberghe@intec.ugent.be">steven.vandenberghe@intec.ugent.be</a></td></tr>
<tr><td class="author" align="right">URI: </td>
<td class="author-text"><a href="http://www.ibcn.intec.ugent.be">http://www.ibcn.intec.ugent.be</a></td></tr>
</table>
<a name="rfc.copyright"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<h3>Intellectual Property Statement</h3>
<p class='copyright'>
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.</p>
<p class='copyright'>
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 <a href='http://www.ietf.org/ipr'>http://www.ietf.org/ipr</a>.</p>
<p class='copyright'>
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 <a href='mailto:ietf-ipr@ietf.org'>ietf-ipr@ietf.org</a>.</p>
<h3>Disclaimer of Validity</h3>
<p class='copyright'>
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.</p>
<h3>Copyright Statement</h3>
<p class='copyright'>
Copyright © The Internet Society (2006).
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.</p>
<h3>Acknowledgment</h3>
<p class='copyright'>
Funding for the RFC Editor function is currently provided by the
Internet Society.</p>
</body></html>
| PAFTECH AB 2003-2026 | 2026-04-23 04:27:41 |