One document matched: draft-ietf-ippm-spatial-composition-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>Spatial Composition of Metrics</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="Spatial Composition of Metrics">
<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</td></tr>
<tr><td class="header">Internet-Draft</td><td class="header">AT&T Labs</td></tr>
<tr><td class="header">Expires: August 30, 2006</td><td class="header">E. Stephan</td></tr>
<tr><td class="header"> </td><td class="header">France Telecom Division R&D</td></tr>
<tr><td class="header"> </td><td class="header">February 26, 2006</td></tr>
</table></td></tr></table>
<div align="right"><span class="title"><br />Spatial Composition of Metrics</span></div>
<div align="right"><span class="title"><br />draft-ietf-ippm-spatial-composition-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 30, 2006.</p>
<h3>Copyright Notice</h3>
<p>
Copyright © The Internet Society (2006).</p>
<h3>Abstract</h3>
<p>This memo utilizes IPPM metrics that are applicable to both complete
paths and sub-paths, and defines relationships to compose a complete
path metric from the sub-path metrics with some accuracy w.r.t. the
actual metrics. This is called Spatial Composition in RFC 2330. The memo
refers to the Framework for Metric Composition, and provides background
and motivation for combining metrics to derive others. The descriptions
of several composed metrics and statistics follow.
</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>
<p>In this memo, the characters "<=" should be read as "less than or
equal to" and ">=" as "greater than or equal to".
</p><a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#anchor1">1.</a>
Contributors<br />
<a href="#anchor2">2.</a>
Introduction<br />
<a href="#anchor3">2.1.</a>
Motivation<br />
<a href="#anchor4">3.</a>
Scope, Application, and Terminology<br />
<a href="#anchor5">3.1.</a>
Scope of work<br />
<a href="#anchor6">3.2.</a>
Application<br />
<a href="#anchor7">3.3.</a>
Terminology<br />
<a href="#anchor8">4.</a>
One-way Delay Composition Metrics and Statistics<br />
<a href="#anchor9">4.1.</a>
Name: Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream<br />
<a href="#anchor10">4.1.1.</a>
Metric Parameters:<br />
<a href="#anchor11">4.1.2.</a>
Definition and Metric Units<br />
<a href="#anchor12">4.1.3.</a>
Discussion and other details<br />
<a href="#anchor13">4.1.4.</a>
Mean Statistic<br />
<a href="#anchor14">4.1.5.</a>
Composition Relationship: Sum of Means<br />
<a href="#anchor15">4.1.6.</a>
Statement of Conjecture<br />
<a href="#anchor16">4.1.7.</a>
Justification of Composite Relationship<br />
<a href="#anchor17">4.1.8.</a>
Sources of Error<br />
<a href="#anchor18">4.1.9.</a>
Specific cases where the conjecture might fail<br />
<a href="#anchor19">4.1.10.</a>
Application of Measurement Methodology<br />
<a href="#anchor20">5.</a>
Loss Metrics and Statistics<br />
<a href="#anchor21">5.1.</a>
Name: Type-P-One-way-Packet-Loss-Poisson/Periodic-Stream<br />
<a href="#anchor22">5.1.1.</a>
Metric Parameters:<br />
<a href="#anchor23">5.1.2.</a>
Definition and Metric Units<br />
<a href="#anchor24">5.1.3.</a>
Discussion and other details<br />
<a href="#anchor25">5.1.4.</a>
Statistic: Type-P-One-way-Packet-Loss-Empirical-Probability<br />
<a href="#anchor26">5.1.5.</a>
Composition Relationship: Composition of Empirical Probabilities<br />
<a href="#anchor27">5.1.6.</a>
Statement of Conjecture<br />
<a href="#anchor28">5.1.7.</a>
Justification of Composite Relationship<br />
<a href="#anchor29">5.1.8.</a>
Sources of Error<br />
<a href="#anchor30">5.1.9.</a>
Specific cases where the conjecture might fail<br />
<a href="#anchor31">5.1.10.</a>
Application of Measurement Methodology<br />
<a href="#anchor32">6.</a>
Delay Variation Metrics and Statistics<br />
<a href="#anchor33">6.1.</a>
Name: Type-P-One-way-ipdv-refmin-Poisson/Periodic-Stream<br />
<a href="#anchor34">6.1.1.</a>
Metric Parameters:<br />
<a href="#anchor35">6.1.2.</a>
Definition and Metric Units<br />
<a href="#anchor36">6.1.3.</a>
Discussion and other details<br />
<a href="#anchor37">6.1.4.</a>
Statistics: Mean, Variance, Skewness, Quanitle<br />
<a href="#anchor38">6.1.5.</a>
Composition Relationships:<br />
<a href="#anchor39">6.1.6.</a>
Statement of Conjecture<br />
<a href="#anchor40">6.1.7.</a>
Justification of Composite Relationship<br />
<a href="#anchor41">6.1.8.</a>
Sources of Error<br />
<a href="#anchor42">6.1.9.</a>
Specific cases where the conjecture might fail<br />
<a href="#anchor43">6.1.10.</a>
Application of Measurement Methodology<br />
<a href="#anchor44">7.</a>
Other Metrics and Statistics: One-way Combined Metric<br />
<a href="#anchor45">7.1.</a>
Metric Name:<br />
<a href="#anchor46">7.1.1.</a>
Metric Parameters:<br />
<a href="#anchor47">7.1.2.</a>
Definition and Metric Units<br />
<a href="#anchor48">7.1.3.</a>
Discussion and other details<br />
<a href="#anchor49">7.1.4.</a>
Type-P-One-way-Combo-subpathes-stream<br />
<a href="#anchor50">7.1.5.</a>
Type-P-One-way-composition<br />
<a href="#anchor51">7.1.6.</a>
Type-P-One-way-composition<br />
<a href="#anchor52">7.1.7.</a>
Statement of Conjecture<br />
<a href="#anchor53">7.1.8.</a>
Justification of Composite Relationship<br />
<a href="#anchor54">7.1.9.</a>
Sources of Error<br />
<a href="#anchor55">7.1.10.</a>
Specific cases where the conjecture might fail<br />
<a href="#anchor56">7.1.11.</a>
Application of Measurement Methodology<br />
<a href="#anchor57">8.</a>
Security Considerations<br />
<a href="#anchor58">8.1.</a>
Denial of Service Attacks<br />
<a href="#anchor59">8.2.</a>
User Data Confidentiality<br />
<a href="#anchor60">8.3.</a>
Interference with the metrics<br />
<a href="#IANA">9.</a>
IANA Considerations<br />
<a href="#Security">10.</a>
Security Considerations<br />
<a href="#anchor61">11.</a>
Open Issues<br />
<a href="#Acknowledgements">12.</a>
Acknowledgements<br />
<a href="#rfc.references1">13.</a>
References<br />
<a href="#rfc.references1">13.1.</a>
Normative References<br />
<a href="#rfc.references2">13.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. Contributors</h3>
<p>Thus far, the following people have contributed useful ideas,
suggestions, or the text of sections that have been incorporated into
this memo:
</p>
<p>- Phil Chimento <vze275m9@verizon.net>
</p>
<p>- Reza Fardid <RFardid@Covad.COM>
</p>
<p>- Roman Krzanowski <roman.krzanowski@verizon.com>
</p>
<p>- Maurizio Molina <maurizio.molina@dante.org.uk>
</p>
<p>- Al Morton <acmorton@att.com>
</p>
<p>- Emile Stephan <emile.stephan@francetelecom.com>
</p>
<p>- Lei Liang <L.Liang@surrey.ac.uk>
</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.2"></a><h3>2. Introduction</h3>
<p>The IPPM framework <a class="info" href="#RFC2330">RFC 2330<span> (</span><span class="info">Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, “Framework for IP Performance Metrics,” May 1998.</span><span>)</span></a> [RFC2330] describes
two forms of metric composition, spatial and temporal. The new
composition framework [FRMWK] expands and further qualifies these
original forms into three categories. This memo describes Spatial
Composition, one of the categories of metrics under the umbrella of the
composition framework.
</p>
<p>Spatial composition encompasses the definition of performance metrics
that are applicable to a complete path, based on metrics collected on
various sub-paths.
</p>
<p>The purpose of this memo is to define relationships that yield the
complete path metrics using metrics of the sub-paths. The effectiveness
of such metrics is dependent on their usefulness in analysis and
applicability with practical measurement methods.
</p>
<p>The relationships may involve conjecture, and [RFC2330] lists four
points that the metric definitions should include: </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 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>RFC 2330 also gives an example where a conjecture that the
delay of a path is very nearly the sum of the delays of the exchanges
and clouds of the corresponding path digest. This example is
particularly relevant to those who wish to assess the performance of an
Inter-domain path without direct measurement, and the performance
estimate of the complete path is related to the measured results for
various sub-paths instead.
</p>
<p>Approximate relationships between the sub-path and complete path
metrics are useful, with knowledge of the circumstances where the
relationships are/are not applicable. For example, we would not expect
that delay singletons from each sub-path would sum to produce an
accurate estimate of a delay singleton for the complete path (unless all
the delays were essentially constant - very unlikely). However, other
delay statistics (based on a reasonable sample size) may have a
sufficiently large set of circumstances where they are applicable.
</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.1"></a><h3>2.1. Motivation</h3>
<p>One-way metrics defined in other IPPM RFCs all assume that the
measurement can be practically carried out between the source and the
destination of the interest. Sometimes there are reasons that the
measurement can not be executed from the source to the destination.
For instance, the measurement path may cross several independent
domains that have conflicting policies, measurement tools and methods,
and measurement time slot assignment. The solution then may be the
composition of several sub-path measurements. That means each domain
performs the One-way measurement on a sub path between two nodes that
are involved in the complete path following its own policy, using its
own measurement tools and methods, and within its own measurement time
slot. Under the appropriate conditions, one can combine the sub-path
One-way metric results to estimate the complete path One-way
measurement metric with some accuracy.
</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. Scope, Application, and Terminology</h3>
<p>
</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. Scope of work</h3>
<p>For the primary IPPM metrics (currently Loss, Delay, and Delay
Variation), this memo gives a set of complete path metrics that can be
composed from the same or similar sub-path metrics. This means that
the complete path metric may be composed from: </p>
<ul class="text">
<li>the same metric for each sub-path;
</li>
<li>multiple metrics for each sub-path (possibly one that is the
same as the complete path metric);
</li>
<li>a single sub-path metrics that is different from the complete
path metric;
</li>
<li>different measurement techniques like active and passive
(recognizing that PSAMP WG will define capabilities to sample
packets to support measurement).
</li>
</ul>
<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. Application</h3>
<p>The new composition framework [FRMWK] requires the specification of
the applicable circumstances for each metric. In particular, the
application of Spatial Composition metrics are addressed as to whether
the metric:
</p>
<p>Requires the same test packets to traverse all sub-paths, or may
use similar packets sent and collected separately in each
sub-path.
</p>
<p>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.
</p>
<p>Needs information or access that will only be available within an
operator's domain, or is applicable to Inter-domain composition.
</p>
<p>Requires synchronized measurement time intervals in all sub-paths,
or largely overlapping, or no timing requirements.
</p>
<p>Requires assumption of sub-path independence w.r.t. the metric
being defined/composed, or other assumptions.
</p>
<p>Has known sources of inaccuracy/error, and identifies the
sources.
</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. Terminology</h3>
<p>This section defines the terminology applicable to Spatial
Composition metrics.
</p>
<p>Measurement Points:
</p>
<p><there must be a suitable definition for this in IPPM’s
literature>
</p>
<p>Complete path:
</p>
<p>The complete path is the true path that a packet would follow as it
traverses from the packet’s Source to its Destination.
</p>
<p>Complete path metric:
</p>
<p>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.
</p>
<p>Composite Metric (or Composed Metric):
</p>
<p>A composite metric is type of metric that is derived from other
metrics principally by applying a composition relationship.
</p>
<p>Composition Relationship:
</p>
<p>A composition relationship is a deterministic process applied to
Sub-path metrics to derive another metric (such as a Composite
metric).
</p>
<p>Sub-path:
</p>
<p>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
path. We say that this sub-path is “involved” in the
complete path.
</p>
<p>Sub-path metrics:
</p>
<p>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.
</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.4"></a><h3>4. One-way Delay Composition Metrics and Statistics</h3>
<p>
</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.4.1"></a><h3>4.1. Name: Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream</h3>
<p>This metric is a necessary element of Delay Composition metrics,
and its definition does not formally exist elsewhere in IPPM
literature.
</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.1.1"></a><h3>4.1.1. Metric Parameters:</h3>
<p></p>
<ul class="text">
<li>Src, the IP address of a host + Dst, the IP address of a
host
</li>
<li>T, a time (start of test interval)
</li>
<li>Tf, a time (end of test interval)
</li>
<li>lambda, a rate in reciprocal seconds (for Poisson
Streams)
</li>
<li>incT, the nominal duration of inter-packet interval, first
bit to first bit (for Periodic Streams)
</li>
<li>T0, a time that MUST be selected at random from the interval
[T, T+dT] to start generating packets and taking measurements
(for Periodic Streams)
</li>
<li>TstampSrc, the wire time of the packet as measured at
MP(Src)
</li>
<li>TstampDst, the wire time of the packet as measured at
MP(Dst), assigned to packets that arrive within a "reasonable"
time.
</li>
<li>Tmax, a maximum waiting time for packets at the
destination.
</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.4.1.2"></a><h3>4.1.2. Definition and Metric Units</h3>
<p>Using the parameters above, we obtain the value of
Type-P-One-way-Delay singleton as per <a class="info" href="#RFC2679">RFC
2679<span> (</span><span class="info">Almes, G., Kalidindi, S., and M. Zekauskas, “A One-way Delay Metric for IPPM,” September 1999.</span><span>)</span></a> [RFC2679].
</p>
<p>For each packet [i] that has a finite One-way Delay (in other
words, excluding packets which have undefined, or infinite one-way
delay):
</p>
<p>Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i] =
</p>
<p>FiniteDelay[i] = TstampDst - TstampSrc
</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.4.1.3"></a><h3>4.1.3. Discussion and other details</h3>
<p>The “Type-P-Finite-One-way-Delay” metric allows
calculation of the mean statistic. This avoids the need to include
lost packets in the sample (whose delay is undefined), and the issue
with the prescribed assignment of infinite delay to lost packets
when practical systems can only assign some very large value.
</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.4.1.4"></a><h3>4.1.4. Mean Statistic</h3>
<p>We add the following parameter:
</p>
<p></p>
<ul class="text">
<li>N, the total number of packets received at Dst (sent between
T0 and Tf)
</li>
</ul><p>and define
</p>
<p>Type-P-Finite-One-way-Delay-Mean =
</p><pre> N
---
1 \
- * > (FiniteDelay [i])
N /
---
i = 1</pre>
<p>
</p>
<p>where all packets i= 1 through N have finite singleton
delays.
</p>
<a name="anchor14"></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.1.5"></a><h3>4.1.5. Composition Relationship: Sum of Means</h3>
<p>The Type-P-Finite—Composite-One-way-Delay-Mean, or
CompMeanDelay for the complete Source to Destination path can be
calculated from sum of the Mean Delays of all its S constituent
sub-paths.
</p>
<p></p>
<ul class="text">
<li>S, the number of sub-paths involved in the complete Src-Dst
path.
</li>
</ul>
<p>Then the
</p>
<p>Type-P-Finite-Composite-One-way-Delay-Mean =
</p>
<p>CompMeanDelay = (1/S)Sum(from i=1 to S, MeanDelay[i])
</p>
<a name="anchor15"></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.1.6"></a><h3>4.1.6. Statement of Conjecture</h3>
<p>The mean of a sufficiently large stream of packets measured on
each sub-path during the interval [T, Tf] will be representative of
the true mean of the delay distribution (and the distributions
themselves are sufficiently independent), such that the means may be
added to produce an estimate of the complete path mean delay.
</p>
<a name="anchor16"></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.1.7"></a><h3>4.1.7. Justification of Composite Relationship</h3>
<p>It is sometimes impractical to conduct active measurements
between every Src-Dst pair. For example, it may not be possible to
collect the desired sample size in each test interval when access
link speed is limited, because of the potential for measurement
traffic to degrade the user traffic performance. The conditions on a
low-speed access link may be understood well-enough to permit use of
a small sample size/rate, while a larger sample size/rate may be
used on other sub-paths.
</p>
<p>Also, since measurement operations have a real monetary cost,
there is value in re-using measurements where they are applicable,
rather than launching new measurements for every possible
source-destination pair.
</p>
<a name="anchor17"></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.1.8"></a><h3>4.1.8. Sources of Error</h3>
<p>The measurement packets, each having source and destination
addresses intended for collection at edges of the sub-path, may take
a different specific path through the network equipment and parallel
exchanges than packets with the source and destination addresses of
the complete path. Therefore, the sub-path measurements may differ
from the performance experienced by packets on the complete path.
Multiple measurements employing sufficient sub-path address pairs
might produce bounds on the extent of this error.
</p>
<p>others...
</p>
<a name="anchor18"></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.1.9"></a><h3>4.1.9. Specific cases where the conjecture might fail</h3>
<p>If any of the sub-path distributions are bimodal, then the
measured means may not be stable, and in this case the mean will not
be a particularly useful statistic when describing the delay
distribution of the complete path.
</p>
<p>The mean may not be sufficiently robust statistic to produce a
reliable estimate, or to be useful even if it can be measured.
</p>
<p>others...
</p>
<a name="anchor19"></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.1.10"></a><h3>4.1.10. Application of Measurement Methodology</h3>
<p>The methodology:
</p>
<p>SHOULD use similar packets sent and collected separately in each
sub-path.
</p>
<p>Allows a degree of flexibility (e.g., active or passive methods
can produce the "same" metric, but timing and correlation of passive
measurements is much more challenging).
</p>
<p>Poisson and/or Periodic streams are RECOMMENDED.
</p>
<p>Applicable to both Inter-domain and Intra-domain composition.
</p>
<p>SHOULD have synchronized measurement time intervals in all
sub-paths, but largely overlapping intervals MAY suffice.
</p>
<p>REQUIRES assumption of sub-path independence w.r.t. the metric
being defined/composed.
</p>
<a name="anchor20"></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. Loss Metrics and Statistics</h3>
<p>
</p>
<a name="anchor21"></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. Name: Type-P-One-way-Packet-Loss-Poisson/Periodic-Stream</h3>
<p>
</p>
<a name="anchor22"></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.1"></a><h3>5.1.1. Metric Parameters:</h3>
<p>Same as section 4.1.1.
</p>
<a name="anchor23"></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.2"></a><h3>5.1.2. Definition and Metric Units</h3>
<p>Using the parameters above, we obtain the value of
Type-P-One-way-Packet-Loss singleton and stream as per <a class="info" href="#RFC2680">RFC 2680<span> (</span><span class="info">Almes, G., Kalidindi, S., and M. Zekauskas, “A One-way Packet Loss Metric for IPPM,” September 1999.</span><span>)</span></a> [RFC2680].
</p>
<p>We obtain a sequence of pairs with elements as follows: </p>
<ul class="text">
<li>TstampSrc, as above
</li>
<li>L, either zero or one, where L=1 indicates loss and L=0
indicates arrival at the destination within TstampSrc +
Tmax.
</li>
</ul>
<a name="anchor24"></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.3"></a><h3>5.1.3. Discussion and other details</h3>
<p>
</p>
<a name="anchor25"></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.4"></a><h3>5.1.4. Statistic: Type-P-One-way-Packet-Loss-Empirical-Probability</h3>
<p>Given the following stream parameter
</p>
<p></p>
<ul class="text">
<li>N, the total number of packets sent between T0 and Tf
</li>
</ul><p>We can define the Empirical Probability of Loss Statistic
(Ep), consistent with Average Loss in [RFC2680], as follows:
</p>
<p>Type-P-One-way-Packet-Loss-Empirical-Probability =
</p>
<p>Ep = (1/N)Sum(from i=1 to N, L[i])
</p>
<p>where all packets i= 1 through N have a value for L.
</p>
<a name="anchor26"></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.5"></a><h3>5.1.5. Composition Relationship: Composition of Empirical Probabilities</h3>
<p>The Type-P-One-way-Composite-Packet-Loss-Empirical-Probability,
or CompEp for the complete Source to Destination path can be
calculated by combining Ep of all its constituent sub-paths (Ep1,
Ep2, Ep3, ... Epn) as
</p>
<p>Type-P-One-way-Composite-Packet-Loss-Empirical-Probability =
CompEp = 1 – {(1 - Ep1) x (1 – Ep2) x (1 – Ep3) x
... x (1 – Epn)}
</p>
<a name="anchor27"></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.6"></a><h3>5.1.6. Statement of Conjecture</h3>
<p>The empirical probability of loss calculated on a sufficiently
large stream of packets measured on each sub-path during the
interval [T, Tf] will be representative of the true loss probability
(and the probabilities themselves are sufficiently independent),
such that the sub-path probabilities may be combined to produce an
estimate of the complete path loss probability.
</p>
<a name="anchor28"></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.7"></a><h3>5.1.7. Justification of Composite Relationship</h3>
<p>It is sometimes impractical to conduct active measurements
between every Src-Dst pair. For example, it may not be possible to
collect the desired sample size in each test interval when access
link speed is limited, because of the potential for measurement
traffic to degrade the user traffic performance. The conditions on a
low-speed access link may be understood well-enough to permit use of
a small sample size/rate, while a larger sample size/rate may be
used on other sub-paths.
</p>
<p>Also, since measurement operations have a real monetary cost,
there is value in re-using measurements where they are applicable,
rather than launching new measurements for every possible
source-destination pair.
</p>
<a name="anchor29"></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.8"></a><h3>5.1.8. Sources of Error</h3>
<p>The measurement packets, each having source and destination
addresses intended for collection at edges of the sub-path, may take
a different specific path through the network equipment and parallel
exchanges than packets with the source and destination addresses of
the complete path. Therefore, the sub-path measurements may differ
from the performance experienced by packets on the complete path.
Multiple measurements employing sufficient sub-path address pairs
might produce bounds on the extent of this error.
</p>
<p>others...
</p>
<a name="anchor30"></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.9"></a><h3>5.1.9. Specific cases where the conjecture might fail</h3>
<p>A concern for loss measurements combined in this way is that root
causes may be correlated to some degree.
</p>
<p>For example, if the links of different networks follow the same
physical route, then a single event like a tunnel fire could cause
an outage or congestion on remaining paths in multiple networks.
Here it is important to ensure that measurements before the event
and after the event are not combined to estimate the composite
performance.
</p>
<p>Or, when traffic volumes rise due to the rapid spread of an
email-born worm, loss due to queue overflow in one network may help
another network to carry its traffic without loss.
</p>
<p>others...
</p>
<a name="anchor31"></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.10"></a><h3>5.1.10. Application of Measurement Methodology</h3>
<p>The methodology:
</p>
<p>SHOULD use similar packets sent and collected separately in each
sub-path.
</p>
<p>Allows a degree of flexibility (e.g., active or passive methods
can produce the "same" metric, but timing and correlation of passive
measurements is much more challenging).
</p>
<p>Poisson and/or Periodic streams are RECOMMENDED.
</p>
<p>Applicable to both Inter-domain and Intra-domain composition.
</p>
<p>SHOULD have synchronized measurement time intervals in all
sub-paths, but largely overlapping intervals MAY suffice.
</p>
<p>REQUIRES assumption of sub-path independence w.r.t. the metric
being defined/composed.
</p>
<a name="anchor32"></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. Delay Variation Metrics and Statistics</h3>
<p>
</p>
<a name="anchor33"></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.1"></a><h3>6.1. Name: Type-P-One-way-ipdv-refmin-Poisson/Periodic-Stream</h3>
<p>This metric is a necessary element of Composed Delay Variation
metrics, and its definition does not formally exist elsewhere in IPPM
literature.
</p>
<a name="anchor34"></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.1.1"></a><h3>6.1.1. Metric Parameters:</h3>
<p>In addition to the parameters of section 4.1.1:</p>
<ul class="text">
<li>TstampSrc[i], the wire time of packet[i] as measured at
MP(Src)
</li>
<li>TstampDst[i], the wire time of packet[i] as measured at
MP(Dst), assigned to packets that arrive within a "reasonable"
time.
</li>
<li>B, a packet length in bits
</li>
<li>F, a selection function unambiguously defining the packets
from the stream that are selected for the packet-pair
computation of this metric. F(first packet), the first packet of
the pair, MUST have a valid Type-P-Finite-One-way-Delay less
than Tmax (in other words, excluding packets which have
undefined, or infinite one-way delay) and MUST have been
transmitted during the interval T, Tf. The second packet in the
pair MUST be the packet with the minimum valid value of
Type-P-Finite-One-way-Delay for the stream, in addition to the
criteria for F(first packet). If multiple packets have equal
minimum Type-P-Finite-One-way-Delay values, then the value for
the earliest arriving packet SHOULD be used.
</li>
<li>MinDelay, the Type-P-Finite-One-way-Delay value for F(second
packet) given above.
</li>
<li>N, the number of packets received at the Destination meeting
the F(first packet) criteria.
</li>
</ul>
<a name="anchor35"></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.1.2"></a><h3>6.1.2. Definition and Metric Units</h3>
<p>Using the definition above in section 4.1.2, we obtain the value
of Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i], the
singleton for each packet[i] in the stream (a.k.a.
FiniteDelay[i]).
</p>
<p>For each packet[i] that meets the F(first packet) criteria given
above: Type-P-One-way-ipdv-refmin-Poisson/Periodic-Stream[i] =
</p>
<p>IPDVRefMin[i] = FiniteDelay[i] – MinDelay
</p>
<p>where IPDVRefMin[i] is in units of time (seconds,
milliseconds).
</p>
<a name="anchor36"></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.1.3"></a><h3>6.1.3. Discussion and other details</h3>
<p>This metric produces a sample of delay variation normalized to
the minimum delay of the sample. The resulting delay variation
distribution is independent of the sending sequence (although
specific FiniteDelay values within the distribution may be
correlated, depending on various stream parameters such as packet
spacing). This metric is equivalent to the IP Packet Delay Variation
parameter defined in [Y.1540].
</p>
<a name="anchor37"></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.1.4"></a><h3>6.1.4. Statistics: Mean, Variance, Skewness, Quanitle</h3>
<p>We define the mean IPDVRefMin as follows (where all packets i= 1
through N have a value for IPDVRefMin):
</p>
<p>Type-P-One-way-ipdv-refmin-Mean = MeanIPDVRefMin
=
</p><pre> N
---
1 \
- * > (IPDVRefMin [i])
N /
---
i = 1</pre>
<p>
</p>
<p>We define the variance of IPDVRefMin as follows:
</p>
<p>Type-P-One-way-ipdv-refmin-Variance = VarIPDVRefMin
=
</p><pre> N
---
1 \ 2
------- > (IPDVRefMin [i] - MeanIPDVRefMin)
(N - 1) /
---
i = 1</pre>
<p>
</p>
<p>
</p>
<p>We define the skewness of IPDVRefMin as follows:
</p>
<p>Type-P-One-way-ipdv-refmin-Skewness = SkewIPDVRefMin
=
</p><pre> N
--- 3
\ / \
> | IPDVRefMin[i]- MeanIPDVRefMin |
/ \ /
---
i = 1
-------------------------------------------
/ \
| ( 3/2 ) |
\ (N - 1) * VarIPDVRefMin /</pre>
<p>
</p>
<p>
</p>
<p>We define the Quantile of the IPDVRefMin sample as the value
where the specified fraction of points is less than the given
value.
</p>
<a name="anchor38"></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.1.5"></a><h3>6.1.5. Composition Relationships:</h3>
<p>The Type-P-One-way-Composite-ipdv-refmin-<something> for
the complete Source to Destination path can be calculated by
combining statistics of all the constituent sub-paths in the
following process:
</p>
<p>< to be provided >
</p>
<a name="anchor39"></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.1.6"></a><h3>6.1.6. Statement of Conjecture</h3>
<p>
</p>
<a name="anchor40"></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.1.7"></a><h3>6.1.7. Justification of Composite Relationship</h3>
<p>
</p>
<a name="anchor41"></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.1.8"></a><h3>6.1.8. Sources of Error</h3>
<p>
</p>
<a name="anchor42"></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.1.9"></a><h3>6.1.9. Specific cases where the conjecture might fail</h3>
<p>
</p>
<a name="anchor43"></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.1.10"></a><h3>6.1.10. Application of Measurement Methodology</h3>
<p>
</p>
<a name="anchor44"></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. Other Metrics and Statistics: One-way Combined Metric</h3>
<p>This definition may be the common part for the definition of "Loss
Metrics/Statistics" and for the definition of "One-way Delay Composition
Metrics and Statistics".
</p>
<a name="anchor45"></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.1"></a><h3>7.1. Metric Name:</h3>
<p>Type-P-One-way-Combo-mean
</p>
<a name="anchor46"></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.1.1"></a><h3>7.1.1. Metric Parameters:</h3>
<p>Editorial notes (ES): parameters list to be completed
</p>
<p><P1,T1,dt1>...<Pn,Tn,dtn>:
</p>
<p>It is a stream of One-way delay corresponding either to an end to
end measure of a sub-path, or to the spatial measure of the
sub-path:
</p>
<p>- Type-P-One-way-Delay-Poisson-Stream as per [RFC2679];
</p>
<p>- Type-P-One-way-Delay-Periodic-Stream a per <a class="info" href="#RFC3432">RFC 3432<span> (</span><span class="info">Raisanen, V., Grotefeld, G., and A. Morton, “Network performance measurement with periodic streams,” November 2002.</span><span>)</span></a> [RFC3432];
</p>
<p>- Type-P-One-way-Composition-Stream as defined below;
</p>
<p>- Type-P-subpath-One-way-Delay-Stream as per
</p>
<p><a class="info" href="#I-D.stephan-ippm-multimetrics">I-D.stephan-ippm-multimetrics<span> (</span><span class="info">Stephan, E., “IP Performance Metrics (IPPM) for spatial and multicast,” October 2005.</span><span>)</span></a> [I-D.stephan-ippm-multimetrics].
</p>
<a name="anchor47"></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.1.2"></a><h3>7.1.2. Definition and Metric Units</h3>
<p>Using the value <P1,T1,dt1>...<Pn,Tn,dtn> of one of
the One-way delay Stream listed above, we define
Type-P-One-way-Combo as the couple (D,L) where D is the mean of the
delay of the packets that have a finite One-way, and where L is the
average of lost of packets (which have undefined, or infinite
one-way delay).
</p>
<p>D corresponds to the Type-P-Finite-One-way-Delay-Mean defined
above.
</p>
<p>L corresponds to the
Type-P-One-way-Packet-Loss-Empirical-Probability defined above.
</p>
<a name="anchor48"></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.1.3"></a><h3>7.1.3. Discussion and other details</h3>
<p>
</p>
<a name="anchor49"></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.1.4"></a><h3>7.1.4. Type-P-One-way-Combo-subpathes-stream</h3>
<p>Parameters:
</p>
<p>+ dT1,..., dTn a list of delay.
</p>
<p>+ <Src, H1, H2,..., Hn, Dst>, the equivalent path.
</p>
<p>Definition:
</p>
<p>Using Type-P-One-way-Combo-mean of each sub-path in the
equivalent path we define a Type-P-One-way-subpathes-stream as the
list of couples (D,L) of the sub-path list;
</p>
<p>Results: {<D0,L0>, <D1,L1>, <D2,L2>, …
<Dn,Ln>}
</p>
<a name="anchor50"></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.1.5"></a><h3>7.1.5. Type-P-One-way-composition</h3>
<p>The composition over a path gives D and L which give an
estimation of the end-to-end delay and end-to-end packet lost over
this path.
</p>
<p>Parameters:
</p>
<p>+ <Src, H1, H2,..., Hn, Dst>, the complete path.
</p>
<p>+ {<D0,L0>, <D1,L1>, <D2,L2>, …
<Dn,Ln>}, the composition stream of the sub-paths of a
path.
</p>
<p>Definition:
</p>
<p>Using Type-P-One-way-subpathes-stream we define
Type-P-One-way-composition as the couple <D,L> where D is the
mean of the delays Di and where L is the average of lost of Li.
</p>
<p>Results: <D,L>, where D is a delay and L is the lost
</p>
<a name="anchor51"></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.1.6"></a><h3>7.1.6. Type-P-One-way-composition</h3>
<p>The sample of Type-P-One-way-composition is defined to permit the
usage of the results of Type-P-One-way-composition measure in
computation of Type-P-One-way-Combo-mean composition.
</p>
<p>Parameters:
</p>
<p>+ T1,..., Tn, a list of times;
</p>
<p>+ <D,L>, the delay and the lost computed by
composition.
</p>
<p>Definition:
</p>
<p>Using Type-P-One-way-composition we define
Type-P-One-way-composition-stream as the stream of couples
<D,L> over time.
</p>
<p>Results: <T1,D1,L1>...<Tn,Dn,Ln>
</p>
<a name="anchor52"></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.1.7"></a><h3>7.1.7. Statement of Conjecture</h3>
<p>
</p>
<a name="anchor53"></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.1.8"></a><h3>7.1.8. Justification of Composite Relationship</h3>
<p>Combo metric is very easy to measure and to compose.
</p>
<p>It gives the delay and the lost, so most of the need.
</p>
<p>Combo metric may be performed on com metric too.
</p>
<a name="anchor54"></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.1.9"></a><h3>7.1.9. Sources of Error</h3>
<p>Packets may cross different sub path than the equivalent
end-to-end measure because Type-P differ.
</p>
<p>Packets may experiment different behavior than the equivalent
end-to-end measure because of access classification based on packet
addresses.
</p>
<a name="anchor55"></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.1.10"></a><h3>7.1.10. Specific cases where the conjecture might fail</h3>
<p>When
</p>
<p>+ Sum of sub-path differ from the equivalent path.
</p>
<p>+ Type-P differ.
</p>
<p>+ Size differ.
</p>
<a name="anchor56"></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.1.11"></a><h3>7.1.11. Application of Measurement Methodology</h3>
<p>The methodology: Is applicable to Intra and interdomain;
</p>
<p>SHOULD report the context of the measure;
</p>
<a name="anchor57"></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. Security Considerations</h3>
<p>
</p>
<a name="anchor58"></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.1"></a><h3>8.1. Denial of Service Attacks</h3>
<p>This metric requires a stream of packets sent from one host
(source) to another host (destination) through intervening networks.
This method could be abused for denial of service attacks directed at
destination and/or the intervening network(s).
</p>
<p>Administrators of source, destination, and the intervening
network(s) should establish bilateral or multi-lateral agreements
regarding the timing, size, and frequency of collection of sample
metrics. Use of this method in excess of the terms agreed between the
participants may be cause for immediate rejection or discard of
packets or other escalation procedures defined between the affected
parties.
</p>
<a name="anchor59"></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.2"></a><h3>8.2. User Data Confidentiality</h3>
<p>Active use of this method generates packets for a sample, rather
than taking samples based on user data, and does not threaten user
data confidentiality. Passive measurement must restrict attention to
the headers of interest. Since user payloads may be temporarily stored
for length analysis, suitable precautions MUST be taken to keep this
information safe and confidential. In most cases, a hashing function
will produce a value suitable for payload comparisons.
</p>
<a name="anchor60"></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.3"></a><h3>8.3. Interference with the metrics</h3>
<p>It may be possible to identify that a certain packet or stream of
packets is part of a sample. With that knowledge at the destination
and/or the intervening networks, it is possible to change the
processing of the packets (e.g. increasing or decreasing delay) that
may distort the measured performance. It may also be possible to
generate additional packets that appear to be part of the sample
metric. These additional packets are likely to perturb the results of
the sample measurement.
</p>
<p>To discourage the kind of interference mentioned above, packet
interference checks, such as cryptographic hash, may be used.
</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.9"></a><h3>9. IANA Considerations</h3>
<p>Metrics defined in this memo will be registered in the IANA IPPM
METRICS REGISTRY as described in initial version of the registry <a class="info" href="#RFC4148">RFC 4148<span> (</span><span class="info">Stephan, E., “IP Performance Metrics (IPPM) Metrics Registry,” August 2005.</span><span>)</span></a> [RFC4148].
</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.10"></a><h3>10. Security Considerations</h3>
<p>
</p>
<a name="anchor61"></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.11"></a><h3>11. Open Issues</h3>
<p>>>>>>>>>>>>>Open issue:
</p>
<p>What is the relationship between the decomposition and composition
metrics? Should we put both kinds in one draft to make up a framework?
The motivation of decomposition is as follows:
</p>
<p>The One-way measurement can provide result to show what the network
performance between two end hosts is and whether it meets operator
expectations or not. It cannot provide further information to engineers
where and how to improve the performance between the source and the
destination. For instance, if the network performance is not acceptable
in terms of the One-way measurement, in which part of the network the
engineers should put their efforts. This question can to be answered by
decompose the One-way measurement to sub-path measurement to investigate
the performance of different part of the network.
</p>
<p>Editor’s Questions for clarification: What additional
information would be provided to the decomposition process, beyond the
measurement of the complete path?
</p>
<p>Is the decomposition described above intended to estimate a metric
for some/all disjoint sub-paths involved in the complete path?
</p>
<p>>>>>>>>>>>>>>>>>>>>
</p>
<p>>>>>>>>>>>>>>>>>>>>OPEN
Issue
</p>
<p>Section 7 defines a new type of metric, a “combination”
of metrics for one-way delay and packet loss. The purpose of this metric
is to link these two primary metrics in a convenient way.
</p>
<p>Readers are asked to comment on the efficiency of the combination
metric.
</p>
<p>>>>>>>>>>>>>>>>>>>
</p>
<p>>>>>>>>>>>>>>>>>>
OPEN Issue
</p>
<p>How can we introduce multicast metrics here, without causing too much
confusion? Should the multicast version of this draft wait until the
Unicast concepts are stable (or maybe appear in a separate draft)?
</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.12"></a><h3>12. Acknowledgements</h3>
<p>
</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.13"></a><h3>13. 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>13.1. Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="FRMWK">[FRMWK]</a></td>
<td class="author-text">Morton, A. and S.Van Den Berghe, “Framework for Metric Composition,” February 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>
<tr><td class="author-text" valign="top"><a name="RFC2330">[RFC2330]</a></td>
<td class="author-text"><a href="mailto:vern@ee.lbl.gov">Paxson, V.</a>, <a href="mailto:almes@advanced.org">Almes, G.</a>, <a href="mailto:mahdavi@psc.edu">Mahdavi, J.</a>, and <a href="mailto:mathis@psc.edu">M. Mathis</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc2330.txt">Framework for IP Performance Metrics</a>,” RFC 2330, May 1998 (<a href="ftp://ftp.isi.edu/in-notes/rfc2330.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2330.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2330.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2679">[RFC2679]</a></td>
<td class="author-text"><a href="mailto:almes@advanced.org">Almes, G.</a>, <a href="mailto:kalidindi@advanced.org">Kalidindi, S.</a>, and <a href="mailto:matt@advanced.org">M. Zekauskas</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc2679.txt">A One-way Delay Metric for IPPM</a>,” RFC 2679, September 1999.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2680">[RFC2680]</a></td>
<td class="author-text"><a href="mailto:almes@advanced.org">Almes, G.</a>, <a href="mailto:kalidindi@advanced.org">Kalidindi, S.</a>, and <a href="mailto:matt@advanced.org">M. Zekauskas</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc2680.txt">A One-way Packet Loss Metric for IPPM</a>,” RFC 2680, September 1999.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3432">[RFC3432]</a></td>
<td class="author-text">Raisanen, V., Grotefeld, G., and A. Morton, “<a href="ftp://ftp.isi.edu/in-notes/rfc3432.txt">Network performance measurement with periodic streams</a>,” RFC 3432, November 2002.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC4148">[RFC4148]</a></td>
<td class="author-text">Stephan, E., “<a href="ftp://ftp.isi.edu/in-notes/rfc4148.txt">IP Performance Metrics (IPPM) Metrics Registry</a>,” BCP 108, RFC 4148, August 2005.</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>13.2. Informative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="I-D.stephan-ippm-multimetrics">[I-D.stephan-ippm-multimetrics]</a></td>
<td class="author-text">Stephan, E., “<a href="http://www.ietf.org/internet-drafts/draft-stephan-ippm-multimetrics-02.txt">IP Performance Metrics (IPPM) for spatial and multicast</a>,” draft-stephan-ippm-multimetrics-02 (work in progress), October 2005.</td></tr>
<tr><td class="author-text" valign="top"><a name="Y.1540">[Y.1540]</a></td>
<td class="author-text">ITU-T Recommendation Y.1540, “Internet protocol data communication service - IP packet
transfer and availability performance parameters,” December 2002.</td></tr>
</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</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">Emile Stephan</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">France Telecom Division R&D</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">2 avenue Pierre Marzin</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Lannion, F-22307</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">France</td></tr>
<tr><td class="author" align="right">Phone: </td>
<td class="author-text"></td></tr>
<tr><td class="author" align="right">Fax: </td>
<td class="author-text">+33 2 96 05 18 52</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:emile.stephan@francetelecom.com">emile.stephan@francetelecom.com</a></td></tr>
<tr><td class="author" align="right">URI: </td>
<td class="author-text"><a href=""></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-24 10:19:40 |