draft-ietf-ippm-multimetrics-07.txt   draft-ietf-ippm-multimetrics-08.txt 
Network Working Group E. Stephan Network Working Group E. Stephan
Internet-Draft France Telecom Internet-Draft France Telecom
Intended status: Standards Track L. Liang Intended status: Standards Track L. Liang
Expires: December 28, 2008 University of Surrey Expires: April 3, 2009 University of Surrey
A. Morton A. Morton
AT&T Labs AT&T Labs
June 26, 2008 September 30, 2008
IP Performance Metrics (IPPM) for spatial and multicast IP Performance Metrics (IPPM) for spatial and multicast
draft-ietf-ippm-multimetrics-07 draft-ietf-ippm-multimetrics-08
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 28, 2008. This Internet-Draft will expire on April 3, 2009.
Abstract Abstract
The IETF IP Performance Metrics (IPPM) working group has standardized The IETF has standardized IP Performance Metrics (IPPM) for measuring
metrics for measuring end-to-end performance between two points. end-to-end performance between two points. This memo defines two new
This memo defines two new categories of metrics that extend the categories of metrics that extend the coverage to multiple
coverage to multiple measurement points. It defines spatial metrics measurement points. It defines spatial metrics for measuring the
for measuring the performance of segments of a source to destination performance of segments of a source to destination path, and metrics
path, and metrics for measuring the performance between a source and for measuring the performance between a source and many destinations
many destinations in multiparty communications (e.g., a multicast in multiparty communications (e.g., a multicast tree).
tree).
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Path Digest Hosts . . . . . . . . . . . . . . . . . . . . 6 3. Brief Metric Descriptions . . . . . . . . . . . . . . . . . . 7
2.2. Multiparty metric . . . . . . . . . . . . . . . . . . . . 6 4. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Spatial metric . . . . . . . . . . . . . . . . . . . . . . 7 5. Spatial vector metrics definitions . . . . . . . . . . . . . . 11
2.4. One-to-group metric . . . . . . . . . . . . . . . . . . . 7 6. Spatial Segment Metrics Definitions . . . . . . . . . . . . . 18
2.5. Points of interest . . . . . . . . . . . . . . . . . . . . 7 7. One-to-group metrics definitions . . . . . . . . . . . . . . . 23
2.6. Reference point . . . . . . . . . . . . . . . . . . . . . 8 8. One-to-group Sample Statistics . . . . . . . . . . . . . . . . 26
2.7. Vector . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Measurement Methods: Scalability and Reporting . . . . . . . . 36
2.8. Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. Manageability Considerations . . . . . . . . . . . . . . . . . 39
3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. Security Considerations . . . . . . . . . . . . . . . . . . . 44
3.1. Motivations for spatial metrics . . . . . . . . . . . . . 9 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
3.2. Motivations for One-to-group metrics . . . . . . . . . . . 10 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
3.3. Discussion on Group-to-one and Group-to-group metrics . . 11 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4. Spatial vectors metrics definitions . . . . . . . . . . . . . 11 14.1. Normative References . . . . . . . . . . . . . . . . . . 49
4.1. A Definition for Spatial One-way Delay Vector . . . . . . 12 14.2. Informative References . . . . . . . . . . . . . . . . . 50
4.2. A Definition for Spatial One-way Packet Loss Vector . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3. A Definition for Spatial One-way Ipdv Vector . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 51
4.4. Spatial Methodology . . . . . . . . . . . . . . . . . . . 16
5. Spatial Segments metrics definitions . . . . . . . . . . . . . 17
5.1. A Definition of a sample of One-way Delay of a segment
of the path . . . . . . . . . . . . . . . . . . . . . . . 18
5.2. A Definition of a sample of Packet Loss of a segment
of the path . . . . . . . . . . . . . . . . . . . . . . . 19
5.3. A Definition of a sample of ipdv of a segment using
the previous packet selection function . . . . . . . . . . 20
5.4. A Definition of a sample of ipdv of a segment using
the minimum delay selection function . . . . . . . . . . . 22
6. One-to-group metrics definitions . . . . . . . . . . . . . . . 23
6.1. A Definition for One-to-group One-way Delay . . . . . . . 23
6.2. A Definition for One-to-group One-way Packet Loss . . . . 24
6.3. A Definition for One-to-group One-way Ipdv . . . . . . . . 25
7. One-to-Group Sample Statistics . . . . . . . . . . . . . . . . 26
7.1. Discussion on the Impact of packet loss on statistics . . 28
7.2. General Metric Parameters . . . . . . . . . . . . . . . . 29
7.3. One-to-Group one-way Delay Statistics . . . . . . . . . . 30
7.4. One-to-Group one-way Loss Statistics . . . . . . . . . . . 32
7.5. One-to-Group one-way Delay Variation Statistics . . . . . 34
8. Measurement Methods: Scalability and Reporting . . . . . . . . 35
8.1. Computation methods . . . . . . . . . . . . . . . . . . . 36
8.2. Measurement . . . . . . . . . . . . . . . . . . . . . . . 37
8.3. Effect of Time and Space Aggregation Order on Stats . . . 37
9. Manageability Considerations . . . . . . . . . . . . . . . . . 38
9.1. Reporting spatial metric . . . . . . . . . . . . . . . . . 39
9.2. Reporting One-to-group metric . . . . . . . . . . . . . . 40
9.3. Metric identification . . . . . . . . . . . . . . . . . . 40
9.4. Information model . . . . . . . . . . . . . . . . . . . . 41
10. Security Considerations . . . . . . . . . . . . . . . . . . . 43
10.1. Spatial metrics . . . . . . . . . . . . . . . . . . . . . 43
10.2. one-to-group metric . . . . . . . . . . . . . . . . . . . 43
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
13.1. Normative References . . . . . . . . . . . . . . . . . . . 48
13.2. Informative References . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
Intellectual Property and Copyright Statements . . . . . . . . . . 50
1. Introduction 1. Introduction and Scope
The IETF IP Performance Metrics (IPPM) working group has standardized IETF has standardized IP Performance Metrics (IPPM) for measuring
metrics for measuring end-to-end performance between two points. end-to-end performance between two points. This memo defines two new
This memo defines two new categories of metrics that extend the categories of metrics that extend the coverage to multiple
coverage to multiple measurement points. It defines spatial metrics measurement points. It defines spatial metrics for measuring the
for measuring the performance of segments of a source to destination performance of segments of a source to destination path, and metrics
path, and metrics for measuring the performance between a source and for measuring the performance between a source and many destinations
many destinations in multiparty communications (e.g., a multicast in multiparty communications (e.g., a multicast tree).
tree).
The purpose of the memo is to define metrics to fulfill the new The purpose of the memo is to define metrics to fulfill the new
requirements of measurement involving multiple measurement points. requirements of measurement involving multiple measurement points.
Spatial metrics are defined to measure the performance of each Spatial metrics measure the performance of each segment along a path.
segments along a path while the one-to-group metrics are aiming to One-to-group metrics measure the performance for a group of users.
provide a ruler to measure the performance of a group of users. These metrics are derived from one-way end-to-end metrics, all of
These metrics are derived from one-way end-to-end metrics defined by which follow the IPPM framework [RFC2330].
IETF and follow the criteria described in the IPPM framework
[RFC2330].
New terms are introduced to extend the terminology of the IPPM This memo is organized as follows: Section 2 introduces new terms
framework to spatial metrics and one-to-group metrics. Then a that extend the original IPPM framework [RFC2330]. Section 3
section motivates the need of defining each category of metrics. motivates each metric category and briefly introduces the new
After, each category is defined in a separate section. Then the memo metrics. Sections 4 through 7 develop each category of metrics with
discusses the impact of the measurement methods on the scalability definitions and statistics. Then the memo discusses the impact of
and proposes an information model for reporting the measurements. the measurement methods on the scaleability and proposes an
Finally the document discusses security aspects related to information model for reporting the measurements. Finally, the memo
measurement and registers the metrics in the IANA IP Performance discusses security aspects related to measurement and registers the
Metrics Registry [RFC4148]. metrics in the IANA IP Performance Metrics Registry [RFC4148].
Note that all these metrics are based on observations of packets The scope of this memo is limited to metrics using a single source
dedicated to testing, a process which is called Active measurement. packet or stream, and observations of corresponding packets along the
Purely passive spatial measurement (for example, a spatial metric path (spatial), at one or more destinations (one-to-group), or both.
Note that all the metrics defined herein are based on observations of
packets dedicated to testing, a process which is called active
measurement. Passive measurement (for example, a spatial metric
based on the observation of user traffic) is beyond the scope of this based on the observation of user traffic) is beyond the scope of this
memo. memo.
Following is a summary of the metrics defined. 2. Terminology
This memo firstly defines metrics for spatial measurement based on 2.1. Naming of the metrics
the decomposition of standard end-to-end metrics defined by IETF in
[[RFC2679], [RFC2680], [RFC3393], [RFC3432]. Seven metrics are
defined including their names, parameters, units and measurement
methodologies. Each definion includes a specific section discussing
measurements constraints and issues, and proposing guidance to
increase results accucacy. These spatial metrics are:
o A 'Vector', called Type-P-Spatial-One-way-Delay-Vector, will be
introduced to divide an end-to-end Type-P-One-way-Delay [RFC2679]
into a spatial sequence of one-way delay metrics.
o A 'Vector', called Type-P-Spatial-One-way-Packet-Loss-Vector, will The names of the metrics, including capitalization letters, are as
be introduced to divide an end-to-end Type-P-One-way-Packet-Loss close as possible of the names of the one-way end-to-end metrics they
[RFC2680] in a spatial sequence of packet loss metrics. are derived from.
o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'vector',
called Type-P-Spatial-One-way-ipdv-Vector, will be introduced to
divide an end-to-end Type-P-One-way-ipdv in a spatial sequence of
ipdv metrics.
o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'sample',
called Type-P-Segment-One-way-Delay-Stream, will be introduced to
collect one-way delay metrics over time between two points of
interest of the path;
o Using the Type-P-Spatial-Packet-Loss-Vector metric, a 'sample',
called Type-P-Segment-Packet-Loss-Stream, will be introduced to
collect packet loss metrics over time between two points of
interest of the path;
o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'sample',
called Type-P-Segment-ipdv-prev-Stream, will be introduced to
compute ipdv metrics over time between two points of interest of
the path using the previous packet selection function;
o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'sample',
called Type-P-Segment-ipdv-min-Stream, will be introduced to
compute ipdv metrics over time between two points of interest of
the path using the shortest delay selection function;
Then the memo defines one-to-group metrics and one-to-group 2.2. Terms Defined Elsewhere
statistics.
Three one-to-group metrics are defined to measure the one-way host: section 5 of RFC 2330
performance between a source and a group of receivers. Definitions
derive from one-way metrics definitions of RFCs in [RFC2679],
[RFC2680], [RFC3393], [RFC3432]:
o A 'Vector', called Type-P-One-to-Group-One-way-Delay-Vector, will
be introduced to collect the set of Type-P-one-way-delay
singletons between one sender and N receivers;
o A 'Vector', called Type-P-One-to-Group-One-way-Packet-Loss-Vector,
will be introduced to collect the set of Type-P-One-way-Packet-
Loss singletons between one sender and N receivers;
o A 'Vector', called Type-P-One-to-Group-One-way-ipdv-Vector, will
be introduced to collect the set of Type-P-One-way-ipdv singletons
between one sender and N receivers.
Then, based on the One-to-group vector metrics listed above, loss threshold: section 2.8.2 of RFC 2680
statistics are defined to capture single receiver performance, group
performance and relative performance situation inside a multiparty
communication for each packet sent during the test interval between
one sender and N receivers:
o Using the Type-P-One-to-Group-One-way-Delay-Vector, a metric path: section 5 of RFC 2330
called Type-P-One-to-Group-Receiver-n-Mean-Delay will be
introduced to present the mean of delays between one sender and a
receiver 'n'. Then, based on this definition, 3 metrics will be
defined to characterize the mean delay over the entire group
during this interval:
* a metric called Type-P-One-to-Group-Mean-Delay, will be
introduced to present the mean of delays;
* a metric called Type-P-One-to-Group-Range-Mean-Delay will be
introduced to present the range of mean delays;
* a metric called Type-P-One-to-Group-Max-Mean-Delay will be
introduced to present the maximum of mean delays;
o Using the Type-P-one-to-group-One-way-Packet-Loss-Vector, a metric
called Type-P-One-to-Group-Receiver-n-Loss-Ratio will be
introduced to capture packet loss ratio between one sender and a
receiver 'n'. Then based on this definition, 2 metrics will be
defined to characterize packet loss over the entire group during
this interval:
* a metric called Type-P-One-to-Group-Loss-Ratio will be
introduced to capture packet loss ratio overall over the entire
group or all receivers;
* a metric called Type-P-One-to-Group-Range-Loss-Ratio will be
introduced to present comparative packet loss ratio for each
packet during the test interval between one sender and N
Receivers.
o Using Type-P-one-to-group-One-way-ipdv-Vector, a metric called
Type-P-One-to-Group-Range-Delay-Variation will be introduced to
present the range of delay variation between one sender and a
group of receivers.
2. Terminology path digest: section 5 of RFC 2330
2.1. Path Digest Hosts sample: section 11 of RFC 2330
The list of the hosts on a path from the source to the destination. singleton: section 11 of RFC 2330
2.2. Multiparty metric 2.3. Path Digest Hosts
The list of the hosts on a path from the source to the destination,
also referred to as the host path digest.
2.4. Multiparty metric
A metric is said to be multiparty if the topology involves more than A metric is said to be multiparty if the topology involves more than
one measurement collection point. All multiparty metrics define a one measurement collection point. All multiparty metrics designate a
set of hosts called "points of interest", where one host is the set of hosts as "points of interest", where one host is the source
source and other hosts are the measurement collection points. For and other hosts are the measurement collection points. For example,
example, if the set of points of interest is < ha, hb, hc, ..., hn >, if the set of points of interest is < ha, hb, hc, ..., hn >, where ha
where ha is the source and < hb, hc, ..., hn > are the destinations, is the source and < hb, hc, ..., hn > are the destinations, then
then measurements may be conducted between < ha, hb>, < ha, hc>, ..., measurements may be conducted between < ha, hb>, < ha, hc>, ..., <ha,
<ha, hn >. hn >.
For the purposes of this memo (reflecting the scope of a single For the purposes of this memo (reflecting the scope of a single
source), the only multiparty metrics are one-to-group metrics. source), the only multiparty metrics are one-to-group metrics.
2.3. Spatial metric 2.5. Spatial metric
A metric is said to be spatial if one of the hosts (measurement A metric is said to be spatial if one of the hosts (measurement
collection points) involved is neither the source nor a destination collection points) involved is neither the source nor a destination
of the measured packet. of the measured packet(s). Such measurement hosts will usually be
members of the path digest.
2.4. One-to-group metric 2.6. One-to-group metric
A metric is said to be one-to-group if the measured packet is sent by A metric is said to be one-to-group if the measured packet is sent by
one source and (potentially) received by several destinations. Thus, one source and (potentially) received by more than one destination.
the topology of the communication group can be viewed as a centre- Thus, the topology of the communication group can be viewed as a
distributed or server-client topology with the source as the centre/ center-distributed or server-client topology with the source as the
server in the topology. center/server in the topology.
2.5. Points of interest 2.7. Points of interest
Points of interest are the hosts* (as per RFC2330 definition, that Points of interest are the hosts (as per the RFC 2330 definition,
includes routing nodes) that are measurement collection points, a "hosts" include routing nodes) that are measurement collection
sub-set of the set of hosts involved in the delivery of the packets points, a sub-set of the set of hosts involved in the delivery of the
(in addition to the source itself). Note that the points of interest packets (in addition to the source itself).
are a possibly arbitrary sub-set of all the hosts involved in the
path. For spatial metrics, points of interest are a (possibly arbitrary)
sub-set of all the hosts involved in the path.
Points of interest of one-to-group metrics are the intended Points of interest of one-to-group metrics are the intended
destination hosts for packets from the source (in addition to the destination hosts for packets from the source (in addition to the
source itself). source itself).
Src Recv Src Dst
`. ,-. `. ,-.
`. ,' `...... 1 `. ,' `...... 1
`. ; : `. ; :
`. ; : `. ; :
; :... 2 ; :... 2
| | | |
: ; : ;
: ;.... 3 : ;.... 3
: ; : ;
`. ,' `. ,'
`-'....... N `-'....... N
Figure 1: One-to-group points of interest Figure 1: One-to-group points of interest
A candidate point of interest for spatial metrics is a host from the A candidate point of interest for spatial metrics is a host from the
set of hosts involved in the delivery of the packets from the source. set of hosts involved in the delivery of the packets from source to
destination.
Src ------. Hosts Src ------. Hosts
\ \
`---X ... 1 `---X ... 1
\ \
x x
/ /
.---------X .... 2 .---------X .... 2
/ /
x x
skipping to change at page 8, line 29 skipping to change at page 6, line 29
X .... N X .... N
\ \
\ \
\ \
`---- Dst `---- Dst
Note: 'x' are nodes which are not points of interest Note: 'x' are nodes which are not points of interest
Figure 2: Spatial points of interest Figure 2: Spatial points of interest
2.6. Reference point 2.8. Reference point
A reference point is defined as the server where the statistical A reference point is defined as the server where the statistical
calculations will be carried out. A centre/server in the calculations will be carried out. It is usually a centralized server
multimetrics measurement that is controlled by a network operator is in the measurement architecture that is controlled by a network
a good example of a reference point, where measurement data can be operator, where measurement data can be collected for further
collected for further processing. However, the actual measurements processing. The reference point is distinctly different from hosts
have to be carried out at all points of interest. at measurement collection points, where the actual measurements are
carried out (e.g., points of interest).
2.7. Vector 2.9. Vector
A Vector is a set of singletons, which are a set of results of the A vector is a set of singletons (single atomic results) comprised of
observation of the behaviour of the same packet at different places observations corresponding to a single source packet at different
of a network at different times. For instance, if one-way delay hosts in a network. For instance, if the one-way delay singletons
singletons observed at N receivers for Packet P sent by the source observed at N receivers for Packet P sent by the source Src are dT1,
Src are dT1, dT2,..., dTN, it can be say that a vector V with N dT2,..., dTN, then a vector V with N elements can be organized as
elements can be organized as {dT1, dT2,..., dTN}. The elements in {dT1, dT2,..., dTN}. The element dT1 is distinct from all others as
one vector are singletons distinct with each other in terms of both the singleton at receiver 1 in response to a packet sent from the
measurement point and sending time. Given the vector V as an source at a specific time. The complete vector gives information
example, the element dT1 is distinct from all others as the singleton over the dimension of space; a set of N receivers in this example.
at receiver 1 in response to a packet sent from the source at time
T1. The complete Vector gives information over the dimension of
space.
2.8. Matrix The singleton elements of any vector are distinctly different from
each other in terms of their measurement collection point. Different
vectors for common measurement points of interest are distinguished
by the source packet sending time.
Several vectors form a Matrix, which contains results observed in a 2.10. Matrix
Several vectors form a matrix, which contains results observed over a
sampling interval at different places in a network at different sampling interval at different places in a network at different
times. For instance, given One-way delay vectors V1={dT11, dT12,..., times. For example, the One-way delay vectors V1={dT11, dT12,...,
dT1N}, V2={dT21, dT22,..., dT2N},..., Vm={dTm1, dTm2,..., dTmN} for dT1N}, V2={dT21, dT22,..., dT2N},..., Vm={dTm1, dTm2,..., dTmN} for
Packet P1, P2,...,Pm, we can have a One-way delay Matrix {V1, Packet P1, P2,...,Pm, form a One-way delay Matrix {V1, V2,...,Vm}.
V2,...,Vm}. Additional to the information given by a Vector, a The matrix organizes the vector information to present network
Matrix is more powerful to present network performance in both space performance in both space and time.
and time dimensions. It normally corresponds to a sample in simple
A one-dimensional matrix (row) corresponds to a sample in simple
point-to-point measurement. point-to-point measurement.
The relation among Singleton, Vector and Matrix can be shown in the The relationship among singleton, sample, vector and matrix is
following Figure 3. illustrated in the following Figure 3.
Point of Singleton points of singleton
interest / Samples interest / samples(time)
,----. ^ / ,----. ^ /
/ R1.....| / R1dT1 R1dT2 R1dT3 ... R3dTk \ / R1.....| / R1dT1 R1dT2 R1dT3 ... R3dTk \
/ \ | | | / \ | | |
; R2........| | R2dT1 R2dT2 R2dT3 ... R3dTk | ; R2........| | R2dT1 R2dT2 R2dT3 ... R3dTk |
Src | || | | Src | || | |
| R3....| | R3dT1 R3dT2 R3dT3 ... R3dTk | | R3....| | R3dT1 R3dT2 R3dT3 ... R3dTk |
| || | | | || | |
: ;| | | : ;| | |
\ / | | | \ / | | |
\ Rn......| \ RndT1 RndT2 RndT3 ... RndTk / \ Rn......| \ RndT1 RndT2 RndT3 ... RndTk /
`-----' +-------------------------------------> time `-----' +-------------------------------------> time
Vector Matrix vector matrix
(space) (time) (space) (time and space)
Figure 3: Relation beween Singletons, vectors and matrix Figure 3: Relationship between singletons, samples, vectors and
matrix
3. Motivations 3. Brief Metric Descriptions
All IPPM metrics are defined for end-to-end (source to destination) The metrics for spatial and one-to-group measurement are based on the
measurement of point-to-point paths. It is a logical extension to source-to-destination, or end-to-end metrics defined by IETF in
define metrics for multiparty measurements such as one to one [[RFC2679], [RFC2680], [RFC3393], [RFC3432].
trajectory metrics and one to multipoint metrics.
3.1. Motivations for spatial metrics This memo defines seven new spatial metrics using the [RFC2330]
framework of parameters, units of measure, and measurement
methodologies. Each definition includes a section that describes
measurements constraints and issues, and provides guidance to
increase the accuracy of the results.
Decomposition of instantaneous end-to-end measures is needed: The spatial metrics are:
o Decomposing the performance of interdomain path is desirable to o Type-P-Spatial-One-way-Delay-Vector divides the end-to-end Type-P-
quantify the per-AS contribution to the performance. It is One-way-Delay [RFC2679] into a spatial vector of one-way delay
valuable to define standard spatial metrics before pursuing inter- singletons.
domain path performance specifications. o Type-P-Spatial-One-way-Packet-Loss-Vector divides an end-to-end
o Traffic engineering and troubleshooting applications benefit from Type-P-One-way-Packet-Loss [RFC2680] into a spatial vector of
spatial views of one-way delay and ipdv consumption, and packet loss singletons.
identification of the location of the lost of packets. o Type-P-Spatial-One-way-ipdv-Vector divides an end-to-end Type-P-
o Monitoring the performance of a multicast tree composed of MPLS One-way-ipdv into a spatial vector of ipdv singletons.
point-to-multipoint and inter-domain communication require spatial o Using elements of the Type-P-Spatial-One-way-Delay-Vector metric,
decomposition of the one-way delay, ipdv, and packet loss. a sample called Type-P-Segment-One-way-Delay-Stream collects one-
o Composition of metrics is needed to help measurement systems reach way delay metrics between two points of interest on the path over
large scale coverage. Spatial measures typically give the time.
individual performance of an intra domain segment and provide an o Likewise, using elements of the Type-P-Spatial-Packet-Loss-Vector
elementary piece of information needed to estimate interdomain metric, a sample called Type-P-Segment-Packet-Loss-Stream collects
performance based on composition of metrics. one-way delay metrics between two points of interest on the path
over time.
o Using the Type-P-Spatial-One-way-Delay-Vector metric, a sample
called Type-P-Segment-ipdv-prev-Stream, will be introduced to
compute ipdv metrics (using the previous packet selection
function) between two points of interest on the path over time.
o Again using the Type-P-Spatial-One-way-Delay-Vector metric, a
sample called Type-P-Segment-ipdv-min-Stream will define another
set of ipdv metrics (using the minimum delay packet selection
function) between two points of interest on the path over time.
3.2. Motivations for One-to-group metrics The memo also defines three one-to-group metrics to measure the one-
way performance between a source and a group of receivers. They are:
o Type-P-One-to-group-Delay-Vector collects the set of Type-P-one-
way-delay singletons between one sender and N receivers.
o Type-P-One-to-group-Packet-Loss-Vector collects the set of Type-P-
One-way-Packet-Loss singletons between one sender and N receivers.
o Type-P-One-to-group-ipdv-Vector collects the set of Type-P-One-
way-ipdv singletons between one sender and N receivers.
Finally, based on the one-to-group vector metrics listed above,
statistics are defined to capture single receiver performance, group
performance and the relative performance for a multiparty
communication:
o Using the Type-P-One-to-group-Delay-Vector, a metric called Type-
P-One-to-group-Receiver-n-Mean-Delay or RnMD, presents the mean of
delays between one sender and a single receiver 'n'. From this
metric, 3 additional metrics are defined to characterize the mean
delay over the entire group of receivers during the same time
interval:
* Type-P-One-to-group-Mean-Delay or GMD, presents the mean of
delays;
* Type-P-One-to-group-Range-Mean-Delay or GRMD, presents the
range of mean delays;
* Type-P-One-to-group-Max-Mean-Delay or GMMD, presents the
maximum of mean delays.
o Using the Type-P-One-to-group-Packet-Loss-Vector, a metric called
Type-P-One-to-group-Receiver-n-Loss-Ratio or RnLR, captures the
packet loss ratio between one sender and a single receiver 'n'.
Based on this definition, 2 more metrics are defined to
characterize packet loss over the entire group during the same
time interval:
* Type-P-One-to-group-Loss-Ratio or GLR, captures the overall
packet loss ratio for the entire group of receivers;
* Type-P-One-to-group-Range-Loss-Ratio, or GRLR, presents the
comparative packet loss ratio during the test interval between
one sender and N receivers.
o Using the Type-P-One-to-group-Packet-Loss-Vector, a metric called
Type-P-One-to-group-Receiver-n-Comp-Loss-Ratio, or RnCLR, computes
a packet loss ratio using the maximum number of packets received
at any receiver.
o Using Type-P-One-to-group-ipdv-Vector, a metric called Type-P-One-
to-group-Range-Delay-Variation, or GRDV, presents the range of
delay variation between one sender and a group of receivers.
4. Motivations
All existing IPPM metrics are defined for end-to-end (source to
destination) measurement of point-to-point paths. It is logical to
extend them to multiparty situations such as one to one trajectory
metrics and one to multipoint metrics.
4.1. Motivations for spatial metrics
Spatial metrics are needed for:
o Decomposing the performance of an inter-domain path to quantify
the per-AS contribution to the end-to-end performance.
o Traffic engineering and troubleshooting, which benefit from
spatial views of one-way delay and ipdv consumption, or
identification of the path segment where packets were lost.
o Monitoring the decomposed performance of a multicast tree based on
of MPLS point-to-multipoint communications.
o Dividing end-to-end metrics, so that some segment measurements can
be re-used and help measurement systems reach large-scale
coverage. Spatial measures could characterize the performance of
an intra-domain segment and provide an elementary piece of
information needed to estimate inter-domain performance to another
destination using Spatial Composition metrics
[I-D.ietf-ippm-spatial-composition].
4.2. Motivations for One-to-group metrics
While the node-to-node based spatial measures can provide very useful While the node-to-node based spatial measures can provide very useful
data in the view of each connection, we also need measures to present data in the view of each connection, we also need measures to present
the performance of a multiparty communication topology. A simple the performance of a multiparty communication topology. A simple
one-way metric cannot completely describe the multiparty situation. point-to-point metric cannot completely describe the multiparty
New one-to-group metrics assess performance of all the paths for situation. New one-to-group metrics assess performance of the
further statistical analysis. The new metrics proposed in this stage multiple paths for further statistical analysis. The new metrics are
are named one-to-group performance metrics, and they are based on the named one-to-group performance metrics, and they are based on the
unicast metrics defined in IPPM WG. One-to-group metrics are one-way unicast metrics defined in IPPM RFCs. One-to-group metrics are one-
metrics from one source to a group of destinations. The metrics are way metrics from one source to a group of destinations, or receivers.
helpful for judging the network performance of multiparty The metrics are helpful for judging the overall performance of a
communications and can also be used to describe the variation of multiparty communications network, and for describing the performance
performance delivered to a group of destination hosts and their variation across a group of destinations.
users.
One-to-group performance metrics are needed for several reasons: One-to-group performance metrics are needed for:
o For designing and engineering multicast trees and MPLS point-to- o Designing and engineering multicast trees and MPLS point-to-
multipoint LSP; multipoint LSPs.
o For evaluating and controlling of the quality of the multicast o Evaluating and controlling the quality of multicast services,
services; including inter-domain multicast.
o For controlling the performance of the inter domain multicast o Presenting and evaluating the performance requirements for
services;
o For presenting and evaluating the performance requirements for
multiparty communications and overlay multicast. multiparty communications and overlay multicast.
To understand the packet transfer performance between one source and To understand the packet transfer performance between one source and
any one receiver in the multiparty communication group, we need to any one receiver in the multiparty communication group, we need to
collect instantaneous end-to-end metrics, or singletons. It will collect instantaneous end-to-end metrics, or singletons. This gives
give a very detailed insight into each branch of the multicast tree a very detailed view into the performance of each branch of the
in terms of end-to-end absolute performance. This detail can provide multicast tree, and can provide clear and helpful information for
clear and helpful information for engineers to identify the sub-path engineers to identify the branch with problems in a complex
with problems in a complex multiparty routing tree. multiparty routing tree.
The one-to-group metrics described in this memo introduce the The one-to-group metrics described in this memo introduce the
multiparty topology to the IPPM working group; the goal is to measure multiparty topology into the IPPM framework, and describe the
the performance delivered to a group of users who are receiving performance delivered to a group receiving packets from the same
packets from the same source. The concept extends the "path" in the source. The concept extends the "path" of the point-to-point
one-way measurement to "path tree" to cover both one-to-one and one- measurement to "path tree" to cover one-to-many topologies. If
to-many communications. If applied to one-to-one communications, the applied to one-to-one topology, the one-to-group metrics provide
one-to-group metrics provide exactly the same results as the exactly the same results as the corresponding one-to-one metrics.
corresponding one-to-one metrics.
3.3. Discussion on Group-to-one and Group-to-group metrics 4.3. Discussion on Group-to-one and Group-to-group metrics
We note that points of interest can also be selected to define We note that points of interest can also be selected to define
measurements on group-to-one and group-to-group topologies. These measurements on group-to-one and group-to-group topologies. These
topologies are currently beyond the scope of this memo, because they topologies are beyond the scope of this memo, because they would
would involve multiple packets launched from different sources. involve multiple packets launched from different sources. However,
However, we can give some clues here on these two cases. this section gives some insights on these two cases.
The measurements for group-to-one topology can be easily derived from The measurements for group-to-one topology can be easily derived from
the one-to-group measurement. The measurement point is the reference the one-to-group measurement. The measurement point is the host that
point that is acting as a receiver while all of clients/receivers is acting as a receiver while all other hosts act as sources in this
defined for one-to-group measurement act as sources in this case. case.
For the group-to-group connection topology, it is difficult to define The group-to-group communication topology has no obvious focal point:
the reference point and therefore it is difficult to define the the sources and the measurement collection points can be anywhere.
measurement points. However, we can always avoid this confusion by However, it is possible to organize the problem by applying
treating the connections as one-to-group or group-to-one in our measurements in one-to-group or group-to-one topologies for each host
measurements without consideration on how the real communication will in a uniform way (without taking account of how the real
be carried out. For example, if one group of hosts < ha, hb, hc, communication might be carried out). For example, one group of hosts
..., hn > are acting as sources to send data to another group of < ha, hb, hc, ..., hn > might act as sources to send data to another
hosts < Ha, Hb, Hc, ..., Hm >, we can always decompose them into n group of hosts < Ha, Hb, Hc, ..., Hm >, and they can be organized
one-to-group communications as < ha, Ha, Hb, Hc, ..., Hm >, < hb, Ha, into n sets of points of interest for one-to-group communications:
Hb, Hc, ..., Hm >, <hc, Ha, Hb, Hc, ..., Hm >, ..., < hn, Ha, Hb, Hc,
..., Hm >.
4. Spatial vectors metrics definitions < ha, Ha, Hb, Hc, ..., Hm >, < hb, Ha, Hb, Hc, ..., Hm >, <hc, Ha,
Hb, Hc, ..., Hm >, ..., < hn, Ha, Hb, Hc, ..., Hm >.
This section defines vectors for the decomposition of end-to-end 5. Spatial vector metrics definitions
singleton metrics over a path.
Spatial vectors metrics are based on the decomposition of standard This section defines vectors for the spatial decomposition of end-to-
end singleton metrics over a path.
Spatial vector metrics are based on the decomposition of standard
end-to-end metrics defined by the IPPM WG in [RFC2679], [RFC2680], end-to-end metrics defined by the IPPM WG in [RFC2679], [RFC2680],
[RFC3393] and [RFC3432]. [RFC3393] and [RFC3432].
Definitions are coupled with the corresponding end-to-end metrics. The spatial vector definitions are coupled with the corresponding
Methodology specificities are common to all the vectors defined and end-to-end metrics. Measurement methodology aspects are common to
are consequently discussed in a common section. all the vectors defined and are consequently discussed in a common
section.
4.1. A Definition for Spatial One-way Delay Vector 5.1. A Definition for Spatial One-way Delay Vector
This section is coupled with the definition of Type-P-One-way-Delay This section is coupled with the definition of Type-P-One-way-Delay
of the section 3 of [RFC2679]. When a parameter of this definition of the section 3 of [RFC2679]. When a parameter from the definition
is first used in this section, it will be tagged with a trailing in [RFC2679] is re-used in this section, the first instance will be
asterisk. tagged with a trailing asterisk.
Sections 3.5 to 3.8 of [RFC2679] give requirements and applicability Sections 3.5 to 3.8 of [RFC2679] give requirements and applicability
statements for end-to-end one-way-delay measurements. They are statements for end-to-end one-way-delay measurements. They are
applicable to each point of interest Hi involved in the measure. applicable to each point of interest, Hi, involved in the measure.
Spatial one-way-delay measurement SHOULD be respectful of them, Spatial one-way-delay measurement MUST respect them, especially those
especially those related to methodology, clock, uncertainties and related to methodology, clock, uncertainties and reporting.
reporting.
4.1.1. Metric Name 5.1.1. Metric Name
Type-P-Spatial-One-way-Delay-Vector Type-P-Spatial-One-way-Delay-Vector
4.1.2. Metric Parameters 5.1.2. Metric Parameters
o Src*, the IP address of the sender. o Src*, the IP address of the sender.
o Dst*, the IP address of the receiver. o Dst*, the IP address of the receiver.
o i, An integer in the ordered list <1,2,...,n> of hosts in the o i, an integer in the ordered list <1,2,...,n> of hosts in the
path. path.
o Hi, A host* of the path digest. o Hi, a host in the path digest.
o T*, a time, the sending (or initial observation) time for a o T*, a time, the sending (or initial observation) time for a
measured packet. measured packet.
o dT*, a delay, the one-way delay for a measured packet. o dT*, a delay, the one-way delay for a measured packet.
o <dT1,..., dTn> a list of delay. o dTi, a delay, the one-way delay for a measured packet from the
o P*, the specification of the packet type. source to host Hi.
o <H1, H2,..., Hn>, hosts path digest. o <dT1,... dTi,... dTn> a list of n delay singletons.
o Type-P*, the specification of the packet type.
o <H1, H2,..., Hn>, a path host digest.
4.1.3. Metric Units 5.1.3. Metric Units
The value of Type-P-Spatial-One-way-Delay-Vector is a sequence of The value of Type-P-Spatial-One-way-Delay-Vector is a sequence of
times. times (a real number in the dimension of seconds with sufficient
resolution to convey the results).
4.1.4. Definition 5.1.4. Definition
Given a Type-P packet sent by the sender Src at wire-time (first bit) Given a Type-P packet sent by the Src at wire-time (first bit) T to
T to the receiver Dst in the path <H1, H2,..., Hn>. Given the the receiver Dst on the path <H1, H2,..., Hn>. There is a sequence
sequence of values <T+dT1,T+dT2,...,T+dTn,T+dT> such that dT is the of values <T+dT1,T+dT2,...,T+dTn,T+dT> such that dT is the Type-P-
Type-P-One-way-Delay from Src to Dst and such that for each Hi of the One-way-Delay from Src to Dst, and for each Hi of the path, T+dTi is
path, T+dTi is either a real number corresponding to the wire-time either a real number corresponding to the wire-time the packet passes
the packet passes (last bit received) Hi, or undefined if the packet (last bit received) Hi, or undefined if the packet does not pass Hi
never passes Hi. within a specified loss threshold* time.
Type-P-Spatial-One-way-Delay-Vector metric is defined for the path Type-P-Spatial-One-way-Delay-Vector metric is defined for the path
<Src, H1, H2,..., Hn, Dst> as the sequence of values <Src, H1, H2,..., Hn, Dst> as the sequence of values
<T,dT1,dT2,...,dTn,dT>. <T,dT1,dT2,...,dTn,dT>.
4.1.5. Discussion 5.1.5. Discussion
Following are specific issues which may occur: Some specific issues that may occur are as follows:
o the delay looks to decrease: dTi > DTi+1. This may occur despite o the delay singletons "appear" to decrease: dTi > DTi+1. This may
it does not make sense per definition: occur despite being physically impossible with the definition
* This is frequently due to some clock synchronization issue. used.
This point is discussed in the section 3.7.1. "Errors or * This is frequently due to a measurement clock synchronization
uncertainties related to Clocks" of [RFC2679]. Consequently, issue. This point is discussed in the section 3.7.1. "Errors
times of a measure at different hosts do not guaranty the or uncertainties related to Clocks" of [RFC2679].
ordering of the hosts on the path of a measure. Consequently, the values of delays measured at multiple hosts
* During some change of routes the order of 2 hosts may change on may not match the order of those hosts on the path.
the main path; * The actual order of hosts on the path may change due to
* The location of the point of interest in the device influences reconvergence (e.g., recovery from a link failure).
the result. If the packet is not observed directly on the * The location of the measurement collection point in the device
input interface the delay includes buffering time and influences the result. If the packet is not observed directly
on the input interface the delay includes buffering time and
consequently an uncertainty due to the difference between 'wire consequently an uncertainty due to the difference between 'wire
time' and 'host time' time' and 'host time'.
4.2. A Definition for Spatial One-way Packet Loss Vector 5.2. A Definition for Spatial Packet Loss Vector
This section is coupled with the definition of Type-P-One-way-Packet- This section is coupled with the definition of Type-P-One-way-Packet-
Loss. Then when a parameter from the section 2 of [RFC2680] is first Loss. When a parameter from the section 2 of [RFC2680] is used in
used in this section, it will be tagged with a trailing asterisk. this section, the first instance will be tagged with a trailing
asterisk.
Sections 2.5 to 2.8 of [RFC2680] give requirements and applicability Sections 2.5 to 2.8 of [RFC2680] give requirements and applicability
statements for end-to-end one-way packet loss measurements. They are statements for end-to-end one-way packet loss measurements. They are
applicable to each point of interest Hi involved in the measure. applicable to each point of interest, Hi, involved in the measure.
Spatial packet loss measurement SHOULD be respectful of them, Spatial packet loss measurement MUST respect them, especially those
especially those related to methodology, clock, uncertainties and related to methodology, clock, uncertainties and reporting.
reporting.
Following we define the spatial metric, then we adapt some of the The following sections define the spatial loss vector, adapt some of
points above and introduce points specific to spatial measurement. the points above, and introduce points specific to spatial loss
measurement.
4.2.1. Metric Name 5.2.1. Metric Name
Type-P-Spatial-One-way-Packet-Loss-Vector Type-P-Spatial-Packet-Loss-Vector
4.2.2. Metric Parameters 5.2.2. Metric Parameters
o Src*, the IP address of the sender. o Src*, the IP address of the sender.
o Dst*, the IP address of the receiver. o Dst*, the IP address of the receiver.
o i, an integer which ordered the hosts in the path. o i, an integer in the ordered list <1,2,...,n> of hosts in the
path.
o Hi, points of interests of the path digest. o Hi, points of interest from the path digest.
o T*, a time, the sending time for a measured packet. o T*, a time, the sending time for a measured packet.
o <dT1,..., dTn, dT>, a list of delay. o dTi, a delay, the one-way delay for a measured packet from the
o P*, the specification of the packet type. source to host Hi.
o <H1, H2,..., Hn>, hosts path digest. o <dT1,..., dTn>, list of n delay singletons.
o Type-P*, the specification of packet type.
o <H1, H2,..., Hn>, a host path digest.
o <L1, L2, ...,Ln>, a list of Boolean values. o <L1, L2, ...,Ln>, a list of Boolean values.
4.2.3. Metric Units 5.2.3. Metric Units
The value of Type-P-Spatial-One-way-Packet-Loss-Vector is a sequence The value of Type-P-Spatial-Packet-Loss-Vector is a sequence of
of Boolean values. Boolean values.
4.2.4. Definition 5.2.4. Definition
Given a Type-P packet sent by the sender Src at time T to the Given a Type-P packet sent by the Src at time T to the receiver Dst
receiver Dst in the path <H1, H2, ..., Hn>. Given the sequence of on the path <H1, H2, ..., Hn>. For the sequence of times <T+dT1,T+
times <T+dT1,T+dT2,...,T+dTn> the packet passes in <H1, H2 ..., Hn>, dT2,..., T+dTi, ...,T+dTn> the packet passes in <H1, H2, ..., Hi,
we define Type-P-One-way-Packet-Lost-Vector metric as the sequence of ..., Hn>, define the Type-P-Packet-Loss-Vector metric as the sequence
values <L1, L2, ..., Ln> such that for each Hi of the path, a value of values <T, L1, L2, ..., Ln> such that for each Hi of the path, a
of 0 for Li means that dTi is a finite value, and a value of 1 means value of 0 for Li means that dTi is a finite value, and a value of 1
that dTi is undefined. means that dTi is undefined.
4.2.5. Discussion 5.2.5. Discussion
Following are specific issues which may occur: Some specific issues that may occur are as follows:
o The result includes the sequence 1,0. This may occur under o The result might include the sequence of values 1,0. Although
specific situations: this appears physically impossible (a packet is lost, then re-
* During some change of routes a packet may be seen by a host but appears later on the path):
not by it successor on the main path; * The actual hosts on the path may change due to reconvergence
(e.g., recovery from a link failure).
* The order of hosts on the path may change due to reconvergence.
* A packet may not be observed in a host due to some buffer or * A packet may not be observed in a host due to some buffer or
CPU overflow in the point of interest; CPU overflow at the measurement collection point.
4.3. A Definition for Spatial One-way Ipdv Vector 5.3. A Definition for Spatial One-way Ipdv Vector
This section uses parameters from the definition of Type-P-One-way- When a parameter from section 2 of [RFC3393] (the definition of Type-
ipdv. When a parameter from section 2 of [RFC3393] is first used in P-One-way-ipdv) is used in this section, the first instance will be
this section, it will be tagged with a trailing asterisk. tagged with a trailing asterisk.
In the following we adapt some of them and introduce points specific The following sections define the spatial ipdv vector, adapt some of
to spatial measurement. the points above, and introduce points specific to spatial ipdv
measurement.
4.3.1. Metric Name 5.3.1. Metric Name
Type-P-Spatial-One-way-ipdv-Vector Type-P-Spatial-One-way-ipdv-Vector
4.3.2. Metric Parameters 5.3.2. Metric Parameters
o Src*, the IP address of the sender. o Src*, the IP address of the sender.
o Dst*, the IP address of the receiver. o Dst*, the IP address of the receiver.
o i, An integer in the ordered list <1,2,...,n> of hosts in the o i, an integer in the ordered list <1,2,...,n> of hosts in the
path. path.
o Hi, A host* of the path digest. o Hi, a host of the path digest.
o T1*, a time, the sending time for a first measured packet. o T1*, a time, the sending time for a first measured packet.
o T2*, a time, the sending time for a second measured packet. o T2*, a time, the sending time for a second measured packet.
o dT*, a delay, the one-way delay for a measured packet. o dT*, a delay, the one-way delay for a measured packet.
o P*, the specification of the packets type. o dTi, a delay, the one-way delay for a measured packet from the
source to host Hi.
o Type-P*, the specification of the packets type.
o P1, the first packet sent at time T1. o P1, the first packet sent at time T1.
o P2, the second packet sent at time T2. o P2, the second packet sent at time T2.
o <H1, H2,..., Hn>, hosts path digest. o <H1, H2,..., Hn>, a host path digest.
o <T1,dT1.1, dT1.2,..., dT1.n,dT1>, the Type-P-Spatial-One-way- o <T1,dT1.1, dT1.2,..., dT1.n,dT1>, the Type-P-Spatial-One-way-
Delay-Vector for packet sent at time T1. Delay-Vector for packet sent at time T1.
o <T2,dT2.1, dT2.2,..., dT2.n,dT2>, the Type-P-Spatial-One-way- o <T2,dT2.1, dT2.2,..., dT2.n,dT2>, the Type-P-Spatial-One-way-
Delay-Vector for packet sent at time T2. Delay-Vector for packet sent at time T2.
o L*, a packet length in bits. The packets of a Type P packet o L*, a packet length in bits. The packets of a Type P packet
stream from which the Type-P-Spatial-One-way-Delay-Vector metric stream from which the Type-P-Spatial-One-way-Delay-Vector metric
is taken MUST all be of the same length. is taken MUST all be of the same length.
4.3.3. Metric Units 5.3.3. Metric Units
The value of Type-P-Spatial-One-way-ipdv-Vector is a sequence of The value of Type-P-Spatial-One-way-ipdv-Vector is a sequence of
times. times (a real number in the dimension of seconds with sufficient
resolution to convey the results).
4.3.4. Definition 5.3.4. Definition
Given P1 the Type-P packet sent by the sender Src at wire-time (first Given P1 the Type-P packet sent by the sender Src at wire-time (first
bit) T1 to the receiver Dst and <T1, dT1.1, dT1.2,..., dT1.n, dT1> bit) T1 to the receiver Dst and <T1, dT1.1, dT1.2,..., dT1.n, dT1>
its Type-P-Spatial-One-way-Delay-Vector over the path <H1, H2,..., its Type-P-Spatial-One-way-Delay-Vector over the path <H1, H2,...,
Hn>. Hn>.
Given P2 the Type-P packet sent by the sender Src at wire-time (first Given P2 the Type-P packet sent by the sender Src at wire-time (first
bit) T2 to the receiver Dst and <T2, dT2.1, dT2.2,..., dT2.n, dT2> bit) T2 to the receiver Dst and <T2, dT2.1, dT2.2,..., dT2.n, dT2>
its Type-P-Spatial-One-way-Delay-Vector over the same path. its Type-P-Spatial-One-way-Delay-Vector over the same path.
Type-P-Spatial-One-way-ipdv-Vector metric is defined as the sequence Type-P-Spatial-One-way-ipdv-Vector metric is defined as the sequence
of values <T2-T1, dT2.1-dT1.1, dT2.2-dT1.2 ,..., dT2.n-dT1.n, dT2- of values <T1, T2, dT2.1-dT1.1, dT2.2-dT1.2 ,..., dT2.n-dT1.n, dT2-
dT1> such that for each Hi of the path <H1, H2,..., Hn>, dT2.i-dT1.i dT1> such that for each Hi of the path <H1, H2,..., Hn>, dT2.i-dT1.i
is either a real number if the packets P1 and P2 passe Hi at wire- is either a real number if the packets P1 and P2 pass Hi at wire-time
time (last bit) dT1.i, respectively dT2.i, or undefined if at least (last bit) dT1.i and dT2.i respectively, or undefined if at least one
one of them never passes Hi. T2-T1 is the inter-packet emission of them never passes Hi (and the respective one-way delay is
interval and dT2-dT1 is ddT* the Type-P-One-way-ipdv at T1,T2*. undefined). The T1,T2* pair indicates the inter-packet emission
interval and dT2-dT1 is ddT* the Type-P-One-way-ipdv.
4.4. Spatial Methodology 5.4. Spatial Methodology
Methodology, reporting and uncertainties points specified in section The methodology, reporting specifications, and uncertainties
3 of [RFC2679] applies to each point of interest Hi measuring a specified in section 3 of [RFC2679] apply to each point of interest
element of a spatial delay vector. (or measurement collection point), Hi, measuring an element of a
spatial delay vector.
Methodology, reporting and uncertainties points specified in section Likewise, the methodology, reporting specifications, and
2 of [RFC2680] applies to each point of interest Hi measuring a uncertainties specified in section 2 of [RFC2680] apply to each point
element of a spatial packet loss vector. of interest, Hi, measuring an element of a spatial packet loss
vector.
Sections 3.5 to 3.7 of [RFC3393] give requirements and applicability Sections 3.5 to 3.7 of [RFC3393] give requirements and applicability
statements for end-to-end One-way ipdv measurements. They are statements for end-to-end One-way ipdv measurements. They are
applicable to each point of interest Hi involved in the measure. applicable to each point of interest, Hi, involved in the measure.
Spatial One-way ipdv measurement SHOULD be respectful of methodology, Spatial One-way ipdv measurement MUST respect the methodology, clock,
clock, uncertainties and reporting aspects given in this section. uncertainties and reporting aspects given there.
Generally, for a given Type-P of length L, in a given Hi, the Generally, for a given Type-P packet of length L at a specific Hi,
methodology for spatial vector metrics may proceed as follows: the methodology for spatial vector metrics may proceed as follows:
o At each Hi, points of interest prepare to capture the packet sent o At each Hi, points of interest/measurement collection points
a time T, take a timestamp Ti', determine the internal delay prepare to capture the packet sent at time T, record a timestamp
correction dTi' (See section 3.7.1. "Errors or uncertainties Ti', and determine the internal delay correction dTi' (See section
related to Clocks" of [RFC2679]), 3.7.1. "Errors or uncertainties related to Clocks" of [RFC2679]);
o Each Hi extracts the path ordering information from the packet o Each Hi extracts the path ordering information from the packet
(e.g. time-to-live); (e.g. time-to-live);
o Each Hi compute the wiretime from Src to Hi: Ti = Ti' - dTi'. o Each Hi computes the corrected wiretime from Src to Hi: Ti = Ti' -
This arrival time is undefined (infinite) if the packet is not dTi'. This arrival time is undefined if the packet is not
detected after the 'loss threshold' duration; detected after the 'loss threshold' duration;
o Each Hi extracts the timestamp T from the packet; o Each Hi extracts the timestamp T from the packet;
o Each Hi computes the one-way-delay from Src to Hi: dTi = Ti - T; o Each Hi computes the one-way-delay from Src to Hi: dTi = Ti - T;
o The reference point gathers the result of each Hi and order them o The reference point gathers the result of each Hi and arranges
according to the path ordering information received to build the them according to the path ordering information received to build
type-P spatial one-way vector (e.g. Type-P-Spatial-One-way-Delay- the type-P spatial one-way vector (e.g. Type-P-Spatial-One-way-
Vector metric <T, dT1, dT2,..., dTn, dT> ) over the path <Src, H1, Delay-Vector metric <T, dT1, dT2,..., dTn, dT>) over the path
H2,..., Hn, Dst> at time T. <Src, H1, H2,..., Hn, Dst> at time T.
4.4.1. Loss threshold 5.4.1. Packet Loss Detection
Loss threshold is the centrality of any methodology because it In an pure end-to-end measurement, packet losses are detected by the
determines the presence the packet in the measurement process of the receiver only. A packet is lost when Type-P-One-way-Delay is
point of interest and consequently determines any ground truth metric undefined or very large (See section 2.4 ans 2.5 of [RFC2680] and
result. It determines the presence of an effective delay, and bias section 3.5 of [RFC2680]). A packet is deemed lost by the receiver
the measure of ipdv, of packet loss and of the statistics. after a duration which starts at the time the packet is sent. This
timeout value is chosen by a measurement process; It determines the
threshold between recording a long packet transfer time as a finite
value or an undefined value.
This is consistent for end-to-end but impacts spatial measure: In a spatial measurement, packet losses may be detected at several
depending on the consistency of the loss threshold among the points measurement collection points. Depending on the consistency of the
of interest, a packet may be considered loss a one host but present packet loss detections among the points of interest, a packet may be
in another one, or may be observed by the last host (last hop) of the considered as lost at one point despite having a finite delay at
path but considered lost by Dst. The analysis of such results is not another one, or may be observed by the last measurement collection
deterministic: Has the path change? Does the packet arrive at point of the path but considered lost by Dst.
destination or was it lost during the last mile? The same applies,
of course, for one-way-delay measures: a delay measured may be
infinite at one host but a real value in another one, or may be
measured as a real value by the last host of the path but observed as
infinite by Dst. The loss threshold should be set up with the same
value in each host of the path and in the destination. The loss
threshold must be systematically reported to permit careful
introspection and to avoid the introduction of any contradiction in
the statistic computation process.
4.4.2. Host Path Digest There is a risk of misinterpreting such results: Has the path
changed? Did the packet arrive at the destination or was it lost on
the very last link?
The methodology given above relies on the order of the points of The same concern applies to one-way-delay measures: a delay measured
interest over the path to [RFC2679] one's. may be computed as infinite by one observation point but as a real
value by another one, or may be measured as a real value by the last
observation point of the path but designated as undefined by Dst.
A test packets may cross several times the same host resulting in the The observation/measurement collection points and the destination
repetition of one or several hosts in the Path Digest. SHOULD use consistent methods to detect packets losses. The methods
and parameters must be systematically reported to permit careful
comparison and to avoid introducing any confounding factors in the
analysis.
As an example. This occurs typically during rerouting phases which 5.4.2. Host Path Digest
introduce temporary micro loops. During such an event the host path
digest for a packet crossing Ha and Hb may include the pattern <Hb,
Ha, Hb, Ha, Hb> meaning that Ha ended the computation of the new path
before Hb and that the initial path wath from Ha to Hb and that the
new path is from Hb to Ha.
Consequently, duplication of hosts in the Path Digest of a vectors The methodology given above relies on knowing the order of the hosts/
MUST be identified before statistics computation to avoid corrupted measurement collection points on the path [RFC2330].
results' production.
5. Spatial Segments metrics definitions Path instability might cause a test packet to be observed more than
once by the same host, resulting in the repetition of one or more
hosts in the Path Digest.
For example, repeated observations may occur during rerouting phases
which introduce temporary micro loops. During such an event the host
path digest for a packet crossing Ha and Hb may include the pattern
<Hb, Ha, Hb, Ha, Hb> meaning that Ha ended the computation of the new
path before Hb and that the initial path was from Ha to Hb and that
the new path is from Hb to Ha.
Consequently, duplication of hosts in the path digest of a vector
MUST be identified before computation of statistics to avoid
producing corrupted information.
6. Spatial Segment Metrics Definitions
This section defines samples to measure the performance of a segment This section defines samples to measure the performance of a segment
of a path over time. Definitions rely on matrix of the spatial of a path over time. The definitions rely on the matrix of the
vector metrics defined above. spatial vector metrics defined above.
Firstly it defines a sample of one-way delay, Type-P-Segment-One-way- Firstly this section defines a sample of one-way delay, Type-P-
Delay-Stream, and a sample of packet loss, Type-P-segment-Packet- Segment-One-way-Delay-Stream, and a sample of packet loss, Type-P-
loss-Stream. segment-Packet-Loss-Stream.
Then it defines 2 different samples of ipdv. The first metric, Type- Then it defines 2 different samples of ipdv: Type-P-Segment-ipdv-
P-Segment-One-way-ipdv-prev-Stream, uses the previous packet as the prev-Stream uses the current and previous packets as the selection
selection function. The second metric, Type-P-Segment-One-way-ipdv- function, and Type-P-Segment-ipdv-min-Stream, uses the minimum delay
min-Stream, uses the minimum delay as the selection. as one of the selected packets in every pair.
5.1. A Definition of a sample of One-way Delay of a segment of the path 6.1. A Definition of a Sample of One-way Delay of a Segment of the Path
This metric defines a sample of One-way delays over time between a This metric defines a sample of One-way delays over time between a
pair of hosts of a path. pair of hosts on a path. Since it is very close semantically to the
metric Type-P-One-way-Delay-Poisson-Stream defined in section 4 of
As its semantic is very close to the metric Type-P-Packet-loss-Stream [RFC2679], sections 4.5 to 4.8 of [RFC2679] are integral parts of the
defined in section 4 of [RFC2679], sections 4.5 to 4.8 of [RFC2679] definition text below.
are part of the current definition.
5.1.1. Metric Name 6.1.1. Metric Name
Type-P-Segment-One-way-Delay-Stream Type-P-Segment-One-way-Delay-Stream
5.1.2. Metric Parameters 6.1.2. Metric Parameters
o Src*, the IP address of the sender. o Src, the IP address of the sender.
o Dst*, the IP address of the receiver. o Dst, the IP address of the receiver.
o P*, the specification of the packet type. o Type-P, the specification of the packet type.
o i, an integer in the ordered list <1,2,...,n> of hosts in the o i, an integer in the ordered list <1,2,...,n> of hosts in the
path. path.
o k, an integer which orders the packets sent. o k, an integer which orders the packets sent.
o a and b, 2 integers where b > a. o a and b, two integers where b > a.
o Hi, a host* of the path digest. o Hi, a host of the path digest.
o <H1,..., Ha, ..., Hb, ...., Hn>, hosts path digest. o <H1,..., Ha, ..., Hb, ...., Hn>, a host path digest.
o <T1, T2, ..., Tm>, a list of times. o <T1, T2, ..., Tm>, a list of times.
5.1.3. Metric Units 6.1.3. Metric Units
The value of a Type-P-Segment-One-way-Delay-Stream is a pair of The value of a Type-P-Segment-One-way-Delay-Stream is a pair of:
list of times <T1, T2, ..., Tm>; A list of times <T1, T2, ..., Tm>;
sequence of delays. A sequence of delays.
5.1.4. Definition 6.1.4. Definition
Given 2 hosts, Ha and Hb, of the path <H1, H2,..., Ha, ..., Hb, ..., Given 2 hosts, Ha and Hb, of the path <H1, H2,..., Ha, ..., Hb, ...,
Hn>, given the matrix of Type-P-Spatial-One-way-Delay-Vector for the Hn>, and the matrix of Type-P-Spatial-One-way-Delay-Vector for the
packets sent from Src to Dst at times <T1, T2, ..., Tm-1, Tm> : packets sent from Src to Dst at times <T1, T2, ..., Tm-1, Tm> :
<T1, dT1.1, dT1.2, ..., dT1.a, ..., dT1.b,..., dT1.n, dT1>; <T1, dT1.1, dT1.2, ..., dT1.a, ..., dT1.b,..., dT1.n, dT1>;
<T2, dT2.1, dT2.2, ..., dT2.a, ..., dT2.b,..., dT2.n, dT2>; <T2, dT2.1, dT2.2, ..., dT2.a, ..., dT2.b,..., dT2.n, dT2>;
... ...
<Tm, dTm.1, dTm.2, ..., dTm.a, ..., dTm.b,..., dTm.n, dTm>. <Tm, dTm.1, dTm.2, ..., dTm.a, ..., dTm.b,..., dTm.n, dTm>.
We define the sample Type-P-segment-One-way-Delay-Stream as the We define the sample Type-P-segment-One-way-Delay-Stream as the
sequence <dT1.ab, dT2.ab, ..., dTk.ab, ..., dTm.ab> such that for sequence <dT1.ab, dT2.ab, ..., dTk.ab, ..., dTm.ab> such that for
each time Tk, 'dTk.ab' is either the real number 'dTk.b - dTk.a' if each time Tk, 'dTk.ab' is either the real number 'dTk.b - dTk.a' if
the packet send a time Tk passes Ha and Hb or undefined if this the packet sent at time Tk passes Ha and Hb or undefined if this
packet never passes Ha or (inclusive) never passes Hb. packet never passes Ha or (inclusive) never passes Hb.
5.1.5. Discussion 6.1.5. Discussion
Following are specific issues which may occur: Some specific issues that may occur are as follows:
o the delay looks to decrease: dTi > DTi+1: o the delay singletons "appear" to decrease: dTi > DTi+1, and is
* This is typically due to clock synchronization issue. this discussed in section 5.1.5.
point is discussed in the section 3.7.1. "Errors or * This could also occur when the clock resolution of one
uncertainties related to Clocks" of of [RFC2679]; measurement collection point is larger than the minimum delay
* This may occurs too when the clock resolution of one probe is of a path. For example, the minimum delay of a 500 km path
bigger than the minimum delay of a path. As an example this through optical fiber facilities is 2.5ms, but the measurement
happen when measuring the delay of a path which is 500 km long collection point has a clock resolution of 8ms.
with one probe synchronized using NTP having a clock resolution The metric SHALL be invalid for times < T1 , T2, ..., Tm-1, Tm> if
of 8ms. the following conditions occur:
The metric can not be performed on < T1 , T2, ..., Tm-1, Tm> in the o Ha or Hb disappears from the path due to some routing change.
following cases: o The order of Ha and Hb changes in the path.
o Ha or Hb disappears from the path due to some change of routes;
o The order of Ha and Hb changes in the path;
5.2. A Definition of a sample of Packet Loss of a segment of the path 6.2. A Definition of a Sample of Packet Loss of a Segment of the Path
This metric defines a sample of packet lost over time between a pair This metric defines a sample of packet loss over time between a pair
of hosts of a path. As its semantic is very close to the metric of hosts of a path. Since it is very close semantically to the
Type-P-Packet-loss-Stream defined in section 3 of [RFC2680], sections metric Type-P-Packet-loss-Stream defined in section 3 of [RFC2680],
3.5 to 3.8 of [RFC2680] are part of the current definition. sections 3.5 to 3.8 of [RFC2680] are integral parts of the definition
text below.
5.2.1. Metric Name 6.2.1. Metric Name
Type-P-segment-Packet-loss-Stream Type-P-segment-Packet-Loss-Stream
5.2.2. Metric Parameters 6.2.2. Metric Parameters
o Src*, the IP address of the sender. o Src, the IP address of the sender.
o Dst*, the IP address of the receiver.
o P*, the specification of the packet type. o Dst, the IP address of the receiver.
o Type-P, the specification of the packet type.
o k, an integer which orders the packets sent. o k, an integer which orders the packets sent.
o n, an integer which orders the hosts on the path. o n, an integer which orders the hosts on the path.
o a and b, 2 integers where b > a. o a and b, two integers where b > a.
o <H1, H2, ..., Ha, ..., Hb, ...,Hn>, hosts path digest. o <H1, H2, ..., Ha, ..., Hb, ...,Hn>, a host path digest.
o Hi, exchange points of the path digest. o Hi, exchange points of the path digest.
o <T1, T2, ..., Tm>, a list of times. o <T1, T2, ..., Tm>, a list of times.
o <L1, L2, ..., Ln> a list of boolean values. o <L1, L2, ..., Ln>, a list of Boolean values.
5.2.3. Metric Units 6.2.3. Metric Units
The value of a Type-P-segment-Packet-loss-Stream is a pair of The value of a Type-P-segment-Packet-Loss-Stream is a pair of:
The list of times <T1, T2, ..., Tm>; A The list of times <T1, T2, ..., Tm>;
a sequence of booleans. A sequence of Boolean values.
5.2.4. Definition 6.2.4. Definition
Given 2 hosts, Ha and Hb, of the path <H1, H2,..., Ha, ..., Hb, ..., Given two hosts, Ha and Hb, of the path <H1, H2,..., Ha, ..., Hb,
Hn>, given the matrix of Type-P-Spatial-Packet-loss-Vector for the ..., Hn>, and the matrix of Type-P-Spatial-Packet-Loss-Vector for the
packets sent from Src to Dst at times <T1, T2, ..., Tm-1, Tm> : packets sent from Src to Dst at times <T1, T2, ..., Tm-1, Tm> :
<L1.1, L1.2,..., L1.a, ..., L1.b, ..., L1.n, L>, <T1, L1.1, L1.2,..., L1.a, ..., L1.b, ..., L1.n, L>,
<L2.1, L2.2,..., L2.a, ..., L2.b, ..., L2.n, L>, <T2, L2.1, L2.2,..., L2.a, ..., L2.b, ..., L2.n, L>,
..., ...,
<Lm.1, Lm.2,..., Lma, ..., Lm.b, ..., Lm.n, L>. <Tm, Lm.1, Lm.2,..., Lma, ..., Lm.b, ..., Lm.n, L>.
We define the value of the sample Type-P-segment-Packet-Lost-Stream We define the value of the sample Type-P-segment-Packet-Lost-Stream
from Ha to Hb as the sequence of booleans <L1.ab, L2.ab,..., Lk.ab, from Ha to Hb as the sequence of Booleans <L1.ab, L2.ab,..., Lk.ab,
..., Lm.ab> such that for each Tk: ..., Lm.ab> such that for each Tk:
o A value of Lk of 0 means that Ha and Hb observed the packet sent o A value of Lk of 0 means that Ha and Hb observed the packet sent
at time Tk (Lk.a and Lk.b have a value of 0); at time Tk (both Lk.a and Lk.b have a value of 0).
o A value of Lk of 1 means that Ha observed the packet sent at time o A value of Lk of 1 means that Ha observed the packet sent at time
Tk (Lk.a has a value of 0) and that Hb did not observed the packet Tk (Lk.a has a value of 0) and that Hb did not observe the packet
sent at time Tk (Lk.b have a value of 1); sent at time Tk (Lk.b has a value of 1).
o The value of Lk is undefined when Neither Ha or Hb observe the o The value of Lk is undefined when neither Ha nor Hb observed the
packet; packet (both Lk.a and Lk.b have a value of 1).
5.2.5. Discussion 6.2.5. Discussion
Unlike Type-P-Packet-loss-Stream, Type-P-Segment-Packet-Loss-Stream
relies on the stability of the host path digest. The metric SHALL be
invalid for times < T1 , T2, ..., Tm-1, Tm> if the following
conditions occur:
o Ha or Hb disappears from the path due to some routing change.
o The order of Ha and Hb changes in the path.
o Lk.a or Lk.b is undefined.
Unlike Type-P-Packet-loss-Stream, Type-P-Segment-Packet-loss-Stream
relies on the stability of the host path digest. The metric can not
be performed on < T1 , T2, ..., Tm-1, Tm> in the following cases:
o Ha or Hb disappears from the path due to some change of routes;
o the order of Ha and Hb changes in the path;
o Lk.a or Lk.b is undefined;
o Lk.a has the value 1 (not observed) and Lk.b has the value 0 o Lk.a has the value 1 (not observed) and Lk.b has the value 0
(observed); (observed);
o L has the value 0 (the packet was received by Dst) and Lk.ab has o L has the value 0 (the packet was received by Dst) and Lk.ab has
the value 1 (the packet was lost between Ha and Hb). the value 1 (the packet was lost between Ha and Hb).
5.3. A Definition of a sample of ipdv of a segment using the previous 6.3. A Definition of a Sample of ipdv of a Segment using the Previous
packet selection function Packet Selection Function
This metric defines a sample of ipdv [RFC3393] over time between a This metric defines a sample of ipdv [RFC3393] over time between a
pair of hosts using the previous packet as the selection function. pair of hosts using the previous packet as the selection function.
5.3.1. Metric Name 6.3.1. Metric Name
Type-P-Segment-One-way-ipdv-prev-Stream Type-P-Segment-ipdv-prev-Stream
5.3.2. Metric Parameters 6.3.2. Metric Parameters
o Src*, the IP address of the sender.
o Dst*, the IP address of the receiver. o Src, the IP address of the sender.
o P*, the specification of the packet type. o Dst, the IP address of the receiver.
o Type-P, the specification of the packet type.
o k, an integer which orders the packets sent. o k, an integer which orders the packets sent.
o n, an integer which orders the hosts on the path. o n, an integer which orders the hosts on the path.
o a and b, 2 integers where b > a. o a and b, two integers where b > a.
o <H1, H2, ..., Ha, ..., Hb, ...,Hn>, the hosts path digest. o <H1, H2, ..., Ha, ..., Hb, ...,Hn>, the hosts path digest.
o <T1, T2, ..., Tm-1, Tm>, a list of times. o <T1, T2, ..., Tm-1, Tm>, a list of times.
o <Tk, dTk.1, dTk.2, ..., dTk.a, ..., dTk.b,..., dTk.n, dTk>, a o <Tk, dTk.1, dTk.2, ..., dTk.a, ..., dTk.b,..., dTk.n, dTk>, a
Type-P-Spatial-One-way-Delay-Vector. Type-P-Spatial-One-way-Delay-Vector.
5.3.3. Metric Units 6.3.3. Metric Units
The value of a Type-P-Segment-One-way-ipdv-prev-Stream is a pair of: The value of a Type-P-Segment-ipdv-prev-Stream is a pair of:
The list of <T1, T2, ..., Tm-1, Tm>; The list of <T1, T2, ..., Tm-1, Tm>;
A list of pairs of interval of times and delays; A list of pairs of interval of times and delays;
5.3.4. Definition 6.3.4. Definition
Given 2 hosts, Ha and Hb, of the path <H1, H2,..., Ha, ..., Hb, ..., Given two hosts, Ha and Hb, of the path <H1, H2,..., Ha, ..., Hb,
Hn>, given the matrix of Type-P-Spatial-One-way-Delay-Vector for the ..., Hn>, and the matrix of Type-P-Spatial-One-way-Delay-Vector for
packets sent from Src to Dst at times <T1, T2, ..., Tm-1, Tm> : the packets sent from Src to Dst at times <T1, T2, ..., Tm-1, Tm> :
<T1, dT1.1, dT1.2, ..., dT1.a, ..., dT1.b,..., dT1.n, dT1>, <T1, dT1.1, dT1.2, ..., dT1.a, ..., dT1.b,..., dT1.n, dT1>,
<T2, dT2.1, dT2.2, ..., dT2.a, ..., dT2.b,..., dT2.n, dT2>, <T2, dT2.1, dT2.2, ..., dT2.a, ..., dT2.b,..., dT2.n, dT2>,
... ...
<Tm, dTm.1, dTm.2, ..., dTm.a, ..., dTm.b,..., dTm.n, dTm>. <Tm, dTm.1, dTm.2, ..., dTm.a, ..., dTm.b,..., dTm.n, dTm>.
We define the Type-P-Segment-One-way-ipdv-prev-Stream as the sequence We define the Type-P-Segment-ipdv-prev-Stream as the sequence of
of pair of packet intervals and delay variations <(dT2_1.a , dT2.ab - packet time pairs and delay variations
dT1.ab) ,..., (dTk_k-1.a, dTk.ab - dTk-1.ab), ..., (dTm_m-1.a, dTm.ab
- dTm-1.ab)> such that for each Tk:
o dTk_k-1.a is either undefined if the delay dTk.a or the delay
dTk-1.a is undefined, or the interval of time, 'dTk.a - dTk-1.a',
between the 2 packets at Ha;
o dTk_k-1.ab, is either undefined if one of the delays dTk.b, dTk.a,
dTk-1.b or dTk-1.a is undefined, or , (dTk.b - dTk.a) - (dTk-1.b -
dTk-1.a), the delay variation from Ha to Hb between the 2 packets
sent at time Tk and Tk-1.
5.3.5. Discussion <(T1, T2 , dT2.ab - dT1.ab) ,...,
(Tk-1, Tk, dTk.ab - dTk-1.ab), ...,
(Tm-1, Tm, dTm.ab - dTm-1.ab)>
For any pair, Tk, Tk-1 in k=1 through m, the difference dTk.ab - dTk-
1.ab is undefined if:
o the delay dTk.a or the delay dTk-1.a is undefined, OR
o the delay dTk.b or the delay dTk-1.b is undefined.
6.3.5. Discussion
This metric belongs to the family of inter packet delay variation This metric belongs to the family of inter packet delay variation
metrics (IPDV in upper case) which results can be extremely sensitive metrics (IPDV in upper case) whose results are extremely sensitive to
to the inter-packet interval. the inter-packet interval in practice.
The inter-packet interval of a end-to-end IPDV metric is under the The inter-packet interval of an end-to-end IPDV metric is under the
control of the ingress point of interest which corresponds exactly to control of the source (ingress point of interest). In contrast, the
the Source of the packet. Unlikely, the inter-packet interval of a inter-packet interval of a segment IPDV metric is not under the
segment IPDV metric is not under the control the ingress point of control the ingress point of interest of the measure, Ha. The
interest of the measure, Ha. However, the interval will vary if interval will certainly vary if there is delay variation between the
there is delay variation between the Source and Ha. Therefore, the Source and Ha. Therefore, the ingress inter-packet interval must be
actual inter-packet interval must be known at Ha in order to fully known at Ha in order to fully comprehend the delay variation between
comprehend the delay variation between Ha and Hb. Ha and Hb.
5.4. A Definition of a sample of ipdv of a segment using the minimum 6.4. A Definition of a Sample of ipdv of a Segment using the Minimum
delay selection function Delay Selection Function
This metric defines a sample of ipdv [RFC3393] over time between a This metric defines a sample of ipdv [RFC3393] over time between a
pair of hosts of a path using the shortest delay as the selection pair of hosts on a path using the minimum delay as one of the
function. selected packets in every pair.
5.4.1. Metric Name 6.4.1. Metric Name
Type-P-Segment-One-way-ipdv-min-Stream Type-P-Segment-One-way-ipdv-min-Stream
5.4.2. Metric Parameters 6.4.2. Metric Parameters
o Src*, the IP address of the sender. o Src, the IP address of the sender.
o Dst*, the IP address of the receiver. o Dst, the IP address of the receiver.
o P*, the specification of the packet type. o Type-P, the specification of the packet type.
o k, an integer which orders the packets sent. o k, an integer which orders the packets sent.
o i, an integer which identifies a packet sent. o i, an integer which identifies a packet sent.
o n, an integer which orders the hosts on the path. o n, an integer which orders the hosts on the path.
o a and b, 2 integers where b > a. o a and b, two integers where b > a.
o <H1, H2, ..., Ha, ..., Hb, ...,Hn>, the hosts path digest. o <H1, H2, ..., Ha, ..., Hb, ...,Hn>, the host path digest.
o <T1, T2, ..., Tm-1, Tm>, a list of times. o <T1, T2, ..., Tm-1, Tm>, a list of times.
o <Tk, dTk.1, dTk.2, ..., dTk.a, ..., dTk.b,..., dTk.n, dTk>, a o <Tk, dTk.1, dTk.2, ..., dTk.a, ..., dTk.b,..., dTk.n, dTk>, a
Type-P-Spatial-One-way-Delay-Vector. Type-P-Spatial-One-way-Delay-Vector.
5.4.3. Metric Units 6.4.3. Metric Units
The value of a Type-P-Segment-One-way-ipdv-min-Stream is a pair of: The value of a Type-P-Segment-One-way-ipdv-min-Stream is a pair of:
The list of <T1, T2, ..., Tm-1, Tm>; The list of <T1, T2, ..., Tm-1, Tm>;
A list of times; A list of times.
5.4.4. Definition 6.4.4. Definition
Given 2 hosts, Ha and Hb, of the path <H1, H2,..., Ha, ..., Hb, ..., Given two hosts, Ha and Hb, of the path <H1, H2,..., Ha, ..., Hb,
Hn>, given the matrix of Type-P-Spatial-One-way-Delay-Vector for the ..., Hn>, and the matrix of Type-P-Spatial-One-way-Delay-Vector for
packets sent from Src to Dst at times <T1, T2, ..., Tm-1, Tm> : the packets sent from Src to Dst at times <T1, T2, ..., Tm-1, Tm> :
<T1, dT1.1, dT1.2, ..., dT1.a, ..., dT1.b,..., dT1.n, dT1>, <T1, dT1.1, dT1.2, ..., dT1.a, ..., dT1.b,..., dT1.n, dT1>,
<T2, dT2.1, dT2.2, ..., dT2.a, ..., dT2.b,..., dT2.n, dT2>, <T2, dT2.1, dT2.2, ..., dT2.a, ..., dT2.b,..., dT2.n, dT2>,
... ...
<Tm, dTm.1, dTm.2, ..., dTm.a, ..., dTm.b,..., dTm.n, dTm>. <Tm, dTm.1, dTm.2, ..., dTm.a, ..., dTm.b,..., dTm.n, dTm>.
We define the Type-P-Segment-One-way-ipdv-min-Stream as the sequence We define the Type-P-Segment-One-way-ipdv-min-Stream as the sequence
of times <dT1.ab - min(dTi.ab) ,..., dTk.ab - min(dTi.ab), ..., of times <dT1.ab - min(dTi.ab) ,..., dTk.ab - min(dTi.ab), ...,
dTm.ab - min(dTi.ab)> such that: dTm.ab - min(dTi.ab)> where:
min(dTi.ab) is the minimum value of the tuples (dTk.b - dTk.a); o min(dTi.ab) is the minimum value of the tuples (dTk.b - dTk.a);
for each time Tk, dTk.ab is undefined if dTk.a or (inclusive) o for each time Tk, dTk.ab is undefined if dTk.a or (inclusive)
dTk.b is undefined, or the real number (dTk.b - dTk.a). dTk.b is undefined, or the real number (dTk.b - dTk.a) is
undefined.
5.4.5. Discussion 6.4.5. Discussion
This metric belongs to the family of packet delay variation metrics This metric belongs to the family of packet delay variation metrics
(PDV). PDV distributions are less sensitive to inter-packet interval (PDV). PDV distributions have less sensitivity to inter-packet
variations than IPDV results. interval variations than IPDV values, as discussed above.
In principle, the PDV distribution reflects the variation over many In principle, the PDV distribution reflects the variation over many
different inter-packet intervals, from the smallest inter-packet different inter-packet intervals, from the smallest inter-packet
interval, up to the length of the evaluation interval, Tm - T1. interval, up to the length of the evaluation interval, Tm - T1.
Therefore, when delay variation occurs and disturbs the packet Therefore, when delay variation occurs and disturbs the packet
spacing observed at Ha, the PDV results will likely compare favorably spacing observed at Ha, the PDV results will likely compare favorably
to a PDV measurement where the source is Ha and the destination is to a PDV measurement where the source is Ha and the destination is
Hb. Hb, because a wide range of spacings are reflected in any PDV
distribution.
6. One-to-group metrics definitions 7. One-to-group metrics definitions
This metric defines metrics to measure the performance between a This section defines performance metrics between a source and a group
source and a group of receivers. of receivers.
6.1. A Definition for One-to-group One-way Delay 7.1. A Definition for One-to-group Delay
This metric defines a metric to measure one-way delay between a This section defines a metric for one-way delay between a source and
source and a group of receivers. a group of receivers.
6.1.1. Metric Name 7.1.1. Metric Name
Type-P-One-to-group-One-way-Delay-Vector Type-P-One-to-group-Delay-Vector
6.1.2. Metric Parameters 7.1.2. Metric Parameters
o Src, the IP address of a host acting as the source. o Src, the IP address of a host acting as the source.
o Recv1,..., RecvN, the IP addresses of the N hosts acting as o Recv1,..., RecvN, the IP addresses of the N hosts acting as
receivers. receivers.
o T, a time. o T, a time.
o dT1,...,dTn a list of time. o dT1,...,dTn a list of times.
o P, the specification of the packet type. o Type-P, the specification of the packet type.
o Gr, the receiving group identifier. The parameter Gr is the o Gr, the receiving group identifier. The parameter Gr is the
multicast group address if the measured packets are transmitted multicast group address if the measured packets are transmitted
over IP multicast. This parameter is to differentiate the over IP multicast. This parameter is to differentiate the
measured traffic from other unicast and multicast traffic. It is measured traffic from other unicast and multicast traffic. It is
optional in the metric to avoid losing any generality, i.e. to OPTIONAL for this metric to avoid losing any generality, i.e. to
make the metric also applicable to unicast measurement where there make the metric also applicable to unicast measurement where there
is only one receiver. is only one receiver.
6.1.3. Metric Units 7.1.3. Metric Units
The value of a Type-P-One-to-group-One-way-Delay-Vector is a set of The value of a Type-P-One-to-group-Delay-Vector is a set of Type-P-
Type-P-One-way-Delay singletons [RFC2679]. One-way-Delay singletons [RFC2679], which is a sequence of times (a
real number in the dimension of seconds with sufficient resolution to
convey the results).
6.1.4. Definition 7.1.4. Definition
Given a Type P packet sent by the source Src at Time T, given the N Given a Type-P packet sent by the source Src at time T, and the N
hosts { Recv1,...,RecvN } which receive the packet at the time { hosts { Recv1,...,RecvN } which receive the packet at the time {
T+dT1,...,T+dTn }, a Type-P-One-to-group-One-way-Delay-Vector is T+dT1,...,T+dTn }, or the packet does not pass a receiver within a
defined as the set of the Type-P-One-way-Delay singleton between Src specified loss threshold time, then the Type-P-One-to-group-Delay-
and each receiver with value of { dT1, dT2,...,dTn }. Vector is defined as the set of the Type-P-One-way-Delay singletons
between Src and each receiver with value of { dT1, dT2,...,dTn },
where any of the singletons may be undefined if the packet did not
pass the corresponding receiver within a specified loss threshold
time.
6.2. A Definition for One-to-group One-way Packet Loss 7.2. A Definition for One-to-group Packet Loss
6.2.1. Metric Name 7.2.1. Metric Name
Type-P-One-to-group-One-way-Packet-Loss-Vector Type-P-One-to-group-Packet-Loss-Vector
6.2.2. Metric Parameters 7.2.2. Metric Parameters
o Src, the IP address of a host acting as the source. o Src, the IP address of a host acting as the source.
o Recv1,..., RecvN, the IP addresses of the N hosts acting as o Recv1,..., RecvN, the IP addresses of the N hosts acting as
receivers. receivers.
o T, a time. o T, a time.
o T1,...,Tn a list of time. o Type-P, the specification of the packet type.
o P, the specification of the packet type. o Gr, the receiving group identifier, OPTIONAL.
o Gr, the receiving group identifier.
6.2.3. Metric Units 7.2.3. Metric Units
The value of a Type-P-One-to-group-One-way-Packet-Loss-Vector is a The value of a Type-P-One-to-group-Packet-Loss-Vector is a set of
set of Type-P-One-way-Packet-Loss singletons [RFC2680]. Type-P-One-way-Packet-Loss singletons [RFC2680].
6.2.4. Definition o T, time the source packet was sent
o L1,...,LN a list of boolean values
7.2.4. Definition
Given a Type P packet sent by the source Src at T and the N hosts, Given a Type P packet sent by the source Src at T and the N hosts,
Recv1,...,RecvN, which should receive the packet at T1,...,Tn, a Recv1,...,RecvN, the Type-P-One-to-group-Packet-Loss-Vector is
Type-P-One-to-group-One-way-Packet-Loss-Vector is defined as a set of defined as a set of the Type-P-One-way-Packet-Loss singletons between
the Type-P-One-way-Packet-Loss singleton between Src and each of the Src and each of the receivers
receivers {<T1,0|1>,<T2,0|1>,..., <Tn,0|1>}.
6.3. A Definition for One-to-group One-way Ipdv {T, <L1=0|1>,<L2=0|1>,..., <LN=0|1>},
6.3.1. Metric Name where the boolean value 0|1 depends on receiving the packet at a
particular receiver within a loss threshold time.
Type-P-One-to-group-One-way-ipdv-Vector 7.3. A Definition for One-to-group ipdv
6.3.2. Metric Parameters 7.3.1. Metric Name
Type-P-One-to-group-ipdv-Vector
7.3.2. Metric Parameters
o Src, the IP address of a host acting as the source. o Src, the IP address of a host acting as the source.
o Recv1,..., RecvN, the IP addresses of the N hosts acting as o Recv1,..., RecvN, the IP addresses of the N hosts acting as
receivers. receivers.
o T1, a time. o T1, a time.
o T2, a time. o T2, a time.
o ddT1, ...,ddTn, a list of time.
o P, the specification of the packet type. o ddT1, ...,ddTn, a list of times.
o F, a selection function defining unambiguously the two packets o Type-P, the specification of the packet type.
o F, a selection function non-ambiguously defining the two packets
from the stream selected for the metric. from the stream selected for the metric.
o Gr, the receiving group identifier. The parameter Gr is the o Gr, the receiving group identifier. The parameter Gr is the
multicast group address if the measured packets are transmitted multicast group address if the measured packets are transmitted
over IP multicast. This parameter is to differentiate the over IP multicast. This parameter is to differentiate the
measured traffic from other unicast and multicast traffic. It is measured traffic from other unicast and multicast traffic. It is
optional in the metric to avoid losing any generality, i.e. to OPTIONAL in the metric to avoid losing any generality, i.e. to
make the metric also applicable to unicast measurement where there make the metric also applicable to unicast measurement where there
is only one receiver. is only one receiver.
6.3.3. Metric Units 7.3.3. Metric Units
The value of a Type-P-One-to-group-One-way-ipdv-Vector is a set of The value of a Type-P-One-to-group-ipdv-Vector is a set of Type-P-
Type-P-One-way-ipdv singletons [RFC3393]. One-way-ipdv singletons [RFC3393].
6.3.4. Definition 7.3.4. Definition
Given a Type P packet stream, Type-P-One-to-group-One-way-ipdv-Vector Given a Type-P packet stream, Type-P-One-to-group-ipdv-Vector is
is defined for two packets from the source Src to the N hosts defined for two packets transferred from the source Src to the N
{Recv1,...,RecvN },which are selected by the selection function F, as hosts {Recv1,...,RecvN }, which are selected by the selection
the difference between the value of the Type-P-One-to-group-One-way- function F as the difference between the value of the Type-P-One-to-
Delay-Vector from Src to { Recv1,..., RecvN } at time T1 and the group-Delay-Vector from Src to { Recv1,..., RecvN } at time T1 and
value of the Type-P-One-to-group-One-way-Delay-Vector from Src to { the value of the Type-P-One-to-group-Delay-Vector from Src to {
Recv1,...,RecvN } at time T2. T1 is the wire-time at which Src sent Recv1,...,RecvN } at time T2. T1 is the wire-time at which Src sent
the first bit of the first packet, and T2 is the wire-time at which the first bit of the first packet, and T2 is the wire-time at which
Src sent the first bit of the second packet. This metric is derived Src sent the first bit of the second packet. This metric is derived
from the Type-P-One-to-group-One-way-Delay-Vector metric. from the Type-P-One-to-group-Delay-Vector metric.
Therefore, for a set of real number {ddT1,...,ddTn},Type-P-One-to- For a set of real numbers {ddT1,...,ddTn}, the Type-P-One-to-group-
group-One-way-ipdv-Vector from Src to { Recv1,...,RecvN } at T1, T2 ipdv-Vector from Src to { Recv1,...,RecvN } at T1, T2 is
is {ddT1,...,ddTn} means that Src sent two packets, the first at {ddT1,...,ddTn} means that Src sent two packets, the first at wire-
wire-time T1 (first bit), and the second at wire-time T2 (first bit) time T1 (first bit), and the second at wire-time T2 (first bit) and
and the packets were received by { Recv1,...,RecvN } at wire-time the packets were received by { Recv1,...,RecvN } at wire-time {dT1+
{dT1+T1,...,dTn+T1}(last bit of the first packet), and at wire-time T1,...,dTn+T1}(last bit of the first packet), and at wire-time {dT'1+
{dT'1+T2,...,dT'n+T2} (last bit of the second packet), and that T2,...,dT'n+T2} (last bit of the second packet), and that {dT'1-
{dT'1-dT1,...,dT'n-dTn} ={ddT1,...,ddTn}. dT1,...,dT'n-dTn} ={ddT1,...,ddTn}.
7. One-to-Group Sample Statistics For any pair of selected packets, the difference dT'n-dTn is
undefined if:
o the delay dTn to Receiver n is undefined, OR
o the delay dT'n to Receiver n is undefined.
The defined one-to-group metrics above can all be directly achieved 8. One-to-group Sample Statistics
from the relevant unicast one-way metrics. They collect all unicast
measurement results of one-way metrics together in one profile and The one-to-group metrics defined above are directly achieved by
sort them by receivers and packets in a receiving group. They collecting relevant unicast one-way metrics measurements results and
provide sufficient information regarding the network performance in by gathering them per group of receivers. They produce network
terms of each receiver and guide engineers to identify potential performance information which guides engineers toward potential
problem happened on each branch of a multicast routing tree. problems which may have happened on any branch of a multicast routing
However, these metrics cannot be directly used to conveniently tree.
present the performance in terms of a group and neither to identify
the relative performance situation. The results of these metrics are not directly usable to present the
performance of a group because each result is made of a huge number
of singletons which are difficult to read and analyze. As an
example, delay are not comparable because the distance between
receiver and sender differs. Furthermore they don't capture relative
performance situation a multiparty communication.
From the performance point of view, the multiparty communication From the performance point of view, the multiparty communication
services not only require the absolute performance support but also services not only require the support of absolute performance
the relative performance. The relative performance means the information but also information on "relative performance". The
difference between absolute performance of all users. Directly using relative performance means the difference between absolute
the one-way metrics cannot present the relative performance performance of all users. Directly using the one-way metrics cannot
situation. However, if we use the variations of all users one-way present the relative performance situation. However, if we use the
parameters, we can have new metrics to measure the difference of the variations of all users one-way parameters, we can have new metrics
absolute performance and hence provide the threshold value of to measure the difference of the absolute performance and hence
relative performance that a multiparty service might demand. A very provide the threshold value of relative performance that a multiparty
good example of the high relative performance requirement is the service might demand. A very good example of the high relative
online gaming. A very light difference in delay might result in performance requirement is the online gaming. A very light
failure in the game. We have to use multicast specific statistic difference in delay might result in failure in the game. We have to
metrics to define exactly how small the relative delay the online use multicast specific statistic metrics to define exactly how small
gaming requires. There are many other services, e.g. online biding, the relative delay the online gaming requires. There are many other
online stock market, etc., that require multicast metrics in order to services, e.g. online biding, online stock market, etc., that require
evaluate the network against their requirements. Therefore, we can multicast metrics in order to evaluate the network against their
see the importance of new, multicast specific, statistic metrics to requirements. Therefore, we can see the importance of new, multicast
feed this need. specific, statistic metrics to feed this need.
We might also use some one-to-group statistic conceptions to present We might also use some one-to-group statistic conceptions to present
and report the group performance and relative performance to save the and report the group performance and relative performance to save the
report transmission bandwidth. Statistics have been defined for One- report transmission bandwidth. Statistics have been defined for One-
way metrics in corresponding RFCs. They provide the foundation of way metrics in corresponding RFCs. They provide the foundation of
definition for performance statistics. For instance, there are definition for performance statistics. For instance, there are
definitions for minimum and maximum One-way delay in [RFC2679]. definitions for minimum and maximum One-way delay in [RFC2679].
However, there is a dramatic difference between the statistics for However, there is a dramatic difference between the statistics for
one-to-one communications and for one-to-many communications. The one-to-one communications and for one-to-many communications. The
former one only has statistics over the time dimension while the former one only has statistics over the time dimension while the
skipping to change at page 28, line 31 skipping to change at page 29, line 26
which dimension a 2-level statistic is calculated first, the results which dimension a 2-level statistic is calculated first, the results
are the same. I.e. one can calculate the 2-level delay mean using are the same. I.e. one can calculate the 2-level delay mean using
the Matrix M by having the 1-level delay mean over the time dimension the Matrix M by having the 1-level delay mean over the time dimension
first and then calculate the mean of the obtained vector to find out first and then calculate the mean of the obtained vector to find out
the 2-level delay mean. Or, he can do the 1-level statistic the 2-level delay mean. Or, he can do the 1-level statistic
calculation over the space dimension first and then have the 2-level calculation over the space dimension first and then have the 2-level
delay mean. Both two results will be exactly the same. Therefore, delay mean. Both two results will be exactly the same. Therefore,
when define a 2-level statistic, there is no need to specify in which when define a 2-level statistic, there is no need to specify in which
procedure the calculation should follow. procedure the calculation should follow.
Comment: The above statement depends on whether the order of
operations has any affect on the outcome.
Many statistics can be defined for the proposed one-to-group metrics Many statistics can be defined for the proposed one-to-group metrics
over either the space dimension or the time dimension or both. This over either the space dimension or the time dimension or both. This
memo treats the case where a stream of packets from the Source memo treats the case where a stream of packets from the Source
results in a sample at each of the Receivers in the Group, and these results in a sample at each of the Receivers in the Group, and these
samples are each summarized with the usual statistics employed in samples are each summarized with the usual statistics employed in
one-to-one communication. New statistic definitions are presented, one-to-one communication. New statistic definitions are presented,
which summarize the one-to-one statistics over all the Receivers in which summarize the one-to-one statistics over all the Receivers in
the Group. the Group.
7.1. Discussion on the Impact of packet loss on statistics 8.1. Discussion on the Impact of packet loss on statistics
The packet loss does have effects on one-way metrics and their The packet loss does have effects on one-way metrics and their
statistics. For example, the lost packet can result an infinite one- statistics. For example, the lost packet can result in an infinite
way delay. It is easy to handle the problem by simply ignoring the one-way delay. It is easy to handle the problem by simply ignoring
infinite value in the metrics and in the calculation of the the infinite value in the metrics and in the calculation of the
corresponding statistics. However, the packet loss has so strong corresponding statistics. However, the packet loss has so strong
impact on the statistics calculation for the one-to-group metrics impact on the statistics calculation for the one-to-group metrics
that it can not be solved by the same method used for one-way that it can not be solved by the same method used for one-way
metrics. This is due to the complex of building a Matrix, which is metrics. This is due to the complexity of building a matrix, which
needed for calculation of the statistics proposed in this memo. is needed for calculation of the statistics proposed in this memo.
The situation is that measurement results obtained by different end The situation is that measurement results obtained by different end
users might have different packet loss pattern. For example, for users might have different packet loss pattern. For example, for
User1, packet A was observed lost. And for User2, packet A was User1, packet A was observed lost. And for User2, packet A was
successfully received but packet B was lost. If the method to successfully received but packet B was lost. If the method to
overcome the packet loss for one-way metrics is applied, the two overcome the packet loss for one-way metrics is applied, the two
singleton sets reported by User1 and User2 will be different in terms singleton sets reported by User1 and User2 will be different in terms
of the transmitted packets. Moreover, if User1 and User2 have of the transmitted packets. Moreover, if User1 and User2 have
different number of lost packets, the size of the results will be different number of lost packets, the size of the results will be
different. Therefore, for the centralized calculation, the reference different. Therefore, for the centralized calculation, the reference
skipping to change at page 29, line 41 skipping to change at page 30, line 33
different "weight" to present the group performance, which is different "weight" to present the group performance, which is
especially true for delay and ipdv relevant metrics. For example, especially true for delay and ipdv relevant metrics. For example,
User1 calculates the Type-P-Finite-One-way-Delay-Mean R1DM as shown User1 calculates the Type-P-Finite-One-way-Delay-Mean R1DM as shown
in Figure. 8 without any packet loss and User2 calculates the R2DM in Figure. 8 without any packet loss and User2 calculates the R2DM
with N-2 packet loss. The R1DM and R2DM should not be treated with with N-2 packet loss. The R1DM and R2DM should not be treated with
equal weight because R2DM was calculated only based on 2 delay values equal weight because R2DM was calculated only based on 2 delay values
in the whole sample interval. One possible solution is to use a in the whole sample interval. One possible solution is to use a
weight factor to mark every statistic value sent by users and use weight factor to mark every statistic value sent by users and use
this factor for further statistic calculation. this factor for further statistic calculation.
7.2. General Metric Parameters 8.2. General Metric Parameters
o Src, the IP address of a host; o Src, the IP address of a host;
o G, the receiving group identifier; o G, the receiving group identifier;
o N, the number of Receivers (Recv1, Recv2, ... RecvN); o N, the number of Receivers (Recv1, Recv2, ... RecvN);
o T, a time (start of test interval); o T, a time (start of test interval);
o Tf, a time (end of test interval); o Tf, a time (end of test interval);
o K, the number of packets sent from the source during the test o K, the number of packets sent from the source during the test
interval; interval;
o J[n], the number of packets received at a particular Receiver, n, o J[n], the number of packets received at a particular Receiver, n,
where 1<=n<=N; where 1<=n<=N;
skipping to change at page 30, line 26 skipping to change at page 31, line 18
o Tmax, a maximum waiting time for packets at the destination, set o Tmax, a maximum waiting time for packets at the destination, set
sufficiently long to disambiguate packets with long delays from sufficiently long to disambiguate packets with long delays from
packets that are discarded (lost), thus the distribution of delay packets that are discarded (lost), thus the distribution of delay
is not truncated; is not truncated;
o dT, shorthand notation for a one-way delay singleton value; o dT, shorthand notation for a one-way delay singleton value;
o L, shorthand notation for a one-way loss singleton value, either o L, shorthand notation for a one-way loss singleton value, either
zero or one, where L=1 indicates loss and L=0 indicates arrival at zero or one, where L=1 indicates loss and L=0 indicates arrival at
the destination within TstampSrc + Tmax, may be indexed over n the destination within TstampSrc + Tmax, may be indexed over n
Receivers; Receivers;
o DV, shorthand notation for a one-way delay variation singleton o DV, shorthand notation for a one-way delay variation singleton
value; value.
7.3. One-to-Group one-way Delay Statistics 8.3. One-to-group Delay Statistics
This section defines the overall one-way delay statistics for a This section defines the overall one-way delay statistics for a
receiver and for an entire group as illustrated by the matrix below. receiver and for an entire group as illustrated by the matrix below.
Recv /----------- Sample -------------\ Stats Group Stat Recv /----------- Sample -------------\ Stats Group Stat
1 R1dT1 R1dT2 R1dT3 ... R1dTk R1DM \ 1 R1dT1 R1dT2 R1dT3 ... R1dTk R1MD \
| |
2 R2dT1 R2dT2 R2dT3 ... R2dTk R2DM | 2 R2dT1 R2dT2 R2dT3 ... R2dTk R2MD |
| |
3 R3dT1 R3dT2 R3dT3 ... R3dTk R2DM > Group delay 3 R3dT1 R3dT2 R3dT3 ... R3dTk R2MD > Group delay
. | . |
. | . |
. | . |
n RndT1 RndT2 RndT3 ... RndTk RnDM / n RndT1 RndT2 RndT3 ... RndTk RnMD /
Receiver-n Receiver-n
delay delay
Figure 5: One-to-Group Mean Delay Figure 5: One-to-group Mean Delay
Statistics are computed on the finite One-way delays of the matrix Statistics are computed on the finite One-way delays of the matrix
above. above.
All One-to-group delay statistics are expressed in seconds with All One-to-group delay statistics are expressed in seconds with
sufficient resolution to convey 3 significant digits. sufficient resolution to convey 3 significant digits.
7.3.1. Type-P-One-to-Group-Receiver-n-Mean-Delay 8.3.1. Type-P-One-to-group-Receiver-n-Mean-Delay
This section defines Type-P-One-to-Group-Receiver-n-Mean-Delay the This section defines Type-P-One-to-group-Receiver-n-Mean-Delay the
Delay Mean at each Receiver N, also named RnDM. Delay Mean at each Receiver N, also named RnDM.
We obtain the value of Type-P-One-way-Delay singleton for all packets We obtain the value of Type-P-One-way-Delay singleton for all packets
sent during the test interval at each Receiver (Destination), as per sent during the test interval at each Receiver (Destination), as per
[RFC2679]. For each packet that arrives within Tmax of its sending [RFC2679]. For each packet that arrives within Tmax of its sending
time, TstampSrc, the one-way delay singleton (dT) will be the finite time, TstampSrc, the one-way delay singleton (dT) will be the finite
value TstampRecv[i] - TstampSrc[i] in units of seconds. Otherwise, value TstampRecv[i] - TstampSrc[i] in units of seconds. Otherwise,
the value of the singleton is Undefined. the value of the singleton is Undefined.
J[n] J[n]
--- ---
1 \ 1 \
RnDM = --- * > TstampRecv[i] - TstampSrc[i] RnMD = --- * > TstampRecv[i] - TstampSrc[i]
J[n] / J[n] /
--- ---
i = 1 i = 1
Figure 6: Type-P-One-to-Group-Receiver-Mean-Delay Figure 6: Type-P-One-to-group-Receiver-N-Mean-Delay
where all packets i= 1 through J[n] have finite singleton delays. where all packets i= 1 through J[n] have finite singleton delays.
7.3.2. Type-P-One-to-Group-Mean-Delay 8.3.2. Type-P-One-to-group-Mean-Delay
This section defines Type-P-One-to-Group-Mean-Delay, the Mean One-way This section defines Type-P-One-to-group-Mean-Delay, the Mean One-way
delay calculated over the entire Group, also named GMD. delay calculated over the entire Group, also named GMD.
N N
--- ---
1 \ 1 \
GMD = - * > RnDM GMD = - * > RnDM
N / N /
--- ---
n = 1 n = 1
Figure 7: Type-P-One-to-Group-Mean-Delay Figure 7: Type-P-One-to-group-Mean-Delay
Note that the Group Mean Delay can also be calculated by summing the Note that the Group Mean Delay can also be calculated by summing the
Finite one-way Delay singletons in the Matrix, and dividing by the Finite one-way Delay singletons in the Matrix, and dividing by the
number of Finite One-way Delay singletons. number of Finite One-way Delay singletons.
7.3.3. Type-P-One-to-Group-Range-Mean-Delay 8.3.3. Type-P-One-to-group-Range-Mean-Delay
This section defines a metric for the range of mean delays over all N This section defines a metric for the range of mean delays over all N
receivers in the Group, (R1DM, R2DM,...RnDM). receivers in the group (R1DM, R2DM,...RnDM).
Type-P-One-to-Group-Range-Mean-Delay = GRMD = max(RnDM) - min(RnDM) Type-P-One-to-group-Range-Mean-Delay = GRMD = max(RnDM) - min(RnDM)
7.3.4. Type-P-One-to-Group-Max-Mean-Delay 8.3.4. Type-P-One-to-group-Max-Mean-Delay
This section defines a metric for the maximum of mean delays over all This section defines a metric for the maximum of mean delays over all
N receivers in the Group, (R1DM, R2DM,...RnDM). N receivers in the group (R1DM, R2DM,...RnDM).
Type-P-One-to-Group-Max-Mean-Delay = GMMD = max(RnDM) Type-P-One-to-group-Max-Mean-Delay = GMMD = max(RnDM)
7.4. One-to-Group one-way Loss Statistics 8.4. One-to-group Packet Loss Statistics
This section defines the overall one-way loss statistics for a This section defines the overall one-way loss statistics for a
receiver and for an entire group as illustrated by the matrix below. receiver and for an entire group as illustrated by the matrix below.
Recv /----------- Sample ----------\ Stats Group Stat Recv /----------- Sample ----------\ Stats Group Stat
1 R1L1 R1L2 R1L3 ... R1Lk R1LR \ 1 R1L1 R1L2 R1L3 ... R1Lk R1LR \
| |
2 R2L1 R2L2 R2L3 ... R2Lk R2LR | 2 R2L1 R2L2 R2L3 ... R2Lk R2LR |
| |
3 R3L1 R3L2 R3L3 ... R3Lk R3LR > Group Loss Ratio 3 R3L1 R3L2 R3L3 ... R3Lk R3LR > Group Loss Ratio
. | . |
. | . |
. | . |
n RnL1 RnL2 RnL3 ... RnLk RnLR / n RnL1 RnL2 RnL3 ... RnLk RnLR /
Receiver-n Receiver-n
Loss Ratio Loss Ratio
Figure 8: One-to-Group Loss Ratio Figure 8: One-to-group Loss Ratio
Statistics are computed on the sample of Type-P-One-way-Packet-Loss Statistics are computed on the sample of Type-P-One-way-Packet-Loss
[RFC2680] of the matrix above. [RFC2680] of the matrix above.
All loss ratios are expressed in units of packets lost to total All loss ratios are expressed in units of packets lost to total
packets sent. packets sent.
7.4.1. Type-P-One-to-Group-Receiver-n-Loss-Ratio 8.4.1. Type-P-One-to-group-Receiver-n-Loss-Ratio
Given a Matrix of loss singletons as illustrated above, determine the Given a Matrix of loss singletons as illustrated above, determine the
Type-P-One-way-Packet-Loss-Average for the sample at each receiver, Type-P-One-way-Packet-Loss-Average for the sample at each receiver,
according to the definitions and method of [RFC2680]. The Type-P- according to the definitions and method of [RFC2680]. The Type-P-
One-way-Packet-Loss-Average and the Type-P-One-to-Group-Receiver-n- One-way-Packet-Loss-Average and the Type-P-One-to-group-Receiver-n-
Loss-Ratio, also named RnLR, are equivalent metrics. In terms of the Loss-Ratio, also named RnLR, are equivalent metrics. In terms of the
parameters used here, these metrics definitions can be expressed as parameters used here, these metrics definitions can be expressed as
K K
--- ---
1 \ 1 \
RnLR = - * > RnLk RnLR = - * > RnLk
K / K /
--- ---
k = 1 k = 1
Figure 9: Type-P-One-to-Group-Receiver-n-Loss-Ratio Figure 9: Type-P-One-to-group-Receiver-n-Loss-Ratio
7.4.2. Type-P-One-to-Group-Receiver-n-Comp-Loss-Ratio 8.4.2. Type-P-One-to-group-Receiver-n-Comp-Loss-Ratio
Usually, the number of packets sent is used in the denominator of Usually, the number of packets sent is used in the denominator of
packet loss ratio metrics. For the comparative metrics defined here, packet loss ratio metrics. For the comparative metrics defined here,
the denominator is the maximum number of packets received at any the denominator is the maximum number of packets received at any
receiver for the sample and test interval of interest. receiver for the sample and test interval of interest.
The Comparative Loss Ratio, also named, RnCLR, is defined as The Comparative Loss Ratio, also named, RnCLR, is defined as
K K
--- ---
skipping to change at page 33, line 42 skipping to change at page 34, line 39
k=1 k=1
RnCLR = ----------------------------- RnCLR = -----------------------------
/ K \ / K \
| --- | | --- |
| \ | | \ |
K - Min | > Ln(k) | K - Min | > Ln(k) |
| / | | / |
| --- | | --- |
\ k=1 / N \ k=1 / N
Figure 10: Type-P-One-to-Group-Receiver-n-Comp-Loss-Ratio Figure 10: Type-P-One-to-group-Receiver-n-Comp-Loss-Ratio
7.4.3. Type-P-One-to-Group-Loss-Ratio 8.4.3. Type-P-One-to-group-Loss-Ratio
Type-P-One-to-Group-Loss-Ratio, the overall Group loss ratio, also Type-P-One-to-group-Loss-Ratio, the overall Group loss ratio, also
named GLR, is defined as named GLR, is defined as
K,N K,N
--- ---
1 \ 1 \
GLR = --- * > L(k,n) GLR = --- * > L(k,n)
K*N / K*N /
--- ---
k,n = 1 k,n = 1
Figure 11: Type-P-One-to-Group-Loss-Ratio Figure 11: Type-P-One-to-group-Loss-Ratio
7.4.4. Type-P-One-to-Group-Range-Loss-Ratio 8.4.4. Type-P-One-to-group-Range-Loss-Ratio
The One-to-Group Loss Ratio Range is defined as: The One-to-group Loss Ratio Range is defined as:
Type-P-One-to-Group-Range-Loss-Ratio = max(RnLR) - min(RnLR) Type-P-One-to-group-Range-Loss-Ratio = max(RnLR) - min(RnLR)
It is most effective to indicate the range by giving both the max and It is most effective to indicate the range by giving both the max and
minimum loss ratios for the Group, rather than only reporting the minimum loss ratios for the Group, rather than only reporting the
difference between them. difference between them.
7.5. One-to-Group one-way Delay Variation Statistics 8.5. One-to-group Delay Variation Statistics
This section defines one-way delay variation (DV) statistics for an This section defines one-way delay variation (DV) statistics for an
entire group as illustrated by the matrix below. entire group as illustrated by the matrix below.
Recv /------------- Sample --------------\ Stats Recv /------------- Sample --------------\ Stats
1 R1ddT1 R1ddT2 R1ddT3 ... R1ddTk R1DV \ 1 R1ddT1 R1ddT2 R1ddT3 ... R1ddTk R1DV \
| |
2 R2ddT1 R2ddT2 R2ddT3 ... R2ddTk R2DV | 2 R2ddT1 R2ddT2 R2ddT3 ... R2ddTk R2DV |
| |
3 R3ddT1 R3ddT2 R3ddT3 ... R3ddTk R3DV > Group Stat 3 R3ddT1 R3ddT2 R3ddT3 ... R3ddTk R3DV > Group Stat
. | . |
. | . |
. | . |
n RnddT1 RnddT2 RnddT3 ... RnddTk RnDV / n RnddT1 RnddT2 RnddT3 ... RnddTk RnDV /
Figure 12: One-to-Group Delay Variation Matrix (DVMa) Figure 12: One-to-group Delay Variation Matrix (DVMa)
Statistics are computed on the sample of Type-P-One-way-Delay- Statistics are computed on the sample of Type-P-One-way-Delay-
Variation singletons of the group delay variation matrix above where Variation singletons of the group delay variation matrix above where
RnddTk is the Type-P-One-way-Delay-Variation singleton evaluated at RnddTk is the Type-P-One-way-Delay-Variation singleton evaluated at
Receiver n for the packet k and where RnDV is the point-to-point one- Receiver n for the packet k and where RnDV is the point-to-point one-
way packet delay variation for Receiver n. way packet delay variation for Receiver n.
All One-to-group delay variation statistics are expressed in seconds All One-to-group delay variation statistics are expressed in seconds
with sufficient resolution to convey 3 significant digits. with sufficient resolution to convey 3 significant digits.
7.5.1. Type-P-One-to-Group-Delay-Variation-Range 8.5.1. Type-P-One-to-group-Range-Delay-Variation
This section defines a metric for the range of delays variation over This section defines a metric for the range of delays variation over
all N receivers in the Group. all N receivers in the Group.
Maximum DV and minimum DV over all receivers summarize the Maximum DV and minimum DV over all receivers summarize the
performance over the Group (where DV is a point-to-point metric). performance over the Group (where DV is a point-to-point metric).
For each receiver, the DV is usually expressed as the 1-10^(-3) For each receiver, the DV is usually expressed as the 1-10^(-3)
quantile of one-way delay minus the minimum one-way delay. quantile of one-way delay minus the minimum one-way delay.
Type-P-One-to-Group-Delay-Variation-Range = GDVR = Type-P-One-to-group-Range-Delay-Variation = GRDV =
= max(RnDV) - min(RnDV) for all n receivers = max(RnDV) - min(RnDV) for all n receivers
This range is determined from the minimum and maximum values of the This range is determined from the minimum and maximum values of the
point-to-point one-way IP Packet Delay Variation for the set of point-to-point one-way IP Packet Delay Variation for the set of
Destinations in the group and a population of interest, using the Destinations in the group and a population of interest, using the
Packet Delay Variation expressed as the 1-10^-3 quantile of one-way Packet Delay Variation expressed as the 1-10^-3 quantile of one-way
delay minus the minimum one-way delay. If a more demanding service delay minus the minimum one-way delay. If a more demanding service
is considered, one alternative is to use the 1-10^-5 quantile, and in is considered, one alternative is to use the 1-10^-5 quantile, and in
either case the quantile used should be recorded with the results. either case the quantile used should be recorded with the results.
Both the minimum and the maximum delay variation are recorded, and Both the minimum and the maximum delay variation are recorded, and
both values are given to indicate the location of the range. both values are given to indicate the location of the range.
8. Measurement Methods: Scalability and Reporting 9. Measurement Methods: Scalability and Reporting
Virtually all the guidance on measurement processes supplied by the Virtually all the guidance on measurement processes supplied by the
earlier IPPM RFCs (such as [RFC2679] and [RFC2680]) for one-to-one earlier IPPM RFCs (such as [RFC2679] and [RFC2680]) for one-to-one
scenarios is applicable here in the spatial and multiparty scenarios is applicable here in the spatial and multiparty
measurement scenario. The main difference is that the spatial and measurement scenario. The main difference is that the spatial and
multiparty configurations require multiple points of interest where a multiparty configurations require multiple points of interest where a
stream of singletons will be collected. The amount of information stream of singletons will be collected. The amount of information
requiring storage grows with both the number of metrics and the requiring storage grows with both the number of metrics and the
points of interest, so the scale of the measurement architecture points of interest, so the scale of the measurement architecture
multiplies the number of singleton results that must be collected and multiplies the number of singleton results that must be collected and
skipping to change at page 36, line 12 skipping to change at page 37, line 12
architectures today, where even the individual singletons may not be architectures today, where even the individual singletons may not be
stored at each point of interest. stored at each point of interest.
In recognition of the likely need to minimize form of the results for In recognition of the likely need to minimize form of the results for
storage and communication, the Group metrics above have been storage and communication, the Group metrics above have been
constructed to allow some computations on a per-Receiver basis. This constructed to allow some computations on a per-Receiver basis. This
means that each Receiver's statistics would normally have an equal means that each Receiver's statistics would normally have an equal
weight with all other Receivers in the Group (regardless of the weight with all other Receivers in the Group (regardless of the
number of packets received). number of packets received).
8.1. Computation methods 9.1. Computation methods
The scalability issue can be raised when there are thousands of The scalability issue can be raised when there are thousands of
points of interest in a group who are trying to send back the points of interest in a group who are trying to send back the
measurement results to the reference point for further processing and measurement results to the reference point for further processing and
analysis. The points of interest can send either the whole measured analysis. The points of interest can send either the whole measured
sample or only the calculated statistics. The former one is a sample or only the calculated statistics. The former one is a
centralized statistic calculation method and the latter one is a centralized statistic calculation method and the latter one is a
distributed statistic calculation method. The sample should include distributed statistic calculation method. The sample should include
all metrics parameters, the values and the corresponding sequence all metrics parameters, the values and the corresponding sequence
numbers. The transmission of the whole sample can cost much more numbers. The transmission of the whole sample can cost much more
skipping to change at page 37, line 5 skipping to change at page 38, line 5
the reference point first to obtain the general information of the the reference point first to obtain the general information of the
group performance. If the detail results are required, the reference group performance. If the detail results are required, the reference
point should send the requests to the points of interest, which could point should send the requests to the points of interest, which could
be particular ones or the whole group. This procedure can happen in be particular ones or the whole group. This procedure can happen in
the off peak time and can be well scheduled to avoid delivery of too the off peak time and can be well scheduled to avoid delivery of too
many points of interest at the same time. Compression techniques can many points of interest at the same time. Compression techniques can
also be used to minimize the bandwidth required by the transmission. also be used to minimize the bandwidth required by the transmission.
This could be a measurement protocol to report the measurement This could be a measurement protocol to report the measurement
results. However, this is out of the scope of this memo. results. However, this is out of the scope of this memo.
8.2. Measurement 9.2. Measurement
To prevent any bias in the result, the configuration of a one-to-many To prevent any bias in the result, the configuration of a one-to-many
measure must take in consideration that implicitly more packets will measure must take in consideration that implicitly more packets will
to be routed than send and selects a test packets rate that will not to be routed than send and selects a test packets rate that will not
impact the network performance. impact the network performance.
8.3. Effect of Time and Space Aggregation Order on Stats 9.3. Effect of Time and Space Aggregation Order on Stats
This section presents the impact of the aggregation order on the This section presents the impact of the aggregation order on the
scalability of the reporting and of the computation. It makes the scalability of the reporting and of the computation. It makes the
hypothesis that receivers are managed remotely and not co-located. hypothesis that receivers are not co-located and that results are
gathered in a point of reference for further usages.
multimetrics samples represented a matrix as illustrated below Multimetrics samples are represented in a matrix as illustrated below
Point of Point of
interest interest
1 R1S1 R1S1 R1S1 ... R1Sk \ 1 R1S1 R1S1 R1S1 ... R1Sk \
| |
2 R2S1 R2S2 R2S3 ... R2Sk | 2 R2S1 R2S2 R2S3 ... R2Sk |
| |
3 R3S1 R3S2 R3S3 ... R3Sk > sample over space 3 R3S1 R3S2 R3S3 ... R3Sk > sample over space
. | . |
. | . |
skipping to change at page 37, line 40 skipping to change at page 38, line 41
n RnS1 RnS2 RnS3 ... RnSk / n RnS1 RnS2 RnS3 ... RnSk /
S1M S2M S3M ... SnM Stats over space S1M S2M S3M ... SnM Stats over space
\------------- ------------/ \------------- ------------/
\/ \/
Stat over space and time Stat over space and time
Figure 13: Impact of space aggregation on multimetrics Stat Figure 13: Impact of space aggregation on multimetrics Stat
2 methods are available to compute statistics on the resulting 2 methods are available to compute statistics on a matrix:
matrix: o Method 1: The statistic metric is computed over time and then over
o metric is computed over time and then over space; space;
o metric is computed over space and then over time. o Method 2: The statistic metric is computed over space and then
over time.
They differ only by the order of the time and of the space
aggregation. View as a matrix this order is neutral as does not
impact the result, but the impact on a measurement deployment is
critical.
In both cases the volume of data to report is proportional to the
number of probes. But there is a major difference between these 2
methods:
method2: In space and time aggregation mode the volume of data to These 2 methods differ only by the order of the aggregation. The
collect is proportional to the number of test packets received; order does not impact the computation resources required. It does
Each received packet RiSi triggers out a block of data that must not change the value of the result. However, it impacts severely the
be reported to a common place for computing the stat over space; minimal volume of data to report:
method1: In time and space aggregation mode the volume of data to
collect is proportional to the period of aggregation, so it does
not depend on the number of packet received;
Method 2 property has severe drawbacks in terms of security and o Method 1: Each point of interest computes periodically statistics
dimensioning: over time to lower the volume of data to report. They are
The increasing of the rate of the test packets may result in a reported to the reference point for computing the stat over space.
sort of DoS toward the computation points; This volume no longer depends on the number of samples. It is
The dimensioning of a measurement system is quite impossible to only proportional to the computation period;
validate. o Method 2: The volume of data to report is proportional to the
number of samples. Each sample, RiSi, must be reported to the
reference point for computing statistic over space and statistic
over time. The volume increases with the number of samples. It
is proportional to the number of test packets;
The time aggregation interval provides the reporting side with a Method 2 has severe drawbacks in terms of security and dimensioning:
control of various collecting aspects such as bandwidth and o Increasing the rate of the test packets may result in a Denial of
computation and storage capacities. So this draft defines metrics Service toward the points of reference;
based on method 1. o The dimensioning of a measurement system is quite impossible to
validate because any increase of the rate of the test packets will
increase the bandwidth requested to collect the raw results.
Note: In some specific cases one may need sample of singletons over The computation period over time period (commonly named aggregation
space. To address this need it is suggested firstly to limit the period) provides the reporting side with a control of various
number of test and the number of test packets per seconds. Then collecting aspects such as bandwidth, computation and storage
reducing the size of the sample over time to one packet give sample capacities. So this draft defines metrics based on method 1.
of singleton over space..
8.3.1. Impact on spatial statistics 9.3.1. Impact on spatial statistics
2 methods are available to compute spatial statistics: 2 methods are available to compute spatial statistics:
o method 1: spatial segment metrics and statistics are preferably o Method 1: spatial segment metrics and statistics are preferably
computed over time by each points of interest; computed over time by each points of interest;
o method 2: Vectors metrics are intrinsically instantaneous space o Method 2: Vectors metrics are intrinsically instantaneous space
metrics which must be reported using method2 whenever metrics which must be reported using method2 whenever
instantaneous metrics information is needed. instantaneous metrics information is needed.
8.3.2. Impact on one-to-group statistics 9.3.2. Impact on one-to-group statistics
2 methods are available to compute group statistics: 2 methods are available to compute group statistics:
o method1: Figure 5 andFigure 8 illustrate the method chosen: the o Method1: Figure 5 and Figure 8 illustrate the method chosen: the
one-to-one statistic is computed per interval of time before the one-to-one statistic is computed per interval of time before the
computation of the mean over the group of receivers; computation of the mean over the group of receivers;
o method2: Figure 13 presents the second one, metric is computed o Method2: Figure 13 presents the second one, metric is computed
over space and then over time. over space and then over time.
9. Manageability Considerations 10. Manageability Considerations
Usually IPPM WG documents defines each metric reporting within its Usually IPPM WG documents defines each metric reporting within its
definition. This document defines the reporting of all the metrics definition. This document defines the reporting of all the metrics
introduced in a single section to provide consistent information, to introduced in a single section to provide consistent information, to
avoid repetitions and to conform to IESG recommendation of gathering avoid repetitions and to conform to IESG recommendation of gathering
manageability considerations in a dedicated section. manageability considerations in a dedicated section.
Information models of spatial metrics and of one-to-group metrics are Information models of spatial metrics and of one-to-group metrics are
similar excepted that points of interests of spatial vectors must be similar excepted that points of interests of spatial vectors must be
ordered. ordered.
The complexity of the reporting relies on the number of points of The complexity of the reporting relies on the number of points of
interests. interests.
9.1. Reporting spatial metric 10.1. Reporting spatial metric
The reporting of spatial metrics shares a lot of aspects with The reporting of spatial metrics shares a lot of aspects with
RFC2679-80. New ones are common to all the definitions and are RFC2679-80. New ones are common to all the definitions and are
mostly related to the reporting of the path and of methodology mostly related to the reporting of the path and of methodology
parameters that may bias raw results analysis. This section presents parameters that may bias raw results analysis. This section presents
these specific parameters and then lists exhaustively the parameters these specific parameters and then lists exhaustively the parameters
that shall be reported. that shall be reported.
9.1.1. Path 10.1.1. Path
End-to-end metrics can't determine the path of the measure despite End-to-end metrics can't determine the path of the measure despite
IPPM RFCs recommend it to be reported (See Section 3.8.4 of IPPM RFCs recommend it to be reported (See Section 3.8.4 of
[RFC2679]). Spatial metrics vectors provide this path. The report [RFC2679]). Spatial metrics vectors provide this path. The report
of a spatial vector must include the points of interests involved: of a spatial vector must include the points of interests involved:
the sub set of the hosts of the path participating to the the sub set of the hosts of the path participating to the
instantaneous measure. instantaneous measure.
9.1.2. Host order 10.1.2. Host order
A spatial vector must order the points of interest according to their A spatial vector must order the points of interest according to their
order in the path. It is highly suggested to use the TTL in IPv4, order in the path. It is highly suggested to use the TTL in IPv4,
the Hop Limit in IPv6 or the corresponding information in MPLS. the Hop Limit in IPv6 or the corresponding information in MPLS.
The report of a spatial vector must include the ordered list of the The report of a spatial vector must include the ordered list of the
hosts involved in the instantaneous measure. hosts involved in the instantaneous measure.
9.1.3. Timestamping bias 10.1.3. Timestamping bias
The location of the point of interest inside a node influences the The location of the point of interest inside a node influences the
timestamping skew and accuracy. As an example, consider that some timestamping skew and accuracy. As an example, consider that some
internal machinery delays the timestamping up to 3 milliseconds then internal machinery delays the timestamping up to 3 milliseconds then
the minimal uncertainty reported be 3 ms if the internal delay is the minimal uncertainty reported be 3 ms if the internal delay is
unknown at the time of the timestamping. unknown at the time of the timestamping.
The report of a spatial vector must include the uncertainty of the The report of a spatial vector must include the uncertainty of the
timestamping compared to wire time. timestamping compared to wire time.
9.1.4. Reporting spatial One-way Delay 10.1.4. Reporting spatial One-way Delay
The reporting includes information to report for one-way-delay as the The reporting includes information to report for one-way-delay as the
Section 3.6 of [RFC2679]. The same apply for packet loss and ipdv. Section 3.6 of [RFC2679]. The same apply for packet loss and ipdv.
9.2. Reporting One-to-group metric 10.2. Reporting One-to-group metric
All reporting rules described in RFC2679-80 apply to the All reporting rules described in [RFC2679] and [RFC2680] apply to the
corresponding One-to-group metrics. Following are specific corresponding One-to-group metrics. Following are specific
parameters that should be reported. parameters that should be reported.
9.2.1. Path 10.2.1. Path
As suggested by the RFC2679-80, the path traversed by the packet As suggested by the [RFC2679] and [RFC2680] , the path traversed by
SHOULD be reported, if possible. For One-to-group metrics, there is the packet SHOULD be reported, if possible. For One-to-group
a path tree SHOULD be reported rather than A path. This is even more metrics, there is a path tree SHOULD be reported rather than A path.
impractical. If, by anyway, partial information is available to This is even more impractical. If, by anyway, partial information is
report, it might not be as valuable as it is in the one-to-one case available to report, it might not be as valuable as it is in the one-
because the incomplete path might be difficult to identify its to-one case because the incomplete path might be difficult to
position in the path tree. For example, how many points of interest identify its position in the path tree. For example, how many points
are reached by the packet traveled through this incomplete path? of interest are reached by the packet travelled through this
incomplete path?
9.2.2. Group size 10.2.2. Group size
The group size should be reported as one of the critical management The group size should be reported as one of the critical management
parameters. Unlike the spatial metrics, there is no need of order of parameters. Unlike the spatial metrics, there is no need of order of
points of interests. points of interests.
9.2.3. Timestamping bias 10.2.3. Timestamping bias
It is the same as described in section 9.1.3. It is the same as described in section 10.1.3.
9.2.4. Reporting One-to-group One-way Delay 10.2.4. Reporting One-to-group One-way Delay
It is the same as described in section 9.1.4. It is the same as described in section 10.1.4.
9.2.5. Measurement method 10.2.5. Measurement method
As explained in section 8, the measurement method will have impact on As explained in section 9, the measurement method will have impact on
the analysis of the measurement result. Therefore, it should be the analysis of the measurement result. Therefore, it should be
reported. reported.
9.3. Metric identification 10.3. Metric identification
IANA assigns each metric defined by the IPPM WG with a unique IANA assigns each metric defined by the IPPM WG with a unique
identifier as per [RFC4148] in the IANA-IPPM-METRICS-REGISTRY-MIB. identifier as per [RFC4148] in the IANA-IPPM-METRICS-REGISTRY-MIB.
9.4. Information model 10.4. Information model
This section presents the elements of information and the usage of This section presents the elements of information and the usage of
the information reported for network performance analysis. It is out the information reported for network performance analysis. It is out
of the scope of this section to define how the information is of the scope of this section to define how the information is
reported. reported.
The information model is build with pieces of information introduced The information model is build with pieces of information introduced
and explained in one-way delay definitions [RFC2679], in packet loss and explained in one-way delay definitions [RFC2679], in packet loss
definitions [RFC2680] and in IPDV definitions of [RFC3393] and definitions [RFC2680] and in IPDV definitions of [RFC3393] and
[RFC3432]. It includes not only information given by "Reporting the [RFC3432]. It includes not only information given by "Reporting the
skipping to change at page 43, line 12 skipping to change at page 44, line 12
Following is the information of each statistic that should be Following is the information of each statistic that should be
reported: reported:
o Result; o Result;
o Start_time; o Start_time;
o Duration; o Duration;
o Result_status; o Result_status;
o Singleton_number, the number of singletons the statistic is o Singleton_number, the number of singletons the statistic is
computed on; computed on;
10. Security Considerations 11. Security Considerations
Spatial and one-to-group metrics are defined on the top of end-to-end Spatial and one-to-group metrics are defined on the top of end-to-end
metrics. Security considerations discussed in One-way delay metrics metrics. Security considerations discussed in One-way delay metrics
definitions of [RFC2679] , in packet loss metrics definitions of definitions of [RFC2679] , in packet loss metrics definitions of
[RFC2680] and in IPDV metrics definitions of[RFC3393] and [RFC3432] [RFC2680] and in IPDV metrics definitions of[RFC3393] and [RFC3432]
apply to metrics defined in this memo. apply to metrics defined in this memo.
10.1. Spatial metrics 11.1. Spatial metrics
Malicious generation of packets with spoofing addresses may corrupt Malicious generation of packets with spoofing addresses may corrupt
the results without any possibility to detect the spoofing. the results without any possibility to detect the spoofing.
Malicious generation of packets which match systematically the hash Malicious generation of packets which match systematically the hash
function used to detect the packets may lead to a DoS attack toward function used to detect the packets may lead to a DoS attack toward
the point of reference. the point of reference.
10.2. one-to-group metric 11.2. One-to-group metrics
Reporting of measurement results from a huge number of probes may Reporting of measurement results from a huge number of probes may
overload reference point ressources (network, network interfaces, overload reference point resources (network, network interfaces,
computation capacities ...). computation capacities ...).
The configuration of a measurement must take in consideration that The configuration of a measurement must take in consideration that
implicitly more packets will to be routed than send and selects a implicitly more packets will to be routed than send and selects a
test packets rate accordingly. Collecting statistics from a huge test packets rate accordingly. Collecting statistics from a huge
number of probes may overload any combination of the network where number of probes may overload any combination of the network where
the measurement controller is attached to, measurement controller the measurement controller is attached to, measurement controller
network interfaces and measurement controller computation capacities. network interfaces and measurement controller computation capacities.
One-to-group metrics measurement should consider using source One-to-group metrics measurement should consider using source
authentication protocols, standardized in the MSEC group, to avoid authentication protocols, standardized in the MSEC group, to avoid
fraud packet in the sampling interval. The test packet rate could be fraud packet in the sampling interval. The test packet rate could be
negotiated before any measurement session to avoid deny of service negotiated before any measurement session to avoid deny of service
attacks. attacks.
11. Acknowledgments 12. Acknowledgments
Lei would like to acknowledge Prof. Zhili Sun from CCSR, University Lei would like to acknowledge Prof. Zhili Sun from CCSR, University
of Surrey, for his instruction and helpful comments on this work. of Surrey, for his instruction and helpful comments on this work.
12. IANA Considerations 13. IANA Considerations
Metrics defined in this memo Metrics defined in this memo are Metrics defined in this memo Metrics defined in this memo are
designed to be registered in the IANA IPPM METRICS REGISTRY as designed to be registered in the IANA IPPM METRICS REGISTRY as
described in initial version of the registry [RFC4148] : described in initial version of the registry [RFC4148] :
IANA is asked to register the following metrics in the IANA-IPPM- IANA is asked to register the following metrics in the IANA-IPPM-
METRICS-REGISTRY-MIB : METRICS-REGISTRY-MIB :
ietfSpatialOneWayDelayVector OBJECT-IDENTITY ietfSpatialOneWayDelayVector OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-Spatial-One-way-Delay-Vector" "Type-P-Spatial-One-way-Delay-Vector"
REFERENCE REFERENCE
"Reference "RFCyyyy, section 4.1." "Reference "RFCyyyy, section 5.1."
-- RFC Ed.: replace yyyy with actual RFC number & remove this -- RFC Ed.: replace yyyy with actual RFC number & remove this
note note
:= { ianaIppmMetrics nn } -- IANA assigns nn := { ianaIppmMetrics nn } -- IANA assigns nn
ietfSpatialPacketLossVector OBJECT-IDENTITY ietfSpatialPacketLossVector OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-Spatial-Packet-Loss-Vector" "Type-P-Spatial-Packet-Loss-Vector"
REFERENCE REFERENCE
"Reference "RFCyyyy, section 4.2." "Reference "RFCyyyy, section 5.2."
-- RFC Ed.: replace yyyy with actual RFC number & remove this -- RFC Ed.: replace yyyy with actual RFC number & remove this
note note
:= { ianaIppmMetrics nn } -- IANA assigns nn := { ianaIppmMetrics nn } -- IANA assigns nn
ietfSpatialOneWayIpdvVector OBJECT-IDENTITY ietfSpatialOneWayIpdvVector OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-Spatial-One-way-ipdv-Vector" "Type-P-Spatial-One-way-ipdv-Vector"
REFERENCE REFERENCE
"Reference "RFCyyyy, section 4.3." "Reference "RFCyyyy, section 5.3."
-- RFC Ed.: replace yyyy with actual RFC number & remove this -- RFC Ed.: replace yyyy with actual RFC number & remove this
note note
:= { ianaIppmMetrics nn } -- IANA assigns nn := { ianaIppmMetrics nn } -- IANA assigns nn
ietfSegmentOneWayDelayStream OBJECT-IDENTITY ietfSegmentOneWayDelayStream OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-Segment-One-way-Delay-Stream" "Type-P-Segment-One-way-Delay-Stream"
REFERENCE REFERENCE
"Reference "RFCyyyy, section 5.1." "Reference "RFCyyyy, section 6.1."
-- RFC Ed.: replace yyyy with actual RFC number & remove this -- RFC Ed.: replace yyyy with actual RFC number & remove this
note note
:= { ianaIppmMetrics nn } -- IANA assigns nn := { ianaIppmMetrics nn } -- IANA assigns nn
ietfSegmentPacketLossStream OBJECT-IDENTITY ietfSegmentPacketLossStream OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-Segment-Packet-Loss-Stream" "Type-P-Segment-Packet-Loss-Stream"
REFERENCE REFERENCE
"Reference "RFCyyyy, section 5.2." "Reference "RFCyyyy, section 6.2."
-- RFC Ed.: replace yyyy with actual RFC number & remove this -- RFC Ed.: replace yyyy with actual RFC number & remove this
note note
:= { ianaIppmMetrics nn } -- IANA assigns nn := { ianaIppmMetrics nn } -- IANA assigns nn
ietfSegmentOneWayIpdvPrevStream OBJECT-IDENTITY ietfSegmentIpdvPrevStream OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-Segment-One-way-ipdv-prev-Stream" "Type-P-Segment-ipdv-prev-Stream"
REFERENCE REFERENCE
"Reference "RFCyyyy, section 5.3." "Reference "RFCyyyy, section 6.3."
-- RFC Ed.: replace yyyy with actual RFC number & remove this -- RFC Ed.: replace yyyy with actual RFC number & remove this
note note
:= { ianaIppmMetrics nn } -- IANA assigns nn := { ianaIppmMetrics nn } -- IANA assigns nn
ietfSegmentOneWayIpdvMinStream OBJECT-IDENTITY ietfSegmentIpdvMinStream OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-Segment-One-way-ipdv-min-Stream" "Type-P-Segment-ipdv-min-Stream"
REFERENCE REFERENCE
"Reference "RFCyyyy, section 5.4." "Reference "RFCyyyy, section 6.4."
-- RFC Ed.: replace yyyy with actual RFC number & remove this -- RFC Ed.: replace yyyy with actual RFC number & remove this
note note
:= { ianaIppmMetrics nn } -- IANA assigns nn := { ianaIppmMetrics nn } -- IANA assigns nn
-- One-to-group metrics -- One-to-group metrics
ietfOneToGroupOneWayDelayVector OBJECT-IDENTITY ietfOneToGroupDelayVector OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-One-to-group-One-way-Delay-Vector" "Type-P-One-to-group-Delay-Vector"
REFERENCE REFERENCE
"Reference "RFCyyyy, section 6.1." "Reference "RFCyyyy, section 7.1."
-- RFC Ed.: replace yyyy with actual RFC number & remove this -- RFC Ed.: replace yyyy with actual RFC number & remove this
note note
:= { ianaIppmMetrics nn } -- IANA assigns nn := { ianaIppmMetrics nn } -- IANA assigns nn
ietfOneToGroupOneWayPktLossVector OBJECT-IDENTITY ietfOneToGroupPacketLossVector OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-One-to-Group-One-way-Packet-Loss-Vector" "Type-P-One-to-group-Packet-Loss-Vector"
REFERENCE REFERENCE
"Reference "RFCyyyy, section 6.2." "Reference "RFCyyyy, section 7.2."
-- RFC Ed.: replace yyyy with actual RFC number & remove this -- RFC Ed.: replace yyyy with actual RFC number & remove this
note note
:= { ianaIppmMetrics nn } -- IANA assigns nn := { ianaIppmMetrics nn } -- IANA assigns nn
ietfOneToGroupOneWayIpdvVector OBJECT-IDENTITY ietfOneToGroupIpdvVector OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-One-to-Group-One-way-ipdv-Vector" "Type-P-One-to-group-ipdv-Vector"
REFERENCE REFERENCE
"Reference "RFCyyyy, section 6.3." "Reference "RFCyyyy, section 7.3."
-- RFC Ed.: replace yyyy with actual RFC number & remove this -- RFC Ed.: replace yyyy with actual RFC number & remove this
note note
:= { ianaIppmMetrics nn } -- IANA assigns nn := { ianaIppmMetrics nn } -- IANA assigns nn
-- One to group statistics -- One to group statistics
-- --
ietfOnetoGroupReceiverNMeanDelay OBJECT-IDENTITY ietfOnetoGroupReceiverNMeanDelay OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-One-to-Group-Receiver-n-Mean-Delay" "Type-P-One-to-group-Receiver-n-Mean-Delay"
REFERENCE REFERENCE
"Reference "RFCyyyy, section 7.3.1." "Reference "RFCyyyy, section 8.3.1."
-- RFC Ed.: replace yyyy with actual RFC number & remove this -- RFC Ed.: replace yyyy with actual RFC number & remove this
note note
:= { ianaIppmMetrics nn } -- IANA assigns nn := { ianaIppmMetrics nn } -- IANA assigns nn
ietfOneToGroupMeanDelay OBJECT-IDENTITY ietfOneToGroupMeanDelay OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-One-to-Group-Mean-Delay" "Type-P-One-to-group-Mean-Delay"
REFERENCE REFERENCE
"Reference "RFCyyyy, section 7.3.2." "Reference "RFCyyyy, section 8.3.2."
-- RFC Ed.: replace yyyy with actual RFC number & remove this -- RFC Ed.: replace yyyy with actual RFC number & remove this
note note
:= { ianaIppmMetrics nn } -- IANA assigns nn := { ianaIppmMetrics nn } -- IANA assigns nn
ietfOneToGroupRangeMeanDelay OBJECT-IDENTITY ietfOneToGroupRangeMeanDelay OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-One-to-Group-Range-Mean-Delay" "Type-P-One-to-group-Range-Mean-Delay"
REFERENCE REFERENCE
"Reference "RFCyyyy, section 7.3.3." "Reference "RFCyyyy, section 8.3.3."
-- RFC Ed.: replace yyyy with actual RFC number & remove this -- RFC Ed.: replace yyyy with actual RFC number & remove this
note note
:= { ianaIppmMetrics nn } -- IANA assigns nn := { ianaIppmMetrics nn } -- IANA assigns nn
ietfOneToGroupMaxMeanDelay OBJECT-IDENTITY ietfOneToGroupMaxMeanDelay OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-One-to-Group-Max-Mean-Delay" "Type-P-One-to-group-Max-Mean-Delay"
REFERENCE REFERENCE
"Reference "RFCyyyy, section 7.3.4." "Reference "RFCyyyy, section 8.3.4."
-- RFC Ed.: replace yyyy with actual RFC number & remove this -- RFC Ed.: replace yyyy with actual RFC number & remove this
note note
:= { ianaIppmMetrics nn } -- IANA assigns nn := { ianaIppmMetrics nn } -- IANA assigns nn
ietfOneToGroupReceiverNLossRatio OBJECT-IDENTITY ietfOneToGroupReceiverNLossRatio OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-One-to-Group-Receiver-n-Loss-Ratio" "Type-P-One-to-group-Receiver-n-Loss-Ratio"
REFERENCE REFERENCE
"Reference "RFCyyyy, section 7.4.1." "Reference "RFCyyyy, section 8.4.1."
-- RFC Ed.: replace yyyy with actual RFC number & remove this -- RFC Ed.: replace yyyy with actual RFC number & remove this
note note
:= { ianaIppmMetrics nn } -- IANA assigns nn := { ianaIppmMetrics nn } -- IANA assigns nn
-- --
ietfOneToGroupReceiverNCompLossRatio OBJECT-IDENTITY ietfOneToGroupReceiverNCompLossRatio OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-One-to-Group-Receiver-n-Comp-Loss-Ratio" "Type-P-One-to-group-Receiver-n-Comp-Loss-Ratio"
REFERENCE REFERENCE
"Reference "RFCyyyy, section 7.4.2." "Reference "RFCyyyy, section 8.4.2."
-- RFC Ed.: replace yyyy with actual RFC number & remove this -- RFC Ed.: replace yyyy with actual RFC number & remove this
note note
:= { ianaIppmMetrics nn } -- IANA assigns nn := { ianaIppmMetrics nn } -- IANA assigns nn
ietfOneToGroupLossRatio OBJECT-IDENTITY ietfOneToGroupLossRatio OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-One-to-Group-Loss-Ratio" "Type-P-One-to-group-Loss-Ratio"
REFERENCE REFERENCE
"Reference "RFCyyyy, section 7.4.3." "Reference "RFCyyyy, section 8.4.3."
-- RFC Ed.: replace yyyy with actual RFC number & remove this -- RFC Ed.: replace yyyy with actual RFC number & remove this
note note
:= { ianaIppmMetrics nn } -- IANA assigns nn := { ianaIppmMetrics nn } -- IANA assigns nn
-- --
ietfOneToGroupRangeLossRatio OBJECT-IDENTITY ietfOneToGroupRangeLossRatio OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-One-to-Group-Range-Loss-Ratio" "Type-P-One-to-group-Range-Loss-Ratio"
REFERENCE REFERENCE
"Reference "RFCyyyy, section 7.4.4." "Reference "RFCyyyy, section 8.4.4."
-- RFC Ed.: replace yyyy with actual RFC number & remove this -- RFC Ed.: replace yyyy with actual RFC number & remove this
note note
:= { ianaIppmMetrics nn } -- IANA assigns nn := { ianaIppmMetrics nn } -- IANA assigns nn
ietfOneToGroupRangeDelayVariation OBJECT-IDENTITY ietfOneToGroupRangeDelayVariation OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-One-to-Group-Range-Delay-Variation" "Type-P-One-to-group-Range-Delay-Variation"
REFERENCE REFERENCE
"Reference "RFCyyyy, section 7.5.1." "Reference "RFCyyyy, section 8.5.1."
-- RFC Ed.: replace yyyy with actual RFC number & remove this -- RFC Ed.: replace yyyy with actual RFC number & remove this
note note
:= { ianaIppmMetrics nn } -- IANA assigns nn := { ianaIppmMetrics nn } -- IANA assigns nn
-- --
13. References 14. References
13.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999. Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Packet Loss Metric for IPPM", RFC 2680, September 1999. Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393, Metric for IP Performance Metrics (IPPM)", RFC 3393,
November 2002. November 2002.
[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics
Registry", BCP 108, RFC 4148, August 2005. Registry", BCP 108, RFC 4148, August 2005.
13.2. Informative References 14.2. Informative References
[I-D.ietf-ippm-spatial-composition]
Morton, A. and E. Stephan, "Spatial Composition of
Metrics", draft-ietf-ippm-spatial-composition-07 (work in
progress), July 2008.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, "Framework for IP Performance Metrics", RFC 2330,
May 1998. May 1998.
[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network
performance measurement with periodic streams", RFC 3432, performance measurement with periodic streams", RFC 3432,
November 2002. November 2002.
Authors' Addresses Authors' Addresses
 End of changes. 350 change blocks. 
873 lines changed or deleted 901 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/