draft-ietf-ippm-multimetrics-06.txt   draft-ietf-ippm-multimetrics-07.txt 
Network Working Group E. Stephan Network Working Group E. Stephan
Internet-Draft France Telecom Internet-Draft France Telecom
Intended status: Informational L. Liang Intended status: Standards Track L. Liang
Expires: August 17, 2008 University of Surrey Expires: December 28, 2008 University of Surrey
A. Morton A. Morton
AT&T Labs AT&T Labs
February 14, 2008 June 26, 2008
IP Performance Metrics (IPPM) for spatial and multicast IP Performance Metrics (IPPM) for spatial and multicast
draft-ietf-ippm-multimetrics-06 draft-ietf-ippm-multimetrics-07
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 August 17, 2008. This Internet-Draft will expire on December 28, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
The IETF IP Performance Metrics (IPPM) working group has standardized The IETF IP Performance Metrics (IPPM) working group has standardized
metrics for measuring end-to-end performance between two points. metrics for measuring end-to-end performance between two points.
This memo defines two new categories of metrics that extend the This memo defines two new categories of metrics that extend the
coverage to multiple measurement points. It defines spatial metrics coverage to multiple measurement points. It defines spatial metrics
for measuring the performance of segments of a source to destination for measuring the performance of segments of a source to destination
path, and metrics for measuring the performance between a source and path, and metrics for measuring the performance between a source and
many destinations in multiparty communications (e.g., a multicast many destinations in multiparty communications (e.g., a multicast
tree). tree).
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Path Digest Hosts . . . . . . . . . . . . . . . . . . . . 6 2.1. Path Digest Hosts . . . . . . . . . . . . . . . . . . . . 6
2.2. Multiparty metric . . . . . . . . . . . . . . . . . . . . 6 2.2. Multiparty metric . . . . . . . . . . . . . . . . . . . . 6
2.3. Spatial metric . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Spatial metric . . . . . . . . . . . . . . . . . . . . . . 7
2.4. One-to-group metric . . . . . . . . . . . . . . . . . . . 6 2.4. One-to-group metric . . . . . . . . . . . . . . . . . . . 7
2.5. Points of interest . . . . . . . . . . . . . . . . . . . . 7 2.5. Points of interest . . . . . . . . . . . . . . . . . . . . 7
2.6. Reference point . . . . . . . . . . . . . . . . . . . . . 8 2.6. Reference point . . . . . . . . . . . . . . . . . . . . . 8
2.7. Vector . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.7. Vector . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.8. Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.8. Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Motivations for spatial metrics . . . . . . . . . . . . . 9 3.1. Motivations for spatial metrics . . . . . . . . . . . . . 9
3.2. Motivations for One-to-group metrics . . . . . . . . . . . 10 3.2. Motivations for One-to-group metrics . . . . . . . . . . . 10
3.3. Discussion on Group-to-one and Group-to-group metrics . . 11 3.3. Discussion on Group-to-one and Group-to-group metrics . . 11
4. Spatial vectors metrics definitions . . . . . . . . . . . . . 11 4. Spatial vectors metrics definitions . . . . . . . . . . . . . 11
4.1. A Definition for Spatial One-way Delay Vector . . . . . . 12 4.1. A Definition for Spatial One-way Delay Vector . . . . . . 12
4.2. A Definition for Spatial One-way Packet Loss Vector . . . 13 4.2. A Definition for Spatial One-way Packet Loss Vector . . . 13
4.3. A Definition for Spatial One-way Ipdv Vector . . . . . . . 15 4.3. A Definition for Spatial One-way Ipdv Vector . . . . . . . 14
4.4. Spatial Methodology . . . . . . . . . . . . . . . . . . . 16 4.4. Spatial Methodology . . . . . . . . . . . . . . . . . . . 16
5. Spatial Segments metrics definitions . . . . . . . . . . . . . 18 5. Spatial Segments metrics definitions . . . . . . . . . . . . . 17
5.1. A Definition of a sample of One-way Delay of a segment 5.1. A Definition of a sample of One-way Delay of a segment
of the path . . . . . . . . . . . . . . . . . . . . . . . 18 of the path . . . . . . . . . . . . . . . . . . . . . . . 18
5.2. A Definition of a sample of Packet Loss of a segment 5.2. A Definition of a sample of Packet Loss of a segment
of the path . . . . . . . . . . . . . . . . . . . . . . . 20 of the path . . . . . . . . . . . . . . . . . . . . . . . 19
5.3. A Definition of a sample of ipdv of a segment using 5.3. A Definition of a sample of ipdv of a segment using
the previous packet selection function . . . . . . . . . . 22 the previous packet selection function . . . . . . . . . . 20
5.4. A Definition of a sample of ipdv of a segment using 5.4. A Definition of a sample of ipdv of a segment using
the minimum delay selection function . . . . . . . . . . . 24 the minimum delay selection function . . . . . . . . . . . 22
6. One-to-group metrics definitions . . . . . . . . . . . . . . . 25 6. One-to-group metrics definitions . . . . . . . . . . . . . . . 23
6.1. A Definition for One-to-group One-way Delay . . . . . . . 26 6.1. A Definition for One-to-group One-way Delay . . . . . . . 23
6.2. A Definition for One-to-group One-way Packet Loss . . . . 26 6.2. A Definition for One-to-group One-way Packet Loss . . . . 24
6.3. A Definition for One-to-group One-way Ipdv . . . . . . . . 27 6.3. A Definition for One-to-group One-way Ipdv . . . . . . . . 25
7. One-to-Group Sample Statistics . . . . . . . . . . . . . . . . 28 7. One-to-Group Sample Statistics . . . . . . . . . . . . . . . . 26
7.1. Discussion on the Impact of packet loss on statistics . . 31 7.1. Discussion on the Impact of packet loss on statistics . . 28
7.2. General Metric Parameters . . . . . . . . . . . . . . . . 32 7.2. General Metric Parameters . . . . . . . . . . . . . . . . 29
7.3. One-to-Group one-way Delay Statistics . . . . . . . . . . 33 7.3. One-to-Group one-way Delay Statistics . . . . . . . . . . 30
7.4. One-to-Group one-way Loss Statistics . . . . . . . . . . . 36 7.4. One-to-Group one-way Loss Statistics . . . . . . . . . . . 32
7.5. One-to-Group one-way Delay Variation Statistics . . . . . 38 7.5. One-to-Group one-way Delay Variation Statistics . . . . . 34
8. Measurement Methods: Scalability and Reporting . . . . . . . . 38 8. Measurement Methods: Scalability and Reporting . . . . . . . . 35
8.1. Computation methods . . . . . . . . . . . . . . . . . . . 39 8.1. Computation methods . . . . . . . . . . . . . . . . . . . 36
8.2. Measurement . . . . . . . . . . . . . . . . . . . . . . . 40 8.2. Measurement . . . . . . . . . . . . . . . . . . . . . . . 37
8.3. Effect of Time and Space Aggregation Order on Stats . . . 40 8.3. Effect of Time and Space Aggregation Order on Stats . . . 37
9. Manageability Considerations . . . . . . . . . . . . . . . . . 42 9. Manageability Considerations . . . . . . . . . . . . . . . . . 38
9.1. Reporting spatial metric . . . . . . . . . . . . . . . . . 42 9.1. Reporting spatial metric . . . . . . . . . . . . . . . . . 39
9.2. Reporting One-to-group metric . . . . . . . . . . . . . . 43 9.2. Reporting One-to-group metric . . . . . . . . . . . . . . 40
9.3. Metric identification . . . . . . . . . . . . . . . . . . 44 9.3. Metric identification . . . . . . . . . . . . . . . . . . 40
9.4. Reporting data model . . . . . . . . . . . . . . . . . . . 44 9.4. Information model . . . . . . . . . . . . . . . . . . . . 41
10. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 47 10. Security Considerations . . . . . . . . . . . . . . . . . . . 43
11. Security Considerations . . . . . . . . . . . . . . . . . . . 47 10.1. Spatial metrics . . . . . . . . . . . . . . . . . . . . . 43
11.1. Spatial metrics . . . . . . . . . . . . . . . . . . . . . 48 10.2. one-to-group metric . . . . . . . . . . . . . . . . . . . 43
11.2. one-to-group metric . . . . . . . . . . . . . . . . . . . 48 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 13.1. Normative References . . . . . . . . . . . . . . . . . . . 48
14.1. Normative References . . . . . . . . . . . . . . . . . . . 54 13.2. Informative References . . . . . . . . . . . . . . . . . . 49
14.2. Informative References . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 Intellectual Property and Copyright Statements . . . . . . . . . . 50
Intellectual Property and Copyright Statements . . . . . . . . . . 57
1. Introduction 1. Introduction
The IP Performance Metrics (IPPM) WG has defined a framework for The IETF IP Performance Metrics (IPPM) working group has standardized
metric definitions and end-to-end, or source to destination metrics for measuring end-to-end performance between two points.
measurements: This memo defines two new categories of metrics that extend the
coverage to multiple measurement points. It defines spatial metrics
o A general framework for defining performance metrics, described in for measuring the performance of segments of a source to destination
the Framework for IP Performance Metrics [RFC2330]; path, and metrics for measuring the performance between a source and
many destinations in multiparty communications (e.g., a multicast
The Working Group has specified a set of end-to-end metrics using the tree).
framework, and a registry for the metrics:
o The IPPM Metrics for Measuring Connectivity [RFC2678];
o The One-way Delay Metric for IPPM [RFC2679];
o The One-way Packet Loss Metric for IPPM [RFC2680];
o The Round-trip Delay Metric for IPPM [RFC2681];
o A Framework for Defining Empirical Bulk Transfer Capacity Metrics
[RFC3148];
o One-way Loss Pattern Sample Metrics [RFC3357];
o IP Packet Delay Variation Metric for IPPM [RFC3393];
o Network performance measurement for periodic streams [RFC3432];
o Packet Reordering Metrics [RFC4737];
o An IP Performance Metrics Registry [RFC4148];
IPPM has also developed a protocol for one-way source to destination The purpose of the memo is to define metrics to fulfill the new
measurements requirements of measurement involving multiple measurement points.
Spatial metrics are defined to measure the performance of each
segments along a path while the one-to-group metrics are aiming to
provide a ruler to measure the performance of a group of users.
These metrics are derived from one-way end-to-end metrics defined by
IETF and follow the criteria described in the IPPM framework
[RFC2330].
o A One-way Active Measurement Protocol Requirements [RFC3763]; New terms are introduced to extend the terminology of the IPPM
framework to spatial metrics and one-to-group metrics. Then a
section motivates the need of defining each category of metrics.
After, each category is defined in a separate section. Then the memo
discusses the impact of the measurement methods on the scalability
and proposes an information model for reporting the measurements.
Finally the document discusses security aspects related to
measurement and registers the metrics in the IANA IP Performance
Metrics Registry [RFC4148].
o A One-way Active Measurement Protocol (OWAMP) [RFC4656]; Note that all these metrics are based on observations of packets
dedicated to testing, a process which is called Active measurement.
Purely passive spatial measurement (for example, a spatial metric
based on the observation of user traffic) is beyond the scope of this
memo.
This memo defines two new categories of metrics that extend the Following is a summary of the metrics defined.
coverage to multiple measurement points. It first defines spatial
metrics for measuring the performance of segments of a source to
destination path:
o A 'vector', called Type-P-Spatial-One-way-Delay-Vector, will be This memo firstly defines metrics for spatial measurement based on
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] introduced to divide an end-to-end Type-P-One-way-Delay [RFC2679]
into a spatial sequence of one-way delay metrics. into a spatial sequence of one-way delay metrics.
o A 'vector', called Type-P-Spatial-One-way-Packet-Loss-Vector, will o A 'Vector', called Type-P-Spatial-One-way-Packet-Loss-Vector, will
be introduced to divide an end-to-end Type-P-One-way-Packet-Loss be introduced to divide an end-to-end Type-P-One-way-Packet-Loss
[RFC2680] in a spatial sequence of packet loss metrics. [RFC2680] in a spatial sequence of packet loss metrics.
o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'vector', 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 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 divide an end-to-end Type-P-One-way-ipdv in a spatial sequence of
ipdv metrics. ipdv metrics.
o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'sample', 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 called Type-P-Segment-One-way-Delay-Stream, will be introduced to
collect one-way delay metrics over time between two points of collect one-way delay metrics over time between two points of
interest of the path; interest of the path;
o Using the Type-P-Spatial-Packet-Loss-Vector metric, a 'sample', o Using the Type-P-Spatial-Packet-Loss-Vector metric, a 'sample',
called Type-P-Segment-Packet-Loss-Stream, will be introduced to called Type-P-Segment-Packet-Loss-Stream, will be introduced to
collect packet loss metrics over time between two points of collect packet loss metrics over time between two points of
interest of the path; interest of the path;
o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'sample', o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'sample',
called Type-P-Segment-ipdv-prev-Stream, will be introduced to called Type-P-Segment-ipdv-prev-Stream, will be introduced to
compute ipdv metrics over time between two points of interest of compute ipdv metrics over time between two points of interest of
the path using the previous packet selection function; the path using the previous packet selection function;
o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'sample', o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'sample',
called Type-P-Segment-ipdv-min-Stream, will be introduced to called Type-P-Segment-ipdv-min-Stream, will be introduced to
compute ipdv metrics over time between two points of interest of compute ipdv metrics over time between two points of interest of
the path using the shortest delay selection function; the path using the shortest delay selection function;
Note that all these metrics are based on observations of packets Then the memo defines one-to-group metrics and one-to-group
dedicated to testing, a process which is called Active measurement. statistics.
Purely passive spatial measurement (for example, a spatial metric
based on the observation of user traffic) is beyond the scope of this
document and the current IPPM charter.
Next, this memo defines one-to-group metrics.
o Using one test packet sent from one sender to a group of
receivers, a metric called Type-P-one-to-group-One-way-Delay-
Vector will be introduced to collect the set of Type-P-one-way-
delay [RFC2679] singletons between this sender and the group of
receivers.
o Using one test packet sent from one sender to a group of Three one-to-group metrics are defined to measure the one-way
receivers, a metric called Type-P-one-to-group-One-way-Packet- performance between a source and a group of receivers. Definitions
Loss-Vector, will be introduced to collect the set of Type-P-One- derive from one-way metrics definitions of RFCs in [RFC2679],
way-Packet-Loss [RFC2680] singletons between this sender and the [RFC2680], [RFC3393], [RFC3432]:
group of receivers o A 'Vector', called Type-P-One-to-Group-One-way-Delay-Vector, will
o Using one test packet sent from one sender to a group of be introduced to collect the set of Type-P-one-way-delay
receivers, a metric called Type-P-one-to-group-One-way-ipdv- singletons between one sender and N receivers;
Vector, will be introduced to collect the set of Type-P-One-way- o A 'Vector', called Type-P-One-to-Group-One-way-Packet-Loss-Vector,
ipdv singletons between this sender and the group of receivers 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.
o A discussion section presents the set of statistics that may be Then, based on the One-to-group vector metrics listed above,
computed using these metrics to present the network performance in statistics are defined to capture single receiver performance, group
the view of a group of users. The statistics may be the basis for performance and relative performance situation inside a multiparty
requirements (e.g. fairness) on multiparty communications. . communication for each packet sent during the test interval between
one sender and N receivers:
Metric Reporting is defined in the "Manageability Considerations" o Using the Type-P-One-to-Group-One-way-Delay-Vector, a metric
section. 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 2. Terminology
2.1. Path Digest Hosts 2.1. Path Digest Hosts
The list of the hosts on a path from the source to the destination. The list of the hosts on a path from the source to the destination.
2.2. Multiparty metric 2.2. 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
skipping to change at page 9, line 49 skipping to change at page 9, line 49
3. Motivations 3. Motivations
All IPPM metrics are defined for end-to-end (source to destination) All IPPM metrics are defined for end-to-end (source to destination)
measurement of point-to-point paths. It is a logical extension to measurement of point-to-point paths. It is a logical extension to
define metrics for multiparty measurements such as one to one define metrics for multiparty measurements such as one to one
trajectory metrics and one to multipoint metrics. trajectory metrics and one to multipoint metrics.
3.1. Motivations for spatial metrics 3.1. Motivations for spatial metrics
Decomposition of instantaneous end-to-end measures is needed: Decomposition of instantaneous end-to-end measures is needed:
o Decomposing the performance of interdomain path is desirable to o Decomposing the performance of interdomain path is desirable to
quantify the per-AS contribution to the performance. It is quantify the per-AS contribution to the performance. It is
valuable to define standard spatial metrics before pursuing inter- valuable to define standard spatial metrics before pursuing inter-
domain path performance specifications. domain path performance specifications.
o Traffic engineering and troubleshooting applications benefit from o Traffic engineering and troubleshooting applications benefit from
spatial views of one-way delay and ipdv consumption, and spatial views of one-way delay and ipdv consumption, and
identification of the location of the lost of packets. identification of the location of the lost of packets.
o Monitoring the performance of a multicast tree composed of MPLS o Monitoring the performance of a multicast tree composed of MPLS
point-to-multipoint and inter-domain communication require spatial point-to-multipoint and inter-domain communication require spatial
decomposition of the one-way delay, ipdv, and packet loss. decomposition of the one-way delay, ipdv, and packet loss.
o Composition of metrics is needed to help measurement systems reach
o Composition of metrics [I-D.ietf-ippm-spatial-composition] is large scale coverage. Spatial measures typically give the
needed to help measurement systems reach large scale coverage. individual performance of an intra domain segment and provide an
Spatial measures typically give the individual performance of an elementary piece of information needed to estimate interdomain
intra domain segment and provide an elementary piece of performance based on composition of metrics.
information needed to estimate interdomain performance based on
composition of metrics.
3.2. Motivations for One-to-group metrics 3.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. one-way metric cannot completely describe the multiparty situation.
New one-to-group metrics assess performance of all the paths for New one-to-group metrics assess performance of all the paths for
further statistical analysis. The new metrics proposed in this stage further statistical analysis. The new metrics proposed in this stage
are named one-to-group performance metrics, and they are based on the are named one-to-group performance metrics, and they are based on the
skipping to change at page 12, line 16 skipping to change at page 12, line 8
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. Definitions are coupled with the corresponding end-to-end metrics.
Methodology specificities are common to all the vectors defined and Methodology specificities are common to all the vectors defined and
are consequently discussed in a common section. are consequently discussed in a common section.
4.1. A Definition for Spatial One-way Delay Vector 4.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 definitionis of the section 3 of [RFC2679]. When a parameter of this definition
first used in this section, it will be tagged with a trailing is first used in this section, it will be tagged with a trailing
asterisk. 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 SHOULD be respectful of them,
especially those related to methodology, clock, uncertainties and especially those related to methodology, clock, uncertainties and
reporting. reporting.
4.1.1. Metric Name 4.1.1. Metric Name
skipping to change at page 27, line 46 skipping to change at page 25, line 14
6.3. A Definition for One-to-group One-way Ipdv 6.3. A Definition for One-to-group One-way Ipdv
6.3.1. Metric Name 6.3.1. Metric Name
Type-P-One-to-group-One-way-ipdv-Vector Type-P-One-to-group-One-way-ipdv-Vector
6.3.2. Metric Parameters 6.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 ddT1, ...,ddTn, a list of time.
o P, the specification of the packet type. o P, the specification of the packet type.
o F, a selection function defining unambiguously the two packets o F, a selection function defining unambiguously 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. multicast group address if the measured packets are transmitted
over IP multicast. This parameter is to differentiate the
measured traffic from other unicast and multicast traffic. It is
optional in the metric to avoid losing any generality, i.e. to
make the metric also applicable to unicast measurement where there
is only one receiver.
6.3.3. Metric Units 6.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-One-way-ipdv-Vector is a set of
Type-P-One-way-ipdv singletons [RFC3393]. Type-P-One-way-ipdv singletons [RFC3393].
6.3.4. Definition 6.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-One-way-ipdv-Vector
is defined for two packets from the source Src to the N hosts is defined for two packets from the source Src to the N hosts
skipping to change at page 32, line 22 skipping to change at page 29, line 27
Matrix and can not calculate the statistics. In an extreme Matrix and can not calculate the statistics. In an extreme
situation, no single packet arrives all users in the measurement and situation, no single packet arrives all users in the measurement and
the Matrix will be empty. One of the possible solutions is to the Matrix will be empty. One of the possible solutions is to
replace the infinite/undefined delay value by the average of the two replace the infinite/undefined delay value by the average of the two
adjacent values. For example, if the result reported by user1 is { adjacent values. For example, if the result reported by user1 is {
R1dT1 R1dT2 R1dT3 ... R1dTK-1 UNDEF R1dTK+1... R1DM } where "UNDEF" R1dT1 R1dT2 R1dT3 ... R1dTK-1 UNDEF R1dTK+1... R1DM } where "UNDEF"
is an undefined value, the reference point can replace it by R1dTK = is an undefined value, the reference point can replace it by R1dTK =
{(R1dTK-1)+( R1dTK+1)}/2. Therefore, this result can be used to {(R1dTK-1)+( R1dTK+1)}/2. Therefore, this result can be used to
build up the group Matrix with an estimated value R1dTK. There are build up the group Matrix with an estimated value R1dTK. There are
other possible solutions such as using the overall mean of the whole other possible solutions such as using the overall mean of the whole
result to replace the infinite/undefined value, and so on. It is out result to replace the infinite/undefined value, and so on. However
of the scope of this memo. this is out of the scope of this memo.
For the distributed calculation, the reported statistics might have For the distributed calculation, the reported statistics might have
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
skipping to change at page 32, line 39 skipping to change at page 29, line 44
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 7.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;
o lambda, a rate in reciprocal seconds (for Poisson Streams); o lambda, a rate in reciprocal seconds (for Poisson Streams);
o incT, the nominal duration of inter-packet interval, first bit to o incT, the nominal duration of inter-packet interval, first bit to
first bit (for Periodic Streams); first bit (for Periodic Streams);
o T0, a time that MUST be selected at random from the interval [T, o T0, a time that MUST be selected at random from the interval [T,
T+I] to start generating packets and taking measurements (for T+I] to start generating packets and taking measurements (for
Periodic Streams); Periodic Streams);
o TstampSrc, the wire time of the packet as measured at MP(Src) (the o TstampSrc, the wire time of the packet as measured at MP(Src) (the
Source Measurement Point); Source Measurement Point);
o TstampRecv, the wire time of the packet as measured at MP(Recv), o TstampRecv, the wire time of the packet as measured at MP(Recv),
assigned to packets that arrive within a "reasonable" time; assigned to packets that arrive within a "reasonable" time;
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 7.3. One-to-Group one-way Delay Statistics
This section defines the overall one-way delay statistics for an This section defines the overall one-way delay statistics for a
entire Group or receivers. For example, we can define the group mean receiver and for an entire group as illustrated by the matrix below.
delay, as illustrated below. This is a metric designed to summarize
the whole matrix.
Recv /----------- Sample -------------\ Stats Group Stat Recv /----------- Sample -------------\ Stats Group Stat
1 R1dT1 R1dT2 R1dT3 ... R1dTk R1DM \ 1 R1dT1 R1dT2 R1dT3 ... R1dTk R1DM \
| |
2 R2dT1 R2dT2 R2dT3 ... R2dTk R2DM | 2 R2dT1 R2dT2 R2dT3 ... R2dTk R2DM |
| |
3 R3dT1 R3dT2 R3dT3 ... R3dTk R2DM > GMD 3 R3dT1 R3dT2 R3dT3 ... R3dTk R2DM > Group delay
. | . |
. | . |
. | . |
n RndT1 RndT2 RndT3 ... RndTk RnDM / n RndT1 RndT2 RndT3 ... RndTk RnDM /
Figure 5: One-to-Group Mean Delay Receiver-n
delay
where:
R1dT1 is the Type-P-Finite-One-way-Delay singleton evaluated at
Receiver 1 for packet 1.
R1DM is the Type-P-Finite-One-way-Delay-Mean evaluated at Receiver 1
for the sample of packets (1,...K).
GMD is the mean of the sample means over all Receivers (1, ...N).
7.3.1. Definition and Metric Units
Using the parameters above, 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 [RFC2679]. For each packet that
arrives within Tmax of its sending time, TstampSrc, the one-way delay
singleton (dT) will be a finite value in units of seconds.
Otherwise, the value of the singleton is Undefined.
For each packet [i] that has a finite One-way Delay at Receiver n (in Figure 5: One-to-Group Mean Delay
other words, excluding packets which have undefined one-way delay):
Type-P-Finite-One-way-Delay-Receiver-n-[i] = Statistics are computed on the finite One-way delays of the matrix
above.
= TstampRecv[i] - TstampSrc[i] All One-to-group delay statistics are expressed in seconds with
sufficient resolution to convey 3 significant digits.
The units of Finite one-way delay are seconds, with sufficient 7.3.1. Type-P-One-to-Group-Receiver-n-Mean-Delay
resolution to convey 3 significant digits.
7.3.2. Sample Mean Statistic This section defines Type-P-One-to-Group-Receiver-n-Mean-Delay the
Delay Mean at each Receiver N, also named RnDM.
This section defines the Sample Mean at each of N Receivers. 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
[RFC2679]. For each packet that arrives within Tmax of its sending
time, TstampSrc, the one-way delay singleton (dT) will be the finite
value TstampRecv[i] - TstampSrc[i] in units of seconds. Otherwise,
the value of the singleton is Undefined.
Type-P-Finite-One-way-Delay-Mean-Receiver-n = RnDM =
J[n] J[n]
--- ---
1 \ 1 \
--- * > Type-P-Finite-One-way-Delay-Receiver-n-[i] RnDM = --- * > TstampRecv[i] - TstampSrc[i]
J[n] / J[n] /
--- ---
i = 1 i = 1
Figure 6: Type-P-Finite-One-way-Delay-Mean-Receiver-n Figure 6: Type-P-One-to-Group-Receiver-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.3. One-to-Group Mean Delay Statistic 7.3.2. Type-P-One-to-Group-Mean-Delay
This section defines the Mean One-way Delay calculated over the This section defines Type-P-One-to-Group-Mean-Delay, the Mean One-way
entire Group (or Matrix). delay calculated over the entire Group, also named GMD.
Type-P-One-to-Group-Mean-Delay = GMD =
N N
--- ---
1 \ 1 \
- * > 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.4. One-to-Group Range of Mean Delays 7.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.5. One-to-Group Maximum of Mean Delays 7.3.4. Type-P-One-to-Group-Max-Mean-Delay
This section defines a metrics for the maximum of mean delays over This section defines a metric for the maximum of mean delays over all
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 7.4. One-to-Group one-way Loss Statistics
This section defines the overall 1-way loss statistics for an entire This section defines the overall one-way loss statistics for a
Group. For example, we can define the group loss ratio, as receiver and for an entire group as illustrated by the matrix below.
illustrated below. This is a metric designed to summarize the entire
Matrix.
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 > GLR 3 R3L1 R3L2 R3L3 ... R3Lk R3LR > Group Loss Ratio
. | . |
. | . |
. | . |
n RnL1 RnL2 RnL3 ... RnLk RnLR / n RnL1 RnL2 RnL3 ... RnLk RnLR /
Figure 8: One-to-Group Loss Ratio Receiver-n
Loss Ratio
where:
R1L1 is the Type-P-One-way-Loss singleton (L) evaluated at Receiver 1
for packet 1.
R1LR is the Type-P-One-way-Loss-Ratio evaluated at Receiver 1 for the
sample of packets (1,...K).
GLR is the loss ratio over all Receivers (1, ..., N).
7.4.1. One-to-Group Loss Ratio
The overall Group loss ratio id defined as
Type-P-One-to-Group-Loss-Ratio = Figure 8: One-to-Group Loss Ratio
K,N
---
1 \
= --- * > L(k,n)
K*N /
---
k,n = 1
Figure 9 Statistics are computed on the sample of Type-P-One-way-Packet-Loss
[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.2. One-to-Group Loss Ratio Range 7.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, RnLR for receiver n, and the Type-P-One- One-way-Packet-Loss-Average and the Type-P-One-to-Group-Receiver-n-
way-Loss-Ratio illustrated above are equivalent metrics. In terms of Loss-Ratio, also named RnLR, are equivalent metrics. In terms of the
the parameters used here, these metrics definitions can be expressed parameters used here, these metrics definitions can be expressed as
as
Type-P-One-way-Loss-Ratio-Receiver-n = RnLR =
K K
--- ---
1 \ 1 \
- * > RnLk RnLR = - * > RnLk
K / K /
--- ---
k = 1 k = 1
Figure 10: Type-P-One-way-Loss-Ratio-Receiver-n Figure 9: Type-P-One-to-Group-Receiver-n-Loss-Ratio
The One-to-Group Loss Ratio Range is defined as
Type-P-One-to-Group-Loss-Ratio-Range = max(RnLR) - min(RnLR)
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
difference between them.
7.4.3. Comparative Loss Ratio 7.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 is defined as The Comparative Loss Ratio, also named, RnCLR, is defined as
Type-P-Comp-Loss-Ratio-Receiver-n = RnCLR =
K K
--- ---
\ \
> Ln(k) > Ln(k)
/ /
--- ---
k=1 k=1
= ----------------------------- RnCLR = -----------------------------
/ K \ / K \
| --- | | --- |
| \ | | \ |
K - Min | > Ln(k) | K - Min | > Ln(k) |
| / | | / |
| --- | | --- |
\ k=1 / N \ k=1 / N
Figure 11: Type-P-Comp-Loss-Ratio-Receiver-n Figure 10: Type-P-One-to-Group-Receiver-n-Comp-Loss-Ratio
7.4.3. Type-P-One-to-Group-Loss-Ratio
Type-P-One-to-Group-Loss-Ratio, the overall Group loss ratio, also
named GLR, is defined as
K,N
---
1 \
GLR = --- * > L(k,n)
K*N /
---
k,n = 1
Figure 11: Type-P-One-to-Group-Loss-Ratio
7.4.4. Type-P-One-to-Group-Range-Loss-Ratio
The One-to-Group Loss Ratio Range is defined as:
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
minimum loss ratios for the Group, rather than only reporting the
difference between them.
7.5. One-to-Group one-way Delay Variation Statistics 7.5. One-to-Group one-way Delay Variation Statistics
There are two delay variation (DV) statistics that summarize the This section defines one-way delay variation (DV) statistics for an
performance over the Group: the maximum DV over all receivers and the entire group as illustrated by the matrix below.
minimum DV over all receivers (where DV is a point-to-point metric).
Recv /------------- Sample --------------\ Stats
1 R1ddT1 R1ddT2 R1ddT3 ... R1ddTk R1DV \
|
2 R2ddT1 R2ddT2 R2ddT3 ... R2ddTk R2DV |
|
3 R3ddT1 R3ddT2 R3ddT3 ... R3ddTk R3DV > Group Stat
. |
. |
. |
n RnddT1 RnddT2 RnddT3 ... RnddTk RnDV /
Figure 12: One-to-Group Delay Variation Matrix (DVMa)
Statistics are computed on the sample of Type-P-One-way-Delay-
Variation singletons of the group delay variation matrix above where
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-
way packet delay variation for Receiver n.
All One-to-group delay variation statistics are expressed in seconds
with sufficient resolution to convey 3 significant digits.
7.5.1. Type-P-One-to-Group-Delay-Variation-Range
This section defines a metric for the range of delays variation over
all N receivers in the Group.
Maximum DV and minimum DV over all receivers summarize the
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 =
= max(RnDV) - min(RnDV) for all n receivers
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
Destinations in the group and a population of interest, using the
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
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.
Both the minimum and the maximum delay variation are recorded, and
both values are given to indicate the location of the range.
8. Measurement Methods: Scalability and Reporting 8. 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 measurement points 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
number of measurement points, so the scale of the measurement points of interest, so the scale of the measurement architecture
architecture multiplies the number of singleton results that must be multiplies the number of singleton results that must be collected and
collected and processed. processed.
It is possible that the architecture for results collection involves It is possible that the architecture for results collection involves
a single aggregation point with connectivity to all the measurement a single reference point with connectivity to all the points of
points. In this case, the number of measurement points determines interest. In this case, the number of points of interest determines
both storage capacity and packet transfer capacity of the host acting both storage capacity and packet transfer capacity of the host acting
as the aggregation point. However, both the storage and transfer as the reference point. However, both the storage and transfer
capacity can be reduced if the measurement points are capable of capacity can be reduced if the points of interest are capable of
computing the summary statistics that describe each measurement computing the summary statistics that describe each measurement
interval. This is consistent with many operational monitoring interval. This is consistent with many operational monitoring
architectures today, where even the individual singletons may not be architectures today, where even the individual singletons may not be
stored at each measurement point. 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 8.1. Computation methods
skipping to change at page 40, line 9 skipping to change at page 36, line 51
measurement campaign to optimize the measurement results delivery. measurement campaign to optimize the measurement results delivery.
The possible solution could be to transit the statistic parameters to The possible solution could be to transit the statistic parameters to
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. It is out of the scope of this memo. results. However, this is out of the scope of this memo.
8.2. Measurement 8.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 8.3. Effect of Time and Space Aggregation Order on Stats
skipping to change at page 40, line 44 skipping to change at page 37, line 38
. | . |
. | . |
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 12: 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 the resulting
matrix: matrix:
o metric is computed over time and then over space; o metric is computed over time and then over space;
o metric is computed over space and then over time. o metric is computed over space and then over time.
They differ only by the order of the time and of the space 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 aggregation. View as a matrix this order is neutral as does not
impact the result, but the impact on a measurement deployment is impact the result, but the impact on a measurement deployment is
critical. critical.
In both cases the volume of data to report is proportional to the 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 number of probes. But there is a major difference between these 2
skipping to change at page 41, line 44 skipping to change at page 38, line 31
control of various collecting aspects such as bandwidth and control of various collecting aspects such as bandwidth and
computation and storage capacities. So this draft defines metrics computation and storage capacities. So this draft defines metrics
based on method 1. based on method 1.
Note: In some specific cases one may need sample of singletons over Note: In some specific cases one may need sample of singletons over
space. To address this need it is suggested firstly to limit the space. To address this need it is suggested firstly to limit the
number of test and the number of test packets per seconds. Then number of test and the number of test packets per seconds. Then
reducing the size of the sample over time to one packet give sample reducing the size of the sample over time to one packet give sample
of singleton over space.. of singleton over space..
8.3.1. Impact on group stats 8.3.1. Impact on spatial statistics
2 methods are available to compute group statistics:
o method1: Figure 5 andFigure 8 illustrate the method chosen: the
one-to-one statistic is computed per interval of time before the
computation of the mean over the group of receivers;
o method2: Figure 12 presents the second one, metric is computed
over space and then over time.
8.3.2. Impact on spatial stats
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
2 methods are available to compute group statistics:
o method1: Figure 5 andFigure 8 illustrate the method chosen: the
one-to-one statistic is computed per interval of time before the
computation of the mean over the group of receivers;
o method2: Figure 13 presents the second one, metric is computed
over space and then over time.
9. Manageability Considerations 9. 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 introduced in a single section to provide consistent information, to
while avoiding repetitions. The aim is to contribute to the work of avoid repetitions and to conform to IESG recommendation of gathering
the WG on the reporting and to satisfy IESG recommendation of manageability considerations in a dedicated section.
gathering manageability considerations in a dedicated section.
Data models of spatial and one-to-group metrics are similar excepted Information models of spatial metrics and of one-to-group metrics are
that points of interests of spatial vectors must be ordered. similar excepted that points of interests of spatial vectors must be
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 9.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 9.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 (Section 3.8.4 of [RFC2679]). IPPM RFCs recommend it to be reported (See Section 3.8.4 of
Spatial metrics vectors provide this path. The report of a spatial [RFC2679]). Spatial metrics vectors provide this path. The report
vector must include the points of interests involved: the sub set of of a spatial vector must include the points of interests involved:
the hosts of the path participating to the instantaneous measure. the sub set of the hosts of the path participating to the
instantaneous measure.
9.1.2. Host order 9.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.
skipping to change at page 43, line 33 skipping to change at page 40, line 14
timestamping compared to wire time. timestamping compared to wire time.
9.1.4. Reporting spatial One-way Delay 9.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 9.2. Reporting One-to-group metric
All reporting rules described in RFC2679-80 apply to the All reporting rules described in RFC2679-80 apply to the
corresponding One-to-group metrics RFC2679-80. In addition, several corresponding One-to-group metrics. Following are specific
new parameters are needed to report which are common to all the parameters that should be reported.
metrics and are presented here.
9.2.1. Path 9.2.1. Path
As suggested by the RFC2679-80, the path traversed by the packet As suggested by the RFC2679-80, the path traversed by the packet
SHOULD be reported, if possible. For One-to-group metrics, there is SHOULD be reported, if possible. For One-to-group metrics, there is
a path tree SHOULD be reported rather than A path. This is even more a path tree SHOULD be reported rather than A path. This is even more
impractical. If, by anyway, partial information is available to impractical. If, by anyway, partial information is available to
report, it might not be as valuable as it is in the one-to-one case report, it might not be as valuable as it is in the one-to-one case
because the incomplete path might be difficult to identify its because the incomplete path might be difficult to identify its
position in the path tree. For example, how many points of interest position in the path tree. For example, how many points of interest
are reached by the packet traveled through this incomplete path? are reached by the packet traveled through this incomplete path?
However, the multicast path tree is normally more stable than
unicast, which is dependant on multicast routing protocols. For
example, the PIM-SM protocol [RFC4601] initializes the multicast
route before any data packets are sent to the receivers.
9.2.2. Group size 9.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 9.2.3. Timestamping bias
It is the same as described in section 9.1.3. It is the same as described in section 9.1.3.
skipping to change at page 44, line 30 skipping to change at page 41, line 5
As explained in section 8, the measurement method will have impact on As explained in section 8, 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 9.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. Reporting data model 9.4. Information model
This section presents the elements of the datamodel and the usage of This section presents the elements of information and the usage of
the information reported for real network performance analysis. It the information reported for network performance analysis. It is out
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 data model is build with pieces of information introduced and The information model is build with pieces of information introduced
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[RFC3393][RFC3432]. It definitions [RFC2680] and in IPDV definitions of [RFC3393] and
includes not only information given by "Reporting the metric" [RFC3432]. It includes not only information given by "Reporting the
sections but by sections "Methodology" and "Errors and Uncertainties" metric" sections but by sections "Methodology" and "Errors and
sections. Uncertainties" sections.
Following are the elements of the datamodel taken from end-to-end Following are the elements of information taken from end-to-end
definitions referred in this memo and from spatial and multicast definitions referred in this memo and from spatial and multicast
metrics it defines: metrics it defines:
o Packet_type, The Type-P of test packets (Type-P); o Packet_type, The Type-P of test packets (Type-P);
o Packet_length, a packet length in bits (L); o Packet_length, a packet length in bits (L);
o Src_host, the IP address of the sender; o Src_host, the IP address of the sender;
o Dst_host, the IP address of the receiver; o Dst_host, the IP address of the receiver;
o Hosts_serie: <H1, H2,..., Hn>, a list of points of interest; o Hosts_serie: <H1, H2,..., Hn>, a list of points of interest;
o Loss_threshold: The threshold of infinite delay; o Loss_threshold: The threshold of infinite delay;
o Systematic_error: constant delay between wire time and o Systematic_error: constant delay between wire time and
timestamping; timestamping;
o Calibration_error: maximal uncertainty; o Calibration_error: maximal uncertainty;
o Src_time, the sending time for a measured packet; o Src_time, the sending time for a measured packet;
o Dst_time, the receiving time for a measured packet; o Dst_time, the receiving time for a measured packet;
o Result_status : an indicator of usability of a result 'Resource o Result_status : an indicator of usability of a result 'Resource
exhaustion' 'infinite', 'lost'; exhaustion' 'infinite', 'lost';
o Delays_serie: <dT1,..., dTn> a list of delays; o Delays_serie: <dT1,..., dTn> a list of delays;
o Losses_serie: <B1, B2, ..., Bi, ..., Bn>, a list of Boolean values o Losses_serie: <B1, B2, ..., Bi, ..., Bn>, a list of Boolean values
(spatial) or a set of Boolean values (one-to-group); (spatial) or a set of Boolean values (one-to-group);
o Result_status_serie: a list of results status; o Result_status_serie: a list of results status;
o dT: a delay; o dT: a delay;
o Singleton_number: a number of singletons; o Singleton_number: a number of singletons;
o Observation_duration: An observation duration; o Observation_duration: An observation duration;
o metric_identifier. o metric_identifier.
Following is the information of each vector that should be available Following is the information of each vector that should be available
to compute samples: to compute samples:
o Packet_type; o Packet_type;
o Packet_length; o Packet_length;
o Src_host, the sender of the packet; o Src_host, the sender of the packet;
o Dst_host, the receiver of the packet, apply only for spatial o Dst_host, the receiver of the packet, apply only for spatial
vectors; vectors;
o Hosts_serie: not ordered for one-to-group; o Hosts_serie: not ordered for one-to-group;
o Src_time, the sending time for the measured packet; o Src_time, the sending time for the measured packet;
o dT, the end-to-end one-way delay for the measured packet, apply o dT, the end-to-end one-way delay for the measured packet, apply
only for spatial vectors; only for spatial vectors;
o Delays_serie: apply only for delays and ipdv vector, not ordered o Delays_serie: apply only for delays and ipdv vector, not ordered
for one-to-group; for one-to-group;
o Losses_serie: apply only for packets loss vector, not ordered for o Losses_serie: apply only for packets loss vector, not ordered for
one-to-group; one-to-group;
o Result_status_serie; o Result_status_serie;
o Observation_duration: the difference between the time of the last o Observation_duration: the difference between the time of the last
singleton and the time of the first singleton. singleton and the time of the first singleton.
o Following is the context information (measure, points of o Following is the context information (measure, points of
interests) that should be available to compute samples : interests) that should be available to compute samples :
* Loss threshold; * Loss threshold;
* Systematic error: constant delay between wire time and * Systematic error: constant delay between wire time and
timestamping; timestamping;
* Calibration error: maximal uncertainty; * Calibration error: maximal uncertainty;
A spatial or a one-to-group sample is a collection of singletons A spatial or a one-to-group sample is a collection of singletons
giving the performance from the sender to a single point of interest. giving the performance from the sender to a single point of interest.
Following is the information that should be available for each sample Following is the information that should be available for each sample
to compute statistics: to compute statistics:
o Packet_type; o Packet_type;
o Packet_length; o Packet_length;
o Src_host, the sender of the packet; o Src_host, the sender of the packet;
o Dst_host, the receiver of the packet; o Dst_host, the receiver of the packet;
o Start_time, the sending time of the first packet; o Start_time, the sending time of the first packet;
o Delays_serie: apply only for delays and ipdv samples; o Delays_serie: apply only for delays and ipdv samples;
o Losses_serie: apply only for packets loss samples; o Losses_serie: apply only for packets loss samples;
o Result_status_serie; o Result_status_serie;
o Observation_duration: the difference between the time of the last o Observation_duration: the difference between the time of the last
singleton of the last sample and the time of the first singleton singleton of the last sample and the time of the first singleton
of the first sample. of the first sample.
o Following is the context information (measure, points of o Following is the context information (measure, points of
interests) that should be available to compute statistics : interests) that should be available to compute statistics :
* Loss threshold; * Loss threshold;
* Systematic error: constant delay between wire time and * Systematic error: constant delay between wire time and
timestamping; timestamping;
* Calibration error: maximal uncertainty; * Calibration error: maximal uncertainty;
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. Open issues 10. Security Considerations
Do we define min, max, avg of for each segment metrics ?
having the maximum loss metric value could be interesting. Say,
the segment between router A and B always contributes loss metric
value of "1" means it could be the potential problem segment.
Uploading dTi of each Hi consume a lot of bandwidth. Computing
statistics (min, max and avg) of dTi locally in each Hi reduce the
bandwidth consumption.
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 definitions of [RFC2679] , in packet loss metrics definitions of
of[RFC2680] and in IPDV metrics definitions of[RFC3393] and [RFC3432] [RFC2680] and in IPDV metrics definitions of[RFC3393] and [RFC3432]
apply to multimetrics. apply to metrics defined in this memo.
11.1. Spatial metrics 10.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.
11.2. one-to-group metric 10.2. one-to-group metric
The reporting of measurement results from a huge number of probes may Reporting of measurement results from a huge number of probes may
overload the network the reference point is attach to, the reference overload reference point ressources (network, network interfaces,
point network interfaces and the reference point computation computation capacities ...).
capacities.
The configuration of a measure 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 attach 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.
12. Acknowledgments 11. 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.
13. IANA Considerations 12. 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 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
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 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
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 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
ietfSpatialSegmentOnewayDelayStream OBJECT-IDENTITY ietfSegmentOneWayDelayStream OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-Segment-One-way-Delay-Stream"
"Type-P-Spatial-Segment-One-way-Delay-Stream"
REFERENCE REFERENCE
"Reference "RFCyyyy, section 5.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
ietfSpatialSegmentPacketLossStream OBJECT-IDENTITY ietfSegmentPacketLossStream OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-Segment-Packet-Loss-Stream"
"Type-P-Spatial-Segment-Packet-Loss-Stream"
REFERENCE REFERENCE
"Reference "RFCyyyy, section 5.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
ietfSpatialSegmentOneWayIpdvPrevStream OBJECT-IDENTITY ietfSegmentOneWayIpdvPrevStream OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-Segment-One-way-ipdv-prev-Stream"
"Type-P-Spatial-Segment-ipdv-prev-Stream"
REFERENCE REFERENCE
"Reference "RFCyyyy, section 5.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
ietfSpatialSegmentOneWayIpdvMinStream OBJECT-IDENTITY ietfSegmentOneWayIpdvMinStream OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-Segment-One-way-ipdv-min-Stream"
"Type-P-Spatial-Segment-ipdv-minStream"
REFERENCE REFERENCE
"Reference "RFCyyyy, section 5.4." "Reference "RFCyyyy, section 5.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 ietfOneToGroupOneWayDelayVector OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-One-to-group-One-way-Delay-Vector"
"Type-P-one-to-group-One-way-Delay-Vector"
REFERENCE REFERENCE
"Reference "RFCyyyy, section 6.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
ietfOneToGroupOneWayPktLossVector OBJECT-IDENTITY ietfOneToGroupOneWayPktLossVector OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-One-to-Group-One-way-Packet-Loss-Vector"
"Type-P-one-to-group-One-way-Packet-Loss-Vector"
REFERENCE REFERENCE
"Reference "RFCyyyy, section 6.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
ietfOneToGroupOneWayIpdvVector OBJECT-IDENTITY ietfOneToGroupOneWayIpdvVector OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-One-to-Group-One-way-ipdv-Vector"
"Type-P-one-to-group-One-way-ipdv-Vector"
REFERENCE REFERENCE
"Reference "RFCyyyy, section 6.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
-- One to group statistics -- One to group statistics
-- --
ietfOneToGroupMeanDelay OBJECT-IDENTITY ietfOnetoGroupReceiverNMeanDelay OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-One-to-Group-Receiver-n-Mean-Delay"
REFERENCE
"Reference "RFCyyyy, section 7.3.1."
-- RFC Ed.: replace yyyy with actual RFC number & remove this
note
:= { ianaIppmMetrics nn } -- IANA assigns nn
ietfOneToGroupMeanDelay OBJECT-IDENTITY
STATUS current
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 6.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
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 6.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
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."
-- RFC Ed.: replace yyyy with actual RFC number & remove this
note
:= { ianaIppmMetrics nn } -- IANA assigns nn
"Reference "RFCyyyy, section 6.3.5." ietfOneToGroupReceiverNLossRatio OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-One-to-Group-Receiver-n-Loss-Ratio"
REFERENCE
"Reference "RFCyyyy, section 7.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
--
ietfOneToGroupReceiverNCompLossRatio OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-One-to-Group-Receiver-n-Comp-Loss-Ratio"
REFERENCE
"Reference "RFCyyyy, section 7.4.2."
-- RFC Ed.: replace yyyy with actual RFC number & remove this
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 6.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
-- --
ietfOneToGroupLossRatioRange OBJECT-IDENTITY ietfOneToGroupRangeLossRatio OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Type-P-One-to-Group-Range-Loss-Ratio"
"Type-P-One-to-Group-Loss-Ratio-Range"
REFERENCE REFERENCE
"Reference "RFCyyyy, section 7.4.4."
"Reference "RFCyyyy, section 6.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
ietfOneToGroupRangeDelayVariation OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-One-to-Group-Range-Delay-Variation"
REFERENCE
"Reference "RFCyyyy, section 7.5.1."
-- RFC Ed.: replace yyyy with actual RFC number & remove this
note
:= { ianaIppmMetrics nn } -- IANA assigns nn := { ianaIppmMetrics nn } -- IANA assigns nn
-- --
14. References 13. References
14.1. Normative References 13.1. Normative References
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
"Framework for IP Performance Metrics", RFC 2330, Requirement Levels", BCP 14, RFC 2119, March 1997.
May 1998.
[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.
14.2. Informative References 13.2. Informative References
[I-D.ietf-ippm-spatial-composition]
Morton, A. and E. Stephan, "Spatial Composition of
Metrics", draft-ietf-ippm-spatial-composition-05 (work in
progress), November 2007.
[RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring
Connectivity", RFC 2678, September 1999.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, September 1999.
[RFC3148] Mathis, M. and M. Allman, "A Framework for Defining
Empirical Bulk Transfer Capacity Metrics", RFC 3148,
July 2001.
[RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
Metrics", RFC 3357, August 2002. "Framework for IP Performance Metrics", RFC 2330,
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.
[RFC3763] Shalunov, S. and B. Teitelbaum, "One-way Active
Measurement Protocol (OWAMP) Requirements", RFC 3763,
April 2004.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, September 2006.
[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov,
S., and J. Perser, "Packet Reordering Metrics", RFC 4737,
November 2006.
[passive_metrics]
"", 2005.
Authors' Addresses Authors' Addresses
Stephan Emile Stephan Emile
France Telecom Division R&D France Telecom Division R&D
2 avenue Pierre Marzin 2 avenue Pierre Marzin
Lannion, F-22307 Lannion, F-22307
Fax: +33 2 96 05 18 52 Fax: +33 2 96 05 18 52
Email: emile.stephan@orange-ftgroup.com Email: emile.stephan@orange-ftgroup.com
skipping to change at page 57, line 44 skipping to change at line 2305
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 268 change blocks. 
533 lines changed or deleted 394 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/