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/ |