draft-ietf-ippm-multimetrics-07.txt | draft-ietf-ippm-multimetrics-08.txt | |||
---|---|---|---|---|

Network Working Group E. Stephan | Network Working Group E. Stephan | |||

Internet-Draft France Telecom | Internet-Draft France Telecom | |||

Intended status: Standards Track L. Liang | Intended status: Standards Track L. Liang | |||

Expires: December 28, 2008 University of Surrey | Expires: April 3, 2009 University of Surrey | |||

A. Morton | A. Morton | |||

AT&T Labs | AT&T Labs | |||

June 26, 2008 | September 30, 2008 | |||

IP Performance Metrics (IPPM) for spatial and multicast | IP Performance Metrics (IPPM) for spatial and multicast | |||

draft-ietf-ippm-multimetrics-07 | draft-ietf-ippm-multimetrics-08 | |||

Status of this Memo | Status of this Memo | |||

By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||

applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||

have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||

aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||

Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||

Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||

skipping to change at page 1, line 37 | skipping to change at page 1, line 37 | |||

and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||

time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||

material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||

The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||

http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||

The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||

http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||

This Internet-Draft will expire on December 28, 2008. | This Internet-Draft will expire on April 3, 2009. | |||

Abstract | Abstract | |||

The IETF IP Performance Metrics (IPPM) working group has standardized | The IETF has standardized IP Performance Metrics (IPPM) for measuring | |||

metrics for measuring end-to-end performance between two points. | end-to-end performance between two points. This memo defines two new | |||

This memo defines two new categories of metrics that extend the | categories of metrics that extend the coverage to multiple | |||

coverage to multiple measurement points. It defines spatial metrics | measurement points. It defines spatial metrics for measuring the | |||

for measuring the performance of segments of a source to destination | performance of segments of a source to destination path, and metrics | |||

path, and metrics for measuring the performance between a source and | for measuring the performance between a source and many destinations | |||

many destinations in multiparty communications (e.g., a multicast | in multiparty communications (e.g., a multicast tree). | |||

tree). | ||||

Requirements Language | Requirements Language | |||

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||

document are to be interpreted as described in RFC 2119 [RFC2119]. | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||

Table of Contents | Table of Contents | |||

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 3 | |||

2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||

2.1. Path Digest Hosts . . . . . . . . . . . . . . . . . . . . 6 | 3. Brief Metric Descriptions . . . . . . . . . . . . . . . . . . 7 | |||

2.2. Multiparty metric . . . . . . . . . . . . . . . . . . . . 6 | 4. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||

2.3. Spatial metric . . . . . . . . . . . . . . . . . . . . . . 7 | 5. Spatial vector metrics definitions . . . . . . . . . . . . . . 11 | |||

2.4. One-to-group metric . . . . . . . . . . . . . . . . . . . 7 | 6. Spatial Segment Metrics Definitions . . . . . . . . . . . . . 18 | |||

2.5. Points of interest . . . . . . . . . . . . . . . . . . . . 7 | 7. One-to-group metrics definitions . . . . . . . . . . . . . . . 23 | |||

2.6. Reference point . . . . . . . . . . . . . . . . . . . . . 8 | 8. One-to-group Sample Statistics . . . . . . . . . . . . . . . . 26 | |||

2.7. Vector . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 9. Measurement Methods: Scalability and Reporting . . . . . . . . 36 | |||

2.8. Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 10. Manageability Considerations . . . . . . . . . . . . . . . . . 39 | |||

3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 44 | |||

3.1. Motivations for spatial metrics . . . . . . . . . . . . . 9 | 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45 | |||

3.2. Motivations for One-to-group metrics . . . . . . . . . . . 10 | 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 | |||

3.3. Discussion on Group-to-one and Group-to-group metrics . . 11 | 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49 | |||

4. Spatial vectors metrics definitions . . . . . . . . . . . . . 11 | 14.1. Normative References . . . . . . . . . . . . . . . . . . 49 | |||

4.1. A Definition for Spatial One-way Delay Vector . . . . . . 12 | 14.2. Informative References . . . . . . . . . . . . . . . . . 50 | |||

4.2. A Definition for Spatial One-way Packet Loss Vector . . . 13 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 | |||

4.3. A Definition for Spatial One-way Ipdv Vector . . . . . . . 14 | Intellectual Property and Copyright Statements . . . . . . . . . . 51 | |||

4.4. Spatial Methodology . . . . . . . . . . . . . . . . . . . 16 | ||||

5. Spatial Segments metrics definitions . . . . . . . . . . . . . 17 | ||||

5.1. A Definition of a sample of One-way Delay of a segment | ||||

of the path . . . . . . . . . . . . . . . . . . . . . . . 18 | ||||

5.2. A Definition of a sample of Packet Loss of a segment | ||||

of the path . . . . . . . . . . . . . . . . . . . . . . . 19 | ||||

5.3. A Definition of a sample of ipdv of a segment using | ||||

the previous packet selection function . . . . . . . . . . 20 | ||||

5.4. A Definition of a sample of ipdv of a segment using | ||||

the minimum delay selection function . . . . . . . . . . . 22 | ||||

6. One-to-group metrics definitions . . . . . . . . . . . . . . . 23 | ||||

6.1. A Definition for One-to-group One-way Delay . . . . . . . 23 | ||||

6.2. A Definition for One-to-group One-way Packet Loss . . . . 24 | ||||

6.3. A Definition for One-to-group One-way Ipdv . . . . . . . . 25 | ||||

7. One-to-Group Sample Statistics . . . . . . . . . . . . . . . . 26 | ||||

7.1. Discussion on the Impact of packet loss on statistics . . 28 | ||||

7.2. General Metric Parameters . . . . . . . . . . . . . . . . 29 | ||||

7.3. One-to-Group one-way Delay Statistics . . . . . . . . . . 30 | ||||

7.4. One-to-Group one-way Loss Statistics . . . . . . . . . . . 32 | ||||

7.5. One-to-Group one-way Delay Variation Statistics . . . . . 34 | ||||

8. Measurement Methods: Scalability and Reporting . . . . . . . . 35 | ||||

8.1. Computation methods . . . . . . . . . . . . . . . . . . . 36 | ||||

8.2. Measurement . . . . . . . . . . . . . . . . . . . . . . . 37 | ||||

8.3. Effect of Time and Space Aggregation Order on Stats . . . 37 | ||||

9. Manageability Considerations . . . . . . . . . . . . . . . . . 38 | ||||

9.1. Reporting spatial metric . . . . . . . . . . . . . . . . . 39 | ||||

9.2. Reporting One-to-group metric . . . . . . . . . . . . . . 40 | ||||

9.3. Metric identification . . . . . . . . . . . . . . . . . . 40 | ||||

9.4. Information model . . . . . . . . . . . . . . . . . . . . 41 | ||||

10. Security Considerations . . . . . . . . . . . . . . . . . . . 43 | ||||

10.1. Spatial metrics . . . . . . . . . . . . . . . . . . . . . 43 | ||||

10.2. one-to-group metric . . . . . . . . . . . . . . . . . . . 43 | ||||

11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 | ||||

12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 | ||||

13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 | ||||

13.1. Normative References . . . . . . . . . . . . . . . . . . . 48 | ||||

13.2. Informative References . . . . . . . . . . . . . . . . . . 49 | ||||

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 | ||||

Intellectual Property and Copyright Statements . . . . . . . . . . 50 | ||||

1. Introduction | 1. Introduction and Scope | |||

The IETF IP Performance Metrics (IPPM) working group has standardized | IETF has standardized IP Performance Metrics (IPPM) for measuring | |||

metrics for measuring end-to-end performance between two points. | end-to-end performance between two points. This memo defines two new | |||

This memo defines two new categories of metrics that extend the | categories of metrics that extend the coverage to multiple | |||

coverage to multiple measurement points. It defines spatial metrics | measurement points. It defines spatial metrics for measuring the | |||

for measuring the performance of segments of a source to destination | performance of segments of a source to destination path, and metrics | |||

path, and metrics for measuring the performance between a source and | for measuring the performance between a source and many destinations | |||

many destinations in multiparty communications (e.g., a multicast | in multiparty communications (e.g., a multicast tree). | |||

tree). | ||||

The purpose of the memo is to define metrics to fulfill the new | The purpose of the memo is to define metrics to fulfill the new | |||

requirements of measurement involving multiple measurement points. | requirements of measurement involving multiple measurement points. | |||

Spatial metrics are defined to measure the performance of each | Spatial metrics measure the performance of each segment along a path. | |||

segments along a path while the one-to-group metrics are aiming to | One-to-group metrics measure the performance for a group of users. | |||

provide a ruler to measure the performance of a group of users. | These metrics are derived from one-way end-to-end metrics, all of | |||

These metrics are derived from one-way end-to-end metrics defined by | which follow the IPPM framework [RFC2330]. | |||

IETF and follow the criteria described in the IPPM framework | ||||

[RFC2330]. | ||||

New terms are introduced to extend the terminology of the IPPM | This memo is organized as follows: Section 2 introduces new terms | |||

framework to spatial metrics and one-to-group metrics. Then a | that extend the original IPPM framework [RFC2330]. Section 3 | |||

section motivates the need of defining each category of metrics. | motivates each metric category and briefly introduces the new | |||

After, each category is defined in a separate section. Then the memo | metrics. Sections 4 through 7 develop each category of metrics with | |||

discusses the impact of the measurement methods on the scalability | definitions and statistics. Then the memo discusses the impact of | |||

and proposes an information model for reporting the measurements. | the measurement methods on the scaleability and proposes an | |||

Finally the document discusses security aspects related to | information model for reporting the measurements. Finally, the memo | |||

measurement and registers the metrics in the IANA IP Performance | discusses security aspects related to measurement and registers the | |||

Metrics Registry [RFC4148]. | metrics in the IANA IP Performance Metrics Registry [RFC4148]. | |||

Note that all these metrics are based on observations of packets | The scope of this memo is limited to metrics using a single source | |||

dedicated to testing, a process which is called Active measurement. | packet or stream, and observations of corresponding packets along the | |||

Purely passive spatial measurement (for example, a spatial metric | path (spatial), at one or more destinations (one-to-group), or both. | |||

Note that all the metrics defined herein are based on observations of | ||||

packets dedicated to testing, a process which is called active | ||||

measurement. Passive measurement (for example, a spatial metric | ||||

based on the observation of user traffic) is beyond the scope of this | based on the observation of user traffic) is beyond the scope of this | |||

memo. | memo. | |||

Following is a summary of the metrics defined. | 2. Terminology | |||

This memo firstly defines metrics for spatial measurement based on | 2.1. Naming of the metrics | |||

the decomposition of standard end-to-end metrics defined by IETF in | ||||

[[RFC2679], [RFC2680], [RFC3393], [RFC3432]. Seven metrics are | ||||

defined including their names, parameters, units and measurement | ||||

methodologies. Each definion includes a specific section discussing | ||||

measurements constraints and issues, and proposing guidance to | ||||

increase results accucacy. These spatial metrics are: | ||||

o A 'Vector', called Type-P-Spatial-One-way-Delay-Vector, will be | ||||

introduced to divide an end-to-end Type-P-One-way-Delay [RFC2679] | ||||

into a spatial sequence of one-way delay metrics. | ||||

o A 'Vector', called Type-P-Spatial-One-way-Packet-Loss-Vector, will | The names of the metrics, including capitalization letters, are as | |||

be introduced to divide an end-to-end Type-P-One-way-Packet-Loss | close as possible of the names of the one-way end-to-end metrics they | |||

[RFC2680] in a spatial sequence of packet loss metrics. | are derived from. | |||

o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'vector', | ||||

called Type-P-Spatial-One-way-ipdv-Vector, will be introduced to | ||||

divide an end-to-end Type-P-One-way-ipdv in a spatial sequence of | ||||

ipdv metrics. | ||||

o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'sample', | ||||

called Type-P-Segment-One-way-Delay-Stream, will be introduced to | ||||

collect one-way delay metrics over time between two points of | ||||

interest of the path; | ||||

o Using the Type-P-Spatial-Packet-Loss-Vector metric, a 'sample', | ||||

called Type-P-Segment-Packet-Loss-Stream, will be introduced to | ||||

collect packet loss metrics over time between two points of | ||||

interest of the path; | ||||

o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'sample', | ||||

called Type-P-Segment-ipdv-prev-Stream, will be introduced to | ||||

compute ipdv metrics over time between two points of interest of | ||||

the path using the previous packet selection function; | ||||

o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'sample', | ||||

called Type-P-Segment-ipdv-min-Stream, will be introduced to | ||||

compute ipdv metrics over time between two points of interest of | ||||

the path using the shortest delay selection function; | ||||

Then the memo defines one-to-group metrics and one-to-group | 2.2. Terms Defined Elsewhere | |||

statistics. | ||||

Three one-to-group metrics are defined to measure the one-way | host: section 5 of RFC 2330 | |||

performance between a source and a group of receivers. Definitions | ||||

derive from one-way metrics definitions of RFCs in [RFC2679], | ||||

[RFC2680], [RFC3393], [RFC3432]: | ||||

o A 'Vector', called Type-P-One-to-Group-One-way-Delay-Vector, will | ||||

be introduced to collect the set of Type-P-one-way-delay | ||||

singletons between one sender and N receivers; | ||||

o A 'Vector', called Type-P-One-to-Group-One-way-Packet-Loss-Vector, | ||||

will be introduced to collect the set of Type-P-One-way-Packet- | ||||

Loss singletons between one sender and N receivers; | ||||

o A 'Vector', called Type-P-One-to-Group-One-way-ipdv-Vector, will | ||||

be introduced to collect the set of Type-P-One-way-ipdv singletons | ||||

between one sender and N receivers. | ||||

Then, based on the One-to-group vector metrics listed above, | loss threshold: section 2.8.2 of RFC 2680 | |||

statistics are defined to capture single receiver performance, group | ||||

performance and relative performance situation inside a multiparty | ||||

communication for each packet sent during the test interval between | ||||

one sender and N receivers: | ||||

o Using the Type-P-One-to-Group-One-way-Delay-Vector, a metric | path: section 5 of RFC 2330 | |||

called Type-P-One-to-Group-Receiver-n-Mean-Delay will be | ||||

introduced to present the mean of delays between one sender and a | ||||

receiver 'n'. Then, based on this definition, 3 metrics will be | ||||

defined to characterize the mean delay over the entire group | ||||

during this interval: | ||||

* a metric called Type-P-One-to-Group-Mean-Delay, will be | ||||

introduced to present the mean of delays; | ||||

* a metric called Type-P-One-to-Group-Range-Mean-Delay will be | ||||

introduced to present the range of mean delays; | ||||

* a metric called Type-P-One-to-Group-Max-Mean-Delay will be | ||||

introduced to present the maximum of mean delays; | ||||

o Using the Type-P-one-to-group-One-way-Packet-Loss-Vector, a metric | ||||

called Type-P-One-to-Group-Receiver-n-Loss-Ratio will be | ||||

introduced to capture packet loss ratio between one sender and a | ||||

receiver 'n'. Then based on this definition, 2 metrics will be | ||||

defined to characterize packet loss over the entire group during | ||||

this interval: | ||||

* a metric called Type-P-One-to-Group-Loss-Ratio will be | ||||

introduced to capture packet loss ratio overall over the entire | ||||

group or all receivers; | ||||

* a metric called Type-P-One-to-Group-Range-Loss-Ratio will be | ||||

introduced to present comparative packet loss ratio for each | ||||

packet during the test interval between one sender and N | ||||

Receivers. | ||||

o Using Type-P-one-to-group-One-way-ipdv-Vector, a metric called | ||||

Type-P-One-to-Group-Range-Delay-Variation will be introduced to | ||||

present the range of delay variation between one sender and a | ||||

group of receivers. | ||||

2. Terminology | path digest: section 5 of RFC 2330 | |||

2.1. Path Digest Hosts | sample: section 11 of RFC 2330 | |||

The list of the hosts on a path from the source to the destination. | singleton: section 11 of RFC 2330 | |||

2.2. Multiparty metric | 2.3. Path Digest Hosts | |||

The list of the hosts on a path from the source to the destination, | ||||

also referred to as the host path digest. | ||||

2.4. Multiparty metric | ||||

A metric is said to be multiparty if the topology involves more than | A metric is said to be multiparty if the topology involves more than | |||

one measurement collection point. All multiparty metrics define a | one measurement collection point. All multiparty metrics designate a | |||

set of hosts called "points of interest", where one host is the | set of hosts as "points of interest", where one host is the source | |||

source and other hosts are the measurement collection points. For | and other hosts are the measurement collection points. For example, | |||

example, if the set of points of interest is < ha, hb, hc, ..., hn >, | if the set of points of interest is < ha, hb, hc, ..., hn >, where ha | |||

where ha is the source and < hb, hc, ..., hn > are the destinations, | is the source and < hb, hc, ..., hn > are the destinations, then | |||

then measurements may be conducted between < ha, hb>, < ha, hc>, ..., | measurements may be conducted between < ha, hb>, < ha, hc>, ..., <ha, | |||

<ha, hn >. | hn >. | |||

For the purposes of this memo (reflecting the scope of a single | For the purposes of this memo (reflecting the scope of a single | |||

source), the only multiparty metrics are one-to-group metrics. | source), the only multiparty metrics are one-to-group metrics. | |||

2.3. Spatial metric | 2.5. Spatial metric | |||

A metric is said to be spatial if one of the hosts (measurement | A metric is said to be spatial if one of the hosts (measurement | |||

collection points) involved is neither the source nor a destination | collection points) involved is neither the source nor a destination | |||

of the measured packet. | of the measured packet(s). Such measurement hosts will usually be | |||

members of the path digest. | ||||

2.4. One-to-group metric | 2.6. One-to-group metric | |||

A metric is said to be one-to-group if the measured packet is sent by | A metric is said to be one-to-group if the measured packet is sent by | |||

one source and (potentially) received by several destinations. Thus, | one source and (potentially) received by more than one destination. | |||

the topology of the communication group can be viewed as a centre- | Thus, the topology of the communication group can be viewed as a | |||

distributed or server-client topology with the source as the centre/ | center-distributed or server-client topology with the source as the | |||

server in the topology. | center/server in the topology. | |||

2.5. Points of interest | 2.7. Points of interest | |||

Points of interest are the hosts* (as per RFC2330 definition, that | Points of interest are the hosts (as per the RFC 2330 definition, | |||

includes routing nodes) that are measurement collection points, a | "hosts" include routing nodes) that are measurement collection | |||

sub-set of the set of hosts involved in the delivery of the packets | points, a sub-set of the set of hosts involved in the delivery of the | |||

(in addition to the source itself). Note that the points of interest | packets (in addition to the source itself). | |||

are a possibly arbitrary sub-set of all the hosts involved in the | ||||

path. | For spatial metrics, points of interest are a (possibly arbitrary) | |||

sub-set of all the hosts involved in the path. | ||||

Points of interest of one-to-group metrics are the intended | Points of interest of one-to-group metrics are the intended | |||

destination hosts for packets from the source (in addition to the | destination hosts for packets from the source (in addition to the | |||

source itself). | source itself). | |||

Src Recv | Src Dst | |||

`. ,-. | `. ,-. | |||

`. ,' `...... 1 | `. ,' `...... 1 | |||

`. ; : | `. ; : | |||

`. ; : | `. ; : | |||

; :... 2 | ; :... 2 | |||

| | | | | | |||

: ; | : ; | |||

: ;.... 3 | : ;.... 3 | |||

: ; | : ; | |||

`. ,' | `. ,' | |||

`-'....... N | `-'....... N | |||

Figure 1: One-to-group points of interest | Figure 1: One-to-group points of interest | |||

A candidate point of interest for spatial metrics is a host from the | A candidate point of interest for spatial metrics is a host from the | |||

set of hosts involved in the delivery of the packets from the source. | set of hosts involved in the delivery of the packets from source to | |||

destination. | ||||

Src ------. Hosts | Src ------. Hosts | |||

\ | \ | |||

`---X ... 1 | `---X ... 1 | |||

\ | \ | |||

x | x | |||

/ | / | |||

.---------X .... 2 | .---------X .... 2 | |||

/ | / | |||

x | x | |||

skipping to change at page 8, line 29 | skipping to change at page 6, line 29 | |||

X .... N | X .... N | |||

\ | \ | |||

\ | \ | |||

\ | \ | |||

`---- Dst | `---- Dst | |||

Note: 'x' are nodes which are not points of interest | Note: 'x' are nodes which are not points of interest | |||

Figure 2: Spatial points of interest | Figure 2: Spatial points of interest | |||

2.6. Reference point | 2.8. Reference point | |||

A reference point is defined as the server where the statistical | A reference point is defined as the server where the statistical | |||

calculations will be carried out. A centre/server in the | calculations will be carried out. It is usually a centralized server | |||

multimetrics measurement that is controlled by a network operator is | in the measurement architecture that is controlled by a network | |||

a good example of a reference point, where measurement data can be | operator, where measurement data can be collected for further | |||

collected for further processing. However, the actual measurements | processing. The reference point is distinctly different from hosts | |||

have to be carried out at all points of interest. | at measurement collection points, where the actual measurements are | |||

carried out (e.g., points of interest). | ||||

2.7. Vector | 2.9. Vector | |||

A Vector is a set of singletons, which are a set of results of the | A vector is a set of singletons (single atomic results) comprised of | |||

observation of the behaviour of the same packet at different places | observations corresponding to a single source packet at different | |||

of a network at different times. For instance, if one-way delay | hosts in a network. For instance, if the one-way delay singletons | |||

singletons observed at N receivers for Packet P sent by the source | observed at N receivers for Packet P sent by the source Src are dT1, | |||

Src are dT1, dT2,..., dTN, it can be say that a vector V with N | dT2,..., dTN, then a vector V with N elements can be organized as | |||

elements can be organized as {dT1, dT2,..., dTN}. The elements in | {dT1, dT2,..., dTN}. The element dT1 is distinct from all others as | |||

one vector are singletons distinct with each other in terms of both | the singleton at receiver 1 in response to a packet sent from the | |||

measurement point and sending time. Given the vector V as an | source at a specific time. The complete vector gives information | |||

example, the element dT1 is distinct from all others as the singleton | over the dimension of space; a set of N receivers in this example. | |||

at receiver 1 in response to a packet sent from the source at time | ||||

T1. The complete Vector gives information over the dimension of | ||||

space. | ||||

2.8. Matrix | The singleton elements of any vector are distinctly different from | |||

each other in terms of their measurement collection point. Different | ||||

vectors for common measurement points of interest are distinguished | ||||

by the source packet sending time. | ||||

Several vectors form a Matrix, which contains results observed in a | 2.10. Matrix | |||

Several vectors form a matrix, which contains results observed over a | ||||

sampling interval at different places in a network at different | sampling interval at different places in a network at different | |||

times. For instance, given One-way delay vectors V1={dT11, dT12,..., | times. For example, the One-way delay vectors V1={dT11, dT12,..., | |||

dT1N}, V2={dT21, dT22,..., dT2N},..., Vm={dTm1, dTm2,..., dTmN} for | dT1N}, V2={dT21, dT22,..., dT2N},..., Vm={dTm1, dTm2,..., dTmN} for | |||

Packet P1, P2,...,Pm, we can have a One-way delay Matrix {V1, | Packet P1, P2,...,Pm, form a One-way delay Matrix {V1, V2,...,Vm}. | |||

V2,...,Vm}. Additional to the information given by a Vector, a | The matrix organizes the vector information to present network | |||

Matrix is more powerful to present network performance in both space | performance in both space and time. | |||

and time dimensions. It normally corresponds to a sample in simple | ||||

A one-dimensional matrix (row) corresponds to a sample in simple | ||||

point-to-point measurement. | point-to-point measurement. | |||

The relation among Singleton, Vector and Matrix can be shown in the | The relationship among singleton, sample, vector and matrix is | |||

following Figure 3. | illustrated in the following Figure 3. | |||

Point of Singleton | points of singleton | |||

interest / Samples | interest / samples(time) | |||

,----. ^ / | ,----. ^ / | |||

/ R1.....| / R1dT1 R1dT2 R1dT3 ... R3dTk \ | / R1.....| / R1dT1 R1dT2 R1dT3 ... R3dTk \ | |||

/ \ | | | | / \ | | | | |||

; R2........| | R2dT1 R2dT2 R2dT3 ... R3dTk | | ; R2........| | R2dT1 R2dT2 R2dT3 ... R3dTk | | |||

Src | || | | | Src | || | | | |||

| R3....| | R3dT1 R3dT2 R3dT3 ... R3dTk | | | R3....| | R3dT1 R3dT2 R3dT3 ... R3dTk | | |||

| || | | | | || | | | |||

: ;| | | | : ;| | | | |||

\ / | | | | \ / | | | | |||

\ Rn......| \ RndT1 RndT2 RndT3 ... RndTk / | \ Rn......| \ RndT1 RndT2 RndT3 ... RndTk / | |||

`-----' +-------------------------------------> time | `-----' +-------------------------------------> time | |||

Vector Matrix | vector matrix | |||

(space) (time) | (space) (time and space) | |||

Figure 3: Relation beween Singletons, vectors and matrix | Figure 3: Relationship between singletons, samples, vectors and | |||

matrix | ||||

3. Motivations | 3. Brief Metric Descriptions | |||

All IPPM metrics are defined for end-to-end (source to destination) | The metrics for spatial and one-to-group measurement are based on the | |||

measurement of point-to-point paths. It is a logical extension to | source-to-destination, or end-to-end metrics defined by IETF in | |||

define metrics for multiparty measurements such as one to one | [[RFC2679], [RFC2680], [RFC3393], [RFC3432]. | |||

trajectory metrics and one to multipoint metrics. | ||||

3.1. Motivations for spatial metrics | This memo defines seven new spatial metrics using the [RFC2330] | |||

framework of parameters, units of measure, and measurement | ||||

methodologies. Each definition includes a section that describes | ||||

measurements constraints and issues, and provides guidance to | ||||

increase the accuracy of the results. | ||||

Decomposition of instantaneous end-to-end measures is needed: | The spatial metrics are: | |||

o Decomposing the performance of interdomain path is desirable to | o Type-P-Spatial-One-way-Delay-Vector divides the end-to-end Type-P- | |||

quantify the per-AS contribution to the performance. It is | One-way-Delay [RFC2679] into a spatial vector of one-way delay | |||

valuable to define standard spatial metrics before pursuing inter- | singletons. | |||

domain path performance specifications. | o Type-P-Spatial-One-way-Packet-Loss-Vector divides an end-to-end | |||

o Traffic engineering and troubleshooting applications benefit from | Type-P-One-way-Packet-Loss [RFC2680] into a spatial vector of | |||

spatial views of one-way delay and ipdv consumption, and | packet loss singletons. | |||

identification of the location of the lost of packets. | o Type-P-Spatial-One-way-ipdv-Vector divides an end-to-end Type-P- | |||

o Monitoring the performance of a multicast tree composed of MPLS | One-way-ipdv into a spatial vector of ipdv singletons. | |||

point-to-multipoint and inter-domain communication require spatial | o Using elements of the Type-P-Spatial-One-way-Delay-Vector metric, | |||

decomposition of the one-way delay, ipdv, and packet loss. | a sample called Type-P-Segment-One-way-Delay-Stream collects one- | |||

o Composition of metrics is needed to help measurement systems reach | way delay metrics between two points of interest on the path over | |||

large scale coverage. Spatial measures typically give the | time. | |||

individual performance of an intra domain segment and provide an | o Likewise, using elements of the Type-P-Spatial-Packet-Loss-Vector | |||

elementary piece of information needed to estimate interdomain | metric, a sample called Type-P-Segment-Packet-Loss-Stream collects | |||

performance based on composition of metrics. | one-way delay metrics between two points of interest on the path | |||

over time. | ||||

o Using the Type-P-Spatial-One-way-Delay-Vector metric, a sample | ||||

called Type-P-Segment-ipdv-prev-Stream, will be introduced to | ||||

compute ipdv metrics (using the previous packet selection | ||||

function) between two points of interest on the path over time. | ||||

o Again using the Type-P-Spatial-One-way-Delay-Vector metric, a | ||||

sample called Type-P-Segment-ipdv-min-Stream will define another | ||||

set of ipdv metrics (using the minimum delay packet selection | ||||

function) between two points of interest on the path over time. | ||||

3.2. Motivations for One-to-group metrics | The memo also defines three one-to-group metrics to measure the one- | |||

way performance between a source and a group of receivers. They are: | ||||

o Type-P-One-to-group-Delay-Vector collects the set of Type-P-one- | ||||

way-delay singletons between one sender and N receivers. | ||||

o Type-P-One-to-group-Packet-Loss-Vector collects the set of Type-P- | ||||

One-way-Packet-Loss singletons between one sender and N receivers. | ||||

o Type-P-One-to-group-ipdv-Vector collects the set of Type-P-One- | ||||

way-ipdv singletons between one sender and N receivers. | ||||

Finally, based on the one-to-group vector metrics listed above, | ||||

statistics are defined to capture single receiver performance, group | ||||

performance and the relative performance for a multiparty | ||||

communication: | ||||

o Using the Type-P-One-to-group-Delay-Vector, a metric called Type- | ||||

P-One-to-group-Receiver-n-Mean-Delay or RnMD, presents the mean of | ||||

delays between one sender and a single receiver 'n'. From this | ||||

metric, 3 additional metrics are defined to characterize the mean | ||||

delay over the entire group of receivers during the same time | ||||

interval: | ||||

* Type-P-One-to-group-Mean-Delay or GMD, presents the mean of | ||||

delays; | ||||

* Type-P-One-to-group-Range-Mean-Delay or GRMD, presents the | ||||

range of mean delays; | ||||

* Type-P-One-to-group-Max-Mean-Delay or GMMD, presents the | ||||

maximum of mean delays. | ||||

o Using the Type-P-One-to-group-Packet-Loss-Vector, a metric called | ||||

Type-P-One-to-group-Receiver-n-Loss-Ratio or RnLR, captures the | ||||

packet loss ratio between one sender and a single receiver 'n'. | ||||

Based on this definition, 2 more metrics are defined to | ||||

characterize packet loss over the entire group during the same | ||||

time interval: | ||||

* Type-P-One-to-group-Loss-Ratio or GLR, captures the overall | ||||

packet loss ratio for the entire group of receivers; | ||||

* Type-P-One-to-group-Range-Loss-Ratio, or GRLR, presents the | ||||

comparative packet loss ratio during the test interval between | ||||

one sender and N receivers. | ||||

o Using the Type-P-One-to-group-Packet-Loss-Vector, a metric called | ||||

Type-P-One-to-group-Receiver-n-Comp-Loss-Ratio, or RnCLR, computes | ||||

a packet loss ratio using the maximum number of packets received | ||||

at any receiver. | ||||

o Using Type-P-One-to-group-ipdv-Vector, a metric called Type-P-One- | ||||

to-group-Range-Delay-Variation, or GRDV, presents the range of | ||||

delay variation between one sender and a group of receivers. | ||||

4. Motivations | ||||

All existing IPPM metrics are defined for end-to-end (source to | ||||

destination) measurement of point-to-point paths. It is logical to | ||||

extend them to multiparty situations such as one to one trajectory | ||||

metrics and one to multipoint metrics. | ||||

4.1. Motivations for spatial metrics | ||||

Spatial metrics are needed for: | ||||

o Decomposing the performance of an inter-domain path to quantify | ||||

the per-AS contribution to the end-to-end performance. | ||||

o Traffic engineering and troubleshooting, which benefit from | ||||

spatial views of one-way delay and ipdv consumption, or | ||||

identification of the path segment where packets were lost. | ||||

o Monitoring the decomposed performance of a multicast tree based on | ||||

of MPLS point-to-multipoint communications. | ||||

o Dividing end-to-end metrics, so that some segment measurements can | ||||

be re-used and help measurement systems reach large-scale | ||||

coverage. Spatial measures could characterize the performance of | ||||

an intra-domain segment and provide an elementary piece of | ||||

information needed to estimate inter-domain performance to another | ||||

destination using Spatial Composition metrics | ||||

[I-D.ietf-ippm-spatial-composition]. | ||||

4.2. Motivations for One-to-group metrics | ||||

While the node-to-node based spatial measures can provide very useful | While the node-to-node based spatial measures can provide very useful | |||

data in the view of each connection, we also need measures to present | data in the view of each connection, we also need measures to present | |||

the performance of a multiparty communication topology. A simple | the performance of a multiparty communication topology. A simple | |||

one-way metric cannot completely describe the multiparty situation. | point-to-point metric cannot completely describe the multiparty | |||

New one-to-group metrics assess performance of all the paths for | situation. New one-to-group metrics assess performance of the | |||

further statistical analysis. The new metrics proposed in this stage | multiple paths for further statistical analysis. The new metrics are | |||

are named one-to-group performance metrics, and they are based on the | named one-to-group performance metrics, and they are based on the | |||

unicast metrics defined in IPPM WG. One-to-group metrics are one-way | unicast metrics defined in IPPM RFCs. One-to-group metrics are one- | |||

metrics from one source to a group of destinations. The metrics are | way metrics from one source to a group of destinations, or receivers. | |||

helpful for judging the network performance of multiparty | The metrics are helpful for judging the overall performance of a | |||

communications and can also be used to describe the variation of | multiparty communications network, and for describing the performance | |||

performance delivered to a group of destination hosts and their | variation across a group of destinations. | |||

users. | ||||

One-to-group performance metrics are needed for several reasons: | One-to-group performance metrics are needed for: | |||

o For designing and engineering multicast trees and MPLS point-to- | o Designing and engineering multicast trees and MPLS point-to- | |||

multipoint LSP; | multipoint LSPs. | |||

o For evaluating and controlling of the quality of the multicast | o Evaluating and controlling the quality of multicast services, | |||

services; | including inter-domain multicast. | |||

o For controlling the performance of the inter domain multicast | o Presenting and evaluating the performance requirements for | |||

services; | ||||

o For presenting and evaluating the performance requirements for | ||||

multiparty communications and overlay multicast. | multiparty communications and overlay multicast. | |||

To understand the packet transfer performance between one source and | To understand the packet transfer performance between one source and | |||

any one receiver in the multiparty communication group, we need to | any one receiver in the multiparty communication group, we need to | |||

collect instantaneous end-to-end metrics, or singletons. It will | collect instantaneous end-to-end metrics, or singletons. This gives | |||

give a very detailed insight into each branch of the multicast tree | a very detailed view into the performance of each branch of the | |||

in terms of end-to-end absolute performance. This detail can provide | multicast tree, and can provide clear and helpful information for | |||

clear and helpful information for engineers to identify the sub-path | engineers to identify the branch with problems in a complex | |||

with problems in a complex multiparty routing tree. | multiparty routing tree. | |||

The one-to-group metrics described in this memo introduce the | The one-to-group metrics described in this memo introduce the | |||

multiparty topology to the IPPM working group; the goal is to measure | multiparty topology into the IPPM framework, and describe the | |||

the performance delivered to a group of users who are receiving | performance delivered to a group receiving packets from the same | |||

packets from the same source. The concept extends the "path" in the | source. The concept extends the "path" of the point-to-point | |||

one-way measurement to "path tree" to cover both one-to-one and one- | measurement to "path tree" to cover one-to-many topologies. If | |||

to-many communications. If applied to one-to-one communications, the | applied to one-to-one topology, the one-to-group metrics provide | |||

one-to-group metrics provide exactly the same results as the | exactly the same results as the corresponding one-to-one metrics. | |||

corresponding one-to-one metrics. | ||||

3.3. Discussion on Group-to-one and Group-to-group metrics | 4.3. Discussion on Group-to-one and Group-to-group metrics | |||

We note that points of interest can also be selected to define | We note that points of interest can also be selected to define | |||

measurements on group-to-one and group-to-group topologies. These | measurements on group-to-one and group-to-group topologies. These | |||

topologies are currently beyond the scope of this memo, because they | topologies are beyond the scope of this memo, because they would | |||

would involve multiple packets launched from different sources. | involve multiple packets launched from different sources. However, | |||

However, we can give some clues here on these two cases. | this section gives some insights on these two cases. | |||

The measurements for group-to-one topology can be easily derived from | The measurements for group-to-one topology can be easily derived from | |||

the one-to-group measurement. The measurement point is the reference | the one-to-group measurement. The measurement point is the host that | |||

point that is acting as a receiver while all of clients/receivers | is acting as a receiver while all other hosts act as sources in this | |||

defined for one-to-group measurement act as sources in this case. | case. | |||

For the group-to-group connection topology, it is difficult to define | The group-to-group communication topology has no obvious focal point: | |||

the reference point and therefore it is difficult to define the | the sources and the measurement collection points can be anywhere. | |||

measurement points. However, we can always avoid this confusion by | However, it is possible to organize the problem by applying | |||

treating the connections as one-to-group or group-to-one in our | measurements in one-to-group or group-to-one topologies for each host | |||

measurements without consideration on how the real communication will | in a uniform way (without taking account of how the real | |||

be carried out. For example, if one group of hosts < ha, hb, hc, | communication might be carried out). For example, one group of hosts | |||

..., hn > are acting as sources to send data to another group of | < ha, hb, hc, ..., hn > might act as sources to send data to another | |||

hosts < Ha, Hb, Hc, ..., Hm >, we can always decompose them into n | group of hosts < Ha, Hb, Hc, ..., Hm >, and they can be organized | |||

one-to-group communications as < ha, Ha, Hb, Hc, ..., Hm >, < hb, Ha, | into n sets of points of interest for one-to-group communications: | |||

Hb, Hc, ..., Hm >, <hc, Ha, Hb, Hc, ..., Hm >, ..., < hn, Ha, Hb, Hc, | ||||

..., Hm >. | ||||

4. Spatial vectors metrics definitions | < ha, Ha, Hb, Hc, ..., Hm >, < hb, Ha, Hb, Hc, ..., Hm >, <hc, Ha, | |||

Hb, Hc, ..., Hm >, ..., < hn, Ha, Hb, Hc, ..., Hm >. | ||||

This section defines vectors for the decomposition of end-to-end | 5. Spatial vector metrics definitions | |||

singleton metrics over a path. | ||||

Spatial vectors metrics are based on the decomposition of standard | This section defines vectors for the spatial decomposition of end-to- | |||

end singleton metrics over a path. | ||||

Spatial vector metrics are based on the decomposition of standard | ||||

end-to-end metrics defined by the IPPM WG in [RFC2679], [RFC2680], | end-to-end metrics defined by the IPPM WG in [RFC2679], [RFC2680], | |||

[RFC3393] and [RFC3432]. | [RFC3393] and [RFC3432]. | |||

Definitions are coupled with the corresponding end-to-end metrics. | The spatial vector definitions are coupled with the corresponding | |||

Methodology specificities are common to all the vectors defined and | end-to-end metrics. Measurement methodology aspects are common to | |||

are consequently discussed in a common section. | all the vectors defined and are consequently discussed in a common | |||

section. | ||||

4.1. A Definition for Spatial One-way Delay Vector | 5.1. A Definition for Spatial One-way Delay Vector | |||

This section is coupled with the definition of Type-P-One-way-Delay | This section is coupled with the definition of Type-P-One-way-Delay | |||

of the section 3 of [RFC2679]. When a parameter of this definition | of the section 3 of [RFC2679]. When a parameter from the definition | |||

is first used in this section, it will be tagged with a trailing | in [RFC2679] is re-used in this section, the first instance will be | |||

asterisk. | tagged with a trailing asterisk. | |||

Sections 3.5 to 3.8 of [RFC2679] give requirements and applicability | Sections 3.5 to 3.8 of [RFC2679] give requirements and applicability | |||

statements for end-to-end one-way-delay measurements. They are | statements for end-to-end one-way-delay measurements. They are | |||

applicable to each point of interest Hi involved in the measure. | applicable to each point of interest, Hi, involved in the measure. | |||

Spatial one-way-delay measurement SHOULD be respectful of them, | Spatial one-way-delay measurement MUST respect them, especially those | |||

especially those related to methodology, clock, uncertainties and | related to methodology, clock, uncertainties and reporting. | |||

reporting. | ||||

4.1.1. Metric Name | 5.1.1. Metric Name | |||

Type-P-Spatial-One-way-Delay-Vector | Type-P-Spatial-One-way-Delay-Vector | |||

4.1.2. Metric Parameters | 5.1.2. Metric Parameters | |||

o Src*, the IP address of the sender. | o Src*, the IP address of the sender. | |||

o Dst*, the IP address of the receiver. | o Dst*, the IP address of the receiver. | |||

o i, An integer in the ordered list <1,2,...,n> of hosts in the | o i, an integer in the ordered list <1,2,...,n> of hosts in the | |||

path. | path. | |||

o Hi, A host* of the path digest. | o Hi, a host in the path digest. | |||

o T*, a time, the sending (or initial observation) time for a | o T*, a time, the sending (or initial observation) time for a | |||

measured packet. | measured packet. | |||

o dT*, a delay, the one-way delay for a measured packet. | o dT*, a delay, the one-way delay for a measured packet. | |||

o <dT1,..., dTn> a list of delay. | o dTi, a delay, the one-way delay for a measured packet from the | |||

o P*, the specification of the packet type. | source to host Hi. | |||

o <H1, H2,..., Hn>, hosts path digest. | o <dT1,... dTi,... dTn> a list of n delay singletons. | |||

o Type-P*, the specification of the packet type. | ||||

o <H1, H2,..., Hn>, a path host digest. | ||||

4.1.3. Metric Units | 5.1.3. Metric Units | |||

The value of Type-P-Spatial-One-way-Delay-Vector is a sequence of | The value of Type-P-Spatial-One-way-Delay-Vector is a sequence of | |||

times. | times (a real number in the dimension of seconds with sufficient | |||

resolution to convey the results). | ||||

4.1.4. Definition | 5.1.4. Definition | |||

Given a Type-P packet sent by the sender Src at wire-time (first bit) | Given a Type-P packet sent by the Src at wire-time (first bit) T to | |||

T to the receiver Dst in the path <H1, H2,..., Hn>. Given the | the receiver Dst on the path <H1, H2,..., Hn>. There is a sequence | |||

sequence of values <T+dT1,T+dT2,...,T+dTn,T+dT> such that dT is the | of values <T+dT1,T+dT2,...,T+dTn,T+dT> such that dT is the Type-P- | |||

Type-P-One-way-Delay from Src to Dst and such that for each Hi of the | One-way-Delay from Src to Dst, and for each Hi of the path, T+dTi is | |||

path, T+dTi is either a real number corresponding to the wire-time | either a real number corresponding to the wire-time the packet passes | |||

the packet passes (last bit received) Hi, or undefined if the packet | (last bit received) Hi, or undefined if the packet does not pass Hi | |||

never passes Hi. | within a specified loss threshold* time. | |||

Type-P-Spatial-One-way-Delay-Vector metric is defined for the path | Type-P-Spatial-One-way-Delay-Vector metric is defined for the path | |||

<Src, H1, H2,..., Hn, Dst> as the sequence of values | <Src, H1, H2,..., Hn, Dst> as the sequence of values | |||

<T,dT1,dT2,...,dTn,dT>. | <T,dT1,dT2,...,dTn,dT>. | |||

4.1.5. Discussion | 5.1.5. Discussion | |||

Following are specific issues which may occur: | Some specific issues that may occur are as follows: | |||

o the delay looks to decrease: dTi > DTi+1. This may occur despite | o the delay singletons "appear" to decrease: dTi > DTi+1. This may | |||

it does not make sense per definition: | occur despite being physically impossible with the definition | |||

* This is frequently due to some clock synchronization issue. | used. | |||

This point is discussed in the section 3.7.1. "Errors or | * This is frequently due to a measurement clock synchronization | |||

uncertainties related to Clocks" of [RFC2679]. Consequently, | issue. This point is discussed in the section 3.7.1. "Errors | |||

times of a measure at different hosts do not guaranty the | or uncertainties related to Clocks" of [RFC2679]. | |||

ordering of the hosts on the path of a measure. | Consequently, the values of delays measured at multiple hosts | |||

* During some change of routes the order of 2 hosts may change on | may not match the order of those hosts on the path. | |||

the main path; | * The actual order of hosts on the path may change due to | |||

* The location of the point of interest in the device influences | reconvergence (e.g., recovery from a link failure). | |||

the result. If the packet is not observed directly on the | * The location of the measurement collection point in the device | |||

input interface the delay includes buffering time and | influences the result. If the packet is not observed directly | |||

on the input interface the delay includes buffering time and | ||||

consequently an uncertainty due to the difference between 'wire | consequently an uncertainty due to the difference between 'wire | |||

time' and 'host time' | time' and 'host time'. | |||

4.2. A Definition for Spatial One-way Packet Loss Vector | 5.2. A Definition for Spatial Packet Loss Vector | |||

This section is coupled with the definition of Type-P-One-way-Packet- | This section is coupled with the definition of Type-P-One-way-Packet- | |||

Loss. Then when a parameter from the section 2 of [RFC2680] is first | Loss. When a parameter from the section 2 of [RFC2680] is used in | |||

used in this section, it will be tagged with a trailing asterisk. | this section, the first instance will be tagged with a trailing | |||

asterisk. | ||||

Sections 2.5 to 2.8 of [RFC2680] give requirements and applicability | Sections 2.5 to 2.8 of [RFC2680] give requirements and applicability | |||

statements for end-to-end one-way packet loss measurements. They are | statements for end-to-end one-way packet loss measurements. They are | |||

applicable to each point of interest Hi involved in the measure. | applicable to each point of interest, Hi, involved in the measure. | |||

Spatial packet loss measurement SHOULD be respectful of them, | Spatial packet loss measurement MUST respect them, especially those | |||

especially those related to methodology, clock, uncertainties and | related to methodology, clock, uncertainties and reporting. | |||

reporting. | ||||

Following we define the spatial metric, then we adapt some of the | The following sections define the spatial loss vector, adapt some of | |||

points above and introduce points specific to spatial measurement. | the points above, and introduce points specific to spatial loss | |||

measurement. | ||||

4.2.1. Metric Name | 5.2.1. Metric Name | |||

Type-P-Spatial-One-way-Packet-Loss-Vector | Type-P-Spatial-Packet-Loss-Vector | |||

4.2.2. Metric Parameters | 5.2.2. Metric Parameters | |||

o Src*, the IP address of the sender. | o Src*, the IP address of the sender. | |||

o Dst*, the IP address of the receiver. | o Dst*, the IP address of the receiver. | |||

o i, an integer which ordered the hosts in the path. | o i, an integer in the ordered list <1,2,...,n> of hosts in the | |||

path. | ||||

o Hi, points of interests of the path digest. | o Hi, points of interest from the path digest. | |||

o T*, a time, the sending time for a measured packet. | o T*, a time, the sending time for a measured packet. | |||

o <dT1,..., dTn, dT>, a list of delay. | o dTi, a delay, the one-way delay for a measured packet from the | |||

o P*, the specification of the packet type. | source to host Hi. | |||

o <H1, H2,..., Hn>, hosts path digest. | o <dT1,..., dTn>, list of n delay singletons. | |||

o Type-P*, the specification of packet type. | ||||

o <H1, H2,..., Hn>, a host path digest. | ||||

o <L1, L2, ...,Ln>, a list of Boolean values. | o <L1, L2, ...,Ln>, a list of Boolean values. | |||

4.2.3. Metric Units | 5.2.3. Metric Units | |||

The value of Type-P-Spatial-One-way-Packet-Loss-Vector is a sequence | The value of Type-P-Spatial-Packet-Loss-Vector is a sequence of | |||

of Boolean values. | Boolean values. | |||

4.2.4. Definition | 5.2.4. Definition | |||

Given a Type-P packet sent by the sender Src at time T to the | Given a Type-P packet sent by the Src at time T to the receiver Dst | |||

receiver Dst in the path <H1, H2, ..., Hn>. Given the sequence of | on the path <H1, H2, ..., Hn>. For the sequence of times <T+dT1,T+ | |||

times <T+dT1,T+dT2,...,T+dTn> the packet passes in <H1, H2 ..., Hn>, | dT2,..., T+dTi, ...,T+dTn> the packet passes in <H1, H2, ..., Hi, | |||

we define Type-P-One-way-Packet-Lost-Vector metric as the sequence of | ..., Hn>, define the Type-P-Packet-Loss-Vector metric as the sequence | |||

values <L1, L2, ..., Ln> such that for each Hi of the path, a value | of values <T, L1, L2, ..., Ln> such that for each Hi of the path, a | |||

of 0 for Li means that dTi is a finite value, and a value of 1 means | value of 0 for Li means that dTi is a finite value, and a value of 1 | |||

that dTi is undefined. | means that dTi is undefined. | |||

4.2.5. Discussion | 5.2.5. Discussion | |||

Following are specific issues which may occur: | Some specific issues that may occur are as follows: | |||

o The result includes the sequence 1,0. This may occur under | o The result might include the sequence of values 1,0. Although | |||

specific situations: | this appears physically impossible (a packet is lost, then re- | |||

* During some change of routes a packet may be seen by a host but | appears later on the path): | |||

not by it successor on the main path; | * The actual hosts on the path may change due to reconvergence | |||

(e.g., recovery from a link failure). | ||||

* The order of hosts on the path may change due to reconvergence. | ||||

* A packet may not be observed in a host due to some buffer or | * A packet may not be observed in a host due to some buffer or | |||

CPU overflow in the point of interest; | CPU overflow at the measurement collection point. | |||

4.3. A Definition for Spatial One-way Ipdv Vector | 5.3. A Definition for Spatial One-way Ipdv Vector | |||

This section uses parameters from the definition of Type-P-One-way- | When a parameter from section 2 of [RFC3393] (the definition of Type- | |||

ipdv. When a parameter from section 2 of [RFC3393] is first used in | P-One-way-ipdv) is used in this section, the first instance will be | |||

this section, it will be tagged with a trailing asterisk. | tagged with a trailing asterisk. | |||

In the following we adapt some of them and introduce points specific | The following sections define the spatial ipdv vector, adapt some of | |||

to spatial measurement. | the points above, and introduce points specific to spatial ipdv | |||

measurement. | ||||

4.3.1. Metric Name | 5.3.1. Metric Name | |||

Type-P-Spatial-One-way-ipdv-Vector | Type-P-Spatial-One-way-ipdv-Vector | |||

4.3.2. Metric Parameters | 5.3.2. Metric Parameters | |||

o Src*, the IP address of the sender. | o Src*, the IP address of the sender. | |||

o Dst*, the IP address of the receiver. | o Dst*, the IP address of the receiver. | |||

o i, An integer in the ordered list <1,2,...,n> of hosts in the | o i, an integer in the ordered list <1,2,...,n> of hosts in the | |||

path. | path. | |||

o Hi, A host* of the path digest. | o Hi, a host of the path digest. | |||

o T1*, a time, the sending time for a first measured packet. | o T1*, a time, the sending time for a first measured packet. | |||

o T2*, a time, the sending time for a second measured packet. | o T2*, a time, the sending time for a second measured packet. | |||

o dT*, a delay, the one-way delay for a measured packet. | o dT*, a delay, the one-way delay for a measured packet. | |||

o P*, the specification of the packets type. | o dTi, a delay, the one-way delay for a measured packet from the | |||

source to host Hi. | ||||

o Type-P*, the specification of the packets type. | ||||

o P1, the first packet sent at time T1. | o P1, the first packet sent at time T1. | |||

o P2, the second packet sent at time T2. | o P2, the second packet sent at time T2. | |||

o <H1, H2,..., Hn>, hosts path digest. | o <H1, H2,..., Hn>, a host path digest. | |||

o <T1,dT1.1, dT1.2,..., dT1.n,dT1>, the Type-P-Spatial-One-way- | o <T1,dT1.1, dT1.2,..., dT1.n,dT1>, the Type-P-Spatial-One-way- | |||

Delay-Vector for packet sent at time T1. | Delay-Vector for packet sent at time T1. | |||

o <T2,dT2.1, dT2.2,..., dT2.n,dT2>, the Type-P-Spatial-One-way- | o <T2,dT2.1, dT2.2,..., dT2.n,dT2>, the Type-P-Spatial-One-way- | |||

Delay-Vector for packet sent at time T2. | Delay-Vector for packet sent at time T2. | |||

o L*, a packet length in bits. The packets of a Type P packet | o L*, a packet length in bits. The packets of a Type P packet | |||

stream from which the Type-P-Spatial-One-way-Delay-Vector metric | stream from which the Type-P-Spatial-One-way-Delay-Vector metric | |||

is taken MUST all be of the same length. | is taken MUST all be of the same length. | |||

4.3.3. Metric Units | 5.3.3. Metric Units | |||

The value of Type-P-Spatial-One-way-ipdv-Vector is a sequence of | The value of Type-P-Spatial-One-way-ipdv-Vector is a sequence of | |||

times. | times (a real number in the dimension of seconds with sufficient | |||

resolution to convey the results). | ||||

4.3.4. Definition | 5.3.4. Definition | |||

Given P1 the Type-P packet sent by the sender Src at wire-time (first | Given P1 the Type-P packet sent by the sender Src at wire-time (first | |||

bit) T1 to the receiver Dst and <T1, dT1.1, dT1.2,..., dT1.n, dT1> | bit) T1 to the receiver Dst and <T1, dT1.1, dT1.2,..., dT1.n, dT1> | |||

its Type-P-Spatial-One-way-Delay-Vector over the path <H1, H2,..., | its Type-P-Spatial-One-way-Delay-Vector over the path <H1, H2,..., | |||

Hn>. | Hn>. | |||

Given P2 the Type-P packet sent by the sender Src at wire-time (first | Given P2 the Type-P packet sent by the sender Src at wire-time (first | |||

bit) T2 to the receiver Dst and <T2, dT2.1, dT2.2,..., dT2.n, dT2> | bit) T2 to the receiver Dst and <T2, dT2.1, dT2.2,..., dT2.n, dT2> | |||

its Type-P-Spatial-One-way-Delay-Vector over the same path. | its Type-P-Spatial-One-way-Delay-Vector over the same path. | |||

Type-P-Spatial-One-way-ipdv-Vector metric is defined as the sequence | Type-P-Spatial-One-way-ipdv-Vector metric is defined as the sequence | |||

of values <T2-T1, dT2.1-dT1.1, dT2.2-dT1.2 ,..., dT2.n-dT1.n, dT2- | of values <T1, T2, dT2.1-dT1.1, dT2.2-dT1.2 ,..., dT2.n-dT1.n, dT2- | |||

dT1> such that for each Hi of the path <H1, H2,..., Hn>, dT2.i-dT1.i | dT1> such that for each Hi of the path <H1, H2,..., Hn>, dT2.i-dT1.i | |||

is either a real number if the packets P1 and P2 passe Hi at wire- | is either a real number if the packets P1 and P2 pass Hi at wire-time | |||

time (last bit) dT1.i, respectively dT2.i, or undefined if at least | (last bit) dT1.i and dT2.i respectively, or undefined if at least one | |||

one of them never passes Hi. T2-T1 is the inter-packet emission | of them never passes Hi (and the respective one-way delay is | |||

interval and dT2-dT1 is ddT* the Type-P-One-way-ipdv at T1,T2*. | undefined). The T1,T2* pair indicates the inter-packet emission | |||

interval and dT2-dT1 is ddT* the Type-P-One-way-ipdv. | ||||

4.4. Spatial Methodology | 5.4. Spatial Methodology | |||

Methodology, reporting and uncertainties points specified in section | The methodology, reporting specifications, and uncertainties | |||

3 of [RFC2679] applies to each point of interest Hi measuring a | specified in section 3 of [RFC2679] apply to each point of interest | |||

element of a spatial delay vector. | (or measurement collection point), Hi, measuring an element of a | |||

spatial delay vector. | ||||

Methodology, reporting and uncertainties points specified in section | Likewise, the methodology, reporting specifications, and | |||

2 of [RFC2680] applies to each point of interest Hi measuring a | uncertainties specified in section 2 of [RFC2680] apply to each point | |||

element of a spatial packet loss vector. | of interest, Hi, measuring an element of a spatial packet loss | |||

vector. | ||||

Sections 3.5 to 3.7 of [RFC3393] give requirements and applicability | Sections 3.5 to 3.7 of [RFC3393] give requirements and applicability | |||

statements for end-to-end One-way ipdv measurements. They are | statements for end-to-end One-way ipdv measurements. They are | |||

applicable to each point of interest Hi involved in the measure. | applicable to each point of interest, Hi, involved in the measure. | |||

Spatial One-way ipdv measurement SHOULD be respectful of methodology, | Spatial One-way ipdv measurement MUST respect the methodology, clock, | |||

clock, uncertainties and reporting aspects given in this section. | uncertainties and reporting aspects given there. | |||

Generally, for a given Type-P of length L, in a given Hi, the | Generally, for a given Type-P packet of length L at a specific Hi, | |||

methodology for spatial vector metrics may proceed as follows: | the methodology for spatial vector metrics may proceed as follows: | |||

o At each Hi, points of interest prepare to capture the packet sent | o At each Hi, points of interest/measurement collection points | |||

a time T, take a timestamp Ti', determine the internal delay | prepare to capture the packet sent at time T, record a timestamp | |||

correction dTi' (See section 3.7.1. "Errors or uncertainties | Ti', and determine the internal delay correction dTi' (See section | |||

related to Clocks" of [RFC2679]), | 3.7.1. "Errors or uncertainties related to Clocks" of [RFC2679]); | |||

o Each Hi extracts the path ordering information from the packet | o Each Hi extracts the path ordering information from the packet | |||

(e.g. time-to-live); | (e.g. time-to-live); | |||

o Each Hi compute the wiretime from Src to Hi: Ti = Ti' - dTi'. | o Each Hi computes the corrected wiretime from Src to Hi: Ti = Ti' - | |||

This arrival time is undefined (infinite) if the packet is not | dTi'. This arrival time is undefined if the packet is not | |||

detected after the 'loss threshold' duration; | detected after the 'loss threshold' duration; | |||

o Each Hi extracts the timestamp T from the packet; | o Each Hi extracts the timestamp T from the packet; | |||

o Each Hi computes the one-way-delay from Src to Hi: dTi = Ti - T; | o Each Hi computes the one-way-delay from Src to Hi: dTi = Ti - T; | |||

o The reference point gathers the result of each Hi and order them | o The reference point gathers the result of each Hi and arranges | |||

according to the path ordering information received to build the | them according to the path ordering information received to build | |||

type-P spatial one-way vector (e.g. Type-P-Spatial-One-way-Delay- | the type-P spatial one-way vector (e.g. Type-P-Spatial-One-way- | |||

Vector metric <T, dT1, dT2,..., dTn, dT> ) over the path <Src, H1, | Delay-Vector metric <T, dT1, dT2,..., dTn, dT>) over the path | |||

H2,..., Hn, Dst> at time T. | <Src, H1, H2,..., Hn, Dst> at time T. | |||

4.4.1. Loss threshold | 5.4.1. Packet Loss Detection | |||

Loss threshold is the centrality of any methodology because it | In an pure end-to-end measurement, packet losses are detected by the | |||

determines the presence the packet in the measurement process of the | receiver only. A packet is lost when Type-P-One-way-Delay is | |||

point of interest and consequently determines any ground truth metric | undefined or very large (See section 2.4 ans 2.5 of [RFC2680] and | |||

result. It determines the presence of an effective delay, and bias | section 3.5 of [RFC2680]). A packet is deemed lost by the receiver | |||

the measure of ipdv, of packet loss and of the statistics. | after a duration which starts at the time the packet is sent. This | |||

timeout value is chosen by a measurement process; It determines the | ||||

threshold between recording a long packet transfer time as a finite | ||||

value or an undefined value. | ||||

This is consistent for end-to-end but impacts spatial measure: | In a spatial measurement, packet losses may be detected at several | |||

depending on the consistency of the loss threshold among the points | measurement collection points. Depending on the consistency of the | |||

of interest, a packet may be considered loss a one host but present | packet loss detections among the points of interest, a packet may be | |||

in another one, or may be observed by the last host (last hop) of the | considered as lost at one point despite having a finite delay at | |||

path but considered lost by Dst. The analysis of such results is not | another one, or may be observed by the last measurement collection | |||

deterministic: Has the path change? Does the packet arrive at | point of the path but considered lost by Dst. | |||

destination or was it lost during the last mile? The same applies, | ||||

of course, for one-way-delay measures: a delay measured may be | ||||

infinite at one host but a real value in another one, or may be | ||||

measured as a real value by the last host of the path but observed as | ||||

infinite by Dst. The loss threshold should be set up with the same | ||||

value in each host of the path and in the destination. The loss | ||||

threshold must be systematically reported to permit careful | ||||

introspection and to avoid the introduction of any contradiction in | ||||

the statistic computation process. | ||||

4.4.2. Host Path Digest | There is a risk of misinterpreting such results: Has the path | |||

changed? Did the packet arrive at the destination or was it lost on | ||||

the very last link? | ||||

The methodology given above relies on the order of the points of | The same concern applies to one-way-delay measures: a delay measured | |||

interest over the path to [RFC2679] one's. | may be computed as infinite by one observation point but as a real | |||

value by another one, or may be measured as a real value by the last | ||||

observation point of the path but designated as undefined by Dst. | ||||

A test packets may cross several times the same host resulting in the | The observation/measurement collection points and the destination | |||

repetition of one or several hosts in the Path Digest. | SHOULD use consistent methods to detect packets losses. The methods | |||

and parameters must be systematically reported to permit careful | ||||

comparison and to avoid introducing any confounding factors in the | ||||

analysis. | ||||

As an example. This occurs typically during rerouting phases which | 5.4.2. Host Path Digest | |||

introduce temporary micro loops. During such an event the host path | ||||

digest for a packet crossing Ha and Hb may include the pattern <Hb, | ||||

Ha, Hb, Ha, Hb> meaning that Ha ended the computation of the new path | ||||

before Hb and that the initial path wath from Ha to Hb and that the | ||||

new path is from Hb to Ha. | ||||

Consequently, duplication of hosts in the Path Digest of a vectors | The methodology given above relies on knowing the order of the hosts/ | |||

MUST be identified before statistics computation to avoid corrupted | measurement collection points on the path [RFC2330]. | |||

results' production. | ||||

5. Spatial Segments metrics definitions | Path instability might cause a test packet to be observed more than | |||

once by the same host, resulting in the repetition of one or more | ||||

hosts in the Path Digest. | ||||

For example, repeated observations may occur during rerouting phases | ||||

which introduce temporary micro loops. During such an event the host | ||||

path digest for a packet crossing Ha and Hb may include the pattern | ||||

<Hb, Ha, Hb, Ha, Hb> meaning that Ha ended the computation of the new | ||||

path before Hb and that the initial path was from Ha to Hb and that | ||||

the new path is from Hb to Ha. | ||||

Consequently, duplication of hosts in the path digest of a vector | ||||

MUST be identified before computation of statistics to avoid | ||||

producing corrupted information. | ||||

6. Spatial Segment Metrics Definitions | ||||

This section defines samples to measure the performance of a segment | This section defines samples to measure the performance of a segment | |||

of a path over time. Definitions rely on matrix of the spatial | of a path over time. The definitions rely on the matrix of the | |||

vector metrics defined above. | spatial vector metrics defined above. | |||

Firstly it defines a sample of one-way delay, Type-P-Segment-One-way- | Firstly this section defines a sample of one-way delay, Type-P- | |||

Delay-Stream, and a sample of packet loss, Type-P-segment-Packet- | Segment-One-way-Delay-Stream, and a sample of packet loss, Type-P- | |||

loss-Stream. | segment-Packet-Loss-Stream. | |||

Then it defines 2 different samples of ipdv. The first metric, Type- | Then it defines 2 different samples of ipdv: Type-P-Segment-ipdv- | |||

P-Segment-One-way-ipdv-prev-Stream, uses the previous packet as the | prev-Stream uses the current and previous packets as the selection | |||

selection function. The second metric, Type-P-Segment-One-way-ipdv- | function, and Type-P-Segment-ipdv-min-Stream, uses the minimum delay | |||

min-Stream, uses the minimum delay as the selection. | as one of the selected packets in every pair. | |||

5.1. A Definition of a sample of One-way Delay of a segment of the path | 6.1. A Definition of a Sample of One-way Delay of a Segment of the Path | |||

This metric defines a sample of One-way delays over time between a | This metric defines a sample of One-way delays over time between a | |||

pair of hosts of a path. | pair of hosts on a path. Since it is very close semantically to the | |||

metric Type-P-One-way-Delay-Poisson-Stream defined in section 4 of | ||||

As its semantic is very close to the metric Type-P-Packet-loss-Stream | [RFC2679], sections 4.5 to 4.8 of [RFC2679] are integral parts of the | |||

defined in section 4 of [RFC2679], sections 4.5 to 4.8 of [RFC2679] | definition text below. | |||

are part of the current definition. | ||||

5.1.1. Metric Name | 6.1.1. Metric Name | |||

Type-P-Segment-One-way-Delay-Stream | Type-P-Segment-One-way-Delay-Stream | |||

5.1.2. Metric Parameters | 6.1.2. Metric Parameters | |||

o Src*, the IP address of the sender. | o Src, the IP address of the sender. | |||

o Dst*, the IP address of the receiver. | o Dst, the IP address of the receiver. | |||

o P*, the specification of the packet type. | o Type-P, the specification of the packet type. | |||

o i, an integer in the ordered list <1,2,...,n> of hosts in the | o i, an integer in the ordered list <1,2,...,n> of hosts in the | |||

path. | path. | |||

o k, an integer which orders the packets sent. | o k, an integer which orders the packets sent. | |||

o a and b, 2 integers where b > a. | o a and b, two integers where b > a. | |||

o Hi, a host* of the path digest. | o Hi, a host of the path digest. | |||

o <H1,..., Ha, ..., Hb, ...., Hn>, hosts path digest. | o <H1,..., Ha, ..., Hb, ...., Hn>, a host path digest. | |||

o <T1, T2, ..., Tm>, a list of times. | o <T1, T2, ..., Tm>, a list of times. | |||

5.1.3. Metric Units | 6.1.3. Metric Units | |||

The value of a Type-P-Segment-One-way-Delay-Stream is a pair of | The value of a Type-P-Segment-One-way-Delay-Stream is a pair of: | |||

list of times <T1, T2, ..., Tm>; | A list of times <T1, T2, ..., Tm>; | |||

sequence of delays. | A sequence of delays. | |||

5.1.4. Definition | 6.1.4. Definition | |||

Given 2 hosts, Ha and Hb, of the path <H1, H2,..., Ha, ..., Hb, ..., | Given 2 hosts, Ha and Hb, of the path <H1, H2,..., Ha, ..., Hb, ..., | |||

Hn>, given the matrix of Type-P-Spatial-One-way-Delay-Vector for the | Hn>, and the matrix of Type-P-Spatial-One-way-Delay-Vector for the | |||

packets sent from Src to Dst at times <T1, T2, ..., Tm-1, Tm> : | packets sent from Src to Dst at times <T1, T2, ..., Tm-1, Tm> : | |||

<T1, dT1.1, dT1.2, ..., dT1.a, ..., dT1.b,..., dT1.n, dT1>; | <T1, dT1.1, dT1.2, ..., dT1.a, ..., dT1.b,..., dT1.n, dT1>; | |||

<T2, dT2.1, dT2.2, ..., dT2.a, ..., dT2.b,..., dT2.n, dT2>; | <T2, dT2.1, dT2.2, ..., dT2.a, ..., dT2.b,..., dT2.n, dT2>; | |||

... | ... | |||

<Tm, dTm.1, dTm.2, ..., dTm.a, ..., dTm.b,..., dTm.n, dTm>. | <Tm, dTm.1, dTm.2, ..., dTm.a, ..., dTm.b,..., dTm.n, dTm>. | |||

We define the sample Type-P-segment-One-way-Delay-Stream as the | We define the sample Type-P-segment-One-way-Delay-Stream as the | |||

sequence <dT1.ab, dT2.ab, ..., dTk.ab, ..., dTm.ab> such that for | sequence <dT1.ab, dT2.ab, ..., dTk.ab, ..., dTm.ab> such that for | |||

each time Tk, 'dTk.ab' is either the real number 'dTk.b - dTk.a' if | each time Tk, 'dTk.ab' is either the real number 'dTk.b - dTk.a' if | |||

the packet send a time Tk passes Ha and Hb or undefined if this | the packet sent at time Tk passes Ha and Hb or undefined if this | |||

packet never passes Ha or (inclusive) never passes Hb. | packet never passes Ha or (inclusive) never passes Hb. | |||

5.1.5. Discussion | 6.1.5. Discussion | |||

Following are specific issues which may occur: | Some specific issues that may occur are as follows: | |||

o the delay looks to decrease: dTi > DTi+1: | o the delay singletons "appear" to decrease: dTi > DTi+1, and is | |||

* This is typically due to clock synchronization issue. this | discussed in section 5.1.5. | |||

point is discussed in the section 3.7.1. "Errors or | * This could also occur when the clock resolution of one | |||

uncertainties related to Clocks" of of [RFC2679]; | measurement collection point is larger than the minimum delay | |||

* This may occurs too when the clock resolution of one probe is | of a path. For example, the minimum delay of a 500 km path | |||

bigger than the minimum delay of a path. As an example this | through optical fiber facilities is 2.5ms, but the measurement | |||

happen when measuring the delay of a path which is 500 km long | collection point has a clock resolution of 8ms. | |||

with one probe synchronized using NTP having a clock resolution | The metric SHALL be invalid for times < T1 , T2, ..., Tm-1, Tm> if | |||

of 8ms. | the following conditions occur: | |||

The metric can not be performed on < T1 , T2, ..., Tm-1, Tm> in the | o Ha or Hb disappears from the path due to some routing change. | |||

following cases: | o The order of Ha and Hb changes in the path. | |||

o Ha or Hb disappears from the path due to some change of routes; | ||||

o The order of Ha and Hb changes in the path; | ||||

5.2. A Definition of a sample of Packet Loss of a segment of the path | 6.2. A Definition of a Sample of Packet Loss of a Segment of the Path | |||

This metric defines a sample of packet lost over time between a pair | This metric defines a sample of packet loss over time between a pair | |||

of hosts of a path. As its semantic is very close to the metric | of hosts of a path. Since it is very close semantically to the | |||

Type-P-Packet-loss-Stream defined in section 3 of [RFC2680], sections | metric Type-P-Packet-loss-Stream defined in section 3 of [RFC2680], | |||

3.5 to 3.8 of [RFC2680] are part of the current definition. | sections 3.5 to 3.8 of [RFC2680] are integral parts of the definition | |||

text below. | ||||

5.2.1. Metric Name | 6.2.1. Metric Name | |||

Type-P-segment-Packet-loss-Stream | Type-P-segment-Packet-Loss-Stream | |||

5.2.2. Metric Parameters | 6.2.2. Metric Parameters | |||

o Src*, the IP address of the sender. | o Src, the IP address of the sender. | |||

o Dst*, the IP address of the receiver. | ||||

o P*, the specification of the packet type. | o Dst, the IP address of the receiver. | |||

o Type-P, the specification of the packet type. | ||||

o k, an integer which orders the packets sent. | o k, an integer which orders the packets sent. | |||

o n, an integer which orders the hosts on the path. | o n, an integer which orders the hosts on the path. | |||

o a and b, 2 integers where b > a. | o a and b, two integers where b > a. | |||

o <H1, H2, ..., Ha, ..., Hb, ...,Hn>, hosts path digest. | o <H1, H2, ..., Ha, ..., Hb, ...,Hn>, a host path digest. | |||

o Hi, exchange points of the path digest. | o Hi, exchange points of the path digest. | |||

o <T1, T2, ..., Tm>, a list of times. | o <T1, T2, ..., Tm>, a list of times. | |||

o <L1, L2, ..., Ln> a list of boolean values. | o <L1, L2, ..., Ln>, a list of Boolean values. | |||

5.2.3. Metric Units | 6.2.3. Metric Units | |||

The value of a Type-P-segment-Packet-loss-Stream is a pair of | The value of a Type-P-segment-Packet-Loss-Stream is a pair of: | |||

The list of times <T1, T2, ..., Tm>; | A The list of times <T1, T2, ..., Tm>; | |||

a sequence of booleans. | A sequence of Boolean values. | |||

5.2.4. Definition | 6.2.4. Definition | |||

Given 2 hosts, Ha and Hb, of the path <H1, H2,..., Ha, ..., Hb, ..., | Given two hosts, Ha and Hb, of the path <H1, H2,..., Ha, ..., Hb, | |||

Hn>, given the matrix of Type-P-Spatial-Packet-loss-Vector for the | ..., Hn>, and the matrix of Type-P-Spatial-Packet-Loss-Vector for the | |||

packets sent from Src to Dst at times <T1, T2, ..., Tm-1, Tm> : | packets sent from Src to Dst at times <T1, T2, ..., Tm-1, Tm> : | |||

<L1.1, L1.2,..., L1.a, ..., L1.b, ..., L1.n, L>, | <T1, L1.1, L1.2,..., L1.a, ..., L1.b, ..., L1.n, L>, | |||

<L2.1, L2.2,..., L2.a, ..., L2.b, ..., L2.n, L>, | <T2, L2.1, L2.2,..., L2.a, ..., L2.b, ..., L2.n, L>, | |||

..., | ..., | |||

<Lm.1, Lm.2,..., Lma, ..., Lm.b, ..., Lm.n, L>. | <Tm, Lm.1, Lm.2,..., Lma, ..., Lm.b, ..., Lm.n, L>. | |||

We define the value of the sample Type-P-segment-Packet-Lost-Stream | We define the value of the sample Type-P-segment-Packet-Lost-Stream | |||

from Ha to Hb as the sequence of booleans <L1.ab, L2.ab,..., Lk.ab, | from Ha to Hb as the sequence of Booleans <L1.ab, L2.ab,..., Lk.ab, | |||

..., Lm.ab> such that for each Tk: | ..., Lm.ab> such that for each Tk: | |||

o A value of Lk of 0 means that Ha and Hb observed the packet sent | o A value of Lk of 0 means that Ha and Hb observed the packet sent | |||

at time Tk (Lk.a and Lk.b have a value of 0); | at time Tk (both Lk.a and Lk.b have a value of 0). | |||

o A value of Lk of 1 means that Ha observed the packet sent at time | o A value of Lk of 1 means that Ha observed the packet sent at time | |||

Tk (Lk.a has a value of 0) and that Hb did not observed the packet | Tk (Lk.a has a value of 0) and that Hb did not observe the packet | |||

sent at time Tk (Lk.b have a value of 1); | sent at time Tk (Lk.b has a value of 1). | |||

o The value of Lk is undefined when Neither Ha or Hb observe the | o The value of Lk is undefined when neither Ha nor Hb observed the | |||

packet; | packet (both Lk.a and Lk.b have a value of 1). | |||

5.2.5. Discussion | 6.2.5. Discussion | |||

Unlike Type-P-Packet-loss-Stream, Type-P-Segment-Packet-Loss-Stream | ||||

relies on the stability of the host path digest. The metric SHALL be | ||||

invalid for times < T1 , T2, ..., Tm-1, Tm> if the following | ||||

conditions occur: | ||||

o Ha or Hb disappears from the path due to some routing change. | ||||

o The order of Ha and Hb changes in the path. | ||||

o Lk.a or Lk.b is undefined. | ||||

Unlike Type-P-Packet-loss-Stream, Type-P-Segment-Packet-loss-Stream | ||||

relies on the stability of the host path digest. The metric can not | ||||

be performed on < T1 , T2, ..., Tm-1, Tm> in the following cases: | ||||

o Ha or Hb disappears from the path due to some change of routes; | ||||

o the order of Ha and Hb changes in the path; | ||||

o Lk.a or Lk.b is undefined; | ||||

o Lk.a has the value 1 (not observed) and Lk.b has the value 0 | o Lk.a has the value 1 (not observed) and Lk.b has the value 0 | |||

(observed); | (observed); | |||

o L has the value 0 (the packet was received by Dst) and Lk.ab has | o L has the value 0 (the packet was received by Dst) and Lk.ab has | |||

the value 1 (the packet was lost between Ha and Hb). | the value 1 (the packet was lost between Ha and Hb). | |||

5.3. A Definition of a sample of ipdv of a segment using the previous | 6.3. A Definition of a Sample of ipdv of a Segment using the Previous | |||

packet selection function | Packet Selection Function | |||

This metric defines a sample of ipdv [RFC3393] over time between a | This metric defines a sample of ipdv [RFC3393] over time between a | |||

pair of hosts using the previous packet as the selection function. | pair of hosts using the previous packet as the selection function. | |||

5.3.1. Metric Name | 6.3.1. Metric Name | |||

Type-P-Segment-One-way-ipdv-prev-Stream | Type-P-Segment-ipdv-prev-Stream | |||

5.3.2. Metric Parameters | 6.3.2. Metric Parameters | |||

o Src*, the IP address of the sender. | ||||

o Dst*, the IP address of the receiver. | o Src, the IP address of the sender. | |||

o P*, the specification of the packet type. | o Dst, the IP address of the receiver. | |||

o Type-P, the specification of the packet type. | ||||

o k, an integer which orders the packets sent. | o k, an integer which orders the packets sent. | |||

o n, an integer which orders the hosts on the path. | o n, an integer which orders the hosts on the path. | |||

o a and b, 2 integers where b > a. | o a and b, two integers where b > a. | |||

o <H1, H2, ..., Ha, ..., Hb, ...,Hn>, the hosts path digest. | o <H1, H2, ..., Ha, ..., Hb, ...,Hn>, the hosts path digest. | |||

o <T1, T2, ..., Tm-1, Tm>, a list of times. | o <T1, T2, ..., Tm-1, Tm>, a list of times. | |||

o <Tk, dTk.1, dTk.2, ..., dTk.a, ..., dTk.b,..., dTk.n, dTk>, a | o <Tk, dTk.1, dTk.2, ..., dTk.a, ..., dTk.b,..., dTk.n, dTk>, a | |||

Type-P-Spatial-One-way-Delay-Vector. | Type-P-Spatial-One-way-Delay-Vector. | |||

5.3.3. Metric Units | 6.3.3. Metric Units | |||

The value of a Type-P-Segment-One-way-ipdv-prev-Stream is a pair of: | The value of a Type-P-Segment-ipdv-prev-Stream is a pair of: | |||

The list of <T1, T2, ..., Tm-1, Tm>; | The list of <T1, T2, ..., Tm-1, Tm>; | |||

A list of pairs of interval of times and delays; | A list of pairs of interval of times and delays; | |||

5.3.4. Definition | 6.3.4. Definition | |||

Given 2 hosts, Ha and Hb, of the path <H1, H2,..., Ha, ..., Hb, ..., | Given two hosts, Ha and Hb, of the path <H1, H2,..., Ha, ..., Hb, | |||

Hn>, given the matrix of Type-P-Spatial-One-way-Delay-Vector for the | ..., Hn>, and the matrix of Type-P-Spatial-One-way-Delay-Vector for | |||

packets sent from Src to Dst at times <T1, T2, ..., Tm-1, Tm> : | the packets sent from Src to Dst at times <T1, T2, ..., Tm-1, Tm> : | |||

<T1, dT1.1, dT1.2, ..., dT1.a, ..., dT1.b,..., dT1.n, dT1>, | <T1, dT1.1, dT1.2, ..., dT1.a, ..., dT1.b,..., dT1.n, dT1>, | |||

<T2, dT2.1, dT2.2, ..., dT2.a, ..., dT2.b,..., dT2.n, dT2>, | <T2, dT2.1, dT2.2, ..., dT2.a, ..., dT2.b,..., dT2.n, dT2>, | |||

... | ... | |||

<Tm, dTm.1, dTm.2, ..., dTm.a, ..., dTm.b,..., dTm.n, dTm>. | <Tm, dTm.1, dTm.2, ..., dTm.a, ..., dTm.b,..., dTm.n, dTm>. | |||

We define the Type-P-Segment-One-way-ipdv-prev-Stream as the sequence | We define the Type-P-Segment-ipdv-prev-Stream as the sequence of | |||

of pair of packet intervals and delay variations <(dT2_1.a , dT2.ab - | packet time pairs and delay variations | |||

dT1.ab) ,..., (dTk_k-1.a, dTk.ab - dTk-1.ab), ..., (dTm_m-1.a, dTm.ab | ||||

- dTm-1.ab)> such that for each Tk: | ||||

o dTk_k-1.a is either undefined if the delay dTk.a or the delay | ||||

dTk-1.a is undefined, or the interval of time, 'dTk.a - dTk-1.a', | ||||

between the 2 packets at Ha; | ||||

o dTk_k-1.ab, is either undefined if one of the delays dTk.b, dTk.a, | ||||

dTk-1.b or dTk-1.a is undefined, or , (dTk.b - dTk.a) - (dTk-1.b - | ||||

dTk-1.a), the delay variation from Ha to Hb between the 2 packets | ||||

sent at time Tk and Tk-1. | ||||

5.3.5. Discussion | <(T1, T2 , dT2.ab - dT1.ab) ,..., | |||

(Tk-1, Tk, dTk.ab - dTk-1.ab), ..., | ||||

(Tm-1, Tm, dTm.ab - dTm-1.ab)> | ||||

For any pair, Tk, Tk-1 in k=1 through m, the difference dTk.ab - dTk- | ||||

1.ab is undefined if: | ||||

o the delay dTk.a or the delay dTk-1.a is undefined, OR | ||||

o the delay dTk.b or the delay dTk-1.b is undefined. | ||||

6.3.5. Discussion | ||||

This metric belongs to the family of inter packet delay variation | This metric belongs to the family of inter packet delay variation | |||

metrics (IPDV in upper case) which results can be extremely sensitive | metrics (IPDV in upper case) whose results are extremely sensitive to | |||

to the inter-packet interval. | the inter-packet interval in practice. | |||

The inter-packet interval of a end-to-end IPDV metric is under the | The inter-packet interval of an end-to-end IPDV metric is under the | |||

control of the ingress point of interest which corresponds exactly to | control of the source (ingress point of interest). In contrast, the | |||

the Source of the packet. Unlikely, the inter-packet interval of a | inter-packet interval of a segment IPDV metric is not under the | |||

segment IPDV metric is not under the control the ingress point of | control the ingress point of interest of the measure, Ha. The | |||

interest of the measure, Ha. However, the interval will vary if | interval will certainly vary if there is delay variation between the | |||

there is delay variation between the Source and Ha. Therefore, the | Source and Ha. Therefore, the ingress inter-packet interval must be | |||

actual inter-packet interval must be known at Ha in order to fully | known at Ha in order to fully comprehend the delay variation between | |||

comprehend the delay variation between Ha and Hb. | Ha and Hb. | |||

5.4. A Definition of a sample of ipdv of a segment using the minimum | 6.4. A Definition of a Sample of ipdv of a Segment using the Minimum | |||

delay selection function | Delay Selection Function | |||

This metric defines a sample of ipdv [RFC3393] over time between a | This metric defines a sample of ipdv [RFC3393] over time between a | |||

pair of hosts of a path using the shortest delay as the selection | pair of hosts on a path using the minimum delay as one of the | |||

function. | selected packets in every pair. | |||

5.4.1. Metric Name | 6.4.1. Metric Name | |||

Type-P-Segment-One-way-ipdv-min-Stream | Type-P-Segment-One-way-ipdv-min-Stream | |||

5.4.2. Metric Parameters | 6.4.2. Metric Parameters | |||

o Src*, the IP address of the sender. | o Src, the IP address of the sender. | |||

o Dst*, the IP address of the receiver. | o Dst, the IP address of the receiver. | |||

o P*, the specification of the packet type. | o Type-P, the specification of the packet type. | |||

o k, an integer which orders the packets sent. | o k, an integer which orders the packets sent. | |||

o i, an integer which identifies a packet sent. | o i, an integer which identifies a packet sent. | |||

o n, an integer which orders the hosts on the path. | o n, an integer which orders the hosts on the path. | |||

o a and b, 2 integers where b > a. | o a and b, two integers where b > a. | |||

o <H1, H2, ..., Ha, ..., Hb, ...,Hn>, the hosts path digest. | o <H1, H2, ..., Ha, ..., Hb, ...,Hn>, the host path digest. | |||

o <T1, T2, ..., Tm-1, Tm>, a list of times. | o <T1, T2, ..., Tm-1, Tm>, a list of times. | |||

o <Tk, dTk.1, dTk.2, ..., dTk.a, ..., dTk.b,..., dTk.n, dTk>, a | o <Tk, dTk.1, dTk.2, ..., dTk.a, ..., dTk.b,..., dTk.n, dTk>, a | |||

Type-P-Spatial-One-way-Delay-Vector. | Type-P-Spatial-One-way-Delay-Vector. | |||

5.4.3. Metric Units | 6.4.3. Metric Units | |||

The value of a Type-P-Segment-One-way-ipdv-min-Stream is a pair of: | The value of a Type-P-Segment-One-way-ipdv-min-Stream is a pair of: | |||

The list of <T1, T2, ..., Tm-1, Tm>; | The list of <T1, T2, ..., Tm-1, Tm>; | |||

A list of times; | A list of times. | |||

5.4.4. Definition | 6.4.4. Definition | |||

Given 2 hosts, Ha and Hb, of the path <H1, H2,..., Ha, ..., Hb, ..., | Given two hosts, Ha and Hb, of the path <H1, H2,..., Ha, ..., Hb, | |||

Hn>, given the matrix of Type-P-Spatial-One-way-Delay-Vector for the | ..., Hn>, and the matrix of Type-P-Spatial-One-way-Delay-Vector for | |||

packets sent from Src to Dst at times <T1, T2, ..., Tm-1, Tm> : | the packets sent from Src to Dst at times <T1, T2, ..., Tm-1, Tm> : | |||

<T1, dT1.1, dT1.2, ..., dT1.a, ..., dT1.b,..., dT1.n, dT1>, | <T1, dT1.1, dT1.2, ..., dT1.a, ..., dT1.b,..., dT1.n, dT1>, | |||

<T2, dT2.1, dT2.2, ..., dT2.a, ..., dT2.b,..., dT2.n, dT2>, | <T2, dT2.1, dT2.2, ..., dT2.a, ..., dT2.b,..., dT2.n, dT2>, | |||

... | ... | |||

<Tm, dTm.1, dTm.2, ..., dTm.a, ..., dTm.b,..., dTm.n, dTm>. | <Tm, dTm.1, dTm.2, ..., dTm.a, ..., dTm.b,..., dTm.n, dTm>. | |||

We define the Type-P-Segment-One-way-ipdv-min-Stream as the sequence | We define the Type-P-Segment-One-way-ipdv-min-Stream as the sequence | |||

of times <dT1.ab - min(dTi.ab) ,..., dTk.ab - min(dTi.ab), ..., | of times <dT1.ab - min(dTi.ab) ,..., dTk.ab - min(dTi.ab), ..., | |||

dTm.ab - min(dTi.ab)> such that: | dTm.ab - min(dTi.ab)> where: | |||

min(dTi.ab) is the minimum value of the tuples (dTk.b - dTk.a); | o min(dTi.ab) is the minimum value of the tuples (dTk.b - dTk.a); | |||

for each time Tk, dTk.ab is undefined if dTk.a or (inclusive) | o for each time Tk, dTk.ab is undefined if dTk.a or (inclusive) | |||

dTk.b is undefined, or the real number (dTk.b - dTk.a). | dTk.b is undefined, or the real number (dTk.b - dTk.a) is | |||

undefined. | ||||

5.4.5. Discussion | 6.4.5. Discussion | |||

This metric belongs to the family of packet delay variation metrics | This metric belongs to the family of packet delay variation metrics | |||

(PDV). PDV distributions are less sensitive to inter-packet interval | (PDV). PDV distributions have less sensitivity to inter-packet | |||

variations than IPDV results. | interval variations than IPDV values, as discussed above. | |||

In principle, the PDV distribution reflects the variation over many | In principle, the PDV distribution reflects the variation over many | |||

different inter-packet intervals, from the smallest inter-packet | different inter-packet intervals, from the smallest inter-packet | |||

interval, up to the length of the evaluation interval, Tm - T1. | interval, up to the length of the evaluation interval, Tm - T1. | |||

Therefore, when delay variation occurs and disturbs the packet | Therefore, when delay variation occurs and disturbs the packet | |||

spacing observed at Ha, the PDV results will likely compare favorably | spacing observed at Ha, the PDV results will likely compare favorably | |||

to a PDV measurement where the source is Ha and the destination is | to a PDV measurement where the source is Ha and the destination is | |||

Hb. | Hb, because a wide range of spacings are reflected in any PDV | |||

distribution. | ||||

6. One-to-group metrics definitions | 7. One-to-group metrics definitions | |||

This metric defines metrics to measure the performance between a | This section defines performance metrics between a source and a group | |||

source and a group of receivers. | of receivers. | |||

6.1. A Definition for One-to-group One-way Delay | 7.1. A Definition for One-to-group Delay | |||

This metric defines a metric to measure one-way delay between a | This section defines a metric for one-way delay between a source and | |||

source and a group of receivers. | a group of receivers. | |||

6.1.1. Metric Name | 7.1.1. Metric Name | |||

Type-P-One-to-group-One-way-Delay-Vector | Type-P-One-to-group-Delay-Vector | |||

6.1.2. Metric Parameters | 7.1.2. Metric Parameters | |||

o Src, the IP address of a host acting as the source. | o Src, the IP address of a host acting as the source. | |||

o Recv1,..., RecvN, the IP addresses of the N hosts acting as | o Recv1,..., RecvN, the IP addresses of the N hosts acting as | |||

receivers. | receivers. | |||

o T, a time. | o T, a time. | |||

o dT1,...,dTn a list of time. | o dT1,...,dTn a list of times. | |||

o P, the specification of the packet type. | o Type-P, the specification of the packet type. | |||

o Gr, the receiving group identifier. The parameter Gr is the | o Gr, the receiving group identifier. The parameter Gr is the | |||

multicast group address if the measured packets are transmitted | multicast group address if the measured packets are transmitted | |||

over IP multicast. This parameter is to differentiate the | over IP multicast. This parameter is to differentiate the | |||

measured traffic from other unicast and multicast traffic. It is | measured traffic from other unicast and multicast traffic. It is | |||

optional in the metric to avoid losing any generality, i.e. to | OPTIONAL for this metric to avoid losing any generality, i.e. to | |||

make the metric also applicable to unicast measurement where there | make the metric also applicable to unicast measurement where there | |||

is only one receiver. | is only one receiver. | |||

6.1.3. Metric Units | 7.1.3. Metric Units | |||

The value of a Type-P-One-to-group-One-way-Delay-Vector is a set of | The value of a Type-P-One-to-group-Delay-Vector is a set of Type-P- | |||

Type-P-One-way-Delay singletons [RFC2679]. | One-way-Delay singletons [RFC2679], which is a sequence of times (a | |||

real number in the dimension of seconds with sufficient resolution to | ||||

convey the results). | ||||

6.1.4. Definition | 7.1.4. Definition | |||

Given a Type P packet sent by the source Src at Time T, given the N | Given a Type-P packet sent by the source Src at time T, and the N | |||

hosts { Recv1,...,RecvN } which receive the packet at the time { | hosts { Recv1,...,RecvN } which receive the packet at the time { | |||

T+dT1,...,T+dTn }, a Type-P-One-to-group-One-way-Delay-Vector is | T+dT1,...,T+dTn }, or the packet does not pass a receiver within a | |||

defined as the set of the Type-P-One-way-Delay singleton between Src | specified loss threshold time, then the Type-P-One-to-group-Delay- | |||

and each receiver with value of { dT1, dT2,...,dTn }. | Vector is defined as the set of the Type-P-One-way-Delay singletons | |||

between Src and each receiver with value of { dT1, dT2,...,dTn }, | ||||

where any of the singletons may be undefined if the packet did not | ||||

pass the corresponding receiver within a specified loss threshold | ||||

time. | ||||

6.2. A Definition for One-to-group One-way Packet Loss | 7.2. A Definition for One-to-group Packet Loss | |||

6.2.1. Metric Name | 7.2.1. Metric Name | |||

Type-P-One-to-group-One-way-Packet-Loss-Vector | Type-P-One-to-group-Packet-Loss-Vector | |||

6.2.2. Metric Parameters | 7.2.2. Metric Parameters | |||

o Src, the IP address of a host acting as the source. | o Src, the IP address of a host acting as the source. | |||

o Recv1,..., RecvN, the IP addresses of the N hosts acting as | o Recv1,..., RecvN, the IP addresses of the N hosts acting as | |||

receivers. | receivers. | |||

o T, a time. | o T, a time. | |||

o T1,...,Tn a list of time. | o Type-P, the specification of the packet type. | |||

o P, the specification of the packet type. | o Gr, the receiving group identifier, OPTIONAL. | |||

o Gr, the receiving group identifier. | ||||

6.2.3. Metric Units | 7.2.3. Metric Units | |||

The value of a Type-P-One-to-group-One-way-Packet-Loss-Vector is a | The value of a Type-P-One-to-group-Packet-Loss-Vector is a set of | |||

set of Type-P-One-way-Packet-Loss singletons [RFC2680]. | Type-P-One-way-Packet-Loss singletons [RFC2680]. | |||

6.2.4. Definition | o T, time the source packet was sent | |||

o L1,...,LN a list of boolean values | ||||

7.2.4. Definition | ||||

Given a Type P packet sent by the source Src at T and the N hosts, | Given a Type P packet sent by the source Src at T and the N hosts, | |||

Recv1,...,RecvN, which should receive the packet at T1,...,Tn, a | Recv1,...,RecvN, the Type-P-One-to-group-Packet-Loss-Vector is | |||

Type-P-One-to-group-One-way-Packet-Loss-Vector is defined as a set of | defined as a set of the Type-P-One-way-Packet-Loss singletons between | |||

the Type-P-One-way-Packet-Loss singleton between Src and each of the | Src and each of the receivers | |||

receivers {<T1,0|1>,<T2,0|1>,..., <Tn,0|1>}. | ||||

6.3. A Definition for One-to-group One-way Ipdv | {T, <L1=0|1>,<L2=0|1>,..., <LN=0|1>}, | |||

6.3.1. Metric Name | where the boolean value 0|1 depends on receiving the packet at a | |||

particular receiver within a loss threshold time. | ||||

Type-P-One-to-group-One-way-ipdv-Vector | 7.3. A Definition for One-to-group ipdv | |||

6.3.2. Metric Parameters | 7.3.1. Metric Name | |||

Type-P-One-to-group-ipdv-Vector | ||||

7.3.2. Metric Parameters | ||||

o Src, the IP address of a host acting as the source. | o Src, the IP address of a host acting as the source. | |||

o Recv1,..., RecvN, the IP addresses of the N hosts acting as | o Recv1,..., RecvN, the IP addresses of the N hosts acting as | |||

receivers. | receivers. | |||

o T1, a time. | o T1, a time. | |||

o T2, a time. | o T2, a time. | |||

o ddT1, ...,ddTn, a list of time. | ||||

o P, the specification of the packet type. | o ddT1, ...,ddTn, a list of times. | |||

o F, a selection function defining unambiguously the two packets | o Type-P, the specification of the packet type. | |||

o F, a selection function non-ambiguously defining the two packets | ||||

from the stream selected for the metric. | from the stream selected for the metric. | |||

o Gr, the receiving group identifier. The parameter Gr is the | o Gr, the receiving group identifier. The parameter Gr is the | |||

multicast group address if the measured packets are transmitted | multicast group address if the measured packets are transmitted | |||

over IP multicast. This parameter is to differentiate the | over IP multicast. This parameter is to differentiate the | |||

measured traffic from other unicast and multicast traffic. It is | measured traffic from other unicast and multicast traffic. It is | |||

optional in the metric to avoid losing any generality, i.e. to | OPTIONAL in the metric to avoid losing any generality, i.e. to | |||

make the metric also applicable to unicast measurement where there | make the metric also applicable to unicast measurement where there | |||

is only one receiver. | is only one receiver. | |||

6.3.3. Metric Units | 7.3.3. Metric Units | |||

The value of a Type-P-One-to-group-One-way-ipdv-Vector is a set of | The value of a Type-P-One-to-group-ipdv-Vector is a set of Type-P- | |||

Type-P-One-way-ipdv singletons [RFC3393]. | One-way-ipdv singletons [RFC3393]. | |||

6.3.4. Definition | 7.3.4. Definition | |||

Given a Type P packet stream, Type-P-One-to-group-One-way-ipdv-Vector | Given a Type-P packet stream, Type-P-One-to-group-ipdv-Vector is | |||

is defined for two packets from the source Src to the N hosts | defined for two packets transferred from the source Src to the N | |||

{Recv1,...,RecvN },which are selected by the selection function F, as | hosts {Recv1,...,RecvN }, which are selected by the selection | |||

the difference between the value of the Type-P-One-to-group-One-way- | function F as the difference between the value of the Type-P-One-to- | |||

Delay-Vector from Src to { Recv1,..., RecvN } at time T1 and the | group-Delay-Vector from Src to { Recv1,..., RecvN } at time T1 and | |||

value of the Type-P-One-to-group-One-way-Delay-Vector from Src to { | the value of the Type-P-One-to-group-Delay-Vector from Src to { | |||

Recv1,...,RecvN } at time T2. T1 is the wire-time at which Src sent | Recv1,...,RecvN } at time T2. T1 is the wire-time at which Src sent | |||

the first bit of the first packet, and T2 is the wire-time at which | the first bit of the first packet, and T2 is the wire-time at which | |||

Src sent the first bit of the second packet. This metric is derived | Src sent the first bit of the second packet. This metric is derived | |||

from the Type-P-One-to-group-One-way-Delay-Vector metric. | from the Type-P-One-to-group-Delay-Vector metric. | |||

Therefore, for a set of real number {ddT1,...,ddTn},Type-P-One-to- | For a set of real numbers {ddT1,...,ddTn}, the Type-P-One-to-group- | |||

group-One-way-ipdv-Vector from Src to { Recv1,...,RecvN } at T1, T2 | ipdv-Vector from Src to { Recv1,...,RecvN } at T1, T2 is | |||

is {ddT1,...,ddTn} means that Src sent two packets, the first at | {ddT1,...,ddTn} means that Src sent two packets, the first at wire- | |||

wire-time T1 (first bit), and the second at wire-time T2 (first bit) | time T1 (first bit), and the second at wire-time T2 (first bit) and | |||

and the packets were received by { Recv1,...,RecvN } at wire-time | the packets were received by { Recv1,...,RecvN } at wire-time {dT1+ | |||

{dT1+T1,...,dTn+T1}(last bit of the first packet), and at wire-time | T1,...,dTn+T1}(last bit of the first packet), and at wire-time {dT'1+ | |||

{dT'1+T2,...,dT'n+T2} (last bit of the second packet), and that | T2,...,dT'n+T2} (last bit of the second packet), and that {dT'1- | |||

{dT'1-dT1,...,dT'n-dTn} ={ddT1,...,ddTn}. | dT1,...,dT'n-dTn} ={ddT1,...,ddTn}. | |||

7. One-to-Group Sample Statistics | For any pair of selected packets, the difference dT'n-dTn is | |||

undefined if: | ||||

o the delay dTn to Receiver n is undefined, OR | ||||

o the delay dT'n to Receiver n is undefined. | ||||

The defined one-to-group metrics above can all be directly achieved | 8. One-to-group Sample Statistics | |||

from the relevant unicast one-way metrics. They collect all unicast | ||||

measurement results of one-way metrics together in one profile and | The one-to-group metrics defined above are directly achieved by | |||

sort them by receivers and packets in a receiving group. They | collecting relevant unicast one-way metrics measurements results and | |||

provide sufficient information regarding the network performance in | by gathering them per group of receivers. They produce network | |||

terms of each receiver and guide engineers to identify potential | performance information which guides engineers toward potential | |||

problem happened on each branch of a multicast routing tree. | problems which may have happened on any branch of a multicast routing | |||

However, these metrics cannot be directly used to conveniently | tree. | |||

present the performance in terms of a group and neither to identify | ||||

the relative performance situation. | The results of these metrics are not directly usable to present the | |||

performance of a group because each result is made of a huge number | ||||

of singletons which are difficult to read and analyze. As an | ||||

example, delay are not comparable because the distance between | ||||

receiver and sender differs. Furthermore they don't capture relative | ||||

performance situation a multiparty communication. | ||||

From the performance point of view, the multiparty communication | From the performance point of view, the multiparty communication | |||

services not only require the absolute performance support but also | services not only require the support of absolute performance | |||

the relative performance. The relative performance means the | information but also information on "relative performance". The | |||

difference between absolute performance of all users. Directly using | relative performance means the difference between absolute | |||

the one-way metrics cannot present the relative performance | performance of all users. Directly using the one-way metrics cannot | |||

situation. However, if we use the variations of all users one-way | present the relative performance situation. However, if we use the | |||

parameters, we can have new metrics to measure the difference of the | variations of all users one-way parameters, we can have new metrics | |||

absolute performance and hence provide the threshold value of | to measure the difference of the absolute performance and hence | |||

relative performance that a multiparty service might demand. A very | provide the threshold value of relative performance that a multiparty | |||

good example of the high relative performance requirement is the | service might demand. A very good example of the high relative | |||

online gaming. A very light difference in delay might result in | performance requirement is the online gaming. A very light | |||

failure in the game. We have to use multicast specific statistic | difference in delay might result in failure in the game. We have to | |||

metrics to define exactly how small the relative delay the online | use multicast specific statistic metrics to define exactly how small | |||

gaming requires. There are many other services, e.g. online biding, | the relative delay the online gaming requires. There are many other | |||

online stock market, etc., that require multicast metrics in order to | services, e.g. online biding, online stock market, etc., that require | |||

evaluate the network against their requirements. Therefore, we can | multicast metrics in order to evaluate the network against their | |||

see the importance of new, multicast specific, statistic metrics to | requirements. Therefore, we can see the importance of new, multicast | |||

feed this need. | specific, statistic metrics to feed this need. | |||

We might also use some one-to-group statistic conceptions to present | We might also use some one-to-group statistic conceptions to present | |||

and report the group performance and relative performance to save the | and report the group performance and relative performance to save the | |||

report transmission bandwidth. Statistics have been defined for One- | report transmission bandwidth. Statistics have been defined for One- | |||

way metrics in corresponding RFCs. They provide the foundation of | way metrics in corresponding RFCs. They provide the foundation of | |||

definition for performance statistics. For instance, there are | definition for performance statistics. For instance, there are | |||

definitions for minimum and maximum One-way delay in [RFC2679]. | definitions for minimum and maximum One-way delay in [RFC2679]. | |||

However, there is a dramatic difference between the statistics for | However, there is a dramatic difference between the statistics for | |||

one-to-one communications and for one-to-many communications. The | one-to-one communications and for one-to-many communications. The | |||

former one only has statistics over the time dimension while the | former one only has statistics over the time dimension while the | |||

skipping to change at page 28, line 31 | skipping to change at page 29, line 26 | |||

which dimension a 2-level statistic is calculated first, the results | which dimension a 2-level statistic is calculated first, the results | |||

are the same. I.e. one can calculate the 2-level delay mean using | are the same. I.e. one can calculate the 2-level delay mean using | |||

the Matrix M by having the 1-level delay mean over the time dimension | the Matrix M by having the 1-level delay mean over the time dimension | |||

first and then calculate the mean of the obtained vector to find out | first and then calculate the mean of the obtained vector to find out | |||

the 2-level delay mean. Or, he can do the 1-level statistic | the 2-level delay mean. Or, he can do the 1-level statistic | |||

calculation over the space dimension first and then have the 2-level | calculation over the space dimension first and then have the 2-level | |||

delay mean. Both two results will be exactly the same. Therefore, | delay mean. Both two results will be exactly the same. Therefore, | |||

when define a 2-level statistic, there is no need to specify in which | when define a 2-level statistic, there is no need to specify in which | |||

procedure the calculation should follow. | procedure the calculation should follow. | |||

Comment: The above statement depends on whether the order of | ||||

operations has any affect on the outcome. | ||||

Many statistics can be defined for the proposed one-to-group metrics | Many statistics can be defined for the proposed one-to-group metrics | |||

over either the space dimension or the time dimension or both. This | over either the space dimension or the time dimension or both. This | |||

memo treats the case where a stream of packets from the Source | memo treats the case where a stream of packets from the Source | |||

results in a sample at each of the Receivers in the Group, and these | results in a sample at each of the Receivers in the Group, and these | |||

samples are each summarized with the usual statistics employed in | samples are each summarized with the usual statistics employed in | |||

one-to-one communication. New statistic definitions are presented, | one-to-one communication. New statistic definitions are presented, | |||

which summarize the one-to-one statistics over all the Receivers in | which summarize the one-to-one statistics over all the Receivers in | |||

the Group. | the Group. | |||

7.1. Discussion on the Impact of packet loss on statistics | 8.1. Discussion on the Impact of packet loss on statistics | |||

The packet loss does have effects on one-way metrics and their | The packet loss does have effects on one-way metrics and their | |||

statistics. For example, the lost packet can result an infinite one- | statistics. For example, the lost packet can result in an infinite | |||

way delay. It is easy to handle the problem by simply ignoring the | one-way delay. It is easy to handle the problem by simply ignoring | |||

infinite value in the metrics and in the calculation of the | the infinite value in the metrics and in the calculation of the | |||

corresponding statistics. However, the packet loss has so strong | corresponding statistics. However, the packet loss has so strong | |||

impact on the statistics calculation for the one-to-group metrics | impact on the statistics calculation for the one-to-group metrics | |||

that it can not be solved by the same method used for one-way | that it can not be solved by the same method used for one-way | |||

metrics. This is due to the complex of building a Matrix, which is | metrics. This is due to the complexity of building a matrix, which | |||

needed for calculation of the statistics proposed in this memo. | is needed for calculation of the statistics proposed in this memo. | |||

The situation is that measurement results obtained by different end | The situation is that measurement results obtained by different end | |||

users might have different packet loss pattern. For example, for | users might have different packet loss pattern. For example, for | |||

User1, packet A was observed lost. And for User2, packet A was | User1, packet A was observed lost. And for User2, packet A was | |||

successfully received but packet B was lost. If the method to | successfully received but packet B was lost. If the method to | |||

overcome the packet loss for one-way metrics is applied, the two | overcome the packet loss for one-way metrics is applied, the two | |||

singleton sets reported by User1 and User2 will be different in terms | singleton sets reported by User1 and User2 will be different in terms | |||

of the transmitted packets. Moreover, if User1 and User2 have | of the transmitted packets. Moreover, if User1 and User2 have | |||

different number of lost packets, the size of the results will be | different number of lost packets, the size of the results will be | |||

different. Therefore, for the centralized calculation, the reference | different. Therefore, for the centralized calculation, the reference | |||

skipping to change at page 29, line 41 | skipping to change at page 30, line 33 | |||

different "weight" to present the group performance, which is | different "weight" to present the group performance, which is | |||

especially true for delay and ipdv relevant metrics. For example, | especially true for delay and ipdv relevant metrics. For example, | |||

User1 calculates the Type-P-Finite-One-way-Delay-Mean R1DM as shown | User1 calculates the Type-P-Finite-One-way-Delay-Mean R1DM as shown | |||

in Figure. 8 without any packet loss and User2 calculates the R2DM | in Figure. 8 without any packet loss and User2 calculates the R2DM | |||

with N-2 packet loss. The R1DM and R2DM should not be treated with | with N-2 packet loss. The R1DM and R2DM should not be treated with | |||

equal weight because R2DM was calculated only based on 2 delay values | equal weight because R2DM was calculated only based on 2 delay values | |||

in the whole sample interval. One possible solution is to use a | in the whole sample interval. One possible solution is to use a | |||

weight factor to mark every statistic value sent by users and use | weight factor to mark every statistic value sent by users and use | |||

this factor for further statistic calculation. | this factor for further statistic calculation. | |||

7.2. General Metric Parameters | 8.2. General Metric Parameters | |||

o Src, the IP address of a host; | o Src, the IP address of a host; | |||

o G, the receiving group identifier; | o G, the receiving group identifier; | |||

o N, the number of Receivers (Recv1, Recv2, ... RecvN); | o N, the number of Receivers (Recv1, Recv2, ... RecvN); | |||

o T, a time (start of test interval); | o T, a time (start of test interval); | |||

o Tf, a time (end of test interval); | o Tf, a time (end of test interval); | |||

o K, the number of packets sent from the source during the test | o K, the number of packets sent from the source during the test | |||

interval; | interval; | |||

o J[n], the number of packets received at a particular Receiver, n, | o J[n], the number of packets received at a particular Receiver, n, | |||

where 1<=n<=N; | where 1<=n<=N; | |||

skipping to change at page 30, line 26 | skipping to change at page 31, line 18 | |||

o Tmax, a maximum waiting time for packets at the destination, set | o Tmax, a maximum waiting time for packets at the destination, set | |||

sufficiently long to disambiguate packets with long delays from | sufficiently long to disambiguate packets with long delays from | |||

packets that are discarded (lost), thus the distribution of delay | packets that are discarded (lost), thus the distribution of delay | |||

is not truncated; | is not truncated; | |||

o dT, shorthand notation for a one-way delay singleton value; | o dT, shorthand notation for a one-way delay singleton value; | |||

o L, shorthand notation for a one-way loss singleton value, either | o L, shorthand notation for a one-way loss singleton value, either | |||

zero or one, where L=1 indicates loss and L=0 indicates arrival at | zero or one, where L=1 indicates loss and L=0 indicates arrival at | |||

the destination within TstampSrc + Tmax, may be indexed over n | the destination within TstampSrc + Tmax, may be indexed over n | |||

Receivers; | Receivers; | |||

o DV, shorthand notation for a one-way delay variation singleton | o DV, shorthand notation for a one-way delay variation singleton | |||

value; | value. | |||

7.3. One-to-Group one-way Delay Statistics | 8.3. One-to-group Delay Statistics | |||

This section defines the overall one-way delay statistics for a | This section defines the overall one-way delay statistics for a | |||

receiver and for an entire group as illustrated by the matrix below. | receiver and for an entire group as illustrated by the matrix below. | |||

Recv /----------- Sample -------------\ Stats Group Stat | Recv /----------- Sample -------------\ Stats Group Stat | |||

1 R1dT1 R1dT2 R1dT3 ... R1dTk R1DM \ | 1 R1dT1 R1dT2 R1dT3 ... R1dTk R1MD \ | |||

| | | | |||

2 R2dT1 R2dT2 R2dT3 ... R2dTk R2DM | | 2 R2dT1 R2dT2 R2dT3 ... R2dTk R2MD | | |||

| | | | |||

3 R3dT1 R3dT2 R3dT3 ... R3dTk R2DM > Group delay | 3 R3dT1 R3dT2 R3dT3 ... R3dTk R2MD > Group delay | |||

. | | . | | |||

. | | . | | |||

. | | . | | |||

n RndT1 RndT2 RndT3 ... RndTk RnDM / | n RndT1 RndT2 RndT3 ... RndTk RnMD / | |||

Receiver-n | Receiver-n | |||

delay | delay | |||

Figure 5: One-to-Group Mean Delay | Figure 5: One-to-group Mean Delay | |||

Statistics are computed on the finite One-way delays of the matrix | Statistics are computed on the finite One-way delays of the matrix | |||

above. | above. | |||

All One-to-group delay statistics are expressed in seconds with | All One-to-group delay statistics are expressed in seconds with | |||

sufficient resolution to convey 3 significant digits. | sufficient resolution to convey 3 significant digits. | |||

7.3.1. Type-P-One-to-Group-Receiver-n-Mean-Delay | 8.3.1. Type-P-One-to-group-Receiver-n-Mean-Delay | |||

This section defines Type-P-One-to-Group-Receiver-n-Mean-Delay the | This section defines Type-P-One-to-group-Receiver-n-Mean-Delay the | |||

Delay Mean at each Receiver N, also named RnDM. | Delay Mean at each Receiver N, also named RnDM. | |||

We obtain the value of Type-P-One-way-Delay singleton for all packets | We obtain the value of Type-P-One-way-Delay singleton for all packets | |||

sent during the test interval at each Receiver (Destination), as per | sent during the test interval at each Receiver (Destination), as per | |||

[RFC2679]. For each packet that arrives within Tmax of its sending | [RFC2679]. For each packet that arrives within Tmax of its sending | |||

time, TstampSrc, the one-way delay singleton (dT) will be the finite | time, TstampSrc, the one-way delay singleton (dT) will be the finite | |||

value TstampRecv[i] - TstampSrc[i] in units of seconds. Otherwise, | value TstampRecv[i] - TstampSrc[i] in units of seconds. Otherwise, | |||

the value of the singleton is Undefined. | the value of the singleton is Undefined. | |||

J[n] | J[n] | |||

--- | --- | |||

1 \ | 1 \ | |||

RnDM = --- * > TstampRecv[i] - TstampSrc[i] | RnMD = --- * > TstampRecv[i] - TstampSrc[i] | |||

J[n] / | J[n] / | |||

--- | --- | |||

i = 1 | i = 1 | |||

Figure 6: Type-P-One-to-Group-Receiver-Mean-Delay | Figure 6: Type-P-One-to-group-Receiver-N-Mean-Delay | |||

where all packets i= 1 through J[n] have finite singleton delays. | where all packets i= 1 through J[n] have finite singleton delays. | |||

7.3.2. Type-P-One-to-Group-Mean-Delay | 8.3.2. Type-P-One-to-group-Mean-Delay | |||

This section defines Type-P-One-to-Group-Mean-Delay, the Mean One-way | This section defines Type-P-One-to-group-Mean-Delay, the Mean One-way | |||

delay calculated over the entire Group, also named GMD. | delay calculated over the entire Group, also named GMD. | |||

N | N | |||

--- | --- | |||

1 \ | 1 \ | |||

GMD = - * > RnDM | GMD = - * > RnDM | |||

N / | N / | |||

--- | --- | |||

n = 1 | n = 1 | |||

Figure 7: Type-P-One-to-Group-Mean-Delay | Figure 7: Type-P-One-to-group-Mean-Delay | |||

Note that the Group Mean Delay can also be calculated by summing the | Note that the Group Mean Delay can also be calculated by summing the | |||

Finite one-way Delay singletons in the Matrix, and dividing by the | Finite one-way Delay singletons in the Matrix, and dividing by the | |||

number of Finite One-way Delay singletons. | number of Finite One-way Delay singletons. | |||

7.3.3. Type-P-One-to-Group-Range-Mean-Delay | 8.3.3. Type-P-One-to-group-Range-Mean-Delay | |||

This section defines a metric for the range of mean delays over all N | This section defines a metric for the range of mean delays over all N | |||

receivers in the Group, (R1DM, R2DM,...RnDM). | receivers in the group (R1DM, R2DM,...RnDM). | |||

Type-P-One-to-Group-Range-Mean-Delay = GRMD = max(RnDM) - min(RnDM) | Type-P-One-to-group-Range-Mean-Delay = GRMD = max(RnDM) - min(RnDM) | |||

7.3.4. Type-P-One-to-Group-Max-Mean-Delay | 8.3.4. Type-P-One-to-group-Max-Mean-Delay | |||

This section defines a metric for the maximum of mean delays over all | This section defines a metric for the maximum of mean delays over all | |||

N receivers in the Group, (R1DM, R2DM,...RnDM). | N receivers in the group (R1DM, R2DM,...RnDM). | |||

Type-P-One-to-Group-Max-Mean-Delay = GMMD = max(RnDM) | Type-P-One-to-group-Max-Mean-Delay = GMMD = max(RnDM) | |||

7.4. One-to-Group one-way Loss Statistics | 8.4. One-to-group Packet Loss Statistics | |||

This section defines the overall one-way loss statistics for a | This section defines the overall one-way loss statistics for a | |||

receiver and for an entire group as illustrated by the matrix below. | receiver and for an entire group as illustrated by the matrix below. | |||

Recv /----------- Sample ----------\ Stats Group Stat | Recv /----------- Sample ----------\ Stats Group Stat | |||

1 R1L1 R1L2 R1L3 ... R1Lk R1LR \ | 1 R1L1 R1L2 R1L3 ... R1Lk R1LR \ | |||

| | | | |||

2 R2L1 R2L2 R2L3 ... R2Lk R2LR | | 2 R2L1 R2L2 R2L3 ... R2Lk R2LR | | |||

| | | | |||

3 R3L1 R3L2 R3L3 ... R3Lk R3LR > Group Loss Ratio | 3 R3L1 R3L2 R3L3 ... R3Lk R3LR > Group Loss Ratio | |||

. | | . | | |||

. | | . | | |||

. | | . | | |||

n RnL1 RnL2 RnL3 ... RnLk RnLR / | n RnL1 RnL2 RnL3 ... RnLk RnLR / | |||

Receiver-n | Receiver-n | |||

Loss Ratio | Loss Ratio | |||

Figure 8: One-to-Group Loss Ratio | Figure 8: One-to-group Loss Ratio | |||

Statistics are computed on the sample of Type-P-One-way-Packet-Loss | Statistics are computed on the sample of Type-P-One-way-Packet-Loss | |||

[RFC2680] of the matrix above. | [RFC2680] of the matrix above. | |||

All loss ratios are expressed in units of packets lost to total | All loss ratios are expressed in units of packets lost to total | |||

packets sent. | packets sent. | |||

7.4.1. Type-P-One-to-Group-Receiver-n-Loss-Ratio | 8.4.1. Type-P-One-to-group-Receiver-n-Loss-Ratio | |||

Given a Matrix of loss singletons as illustrated above, determine the | Given a Matrix of loss singletons as illustrated above, determine the | |||

Type-P-One-way-Packet-Loss-Average for the sample at each receiver, | Type-P-One-way-Packet-Loss-Average for the sample at each receiver, | |||

according to the definitions and method of [RFC2680]. The Type-P- | according to the definitions and method of [RFC2680]. The Type-P- | |||

One-way-Packet-Loss-Average and the Type-P-One-to-Group-Receiver-n- | One-way-Packet-Loss-Average and the Type-P-One-to-group-Receiver-n- | |||

Loss-Ratio, also named RnLR, are equivalent metrics. In terms of the | Loss-Ratio, also named RnLR, are equivalent metrics. In terms of the | |||

parameters used here, these metrics definitions can be expressed as | parameters used here, these metrics definitions can be expressed as | |||

K | K | |||

--- | --- | |||

1 \ | 1 \ | |||

RnLR = - * > RnLk | RnLR = - * > RnLk | |||

K / | K / | |||

--- | --- | |||

k = 1 | k = 1 | |||

Figure 9: Type-P-One-to-Group-Receiver-n-Loss-Ratio | Figure 9: Type-P-One-to-group-Receiver-n-Loss-Ratio | |||

7.4.2. Type-P-One-to-Group-Receiver-n-Comp-Loss-Ratio | 8.4.2. Type-P-One-to-group-Receiver-n-Comp-Loss-Ratio | |||

Usually, the number of packets sent is used in the denominator of | Usually, the number of packets sent is used in the denominator of | |||

packet loss ratio metrics. For the comparative metrics defined here, | packet loss ratio metrics. For the comparative metrics defined here, | |||

the denominator is the maximum number of packets received at any | the denominator is the maximum number of packets received at any | |||

receiver for the sample and test interval of interest. | receiver for the sample and test interval of interest. | |||

The Comparative Loss Ratio, also named, RnCLR, is defined as | The Comparative Loss Ratio, also named, RnCLR, is defined as | |||

K | K | |||

--- | --- | |||

skipping to change at page 33, line 42 | skipping to change at page 34, line 39 | |||

k=1 | k=1 | |||

RnCLR = ----------------------------- | RnCLR = ----------------------------- | |||

/ K \ | / K \ | |||

| --- | | | --- | | |||

| \ | | | \ | | |||

K - Min | > Ln(k) | | K - Min | > Ln(k) | | |||

| / | | | / | | |||

| --- | | | --- | | |||

\ k=1 / N | \ k=1 / N | |||

Figure 10: Type-P-One-to-Group-Receiver-n-Comp-Loss-Ratio | Figure 10: Type-P-One-to-group-Receiver-n-Comp-Loss-Ratio | |||

7.4.3. Type-P-One-to-Group-Loss-Ratio | 8.4.3. Type-P-One-to-group-Loss-Ratio | |||

Type-P-One-to-Group-Loss-Ratio, the overall Group loss ratio, also | Type-P-One-to-group-Loss-Ratio, the overall Group loss ratio, also | |||

named GLR, is defined as | named GLR, is defined as | |||

K,N | K,N | |||

--- | --- | |||

1 \ | 1 \ | |||

GLR = --- * > L(k,n) | GLR = --- * > L(k,n) | |||

K*N / | K*N / | |||

--- | --- | |||

k,n = 1 | k,n = 1 | |||

Figure 11: Type-P-One-to-Group-Loss-Ratio | Figure 11: Type-P-One-to-group-Loss-Ratio | |||

7.4.4. Type-P-One-to-Group-Range-Loss-Ratio | 8.4.4. Type-P-One-to-group-Range-Loss-Ratio | |||

The One-to-Group Loss Ratio Range is defined as: | The One-to-group Loss Ratio Range is defined as: | |||

Type-P-One-to-Group-Range-Loss-Ratio = max(RnLR) - min(RnLR) | Type-P-One-to-group-Range-Loss-Ratio = max(RnLR) - min(RnLR) | |||

It is most effective to indicate the range by giving both the max and | It is most effective to indicate the range by giving both the max and | |||

minimum loss ratios for the Group, rather than only reporting the | minimum loss ratios for the Group, rather than only reporting the | |||

difference between them. | difference between them. | |||

7.5. One-to-Group one-way Delay Variation Statistics | 8.5. One-to-group Delay Variation Statistics | |||

This section defines one-way delay variation (DV) statistics for an | This section defines one-way delay variation (DV) statistics for an | |||

entire group as illustrated by the matrix below. | entire group as illustrated by the matrix below. | |||

Recv /------------- Sample --------------\ Stats | Recv /------------- Sample --------------\ Stats | |||

1 R1ddT1 R1ddT2 R1ddT3 ... R1ddTk R1DV \ | 1 R1ddT1 R1ddT2 R1ddT3 ... R1ddTk R1DV \ | |||

| | | | |||

2 R2ddT1 R2ddT2 R2ddT3 ... R2ddTk R2DV | | 2 R2ddT1 R2ddT2 R2ddT3 ... R2ddTk R2DV | | |||

| | | | |||

3 R3ddT1 R3ddT2 R3ddT3 ... R3ddTk R3DV > Group Stat | 3 R3ddT1 R3ddT2 R3ddT3 ... R3ddTk R3DV > Group Stat | |||

. | | . | | |||

. | | . | | |||

. | | . | | |||

n RnddT1 RnddT2 RnddT3 ... RnddTk RnDV / | n RnddT1 RnddT2 RnddT3 ... RnddTk RnDV / | |||

Figure 12: One-to-Group Delay Variation Matrix (DVMa) | Figure 12: One-to-group Delay Variation Matrix (DVMa) | |||

Statistics are computed on the sample of Type-P-One-way-Delay- | Statistics are computed on the sample of Type-P-One-way-Delay- | |||

Variation singletons of the group delay variation matrix above where | Variation singletons of the group delay variation matrix above where | |||

RnddTk is the Type-P-One-way-Delay-Variation singleton evaluated at | RnddTk is the Type-P-One-way-Delay-Variation singleton evaluated at | |||

Receiver n for the packet k and where RnDV is the point-to-point one- | Receiver n for the packet k and where RnDV is the point-to-point one- | |||

way packet delay variation for Receiver n. | way packet delay variation for Receiver n. | |||

All One-to-group delay variation statistics are expressed in seconds | All One-to-group delay variation statistics are expressed in seconds | |||

with sufficient resolution to convey 3 significant digits. | with sufficient resolution to convey 3 significant digits. | |||

7.5.1. Type-P-One-to-Group-Delay-Variation-Range | 8.5.1. Type-P-One-to-group-Range-Delay-Variation | |||

This section defines a metric for the range of delays variation over | This section defines a metric for the range of delays variation over | |||

all N receivers in the Group. | all N receivers in the Group. | |||

Maximum DV and minimum DV over all receivers summarize the | Maximum DV and minimum DV over all receivers summarize the | |||

performance over the Group (where DV is a point-to-point metric). | performance over the Group (where DV is a point-to-point metric). | |||

For each receiver, the DV is usually expressed as the 1-10^(-3) | For each receiver, the DV is usually expressed as the 1-10^(-3) | |||

quantile of one-way delay minus the minimum one-way delay. | quantile of one-way delay minus the minimum one-way delay. | |||

Type-P-One-to-Group-Delay-Variation-Range = GDVR = | Type-P-One-to-group-Range-Delay-Variation = GRDV = | |||

= max(RnDV) - min(RnDV) for all n receivers | = max(RnDV) - min(RnDV) for all n receivers | |||

This range is determined from the minimum and maximum values of the | This range is determined from the minimum and maximum values of the | |||

point-to-point one-way IP Packet Delay Variation for the set of | point-to-point one-way IP Packet Delay Variation for the set of | |||

Destinations in the group and a population of interest, using the | Destinations in the group and a population of interest, using the | |||

Packet Delay Variation expressed as the 1-10^-3 quantile of one-way | Packet Delay Variation expressed as the 1-10^-3 quantile of one-way | |||

delay minus the minimum one-way delay. If a more demanding service | delay minus the minimum one-way delay. If a more demanding service | |||

is considered, one alternative is to use the 1-10^-5 quantile, and in | is considered, one alternative is to use the 1-10^-5 quantile, and in | |||

either case the quantile used should be recorded with the results. | either case the quantile used should be recorded with the results. | |||

Both the minimum and the maximum delay variation are recorded, and | Both the minimum and the maximum delay variation are recorded, and | |||

both values are given to indicate the location of the range. | both values are given to indicate the location of the range. | |||

8. Measurement Methods: Scalability and Reporting | 9. Measurement Methods: Scalability and Reporting | |||

Virtually all the guidance on measurement processes supplied by the | Virtually all the guidance on measurement processes supplied by the | |||

earlier IPPM RFCs (such as [RFC2679] and [RFC2680]) for one-to-one | earlier IPPM RFCs (such as [RFC2679] and [RFC2680]) for one-to-one | |||

scenarios is applicable here in the spatial and multiparty | scenarios is applicable here in the spatial and multiparty | |||

measurement scenario. The main difference is that the spatial and | measurement scenario. The main difference is that the spatial and | |||

multiparty configurations require multiple points of interest where a | multiparty configurations require multiple points of interest where a | |||

stream of singletons will be collected. The amount of information | stream of singletons will be collected. The amount of information | |||

requiring storage grows with both the number of metrics and the | requiring storage grows with both the number of metrics and the | |||

points of interest, so the scale of the measurement architecture | points of interest, so the scale of the measurement architecture | |||

multiplies the number of singleton results that must be collected and | multiplies the number of singleton results that must be collected and | |||

skipping to change at page 36, line 12 | skipping to change at page 37, line 12 | |||

architectures today, where even the individual singletons may not be | architectures today, where even the individual singletons may not be | |||

stored at each point of interest. | stored at each point of interest. | |||

In recognition of the likely need to minimize form of the results for | In recognition of the likely need to minimize form of the results for | |||

storage and communication, the Group metrics above have been | storage and communication, the Group metrics above have been | |||

constructed to allow some computations on a per-Receiver basis. This | constructed to allow some computations on a per-Receiver basis. This | |||

means that each Receiver's statistics would normally have an equal | means that each Receiver's statistics would normally have an equal | |||

weight with all other Receivers in the Group (regardless of the | weight with all other Receivers in the Group (regardless of the | |||

number of packets received). | number of packets received). | |||

8.1. Computation methods | 9.1. Computation methods | |||

The scalability issue can be raised when there are thousands of | The scalability issue can be raised when there are thousands of | |||

points of interest in a group who are trying to send back the | points of interest in a group who are trying to send back the | |||

measurement results to the reference point for further processing and | measurement results to the reference point for further processing and | |||

analysis. The points of interest can send either the whole measured | analysis. The points of interest can send either the whole measured | |||

sample or only the calculated statistics. The former one is a | sample or only the calculated statistics. The former one is a | |||

centralized statistic calculation method and the latter one is a | centralized statistic calculation method and the latter one is a | |||

distributed statistic calculation method. The sample should include | distributed statistic calculation method. The sample should include | |||

all metrics parameters, the values and the corresponding sequence | all metrics parameters, the values and the corresponding sequence | |||

numbers. The transmission of the whole sample can cost much more | numbers. The transmission of the whole sample can cost much more | |||

skipping to change at page 37, line 5 | skipping to change at page 38, line 5 | |||

the reference point first to obtain the general information of the | the reference point first to obtain the general information of the | |||

group performance. If the detail results are required, the reference | group performance. If the detail results are required, the reference | |||

point should send the requests to the points of interest, which could | point should send the requests to the points of interest, which could | |||

be particular ones or the whole group. This procedure can happen in | be particular ones or the whole group. This procedure can happen in | |||

the off peak time and can be well scheduled to avoid delivery of too | the off peak time and can be well scheduled to avoid delivery of too | |||

many points of interest at the same time. Compression techniques can | many points of interest at the same time. Compression techniques can | |||

also be used to minimize the bandwidth required by the transmission. | also be used to minimize the bandwidth required by the transmission. | |||

This could be a measurement protocol to report the measurement | This could be a measurement protocol to report the measurement | |||

results. However, this is out of the scope of this memo. | results. However, this is out of the scope of this memo. | |||

8.2. Measurement | 9.2. Measurement | |||

To prevent any bias in the result, the configuration of a one-to-many | To prevent any bias in the result, the configuration of a one-to-many | |||

measure must take in consideration that implicitly more packets will | measure must take in consideration that implicitly more packets will | |||

to be routed than send and selects a test packets rate that will not | to be routed than send and selects a test packets rate that will not | |||

impact the network performance. | impact the network performance. | |||

8.3. Effect of Time and Space Aggregation Order on Stats | 9.3. Effect of Time and Space Aggregation Order on Stats | |||

This section presents the impact of the aggregation order on the | This section presents the impact of the aggregation order on the | |||

scalability of the reporting and of the computation. It makes the | scalability of the reporting and of the computation. It makes the | |||

hypothesis that receivers are managed remotely and not co-located. | hypothesis that receivers are not co-located and that results are | |||

gathered in a point of reference for further usages. | ||||

multimetrics samples represented a matrix as illustrated below | Multimetrics samples are represented in a matrix as illustrated below | |||

Point of | Point of | |||

interest | interest | |||

1 R1S1 R1S1 R1S1 ... R1Sk \ | 1 R1S1 R1S1 R1S1 ... R1Sk \ | |||

| | | | |||

2 R2S1 R2S2 R2S3 ... R2Sk | | 2 R2S1 R2S2 R2S3 ... R2Sk | | |||

| | | | |||

3 R3S1 R3S2 R3S3 ... R3Sk > sample over space | 3 R3S1 R3S2 R3S3 ... R3Sk > sample over space | |||

. | | . | | |||

. | | . | | |||

skipping to change at page 37, line 40 | skipping to change at page 38, line 41 | |||

n RnS1 RnS2 RnS3 ... RnSk / | n RnS1 RnS2 RnS3 ... RnSk / | |||

S1M S2M S3M ... SnM Stats over space | S1M S2M S3M ... SnM Stats over space | |||

\------------- ------------/ | \------------- ------------/ | |||

\/ | \/ | |||

Stat over space and time | Stat over space and time | |||

Figure 13: Impact of space aggregation on multimetrics Stat | Figure 13: Impact of space aggregation on multimetrics Stat | |||

2 methods are available to compute statistics on the resulting | 2 methods are available to compute statistics on a matrix: | |||

matrix: | o Method 1: The statistic metric is computed over time and then over | |||

o metric is computed over time and then over space; | space; | |||

o metric is computed over space and then over time. | o Method 2: The statistic metric is computed over space and then | |||

over time. | ||||

They differ only by the order of the time and of the space | ||||

aggregation. View as a matrix this order is neutral as does not | ||||

impact the result, but the impact on a measurement deployment is | ||||

critical. | ||||

In both cases the volume of data to report is proportional to the | ||||

number of probes. But there is a major difference between these 2 | ||||

methods: | ||||

method2: In space and time aggregation mode the volume of data to | These 2 methods differ only by the order of the aggregation. The | |||

collect is proportional to the number of test packets received; | order does not impact the computation resources required. It does | |||

Each received packet RiSi triggers out a block of data that must | not change the value of the result. However, it impacts severely the | |||

be reported to a common place for computing the stat over space; | minimal volume of data to report: | |||

method1: In time and space aggregation mode the volume of data to | ||||

collect is proportional to the period of aggregation, so it does | ||||

not depend on the number of packet received; | ||||

Method 2 property has severe drawbacks in terms of security and | o Method 1: Each point of interest computes periodically statistics | |||

dimensioning: | over time to lower the volume of data to report. They are | |||

The increasing of the rate of the test packets may result in a | reported to the reference point for computing the stat over space. | |||

sort of DoS toward the computation points; | This volume no longer depends on the number of samples. It is | |||

The dimensioning of a measurement system is quite impossible to | only proportional to the computation period; | |||

validate. | o Method 2: The volume of data to report is proportional to the | |||

number of samples. Each sample, RiSi, must be reported to the | ||||

reference point for computing statistic over space and statistic | ||||

over time. The volume increases with the number of samples. It | ||||

is proportional to the number of test packets; | ||||

The time aggregation interval provides the reporting side with a | Method 2 has severe drawbacks in terms of security and dimensioning: | |||

control of various collecting aspects such as bandwidth and | o Increasing the rate of the test packets may result in a Denial of | |||

computation and storage capacities. So this draft defines metrics | Service toward the points of reference; | |||

based on method 1. | o The dimensioning of a measurement system is quite impossible to | |||

validate because any increase of the rate of the test packets will | ||||

increase the bandwidth requested to collect the raw results. | ||||

Note: In some specific cases one may need sample of singletons over | The computation period over time period (commonly named aggregation | |||

space. To address this need it is suggested firstly to limit the | period) provides the reporting side with a control of various | |||

number of test and the number of test packets per seconds. Then | collecting aspects such as bandwidth, computation and storage | |||

reducing the size of the sample over time to one packet give sample | capacities. So this draft defines metrics based on method 1. | |||

of singleton over space.. | ||||

8.3.1. Impact on spatial statistics | 9.3.1. Impact on spatial statistics | |||

2 methods are available to compute spatial statistics: | 2 methods are available to compute spatial statistics: | |||

o method 1: spatial segment metrics and statistics are preferably | o Method 1: spatial segment metrics and statistics are preferably | |||

computed over time by each points of interest; | computed over time by each points of interest; | |||

o method 2: Vectors metrics are intrinsically instantaneous space | o Method 2: Vectors metrics are intrinsically instantaneous space | |||

metrics which must be reported using method2 whenever | metrics which must be reported using method2 whenever | |||

instantaneous metrics information is needed. | instantaneous metrics information is needed. | |||

8.3.2. Impact on one-to-group statistics | 9.3.2. Impact on one-to-group statistics | |||

2 methods are available to compute group statistics: | 2 methods are available to compute group statistics: | |||

o method1: Figure 5 andFigure 8 illustrate the method chosen: the | o Method1: Figure 5 and Figure 8 illustrate the method chosen: the | |||

one-to-one statistic is computed per interval of time before the | one-to-one statistic is computed per interval of time before the | |||

computation of the mean over the group of receivers; | computation of the mean over the group of receivers; | |||

o method2: Figure 13 presents the second one, metric is computed | o Method2: Figure 13 presents the second one, metric is computed | |||

over space and then over time. | over space and then over time. | |||

9. Manageability Considerations | 10. Manageability Considerations | |||

Usually IPPM WG documents defines each metric reporting within its | Usually IPPM WG documents defines each metric reporting within its | |||

definition. This document defines the reporting of all the metrics | definition. This document defines the reporting of all the metrics | |||

introduced in a single section to provide consistent information, to | introduced in a single section to provide consistent information, to | |||

avoid repetitions and to conform to IESG recommendation of gathering | avoid repetitions and to conform to IESG recommendation of gathering | |||

manageability considerations in a dedicated section. | manageability considerations in a dedicated section. | |||

Information models of spatial metrics and of one-to-group metrics are | Information models of spatial metrics and of one-to-group metrics are | |||

similar excepted that points of interests of spatial vectors must be | similar excepted that points of interests of spatial vectors must be | |||

ordered. | ordered. | |||

The complexity of the reporting relies on the number of points of | The complexity of the reporting relies on the number of points of | |||

interests. | interests. | |||

9.1. Reporting spatial metric | 10.1. Reporting spatial metric | |||

The reporting of spatial metrics shares a lot of aspects with | The reporting of spatial metrics shares a lot of aspects with | |||

RFC2679-80. New ones are common to all the definitions and are | RFC2679-80. New ones are common to all the definitions and are | |||

mostly related to the reporting of the path and of methodology | mostly related to the reporting of the path and of methodology | |||

parameters that may bias raw results analysis. This section presents | parameters that may bias raw results analysis. This section presents | |||

these specific parameters and then lists exhaustively the parameters | these specific parameters and then lists exhaustively the parameters | |||

that shall be reported. | that shall be reported. | |||

9.1.1. Path | 10.1.1. Path | |||

End-to-end metrics can't determine the path of the measure despite | End-to-end metrics can't determine the path of the measure despite | |||

IPPM RFCs recommend it to be reported (See Section 3.8.4 of | IPPM RFCs recommend it to be reported (See Section 3.8.4 of | |||

[RFC2679]). Spatial metrics vectors provide this path. The report | [RFC2679]). Spatial metrics vectors provide this path. The report | |||

of a spatial vector must include the points of interests involved: | of a spatial vector must include the points of interests involved: | |||

the sub set of the hosts of the path participating to the | the sub set of the hosts of the path participating to the | |||

instantaneous measure. | instantaneous measure. | |||

9.1.2. Host order | 10.1.2. Host order | |||

A spatial vector must order the points of interest according to their | A spatial vector must order the points of interest according to their | |||

order in the path. It is highly suggested to use the TTL in IPv4, | order in the path. It is highly suggested to use the TTL in IPv4, | |||

the Hop Limit in IPv6 or the corresponding information in MPLS. | the Hop Limit in IPv6 or the corresponding information in MPLS. | |||

The report of a spatial vector must include the ordered list of the | The report of a spatial vector must include the ordered list of the | |||

hosts involved in the instantaneous measure. | hosts involved in the instantaneous measure. | |||

9.1.3. Timestamping bias | 10.1.3. Timestamping bias | |||

The location of the point of interest inside a node influences the | The location of the point of interest inside a node influences the | |||

timestamping skew and accuracy. As an example, consider that some | timestamping skew and accuracy. As an example, consider that some | |||

internal machinery delays the timestamping up to 3 milliseconds then | internal machinery delays the timestamping up to 3 milliseconds then | |||

the minimal uncertainty reported be 3 ms if the internal delay is | the minimal uncertainty reported be 3 ms if the internal delay is | |||

unknown at the time of the timestamping. | unknown at the time of the timestamping. | |||

The report of a spatial vector must include the uncertainty of the | The report of a spatial vector must include the uncertainty of the | |||

timestamping compared to wire time. | timestamping compared to wire time. | |||

9.1.4. Reporting spatial One-way Delay | 10.1.4. Reporting spatial One-way Delay | |||

The reporting includes information to report for one-way-delay as the | The reporting includes information to report for one-way-delay as the | |||

Section 3.6 of [RFC2679]. The same apply for packet loss and ipdv. | Section 3.6 of [RFC2679]. The same apply for packet loss and ipdv. | |||

9.2. Reporting One-to-group metric | 10.2. Reporting One-to-group metric | |||

All reporting rules described in RFC2679-80 apply to the | All reporting rules described in [RFC2679] and [RFC2680] apply to the | |||

corresponding One-to-group metrics. Following are specific | corresponding One-to-group metrics. Following are specific | |||

parameters that should be reported. | parameters that should be reported. | |||

9.2.1. Path | 10.2.1. Path | |||

As suggested by the RFC2679-80, the path traversed by the packet | As suggested by the [RFC2679] and [RFC2680] , the path traversed by | |||

SHOULD be reported, if possible. For One-to-group metrics, there is | the packet SHOULD be reported, if possible. For One-to-group | |||

a path tree SHOULD be reported rather than A path. This is even more | metrics, there is a path tree SHOULD be reported rather than A path. | |||

impractical. If, by anyway, partial information is available to | This is even more impractical. If, by anyway, partial information is | |||

report, it might not be as valuable as it is in the one-to-one case | available to report, it might not be as valuable as it is in the one- | |||

because the incomplete path might be difficult to identify its | to-one case because the incomplete path might be difficult to | |||

position in the path tree. For example, how many points of interest | identify its position in the path tree. For example, how many points | |||

are reached by the packet traveled through this incomplete path? | of interest are reached by the packet travelled through this | |||

incomplete path? | ||||

9.2.2. Group size | 10.2.2. Group size | |||

The group size should be reported as one of the critical management | The group size should be reported as one of the critical management | |||

parameters. Unlike the spatial metrics, there is no need of order of | parameters. Unlike the spatial metrics, there is no need of order of | |||

points of interests. | points of interests. | |||

9.2.3. Timestamping bias | 10.2.3. Timestamping bias | |||

It is the same as described in section 9.1.3. | It is the same as described in section 10.1.3. | |||

9.2.4. Reporting One-to-group One-way Delay | 10.2.4. Reporting One-to-group One-way Delay | |||

It is the same as described in section 9.1.4. | It is the same as described in section 10.1.4. | |||

9.2.5. Measurement method | 10.2.5. Measurement method | |||

As explained in section 8, the measurement method will have impact on | As explained in section 9, the measurement method will have impact on | |||

the analysis of the measurement result. Therefore, it should be | the analysis of the measurement result. Therefore, it should be | |||

reported. | reported. | |||

9.3. Metric identification | 10.3. Metric identification | |||

IANA assigns each metric defined by the IPPM WG with a unique | IANA assigns each metric defined by the IPPM WG with a unique | |||

identifier as per [RFC4148] in the IANA-IPPM-METRICS-REGISTRY-MIB. | identifier as per [RFC4148] in the IANA-IPPM-METRICS-REGISTRY-MIB. | |||

9.4. Information model | 10.4. Information model | |||

This section presents the elements of information and the usage of | This section presents the elements of information and the usage of | |||

the information reported for network performance analysis. It is out | the information reported for network performance analysis. It is out | |||

of the scope of this section to define how the information is | of the scope of this section to define how the information is | |||

reported. | reported. | |||

The information model is build with pieces of information introduced | The information model is build with pieces of information introduced | |||

and explained in one-way delay definitions [RFC2679], in packet loss | and explained in one-way delay definitions [RFC2679], in packet loss | |||

definitions [RFC2680] and in IPDV definitions of [RFC3393] and | definitions [RFC2680] and in IPDV definitions of [RFC3393] and | |||

[RFC3432]. It includes not only information given by "Reporting the | [RFC3432]. It includes not only information given by "Reporting the | |||

skipping to change at page 43, line 12 | skipping to change at page 44, line 12 | |||

Following is the information of each statistic that should be | Following is the information of each statistic that should be | |||

reported: | reported: | |||

o Result; | o Result; | |||

o Start_time; | o Start_time; | |||

o Duration; | o Duration; | |||

o Result_status; | o Result_status; | |||

o Singleton_number, the number of singletons the statistic is | o Singleton_number, the number of singletons the statistic is | |||

computed on; | computed on; | |||

10. Security Considerations | 11. Security Considerations | |||

Spatial and one-to-group metrics are defined on the top of end-to-end | Spatial and one-to-group metrics are defined on the top of end-to-end | |||

metrics. Security considerations discussed in One-way delay metrics | metrics. Security considerations discussed in One-way delay metrics | |||

definitions of [RFC2679] , in packet loss metrics definitions of | definitions of [RFC2679] , in packet loss metrics definitions of | |||

[RFC2680] and in IPDV metrics definitions of[RFC3393] and [RFC3432] | [RFC2680] and in IPDV metrics definitions of[RFC3393] and [RFC3432] | |||

apply to metrics defined in this memo. | apply to metrics defined in this memo. | |||

10.1. Spatial metrics | 11.1. Spatial metrics | |||

Malicious generation of packets with spoofing addresses may corrupt | Malicious generation of packets with spoofing addresses may corrupt | |||

the results without any possibility to detect the spoofing. | the results without any possibility to detect the spoofing. | |||

Malicious generation of packets which match systematically the hash | Malicious generation of packets which match systematically the hash | |||

function used to detect the packets may lead to a DoS attack toward | function used to detect the packets may lead to a DoS attack toward | |||

the point of reference. | the point of reference. | |||

10.2. one-to-group metric | 11.2. One-to-group metrics | |||

Reporting of measurement results from a huge number of probes may | Reporting of measurement results from a huge number of probes may | |||

overload reference point ressources (network, network interfaces, | overload reference point resources (network, network interfaces, | |||

computation capacities ...). | computation capacities ...). | |||

The configuration of a measurement must take in consideration that | The configuration of a measurement must take in consideration that | |||

implicitly more packets will to be routed than send and selects a | implicitly more packets will to be routed than send and selects a | |||

test packets rate accordingly. Collecting statistics from a huge | test packets rate accordingly. Collecting statistics from a huge | |||

number of probes may overload any combination of the network where | number of probes may overload any combination of the network where | |||

the measurement controller is attached to, measurement controller | the measurement controller is attached to, measurement controller | |||

network interfaces and measurement controller computation capacities. | network interfaces and measurement controller computation capacities. | |||

One-to-group metrics measurement should consider using source | One-to-group metrics measurement should consider using source | |||

authentication protocols, standardized in the MSEC group, to avoid | authentication protocols, standardized in the MSEC group, to avoid | |||

fraud packet in the sampling interval. The test packet rate could be | fraud packet in the sampling interval. The test packet rate could be | |||

negotiated before any measurement session to avoid deny of service | negotiated before any measurement session to avoid deny of service | |||

attacks. | attacks. | |||

11. Acknowledgments | 12. Acknowledgments | |||

Lei would like to acknowledge Prof. Zhili Sun from CCSR, University | Lei would like to acknowledge Prof. Zhili Sun from CCSR, University | |||

of Surrey, for his instruction and helpful comments on this work. | of Surrey, for his instruction and helpful comments on this work. | |||

12. IANA Considerations | 13. IANA Considerations | |||

Metrics defined in this memo Metrics defined in this memo are | Metrics defined in this memo Metrics defined in this memo are | |||

designed to be registered in the IANA IPPM METRICS REGISTRY as | designed to be registered in the IANA IPPM METRICS REGISTRY as | |||

described in initial version of the registry [RFC4148] : | described in initial version of the registry [RFC4148] : | |||

IANA is asked to register the following metrics in the IANA-IPPM- | IANA is asked to register the following metrics in the IANA-IPPM- | |||

METRICS-REGISTRY-MIB : | METRICS-REGISTRY-MIB : | |||

ietfSpatialOneWayDelayVector OBJECT-IDENTITY | ietfSpatialOneWayDelayVector OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-Spatial-One-way-Delay-Vector" | "Type-P-Spatial-One-way-Delay-Vector" | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 4.1." | "Reference "RFCyyyy, section 5.1." | |||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | -- RFC Ed.: replace yyyy with actual RFC number & remove this | |||

note | note | |||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics nn } -- IANA assigns nn | |||

ietfSpatialPacketLossVector OBJECT-IDENTITY | ietfSpatialPacketLossVector OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-Spatial-Packet-Loss-Vector" | "Type-P-Spatial-Packet-Loss-Vector" | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 4.2." | "Reference "RFCyyyy, section 5.2." | |||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | -- RFC Ed.: replace yyyy with actual RFC number & remove this | |||

note | note | |||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics nn } -- IANA assigns nn | |||

ietfSpatialOneWayIpdvVector OBJECT-IDENTITY | ietfSpatialOneWayIpdvVector OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-Spatial-One-way-ipdv-Vector" | "Type-P-Spatial-One-way-ipdv-Vector" | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 4.3." | "Reference "RFCyyyy, section 5.3." | |||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | -- RFC Ed.: replace yyyy with actual RFC number & remove this | |||

note | note | |||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics nn } -- IANA assigns nn | |||

ietfSegmentOneWayDelayStream OBJECT-IDENTITY | ietfSegmentOneWayDelayStream OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-Segment-One-way-Delay-Stream" | "Type-P-Segment-One-way-Delay-Stream" | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 5.1." | "Reference "RFCyyyy, section 6.1." | |||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | -- RFC Ed.: replace yyyy with actual RFC number & remove this | |||

note | note | |||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics nn } -- IANA assigns nn | |||

ietfSegmentPacketLossStream OBJECT-IDENTITY | ietfSegmentPacketLossStream OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-Segment-Packet-Loss-Stream" | "Type-P-Segment-Packet-Loss-Stream" | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 5.2." | "Reference "RFCyyyy, section 6.2." | |||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | -- RFC Ed.: replace yyyy with actual RFC number & remove this | |||

note | note | |||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics nn } -- IANA assigns nn | |||

ietfSegmentOneWayIpdvPrevStream OBJECT-IDENTITY | ietfSegmentIpdvPrevStream OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-Segment-One-way-ipdv-prev-Stream" | "Type-P-Segment-ipdv-prev-Stream" | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 5.3." | "Reference "RFCyyyy, section 6.3." | |||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | -- RFC Ed.: replace yyyy with actual RFC number & remove this | |||

note | note | |||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics nn } -- IANA assigns nn | |||

ietfSegmentOneWayIpdvMinStream OBJECT-IDENTITY | ietfSegmentIpdvMinStream OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-Segment-One-way-ipdv-min-Stream" | "Type-P-Segment-ipdv-min-Stream" | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 5.4." | "Reference "RFCyyyy, section 6.4." | |||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | -- RFC Ed.: replace yyyy with actual RFC number & remove this | |||

note | note | |||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics nn } -- IANA assigns nn | |||

-- One-to-group metrics | -- One-to-group metrics | |||

ietfOneToGroupOneWayDelayVector OBJECT-IDENTITY | ietfOneToGroupDelayVector OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-One-to-group-One-way-Delay-Vector" | "Type-P-One-to-group-Delay-Vector" | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 6.1." | "Reference "RFCyyyy, section 7.1." | |||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | -- RFC Ed.: replace yyyy with actual RFC number & remove this | |||

note | note | |||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics nn } -- IANA assigns nn | |||

ietfOneToGroupOneWayPktLossVector OBJECT-IDENTITY | ietfOneToGroupPacketLossVector OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-One-to-Group-One-way-Packet-Loss-Vector" | "Type-P-One-to-group-Packet-Loss-Vector" | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 6.2." | "Reference "RFCyyyy, section 7.2." | |||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | -- RFC Ed.: replace yyyy with actual RFC number & remove this | |||

note | note | |||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics nn } -- IANA assigns nn | |||

ietfOneToGroupOneWayIpdvVector OBJECT-IDENTITY | ietfOneToGroupIpdvVector OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-One-to-Group-One-way-ipdv-Vector" | "Type-P-One-to-group-ipdv-Vector" | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 6.3." | "Reference "RFCyyyy, section 7.3." | |||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | -- RFC Ed.: replace yyyy with actual RFC number & remove this | |||

note | note | |||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics nn } -- IANA assigns nn | |||

-- One to group statistics | -- One to group statistics | |||

-- | -- | |||

ietfOnetoGroupReceiverNMeanDelay OBJECT-IDENTITY | ietfOnetoGroupReceiverNMeanDelay OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-One-to-Group-Receiver-n-Mean-Delay" | "Type-P-One-to-group-Receiver-n-Mean-Delay" | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 7.3.1." | "Reference "RFCyyyy, section 8.3.1." | |||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | -- RFC Ed.: replace yyyy with actual RFC number & remove this | |||

note | note | |||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics nn } -- IANA assigns nn | |||

ietfOneToGroupMeanDelay OBJECT-IDENTITY | ietfOneToGroupMeanDelay OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-One-to-Group-Mean-Delay" | "Type-P-One-to-group-Mean-Delay" | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 7.3.2." | "Reference "RFCyyyy, section 8.3.2." | |||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | -- RFC Ed.: replace yyyy with actual RFC number & remove this | |||

note | note | |||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics nn } -- IANA assigns nn | |||

ietfOneToGroupRangeMeanDelay OBJECT-IDENTITY | ietfOneToGroupRangeMeanDelay OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-One-to-Group-Range-Mean-Delay" | "Type-P-One-to-group-Range-Mean-Delay" | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 7.3.3." | "Reference "RFCyyyy, section 8.3.3." | |||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | -- RFC Ed.: replace yyyy with actual RFC number & remove this | |||

note | note | |||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics nn } -- IANA assigns nn | |||

ietfOneToGroupMaxMeanDelay OBJECT-IDENTITY | ietfOneToGroupMaxMeanDelay OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-One-to-Group-Max-Mean-Delay" | "Type-P-One-to-group-Max-Mean-Delay" | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 7.3.4." | "Reference "RFCyyyy, section 8.3.4." | |||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | -- RFC Ed.: replace yyyy with actual RFC number & remove this | |||

note | note | |||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics nn } -- IANA assigns nn | |||

ietfOneToGroupReceiverNLossRatio OBJECT-IDENTITY | ietfOneToGroupReceiverNLossRatio OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-One-to-Group-Receiver-n-Loss-Ratio" | "Type-P-One-to-group-Receiver-n-Loss-Ratio" | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 7.4.1." | "Reference "RFCyyyy, section 8.4.1." | |||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | -- RFC Ed.: replace yyyy with actual RFC number & remove this | |||

note | note | |||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics nn } -- IANA assigns nn | |||

-- | -- | |||

ietfOneToGroupReceiverNCompLossRatio OBJECT-IDENTITY | ietfOneToGroupReceiverNCompLossRatio OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-One-to-Group-Receiver-n-Comp-Loss-Ratio" | "Type-P-One-to-group-Receiver-n-Comp-Loss-Ratio" | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 7.4.2." | "Reference "RFCyyyy, section 8.4.2." | |||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | -- RFC Ed.: replace yyyy with actual RFC number & remove this | |||

note | note | |||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics nn } -- IANA assigns nn | |||

ietfOneToGroupLossRatio OBJECT-IDENTITY | ietfOneToGroupLossRatio OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-One-to-Group-Loss-Ratio" | "Type-P-One-to-group-Loss-Ratio" | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 7.4.3." | "Reference "RFCyyyy, section 8.4.3." | |||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | -- RFC Ed.: replace yyyy with actual RFC number & remove this | |||

note | note | |||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics nn } -- IANA assigns nn | |||

-- | -- | |||

ietfOneToGroupRangeLossRatio OBJECT-IDENTITY | ietfOneToGroupRangeLossRatio OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-One-to-Group-Range-Loss-Ratio" | "Type-P-One-to-group-Range-Loss-Ratio" | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 7.4.4." | "Reference "RFCyyyy, section 8.4.4." | |||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | -- RFC Ed.: replace yyyy with actual RFC number & remove this | |||

note | note | |||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics nn } -- IANA assigns nn | |||

ietfOneToGroupRangeDelayVariation OBJECT-IDENTITY | ietfOneToGroupRangeDelayVariation OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-One-to-Group-Range-Delay-Variation" | "Type-P-One-to-group-Range-Delay-Variation" | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 7.5.1." | "Reference "RFCyyyy, section 8.5.1." | |||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | -- RFC Ed.: replace yyyy with actual RFC number & remove this | |||

note | note | |||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics nn } -- IANA assigns nn | |||

-- | -- | |||

13. References | 14. References | |||

13.1. Normative References | 14.1. Normative References | |||

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||

Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||

[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way | [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way | |||

Delay Metric for IPPM", RFC 2679, September 1999. | Delay Metric for IPPM", RFC 2679, September 1999. | |||

[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way | [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way | |||

Packet Loss Metric for IPPM", RFC 2680, September 1999. | Packet Loss Metric for IPPM", RFC 2680, September 1999. | |||

[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation | [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation | |||

Metric for IP Performance Metrics (IPPM)", RFC 3393, | Metric for IP Performance Metrics (IPPM)", RFC 3393, | |||

November 2002. | November 2002. | |||

[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics | [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics | |||

Registry", BCP 108, RFC 4148, August 2005. | Registry", BCP 108, RFC 4148, August 2005. | |||

13.2. Informative References | 14.2. Informative References | |||

[I-D.ietf-ippm-spatial-composition] | ||||

Morton, A. and E. Stephan, "Spatial Composition of | ||||

Metrics", draft-ietf-ippm-spatial-composition-07 (work in | ||||

progress), July 2008. | ||||

[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, | [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, | |||

"Framework for IP Performance Metrics", RFC 2330, | "Framework for IP Performance Metrics", RFC 2330, | |||

May 1998. | May 1998. | |||

[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network | [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network | |||

performance measurement with periodic streams", RFC 3432, | performance measurement with periodic streams", RFC 3432, | |||

November 2002. | November 2002. | |||

Authors' Addresses | Authors' Addresses | |||

End of changes. 350 change blocks. | ||||

873 lines changed or deleted | | 901 lines changed or added | ||

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