Network Working Group E. Stephan
Internet Draft France Telecom R&D
Document: draft-stephan-ippm-spatial-metrics-01.txt June, 2003
Category: Informational
Spatial metrics for IPPM
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1] except that the right to
produce derivative works is not granted.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The IETF IP Performance Metrics (IPPM) working group has standardized
metrics for measuring end-to-end performance. This memo defines
spatial metrics both for measuring end-to-end network performance
using aggregation of sequence of network measures and for measuring
the performance of segments of an IP path trajectory. It
distinguishes clearly the decomposition of one end-to-end measure
result in a sequence of per hop results from the aggregation of a
sequence of per hop measure results in an end-to-end result.
Table of Contents
1. Introduction................................................2
2. Terminology.................................................4
2.1. Spatial metric..............................................4
2.2. Asynchronous spatial metrics................................4
2.3. Trajectory..................................................4
3. Motivation..................................................4
3.1. Instantaneous end to end measure decomposition..............4
Stephan Informational - Expires December 2003 [Page 1]
Internet Draft Spatial metrics for IPPM June 2003
4. End-to-end measures aggregation.............................4
5. Metrics for decomposition of end-to-end one way delay.......5
5.1. Spatial one way delay.......................................5
5.2. One way delay Trajectory metric.............................6
5.3. Aggregated One way delay metric.............................6
6. Metrics for aggregation of end-to-end one way delay.........7
6.1. Asynchronous One way delay Trajectory metric................7
6.2. Asynchronous Aggregated One way delay metric................8
7. Spatial metrics for One-way Packet Loss.....................8
7.1. Spatial one way packet loss.................................8
7.2. Samples for Spatial One-way Packet Loss.....................9
7.3. Statistics for Spatial One-way Packet Loss.................10
8. Applicability statements...................................11
9. Security Considerations....................................11
9.1. Privacy....................................................11
10. Change since 00............................................12
11. Acknowledgments............................................12
12. Author Addresses...........................................12
1. Introduction
The metrics specified in this memo are built on notions introduced
and discussed in the IPPM Framework document, RFC 2330 [2]. The
reader should be familiar with these documents.
This memo makes use of definitions of end-to-end One-way Delay
Metrics defined in the RFC 2679 [4] to define metrics for aggregation
and decomposition of end-to-end one-way delays measure.
This memo makes use of definitions of end-to-end One-way Packet loss
Metrics defined in the RFC 2680 [5] to define metrics for aggregation
and decomposition of end-to-end one-way packet loss measure.
The IPPM Framework consists in 4 major components:
+ A general framework for defining performance metrics, described in
the Framework for IP Performance Metrics, RFC 2330;
+ A set of standardized metrics, which conform to this framework:
- The IPPM Metrics for Measuring Connectivity, RFC 2678 [3];
- The One-way Delay Metric for IPPM, RFC 2679 [4];
- The One-way Packet Loss Metric for IPPM, RFC 2680 [5];
- The Round-trip Delay Metric for IPPM, RFC 2681 [6];
- A Framework for Defining Empirical Bulk Transfer Capacity
Metrics RFC 3148 [7];
- One-way Loss Pattern Sample Metrics, RFC 3357, [8];
- IP Packet Delay Variation Metric for IPPM, RFC 3393, [9];
Stephan Informational - Expires December 2003 [Page 2]
Internet Draft Spatial metrics for IPPM June 2003
- Network performance measurement for periodic streams, RFC 3432,
[10].
+ Emerging metrics which are being specified in respect of this
framework;
+ A One-way Active Measurement Protocol;
+ A registry and a Reporting MIB to exchange the results of the
measures.
The structure of the memo is as follows:
+ A 'singleton' analytic metric, called Type-P-spatial-one-way-
delay, will be introduced to measure the one-way delay between 2
consecutive hosts of an IP path.
+ Using this singleton metric, a 'sample', called Type-P-one-way-
delay-trajectory, will be introduced to measure the sequence of Type-
P-spatial-one-way-delay of the successive pair of hosts of the path.
+ Using this sample the end to end metric, called Type-P-
aggregated-one-way-delay, is defined to measure the end to end delay.
+ Using the Type-P-one-way-delay metric, the Type-P-spatial-one-
way-delay metric, the Type-P-aggregated-one-way-delay metric and the
Type-P-asynchronous-aggregated-one-way-delay metric, a 'sample',
called Type-P-asynchronous-one-way-delay-trajectory, will be
introduced to measure the sequence of delays of a sequence of clouds
of an IP path.
+ Using this sample the end to end metric, called Type-P-
asynchronous-aggregated-one-way-delay, is defined to measure the end
to end delay.
+ A 'singleton' analytic metric, called Type-P-spatial-packet-
loss, will be introduced to measure the one-way packet loss between 2
consecutive hosts of an IP path.
+ Using this singleton metric, a 'sample', called Type-P-Spatial-
packet-loss-stream, will be introduced to measure the sequence of
Type-P-Spatial-packet-loss observed between 2 consecutive hosts of an
IP path.
Stephan Informational - Expires December 2003 [Page 3]
Internet Draft Spatial metrics for IPPM June 2003
+ Using this sample, a Type-P-Spatial-packet-loss-average, will be
introduced to measure the average of loss of a Type-P-Spatial-packet-
loss-stream.
2. Terminology
2.1. Spatial metric
A metric is spatial if one of the hosts involved is neither the
sender nor the destination of the measurement packet.
2.2. Asynchronous spatial metrics
A spatial metric is named asynchronous if its definition involves
different measurement packets.
2.3. Trajectory
A trajectory is a sequence of hosts of an IP path. Each hop of the
path may not be present in the sequence.
3. Motivation
3.1. Instantaneous end to end measure decomposition
Decomposition of standard end-to-end measures is needed:
+ For locating delay consumption in a IP path;
+ For locating the loss of packets on an IP path;
+ For trajectory discovery;
+ For troubleshooting the network;
+ For designing and engineering the network;
+ For measuring the performance of a multicast network;
+ For controlling the performance of the inter domain services.
These metrics have to be standardized not only to permit their
results to be collected in the IPPM REPORTING MIB, but to provide
passive measurement techniques with standard metric definitions and
to permit integration of active and passive measurement techniques.
4. End-to-end measures aggregation
The IPPM WG has designed metrics for measuring end-to-end
performance. Today, there does not exit standardized IP measurement
Stephan Informational - Expires December 2003 [Page 4]
Internet Draft Spatial metrics for IPPM June 2003
packets to perform inter domain end-to-end measures. They may only be
performed using aggregation of sequence of intra domain measure
results. To permit interdomain end-to-end measure results
aggregations there is a need to standardize spatial metrics
+ For delay aggregation;
+ For packet loss aggregation;
+ For jitter aggregation.
These metrics have to be standardized to permit their results being
collected in the IPPM REPORTING MIB.
5. Metrics for decomposition of end-to-end one way delay
5.1. Spatial one way delay
5.1.1. Metric Name
Type-P-spatial-one-way-delay
5.1.2. Metric Parameters
+ H0, the address of the sender.
+ Hn, the address of the receiver.
+ I, An integer which ordered the hosts in the path.
+ Hi, exchange points of the path digest.
+ T0, a time.
+ T1,..., Tn a list of time.
+ dT1,..., dTn a list of time.
+ P, the specification of the packet type.
+ a path digest.
5.1.3. Metric Units
The unit is the same as the singleton Type-P-One-way-Delay defined in
[4]. The value of a Type-P-spatial-One-way-Delay is either a real
number, or an undefined (informally, infinite) number of seconds.
5.1.4. Definition
Stephan Informational - Expires December 2003 [Page 5]
Internet Draft Spatial metrics for IPPM June 2003
Given a Type P packet sent by the source H0 at T0 to Hn in the path
, given the sequence of time of arrival of the packets in

, a Type-P-spatial-one-way-delay metric is defined for a hop of
the path as following:
For a real number dTi, the Type-P-spatial-one-way-delay from Hi to
Hi+1 at Ti is dTi means that Hi saw the first bit of a Type-P packet
to Hi+1 at wire-time Ti and that Hi+1 saw the last bit of that packet
at wire-time Ti+dTi.
5.2. One way delay Trajectory metric
5.2.1. Metric Name
Type-P-one-way-delay-trajectory
5.2.2. Metric Parameters
+ H0, the address of the sender.
+ Hn, the address of the receiver.
+ I, An integer which ordered the hosts in the path.
+ Hi, exchange points of the path digest.
+ T0, a time.
+ dT1,..., dTn a list of time.
+ P, the specification of the packet type.
+ a path digest.
5.2.3. Metric Units
A sequence of time.
5.2.4. Definition
Given a Type-P packet sent by the source H0 at T0 to Hn in the path
, given the sequence of time of arrival of the packet in

, a Type-P-one-way-delay-trajectory metric is defined as the
sequence of the Type-P-spatial-one-way-delay values
5.3. Aggregated One way delay metric
Stephan Informational - Expires December 2003 [Page 6]
Internet Draft Spatial metrics for IPPM June 2003
5.3.1. Metric Name
Type-P-aggregated-one-way-delay
5.3.2. Metric Parameters
+ H0, the address of the sender.
+ Hn, the address of the receiver.
+ T0, a time.
+ dT1,..., dTn a list of time.
+ P, the specification of the packet type.
+ a trajectory.
5.3.3. Metric Units
A time.
5.3.4. Definition
Given a Type-P-one-way-delay-trajectory metric value of
the trajectory performed using a single measurement
packet of type P sent at the time T0 by H0, a Type-P-aggregated-one-
way-delay metric is defined as the sum of each term of the Type-P-
one-way-delay-trajectory.
5.3.5. Discussion
Consider a Type-P-aggregated-one-way-delay measure performed
conjointly with a Type-P-one-way-delay measure. As these measures
monitor the behavior of the same test packet their results should be
identical.
Practically these results will differ.
6. Metrics for aggregation of end-to-end one way delay
6.1. Asynchronous One way delay Trajectory metric
6.1.1. Metric Name
Type-P-asynchronous-one-way-delay-trajectory
6.1.2. Metric Parameters
+ H0...Hn, the addresses of the hosts
Stephan Informational - Expires December 2003 [Page 7]
Internet Draft Spatial metrics for IPPM June 2003
+ I, An integer which ordered the hosts in the path.
+ Hi, exchange points of the path digest.
+ P, the specification of the packet type.
6.1.3. Metric Units
A sequence of time.
6.1.4. Definition
Given the hops ,

... , given the Type-P-one-
way-delay Ti from Hi to Hi+1 or the Type-P-spatial-one-way-delay Ti
from Hi to Hi+1 or the Type-P-aggregated-one-way-delay Ti from Hi to
Hi+1 or the Type-P-asynchronous-aggregated-one-way-delay Ti from Hi
to Hi+1, a Type-P-asynchronous-one-way-delay-trajectory metric is
defined as the sequence of the values .
6.2. Asynchronous Aggregated One way delay metric
6.2.1. Metric Name
Type-P-asynchronous-aggregated-one-way-delay
6.2.2. Metric Parameters
+ T1,..., Tn a list of time.
6.2.3. Metric Units
A time.
6.2.4. Definition
Given a Type-P-asynchronous-one-way-delay-trajectory metric
value, a Type-P-asynchronous-aggregated-one-way-delay
metric is defined as the sum of each term of the Type-P-asynchronous-
one-way-delay-trajectory.
7. Spatial metrics for One-way Packet Loss
7.1. Spatial one way packet loss
7.1.1. Metric Name
Type-P-Spatial-packet-loss
Stephan Informational - Expires December 2003 [Page 8]
Internet Draft Spatial metrics for IPPM June 2003
7.1.2. Metric Parameters
+ H0, the address of the sender.
+ Hn, the address of the receiver.
+ i, An integer which ordered the hosts in the path.
+ Hi, exchange points of the path.
+ P, the specification of the packet type.
+ the path digest.
7.1.3. Metric Units
The unit of Type-P-Spatial-packet-loss differs from the unit of Type-
P-One-way-packet-loss defined in RFC 2680 [5].
The value of a Type-P-One-way-packet-loss is either zero (meaning
that all the bits of the packet crossed Hi), or one (signifying the
packet never crossed Hi).
7.1.4. Definition
The Type-P-Spatial-packet-loss metric of a Type-P packet sent by H0
to Hn in the path is defined at the hop i as:
A Type-P-Spatial-packet-loss value of zero at Hi indicates that all
the bits of the packet crossed Hi+1.
The Type-P-spatial-packet-loss value at Hi is one means the packet
did not cross Hi+1.
7.1.5. Discussion
Several issues may appear during the measure:
+ As by essence, the Internet does not guaranty that the path will
not change during the measure, a packet may arrive to destination
while not being metered by each host of the path. That occurs if the
path changes after the configuration of the measure;
+ Duplicated packets may cross 2 or more times the same host;
+ Due to a lack of resources in a host, the packet may not be
metered.
7.2. Samples for Spatial One-way Packet Loss
Stephan Informational - Expires December 2003 [Page 9]
Internet Draft Spatial metrics for IPPM June 2003
The definition does not make any assumption on the way the times of
the measure were generated for the following reasons:
+ Using active measurement test packets are either sent using a
pseudo-random Poisson time generator, either sent periodically,
either sent in bursts.
+ Passive measurement captures packets sent by applications at
arbitrary instants.
7.2.1. Metric Name
Type-P-Spatial-packet-loss-stream
7.2.2. Metric Parameters
+ P, the specification of the packet type.
+ the path digest.
+ i, An integer which ordered the hosts in the path.
+ Hi, An host of the path.
+ Hi,Hi+1, Addresses of 2 consecutives hosts of the path.
+ T0, a time
+ Tf, a time
+ a list of time
+ T, an observation duration
7.2.3. Metric Units
A sequence of couples where T is a time and L a Boolean.
7.2.4. Definition
Given 2 consecutives hosts Hi and Hi+1, given a Type-P-Spatial-
packet-loss performed from Hi to Hi+1 at instants during
the duration T, we obtain a sequence of pairs of time, singleton of
Type-P-Spatial-packet-loss. Type-P-Spatial-packet-loss-stream is
defined as the resulting pairs.
7.3. Statistics for Spatial One-way Packet Loss
7.3.1. Type-P-Spatial-packet-loss-Average
Stephan Informational - Expires December 2003 [Page 10]
Internet Draft Spatial metrics for IPPM June 2003
Given the sample metric Type-P-Sample-packet-loss-Poisson-Stream, a
Type-P-Spatial-packet-loss-Average is defined as the average of all
the L values in the stream.
8. Applicability statements
Spatial metric may be performed using either using active
measurements techniques, either using passive measurements techniques
or a combination of both.
9. Security Considerations
Since this draft proposes sample metrics based on the One-way Delay
singleton metric defined in RFC2679 and RFC2680 it inherits the
security considerations mentioned in this RFC.
9.1. Privacy
The privacy concerns in network measurement are intrinsically limited
by the active measurements. Unlike passive measurements, there can be
no release of existing user data.
Measurement aspects
Conducting Internet measurements raises both security and privacy
concerns. This memo does not specify an implementation of the
metrics, so it directly affects neither the security of the Internet
nor the security of the applications running on the Internet.
However, implementations of these metrics must be mindful of security
and privacy concerns.
There are two types of security concerns: potential dysfunction
caused by the measurements, and potential alteration of the
measurements. The measurements could cause dysfunction because they
are active, and inject packets into the network. The measurement
parameters MUST be carefully selected so that the measurements inject
trivial amounts of additional traffic into the networks they measure.
If they inject "too much" traffic, they can skew the results of the
measurement, and in extreme cases cause congestion and denial of
service.
The measurements themselves could be altered by routers giving
measurement traffic a different priority than "normal" traffic, or by
an attacker injecting artificial measurement traffic. If routers can
recognize measurement traffic and treat it separately, the
measurements will not reflect actual user traffic. If an attacker
injects artificial traffic that is accepted as legitimate, the loss
rate will be artificially lowered. Therefore, the measurement
Stephan Informational - Expires December 2003 [Page 11]
Internet Draft Spatial metrics for IPPM June 2003
methodologies SHOULD include appropriate techniques to reduce the
probability measurement traffic can be distinguished from "normal"
traffic.
Authentication techniques, such as digital signatures, may be used
where appropriate to guard against injected traffic attacks.
10. Change since 00
Spatial packet loss metrics definitions added.
11. Acknowledgments
12. Author Addresses
Emile STEPHAN
France Telecom R & D
2 avenue Pierre Marzin
F-22307 Lannion cedex
Phone: (+ 33) 2 96 05 11 11
Email: emile.stephan@francetelecom.com
Full Copyright Statement
"Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Stephan Informational - Expires December 2003 [Page 12]
Internet Draft Spatial metrics for IPPM June 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2]Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for
IP Performance Metrics", RFC 2330, May 1998.
[3] Mahdavi J. and V. Paxson, "IPPM Metrics for Measuring
Connectivity", RFC 2678, September 1999.
[4] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Delay
Metric for IPPM", RFC 2679, September 1999.
[5] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Packet
Loss Metric for IPPM", RFC 2680, September 1999.
[6] Almes, G., Kalidindi, S. and M. Zekauskas, "A Round-trip Delay
Metric for IPPM.", RFC 2681, September 1999.
[7] Mathis, G. and M. Allman, "A Framework for Defining Empirical
Bulk Transfer Capacity Metrics.", RFC3148, July 2001.
[8] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample
Metrics", RFC 3357, August 2002.
[9] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric
for IPPM", RFC 3393, November 2002.
[
[10]Raisanen,]] V., Grotefeld, G. and A. Morton, "Network performance
measurement for periodic streams", RFC 3432, November 2002
Stephan Informational - Expires December 2003 [Page 13]