draft-ietf-ippm-multimetrics-12.txt | rfc5644.txt | |||
---|---|---|---|---|

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

Internet-Draft France Telecom | Request for Comments: 5644 France Telecom | |||

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

Expires: March 5, 2010 University of Surrey | University of Surrey | |||

A. Morton | A. Morton | |||

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

September 1, 2009 | October 2009 | |||

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

draft-ietf-ippm-multimetrics-12 | ||||

Status of this Memo | ||||

This Internet-Draft is submitted to IETF in full conformance with the | ||||

provisions of BCP 78 and BCP 79. This document may contain material | ||||

from IETF Documents or IETF Contributions published or made publicly | ||||

available before November 10, 2008. The person(s) controlling the | ||||

copyright in some of this material may not have granted the IETF | ||||

Trust the right to allow modifications of such material outside the | ||||

IETF Standards Process. Without obtaining an adequate license from | ||||

the person(s) controlling the copyright in such materials, this | ||||

document may not be modified outside the IETF Standards Process, and | ||||

derivative works of it may not be created outside the IETF Standards | ||||

Process, except to format it for publication as an RFC or to | ||||

translate it into languages other than English. | ||||

Internet-Drafts are working documents of the Internet Engineering | IP Performance Metrics (IPPM): Spatial and Multicast | |||

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

other groups may also distribute working documents as Internet- | ||||

Drafts. | ||||

Internet-Drafts are draft documents valid for a maximum of six months | Abstract | |||

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

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

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

The list of current Internet-Drafts can be accessed at | The IETF has standardized IP Performance Metrics (IPPM) for measuring | |||

http://www.ietf.org/ietf/1id-abstracts.txt. | end-to-end performance between two points. This memo defines two new | |||

categories of metrics that extend the coverage to multiple | ||||

measurement points. It defines spatial metrics for measuring the | ||||

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

for measuring the performance between a source and many destinations | ||||

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

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

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

This Internet-Draft will expire on March 5, 2010. | This document specifies an Internet standards track protocol for the | |||

Internet community, and requests discussion and suggestions for | ||||

improvements. Please refer to the current edition of the "Internet | ||||

Official Protocol Standards" (STD 1) for the standardization state | ||||

and status of this protocol. Distribution of this memo is unlimited. | ||||

Copyright Notice | Copyright Notice | |||

Copyright (c) 2009 IETF Trust and the persons identified as the | Copyright (c) 2009 IETF Trust and the persons identified as the | |||

document authors. All rights reserved. | document authors. All rights reserved. | |||

This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||

Provisions Relating to IETF Documents in effect on the date of | Provisions Relating to IETF Documents | |||

publication of this document (http://trustee.ietf.org/license-info). | (http://trustee.ietf.org/license-info) in effect on the date of | |||

Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||

and restrictions with respect to this document. | carefully, as they describe your rights and restrictions with respect | |||

to this document. Code Components extracted from this document must | ||||

Abstract | include Simplified BSD License text as described in Section 4.e of | |||

the Trust Legal Provisions and are provided without warranty as | ||||

described in the BSD License. | ||||

The IETF has standardized IP Performance Metrics (IPPM) for measuring | This document may contain material from IETF Documents or IETF | |||

end-to-end performance between two points. This memo defines two new | Contributions published or made publicly available before November | |||

categories of metrics that extend the coverage to multiple | 10, 2008. The person(s) controlling the copyright in some of this | |||

measurement points. It defines spatial metrics for measuring the | material may not have granted the IETF Trust the right to allow | |||

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

for measuring the performance between a source and many destinations | ||||

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

Requirements Language | RFC 5644 Spatial and Multicast Metrics October 2009 | |||

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | modifications of such material outside the IETF Standards Process. | |||

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | Without obtaining an adequate license from the person(s) controlling | |||

document are to be interpreted as described in RFC 2119 [RFC2119]. | the copyright in such materials, this document may not be modified | |||

outside the IETF Standards Process, and derivative works of it may | ||||

not be created outside the IETF Standards Process, except to format | ||||

it for publication as an RFC or to translate it into languages other | ||||

than English. | ||||

Table of Contents | Table of Contents | |||

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

2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Terminology .....................................................4 | |||

3. Brief Metric Descriptions . . . . . . . . . . . . . . . . . . 8 | 3. Brief Metric Descriptions .......................................7 | |||

4. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 4. Motivations ....................................................10 | |||

5. Spatial vector metrics definitions . . . . . . . . . . . . . . 12 | 5. Spatial Vector Metrics Definitions .............................12 | |||

6. Spatial Segment Metrics Definitions . . . . . . . . . . . . . 19 | 6. Spatial Segment Metrics Definitions ............................19 | |||

7. One-to-group metrics definitions . . . . . . . . . . . . . . . 24 | 7. One-to-Group Metrics Definitions ...............................27 | |||

8. One-to-group Sample Statistics . . . . . . . . . . . . . . . . 28 | 8. One-to-Group Sample Statistics .................................30 | |||

9. Measurement Methods: Scalability and Reporting . . . . . . . . 37 | 9. Measurement Methods: Scalability and Reporting .................40 | |||

10. Manageability Considerations . . . . . . . . . . . . . . . . . 41 | 10. Manageability Considerations ..................................44 | |||

11. Security Considerations . . . . . . . . . . . . . . . . . . . 45 | 11. Security Considerations .......................................49 | |||

12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47 | 12. Acknowledgments ...............................................50 | |||

13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 | 13. IANA Considerations ...........................................50 | |||

14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 | 14. References ....................................................56 | |||

14.1. Normative References . . . . . . . . . . . . . . . . . . 51 | 14.1. Normative References .....................................56 | |||

14.2. Informative References . . . . . . . . . . . . . . . . . 52 | 14.2. Informative References ...................................57 | |||

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 | ||||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

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

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

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

categories of metrics that extend the coverage to multiple | categories of metrics that extend the coverage to multiple | |||

measurement points. It defines spatial metrics for measuring the | measurement points. It defines spatial metrics for measuring the | |||

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

for measuring the performance between a source and many destinations | for measuring the performance between a source and many destinations | |||

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

The purpose of the memo is to define metrics to fulfill the new | The purpose of this 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 measure the performance of each segment along a path. | Spatial metrics measure the performance of each segment along a path. | |||

One-to-group metrics measure the performance for a group of users. | One-to-group metrics measure the performance for 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, all of | |||

which follow the IPPM framework [RFC2330]. | which follow the IPPM framework [RFC2330]. | |||

This memo is organized as follows: Section 2 introduces new terms | This memo is organized as follows: Section 2 introduces new terms | |||

that extend the original IPPM framework [RFC2330]. Section 3 | that extend the original IPPM framework [RFC2330]. Section 3 briefly | |||

motivates each metric category and briefly introduces the new | introduces the new metrics, and Section 4 motivates each metric | |||

metrics. Sections 4 through 7 develop each category of metrics with | category. Sections 5 through 8 develop each category of metrics with | |||

definitions and statistics. Then the memo discusses the impact of | definitions and statistics. Then the memo discusses the impact of | |||

the measurement methods on the scalability and proposes an | the measurement methods on the scalability and proposes an | |||

information model for reporting the measurements. Finally, the memo | information model for reporting the measurements. Finally, the memo | |||

discusses security aspects related to measurement and registers the | discusses security aspects related to measurement and registers the | |||

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

The scope of this memo is limited to metrics using a single source | The scope of this memo is limited to metrics using a single source | |||

packet or stream, and observations of corresponding packets along the | packet or stream, and observations of corresponding packets along the | |||

path (spatial), at one or more destinations (one-to-group), or both. | path (spatial), at one or more destinations (one-to-group), or both. | |||

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

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

measurement. Passive measurement (for example, a spatial metric | 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. | |||

1.1. Requirements Language | ||||

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

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

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

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

2. Terminology | 2. Terminology | |||

2.1. Naming of the metrics | 2.1. Naming of the Metrics | |||

The names of the metrics, including capitalization letters, are as | The names of the metrics, including capitalized letters, are as close | |||

close as possible of the names of the one-way end-to-end metrics they | as possible of the names of the one-way end-to-end metrics they are | |||

are derived from. | derived from. | |||

2.2. Terms Defined Elsewhere | 2.2. Terms Defined Elsewhere | |||

host: section 5 of RFC 2330 | host: section 5 of RFC 2330 | |||

router: section 5 of RFC 2330 | router: section 5 of RFC 2330 | |||

loss threshold: section 2.8.2 of RFC 2680 | loss threshold: section 2.8.2 of RFC 2680 | |||

path: section 5 of RFC 2330 | path: section 5 of RFC 2330 | |||

sample: section 11 of RFC 2330 | sample: section 11 of RFC 2330 | |||

singleton: section 11 of RFC 2330 | singleton: section 11 of RFC 2330 | |||

2.3. Routers Digest | 2.3. Routers Digest | |||

The list of the routers on the path from the source to the | The list of the routers on the path from the source to the | |||

destination which act as points of interest, also referred to as the | destination that act as points of interest, also referred to as the | |||

routers digest. | routers digest. | |||

2.4. Multiparty metric | 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 designate a | one measurement collection point. All multiparty metrics designate a | |||

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

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

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

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

measurements may be conducted between < ha, hb>, < ha, hc>, ..., <ha, | measurements may be conducted between < ha, hb>, < ha, hc>, ..., <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.5. 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(s). Such measurement hosts will usually be | of the measured packet(s). Such measurement hosts will usually be | |||

routers member of the routers digest. | routers that are members of the routers digest. | |||

2.6. One-to-group metric | RFC 5644 Spatial and Multicast Metrics October 2009 | |||

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 more than one destination. | one source and (potentially) received by more than one destination. | |||

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

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

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

2.7. Points of interest | 2.7. Points of Interest | |||

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

"hosts" include routing nodes) that are measurement collection | "hosts" include routing nodes) that are measurement collection | |||

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

packets (in addition to the source itself). | delivery of the packets (in addition to the source itself). | |||

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

sub-set of all the routers involved in the path. | sub-set of all the routers 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 Dst | Src Dst | |||

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

skipping to change at page 6, line 32 | skipping to change at page 5, line 42 | |||

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

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

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

| | | | | | |||

: ; | : ; | |||

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

: ; | : ; | |||

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

`-'....... I | `-'....... I | |||

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 router from | A candidate point of interest for spatial metrics is a router from | |||

the set of routers involved in the delivery of the packets from | the set of routers involved in the delivery of the packets from | |||

source to destination. | source to destination. | |||

Src ------. Hosts | RFC 5644 Spatial and Multicast Metrics October 2009 | |||

\ | ||||

`---X --- 1 | Src ------. Hosts | |||

\ | \ | |||

x | `---X --- 1 | |||

/ | \ | |||

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

/ | / | |||

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

... | / | |||

`---X ---- ... | x | |||

\ | ... | |||

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

\ | \ | |||

\ | \ | |||

X ---- J | \ | |||

\ | X ---- J | |||

\ | \ | |||

\ | \ | |||

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

`---- Dst | ||||

Note: 'X' are nodes which are points of interest, | Note: 'X' are nodes that are points of interest, | |||

'x' are nodes which are not points of interest | 'x' are nodes that are not points of interest | |||

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

2.8. 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. It is usually a centralized server | calculations will be carried out. It is usually a centralized server | |||

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

operator, where measurement data can be collected for further | operator, where measurement data can be collected for further | |||

processing. The reference point is distinctly different from hosts | processing. The reference point is distinctly different from hosts | |||

at measurement collection points, where the actual measurements are | at measurement collection points, where the actual measurements are | |||

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

2.9. Vector | 2.9. Vector | |||

A vector is a set of singletons (single atomic results) comprised of | A vector is a set of singletons (single atomic results) comprised of | |||

observations corresponding to a single source packet at different | observations corresponding to a single source packet at different | |||

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

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

dT2,..., dTN, then a vector V with N elements can be organized as | dT2,..., dTN, then a vector V with N elements can be organized as | |||

{dT1, dT2,..., dTN}. The element dT1 is distinct from all others as | {dT1, dT2,..., dTN}. The element dT1 is distinct from all others as | |||

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

source at a specific time. The complete vector gives information | source at a specific time. The complete vector gives information | |||

over the dimension of space; a set of N receivers in this example. | over the dimension of space, a set of N receivers in this example. | |||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

The singleton elements of any vector are distinctly different from | The singleton elements of any vector are distinctly different from | |||

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

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

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

2.10. Matrix | 2.10. Matrix | |||

Several vectors form a matrix, which contains results observed over a | 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 example, the 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, form a One-way delay Matrix {V1, V2,...,Vm}. | Packet P1, P2,...,Pm, form a one-way delay Matrix {V1, V2,...,Vm}. | |||

The matrix organizes the vector information to present network | The matrix organizes the vector information to present network | |||

performance in both space and time. | performance in both space and time. | |||

A one-dimensional matrix (row) 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 relationship among singleton, sample, vector and matrix is | The relationship among singleton, sample, vector, and matrix is | |||

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

points of singleton | points of singleton | |||

interest / samples(time) | 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 and space) | (space) (time and space) | |||

Figure 3: Relationship between singletons, samples, vectors and | Figure 3: Relationship between Singletons, Samples, Vectors, and | |||

matrix | Matrix | |||

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

The metrics for spatial and one-to-group measurement are based on the | The metrics for spatial and one-to-group measurement are based on the | |||

source-to-destination, or end-to-end metrics defined by IETF in | source-to-destination, or end-to-end metrics defined by IETF in | |||

[RFC2679], [RFC2680], [RFC3393], [RFC3432]. | [RFC2679], [RFC2680], [RFC3393], and [RFC3432]. | |||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

This memo defines seven new spatial metrics using the [RFC2330] | This memo defines seven new spatial metrics using the [RFC2330] | |||

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

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

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

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

The spatial metrics are: | The spatial metrics are: | |||

o Type-P-Spatial-One-way-Delay-Vector divides the end-to-end Type-P- | o Type-P-Spatial-One-way-Delay-Vector divides the end-to-end Type-P- | |||

One-way-Delay [RFC2679] into a spatial vector of one-way delay | One-way-Delay [RFC2679] into a spatial vector of one-way delay | |||

singletons. | singletons. | |||

o Type-P-Spatial-One-way-Packet-Loss-Vector divides an end-to-end | o Type-P-Spatial-One-way-Packet-Loss-Vector divides an end-to-end | |||

Type-P-One-way-Packet-Loss [RFC2680] into a spatial vector of | Type-P-One-way-Packet-Loss [RFC2680] into a spatial vector of | |||

packet loss singletons. | packet loss singletons. | |||

o Type-P-Spatial-One-way-ipdv-Vector divides an end-to-end Type-P- | o Type-P-Spatial-One-way-ipdv-Vector divides an end-to-end Type-P- | |||

One-way-ipdv into a spatial vector of ipdv (IP Packet Delay | One-way-ipdv into a spatial vector of ipdv (IP Packet Delay | |||

Variation) singletons. | Variation) singletons. | |||

o Using elements of the Type-P-Spatial-One-way-Delay-Vector metric, | o Using elements of the Type-P-Spatial-One-way-Delay-Vector metric, | |||

a sample called Type-P-Segment-One-way-Delay-Stream collects one- | a sample called Type-P-Segment-One-way-Delay-Stream collects one- | |||

way delay metrics between two points of interest on the path over | way delay metrics between two points of interest on the path over | |||

time. | time. | |||

o Likewise, using elements of the Type-P-Spatial-Packet-Loss-Vector | o Likewise, using elements of the Type-P-Spatial-Packet-Loss-Vector | |||

metric, a sample called Type-P-Segment-Packet-Loss-Stream collects | metric, a sample called Type-P-Segment-Packet-Loss-Stream collects | |||

one-way delay metrics between two points of interest on the path | one-way delay metrics between two points of interest on the path | |||

over time. | over time. | |||

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

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

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

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

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

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

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

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

The memo also defines three one-to-group metrics to measure the one- | 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: | 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-Delay-Vector which collects the set of Type-P- | |||

o Type-P-One-to-group-Packet-Loss-Vector collects the set of Type-P- | One-way-Delay singletons between one sender and N receivers; | |||

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- | RFC 5644 Spatial and Multicast Metrics October 2009 | |||

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

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

Type-P-One-way-Packet-Loss singletons between one sender and N | ||||

receivers; and | ||||

o Type-P-One-to-group-ipdv-Vector which 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, | Finally, based on the one-to-group vector metrics listed above, | |||

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

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

communication: | communication: | |||

o Using the Type-P-One-to-group-Delay-Vector, a metric called Type- | 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 | P-One-to-group-Receiver-n-Mean-Delay, or RnMD, presents the mean | |||

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

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

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

interval: | interval: | |||

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

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

delays; | delays; | |||

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

range of mean delays; | * Type-P-One-to-group-Range-Mean-Delay, or GRMD, presents the | |||

* Type-P-One-to-group-Max-Mean-Delay or GMMD, presents the | range of mean delays; and | |||

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

maximum of mean delays. | maximum of mean delays. | |||

o Using the Type-P-One-to-group-Packet-Loss-Vector, a metric called | 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 | Type-P-One-to-group-Receiver-n-Loss-Ratio, or RnLR, captures the | |||

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

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

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

time interval: | 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-Loss-Ratio, or GLR, captures the overall | |||

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

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

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

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

o Using the Type-P-One-to-group-Packet-Loss-Vector, a metric called | 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 | Type-P-One-to-group-Receiver-n-Comp-Loss-Ratio, or RnCLR, computes | |||

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

at any receiver. | at any receiver. | |||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

o Using Type-P-One-to-group-ipdv-Vector, a metric called Type-P-One- | 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 | to-group-Range-Delay-Variation, or GRDV, presents the range of | |||

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

4. Motivations | 4. Motivations | |||

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

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

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

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

4.1. Motivations for spatial metrics | 4.1. Motivations for Spatial Metrics | |||

Spatial metrics are needed for: | Spatial metrics are needed for: | |||

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

the per-AS contribution to the end-to-end performance. | the per-AS (Autonomous System) contribution to the end-to-end | |||

performance. | ||||

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

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

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

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

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

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

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

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

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

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

destination using Spatial Composition metrics | destination using Spatial Composition metrics [SPATIAL]. | |||

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

4.2. Motivations for One-to-group metrics | 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 | |||

point-to-point metric cannot completely describe the multiparty | point-to-point metric cannot completely describe the multiparty | |||

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

multiple paths for further statistical analysis. The new metrics are | multiple paths for further statistical analysis. The new metrics 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 RFCs. One-to-group metrics are one- | unicast metrics defined in IPPM RFCs. One-to-group metrics are one- | |||

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

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

multiparty communications network, and for describing the performance | multiparty communications network and for describing the performance | |||

variation across a group of destinations. | variation across a group of destinations. | |||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

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

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

multipoint LSPs. | multipoint Label Switched Paths (LSPs). | |||

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

including inter-domain multicast. | including inter-domain multicast. | |||

o Presenting and evaluating the performance requirements for | o 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. This gives | collect instantaneous end-to-end metrics, or singletons. This gives | |||

a very detailed view into the performance of each branch of the | a very detailed view into the performance of each branch of the | |||

multicast tree, and can provide clear and helpful information for | multicast tree, and can provide clear and helpful information for | |||

engineers to identify the branch with problems in a complex | engineers to identify the branch 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 into the IPPM framework, and describe the | multiparty topology into the IPPM framework, and they describe the | |||

performance delivered to a group receiving packets from the same | performance delivered to a group receiving packets from the same | |||

source. The concept extends the "path" of the point-to-point | source. The concept extends the "path" of the point-to-point | |||

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

applied to one-to-one topology, the one-to-group metrics provide | applied to one-to-one topology, the one-to-group metrics provide | |||

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

4.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 beyond the scope of this memo, because they would | topologies are beyond the scope of this memo, because they would | |||

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

this section gives some insights 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 host that | the one-to-group measurement. The measurement point is the host that | |||

is acting as a receiver while all other hosts act as sources in this | is acting as a receiver while all other hosts act as sources in this | |||

case. | case. | |||

The group-to-group communication topology has no obvious focal point: | The group-to-group communication topology has no obvious focal point: | |||

the sources and the measurement collection points can be anywhere. | the sources and the measurement collection points can be anywhere. | |||

However, it is possible to organize the problem by applying | However, it is possible to organize the problem by applying | |||

measurements in one-to-group or group-to-one topologies for each host | measurements in one-to-group or group-to-one topologies for each host | |||

in a uniform way (without taking account of how the real | in a uniform way (without taking account of how the real | |||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

communication might be carried out). For example, one group of hosts | communication might be carried out). For example, one group of hosts | |||

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

group of hosts < Ha, Hb, Hc, ..., Hm >, and they can be organized | group of hosts < Ha, Hb, Hc, ..., Hm >, and they can be organized | |||

into n sets of points of interest for one-to-group communications: | into n sets of points of interest for one-to-group communications: | |||

< ha, Ha, Hb, Hc, ..., Hm >, < hb, Ha, Hb, Hc, ..., Hm >, <hc, Ha, | < ha, Ha, Hb, Hc, ..., Hm >, < hb, Ha, Hb, Hc, ..., Hm >, <hc, Ha, | |||

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

5. Spatial vector metrics definitions | 5. Spatial Vector Metrics Definitions | |||

This section defines vectors for the spatial decomposition of end-to- | This section defines vectors for the spatial decomposition of end-to- | |||

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

Spatial vector metrics are based on the decomposition of standard | 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]. | |||

The spatial vector definitions are coupled with the corresponding | The spatial vector definitions are coupled with the corresponding | |||

end-to-end metrics. Measurement methodology aspects are common to | end-to-end metrics. Measurement methodology aspects are common to | |||

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

section. | section. | |||

5.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 from the definition | in section 3 of [RFC2679]. When a parameter from the definition in | |||

in [RFC2679] is re-used in this section, the first instance will be | [RFC2679] is re-used in this section, the first instance will be | |||

tagged with a trailing 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 MUST respect them, especially those | Spatial one-way delay measurements MUST respect them, especially | |||

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

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

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

5.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 routers in the | o i, an integer in the ordered list <1,2,...,n> of routers in the | |||

path. | path. | |||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

o Hi, a router of the routers digest. | o Hi, a router of the routers 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 dTi, a delay, the one-way delay for a measured packet from the | o dTi, a delay, the one-way delay for a measured packet from the | |||

source to router Hi. | source to router Hi. | |||

o <dT1,... dTi,... dTn> a list of n delay singletons. | o <dT1,... dTi,... dTn> a list of n delay singletons. | |||

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

o <H1, H2,..., Hn> the routers digest. | o <H1, H2,..., Hn> the routers digest. | |||

5.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 (a real number in the dimension of seconds with sufficient | times (a real number in the dimension of seconds with sufficient | |||

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

5.1.4. Definition | 5.1.4. Definition | |||

skipping to change at page 14, line 8 | skipping to change at page 13, line 46 | |||

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

within a specified loss threshold* time. | 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>. | |||

5.1.5. Discussion | 5.1.5. Discussion | |||

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

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

occur despite being physically impossible with the definition | occur despite being physically impossible with the definition | |||

used. | used. | |||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

* This is frequently due to a measurement clock synchronization | * This is frequently due to a measurement clock synchronization | |||

issue. This point is discussed in the section 3.7.1. "Errors | issue. This point is discussed in section 3.7.1 "Errors or | |||

or uncertainties related to Clocks" of [RFC2679]. | uncertainties related to Clocks" of [RFC2679]. Consequently, | |||

Consequently, the values of delays measured at multiple routers | the values of delays measured at multiple routers may not match | |||

may not match the order of those routers on the path. | the order of those routers on the path. | |||

* The actual order of routers on the path may change due to | * The actual order of routers on the path may change due to | |||

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

* The location of the measurement collection point in the device | * The location of the measurement collection point in the device | |||

influences the result. If the packet is not observed directly | influences the result. If the packet is not observed directly | |||

on the input interface the delay includes buffering time and | 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 | |||

time' and 'host time'. | 'wire-time' and 'host time'. | |||

5.2. A Definition for Spatial 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. When a parameter from section 2 of [RFC2680] is used in this | Loss. When a parameter from section 2 of [RFC2680] is used in this | |||

section, the first instance will be tagged with a trailing asterisk. | 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 MUST respect them, especially those | Spatial packet loss measurement MUST respect them, especially those | |||

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

The following sections define the spatial loss vector, adapt some of | The following sections define the spatial loss vector, adapt some of | |||

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

measurement. | measurement. | |||

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

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

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

skipping to change at page 14, line 47 | skipping to change at page 14, line 45 | |||

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

measurement. | measurement. | |||

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

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

5.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 in the ordered list <1,2,...,n> of routers in the | o i, an integer in the ordered list <1,2,...,n> of routers in the | |||

path. | path. | |||

o Hi, a router of the routers digest. | o Hi, a router of the routers digest. | |||

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

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

o dTi, a delay, the one-way delay for a measured packet from the | o dTi, a delay, the one-way delay for a measured packet from the | |||

source to host Hi. | source to host Hi. | |||

o <dT1,..., dTn>, list of n delay singletons. | o <dT1,..., dTn>, list of n delay singletons. | |||

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

o <H1, H2,..., Hn>, the routers digest. | o <H1, H2,..., Hn>, the routers digest. | |||

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

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

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

Boolean values. | Boolean values. | |||

5.2.4. Definition | 5.2.4. Definition | |||

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

skipping to change at page 15, line 31 | skipping to change at page 15, line 36 | |||

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

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

..., Hn>, define the Type-P-Packet-Loss-Vector metric as the sequence | ..., Hn>, define the Type-P-Packet-Loss-Vector metric as the sequence | |||

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

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

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

5.2.5. Discussion | 5.2.5. Discussion | |||

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

o The result might include the sequence of values 1,0. Although | o The result might include the sequence of values 1,0. Although | |||

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

appears later on the path): | appears later on the path): | |||

* The actual routers on the path may change due to reconvergence | * The actual routers on the path may change due to reconvergence | |||

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

* The order of routers on the path may change due to | * The order of routers on the path may change due to | |||

reconvergence. | reconvergence. | |||

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

CPU overflow at the measurement collection point. | CPU overflow at the measurement collection point. | |||

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

When a parameter from section 2 of [RFC3393] (the definition of Type- | When a parameter from section 2 of [RFC3393] (the definition of Type- | |||

P-One-way-ipdv) is used in this section, the first instance will be | P-One-way-ipdv) is used in this section, the first instance will be | |||

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

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

The following sections define the spatial ipdv vector, adapt some of | The following sections define the spatial ipdv vector, adapt some of | |||

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

measurement. | measurement. | |||

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

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

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

skipping to change at page 16, line 12 | skipping to change at page 16, line 18 | |||

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

measurement. | measurement. | |||

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

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

5.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 routers in the | o i, an integer in the ordered list <1,2,...,n> of routers in the | |||

path. | path. | |||

o Hi, a router of the routers digest. | o Hi, a router of the routers 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 dTi, a delay, the one-way delay for a measured packet from the | o dTi, a delay, the one-way delay for a measured packet from the | |||

source to router Hi. | source to router Hi. | |||

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

o Type-P*, the specification of the packet 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>, the routers digest. | o <H1, H2,..., Hn>, the routers 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 a 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 a 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. | |||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

5.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 (a real number in the dimension of seconds with sufficient | times (a real number in the dimension of seconds with sufficient | |||

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

5.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. Given <T1, dT1.1, dT1.2,..., dT1.n, dT1> | |||

its Type-P-Spatial-One-way-Delay-Vector over the sequence of routers | the Type-P-Spatial-One-way-Delay-Vector of P1 over the sequence of | |||

<H1, H2,..., Hn>. | routers <H1, H2,..., 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. Given <T2, dT2.1, dT2.2,..., dT2.n, dT2> | |||

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

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

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

dT1> such that for each Hi of the sequence of routers <H1, H2,..., | dT1.n, dT2-dT1> such that for each Hi of the sequence of routers <H1, | |||

Hn>, dT2.i-dT1.i is either a real number if the packets P1 and P2 | H2,..., Hn>, dT2.i-dT1.i is either a real number if the packets P1 | |||

pass Hi at wire-time (last bit) dT1.i and dT2.i respectively, or | and P2 pass Hi at wire-time (last bit) dT1.i and dT2.i respectively, | |||

undefined if at least one of them never passes Hi (and the respective | or undefined if at least one of them never passes Hi (and the | |||

one-way delay is undefined). The T1,T2* pair indicates the inter- | respective one-way delay is undefined). The T1,T2* pair indicates | |||

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

One-way-ipdv. | ||||

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

The methodology, reporting specifications, and uncertainties | The methodology, reporting specifications, and uncertainties | |||

specified in section 3 of [RFC2679] apply to each point of interest | specified in section 3 of [RFC2679] apply to each point of interest | |||

(or measurement collection point), Hi, measuring an element of a | (or measurement collection point), Hi, measuring an element of a | |||

spatial delay vector. | spatial delay vector. | |||

Likewise, the methodology, reporting specifications, and | Likewise, the methodology, reporting specifications, and | |||

uncertainties specified in section 2 of [RFC2680] apply to each point | uncertainties specified in section 2 of [RFC2680] apply to each point | |||

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

vector. | 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 MUST respect the methodology, clock, | Spatial One-way ipdv measurement MUST respect the methodology, clock, | |||

uncertainties and reporting aspects given there. | uncertainties, and reporting aspects given there. | |||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

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

the 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/measurement collection points | o At each Hi, points of interest/measurement collection points | |||

prepare to capture the packet sent at time T, record a timestamp | prepare to capture the packet sent at time T, record a timestamp | |||

Ti', and determine the internal delay correction dTi' (See section | Ti', and determine the internal delay correction dTi' (see section | |||

3.7.1. "Errors or uncertainties 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 (TTL)); | |||

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

dTi'. This arrival time is undefined if the packet is not | o Each Hi computes the corrected wire-time from Src to Hi: Ti = Ti' | |||

- 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 arranges | o The reference point gathers the result of each Hi and arranges | |||

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

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

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

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

5.4.1. Packet Loss Detection | 5.4.1. Packet Loss Detection | |||

In a pure end-to-end measurement, packet losses are detected by the | In a pure end-to-end measurement, packet losses are detected by the | |||

receiver only. A packet is lost when Type-P-One-way-Delay is | receiver only. A packet is lost when Type-P-One-way-Delay is | |||

undefined or very large (See section 2.4 ans 2.5 of [RFC2680] and | undefined or very large (see sections 2.4 and 2.5 of [RFC2680] and | |||

section 3.5 of [RFC2680]). A packet is deemed lost by the receiver | section 3.5 of [RFC2680]). A packet is deemed lost by the receiver | |||

after a duration which starts at the time the packet is sent. This | after a duration that starts at the time the packet is sent. This | |||

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

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

value or an undefined value. | value or an undefined value. | |||

In a spatial measurement, packet losses may be detected at several | In a spatial measurement, packet losses may be detected at several | |||

measurement collection points. Depending on the consistency of the | measurement collection points. Depending on the consistency of the | |||

packet loss detections among the points of interest, a packet may be | packet loss detections among the points of interest, a packet may be | |||

considered as lost at one point despite having a finite delay at | considered as lost at one point despite having a finite delay at | |||

another one, or may be observed by the last measurement collection | another, or it may be observed by the last measurement collection | |||

point of the path but considered lost by Dst. | point of the path but considered lost by Dst. | |||

There is a risk of misinterpreting such results: Has the path | There is a risk of misinterpreting such results: has the path | |||

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

the very last link? | the very last link? | |||

The same concern applies to one-way-delay measures: a delay measured | RFC 5644 Spatial and Multicast Metrics October 2009 | |||

The same concern applies to one-way delay measures: a delay measured | ||||

may be computed as infinite by one observation point but as a real | 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 | 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. | observation point of the path but designated as undefined by Dst. | |||

The observation/measurement collection points and the destination | The observation/measurement collection points and the destination | |||

SHOULD use consistent methods to detect packets losses. The methods | SHOULD use consistent methods to detect packets losses. The methods | |||

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

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

analysis. | analysis. | |||

5.4.2. Routers Digest | 5.4.2. Routers Digest | |||

The methodology given above relies on knowing the order of the | The methodology given above relies on knowing the order of the | |||

router/measurement collection points on the path [RFC2330]. | router/measurement collection points on the path [RFC2330]. | |||

Path instability might cause a test packet to be observed more than | Path instability might cause a test packet to be observed more than | |||

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

routers in the routers digest. | routers in the routers digest. | |||

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

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

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

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

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

and that the new path is from Hb to Ha. | Hb, and that the new path is from Hb to Ha. | |||

Consequently, duplication of routers in the routers digest of a | Consequently, duplication of routers in the routers digest of a | |||

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

producing corrupted information. | producing corrupted information. | |||

6. Spatial Segment Metrics Definitions | 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. The definitions rely on the matrix of the | of a path over time. The definitions rely on the matrix of the | |||

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

Firstly this section defines a sample of one-way delay, Type-P- | First, this section defines a sample of one-way delay, Type-P- | |||

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

segment-Packet-Loss-Stream. | Segment-Packet-Loss-Stream. | |||

Then it defines 2 different samples of ipdv: Type-P-Segment-ipdv- | Then, it defines two different samples of ipdv: Type-P-Segment-ipdv- | |||

prev-Stream uses the current and previous packets as the selection | prev-Stream uses the current and previous packets as the selection | |||

function, and Type-P-Segment-ipdv-min-Stream, uses the minimum delay | function, and Type-P-Segment-ipdv-min-Stream uses the minimum delay | |||

as one of the selected packets in every pair. | as one of the selected packets in every pair. | |||

6.1. A Definition of a Sample of One-way Delay of a Segment of the Path | RFC 5644 Spatial and Multicast Metrics October 2009 | |||

This metric defines a sample of One-way delays over time between a | 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 | ||||

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

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

of [RFC2679], sections 4.5 to 4.8 of [RFC2679] are integral parts of | of [RFC2679], sections 4.5 to 4.8 of [RFC2679] are integral parts of | |||

the definition text below. | the definition text below. | |||

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

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

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

skipping to change at page 19, line 35 | skipping to change at page 20, line 22 | |||

of [RFC2679], sections 4.5 to 4.8 of [RFC2679] are integral parts of | of [RFC2679], sections 4.5 to 4.8 of [RFC2679] are integral parts of | |||

the definition text below. | the definition text below. | |||

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

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

6.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 Type-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 routers in the | o i, an integer in the ordered list <1,2,...,n> of routers in the | |||

path. | path. | |||

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

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

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

o Hi, a router of the routers digest. | o Hi, a router of the routers digest. | |||

o <H1,..., Ha, ..., Hb, ...., Hn>, the routers digest. | o <H1,..., Ha, ..., Hb, ...., Hn>, the routers digest. | |||

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

6.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: | |||

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

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

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

6.1.4. Definition | 6.1.4. Definition | |||

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

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

for the 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> : | |||

: | ||||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

<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 sent at time Tk passes Ha and Hb or undefined if this | the packet sent at the time Tk passes Ha and Hb, or is undefined if | |||

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

6.1.5. Discussion | 6.1.5. Discussion | |||

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

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

discussed in section 5.1.5. | discussed in section 5.1.5. | |||

* This could also occur when the clock resolution of one | * This could also occur when the clock resolution of one | |||

measurement collection point is larger than the minimum delay | measurement collection point is larger than the minimum delay | |||

of a path. For example, the minimum delay of a 500 km path | of a path. For example, the minimum delay of a 500 km path | |||

through optical fiber facilities is 2.5ms, but the measurement | through optical fiber facilities is 2.5 ms, but the measurement | |||

collection point has a clock resolution of 8ms. | collection point has a clock resolution of 8 ms. | |||

The metric SHALL be invalid for times < T1 , T2, ..., Tm-1, Tm> if | The metric SHALL be invalid for times < T1 , T2, ..., Tm-1, Tm> if | |||

the following conditions occur: | the following conditions occur: | |||

o Ha or Hb disappears from the path due to some routing change. | 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 The order of Ha and Hb changes in the path. | |||

6.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 loss over time between a pair | This metric defines a sample of packet loss over time between a pair | |||

of routers of a path. Since it is very close semantically to the | of routers of a path. Since it is very close semantically to the | |||

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

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

text below. | text below. | |||

skipping to change at page 20, line 47 | skipping to change at page 21, line 51 | |||

6.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 loss over time between a pair | This metric defines a sample of packet loss over time between a pair | |||

of routers of a path. Since it is very close semantically to the | of routers of a path. Since it is very close semantically to the | |||

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

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

text below. | text below. | |||

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

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

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

6.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 Dst, the IP address of the receiver. | |||

o Type-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 n, an integer which orders the routers on the path. | o k, an integer that orders the packets sent. | |||

o n, an integer that orders the routers on the path. | ||||

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

o <H1, H2, ..., Ha, ..., Hb, ...,Hn>, the routers digest. | o <H1, H2, ..., Ha, ..., Hb, ...,Hn>, the routers digest. | |||

o Hi, a router of the routers digest. | o Hi, a router of the routers 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. | |||

6.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: | |||

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

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

A sequence of Boolean values. | A sequence of Boolean values. | |||

6.2.4. Definition | 6.2.4. Definition | |||

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

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

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, L1.1, L1.2,..., L1.a, ..., L1.b, ..., L1.n, L>, | <T1, L1.1, L1.2,..., L1.a, ..., L1.b, ..., L1.n, L>, | |||

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

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

<Tm, 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-Loss-Stream | We define the value of the sample Type-P-Segment-Packet-Loss-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: | |||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

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 (both 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 observe the packet | Tk (Lk.a has a value of 0) and that Hb did not observe the packet | |||

sent at time Tk (Lk.b has 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 nor Hb observed the | o The value of Lk is undefined when neither Ha nor Hb observed the | |||

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

6.2.5. Discussion | 6.2.5. Discussion | |||

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

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

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

conditions occur: | conditions occur: | |||

o Ha or Hb disappears from the path due to some routing change. | 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 The order of Ha and Hb changes in the path. | |||

o Lk.a or Lk.b is undefined. | 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). | |||

6.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 routers using the previous packet as the selection function. | pair of routers using the previous packet as the selection function. | |||

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

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

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

skipping to change at page 22, line 24 | skipping to change at page 23, line 49 | |||

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 routers using the previous packet as the selection function. | pair of routers using the previous packet as the selection function. | |||

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

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

6.3.2. Metric Parameters | 6.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 Type-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 n, an integer which orders the routers on the path. | o k, an integer that orders the packets sent. | |||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

o n, an integer that orders the routers on the path. | ||||

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

o <H1, H2, ..., Ha, ..., Hb, ...,Hn>, the routers digest. | o <H1, H2, ..., Ha, ..., Hb, ...,Hn>, the routers 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. | |||

6.3.3. Metric Units | 6.3.3. Metric Units | |||

The value of a Type-P-Segment-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>; and | ||||

A list of pairs of interval of times and delays; | A list of pairs of interval of times and delays; | |||

6.3.4. Definition | 6.3.4. Definition | |||

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

..., Hn>, and the matrix of Type-P-Spatial-One-way-Delay-Vector for | ..., 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> : | 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-ipdv-prev-Stream as the sequence of | We define the Type-P-Segment-ipdv-prev-Stream as the sequence of | |||

packet time pairs and delay variations | packet time pairs and delay variations | |||

<(T1, T2 , dT2.ab - dT1.ab) ,..., | <(T1, T2 , dT2.ab - dT1.ab) ,..., | |||

(Tk-1, Tk, dTk.ab - dTk-1.ab), ..., | (Tk-1, Tk, dTk.ab - dTk-1.ab), ..., | |||

(Tm-1, Tm, dTm.ab - dTm-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- | For any pair, Tk, Tk-1 in k=1 through m, the difference dTk.ab - dTk- | |||

1.ab is undefined if: | 1.ab is undefined if: | |||

o the delay dTk.a or the delay dTk-1.a is undefined, OR | 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. | o the delay dTk.b or the delay dTk-1.b is undefined. | |||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

6.3.5. Discussion | 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) whose results are extremely sensitive to | metrics (IPDV in uppercase) whose results are extremely sensitive to | |||

the inter-packet interval in practice. | the inter-packet interval in practice. | |||

The inter-packet interval of an 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 source (ingress point of interest). In contrast, the | control of the source (ingress point of interest). In contrast, the | |||

inter-packet interval of a segment IPDV metric is not under the | inter-packet interval of a segment IPDV metric is not under the | |||

control the ingress point of interest of the measure, Ha. The | control the ingress point of interest of the measure, Ha. The | |||

interval will certainly vary if there is delay variation between the | interval will certainly vary if there is delay variation between the | |||

Source and Ha. Therefore, the ingress inter-packet interval must be | Source and Ha. Therefore, the ingress inter-packet interval must be | |||

known at Ha in order to fully comprehend the delay variation between | known at Ha in order to fully comprehend the delay variation between | |||

Ha and Hb. | Ha and Hb. | |||

6.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 routers on a path using the minimum delay as one of the | pair of routers on a path using the minimum delay as one of the | |||

selected packets in every pair. | selected packets in every pair. | |||

6.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 | |||

skipping to change at page 23, line 44 | skipping to change at page 25, line 36 | |||

pair of routers on a path using the minimum delay as one of the | pair of routers on a path using the minimum delay as one of the | |||

selected packets in every pair. | selected packets in every pair. | |||

6.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 | |||

6.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 Type-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 i, an integer which identifies a packet sent. | o k, an integer that orders the packets sent. | |||

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

o i, an integer that identifies a packet sent. | ||||

o n, an integer that orders the routers on the path. | ||||

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

o <H1, H2, ..., Ha, ..., Hb, ...,Hn>, the routers digest. | o <H1, H2, ..., Ha, ..., Hb, ...,Hn>, the routers 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. | |||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

6.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>; and | ||||

A list of times. | A list of times. | |||

6.4.4. Definition | 6.4.4. Definition | |||

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

..., Hn>, and the matrix of Type-P-Spatial-One-way-Delay-Vector for | ..., 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> : | 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)> where: | dTm.ab - min(dTi.ab)> where: | |||

o 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); | |||

o 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) is | dTk.b is undefined, or the real number (dTk.b - dTk.a) is | |||

undefined. | undefined. | |||

6.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 have less sensitivity to inter-packet | (PDV). PDV distributions have less sensitivity to inter-packet | |||

interval variations than IPDV values, as discussed above. | interval variations than IPDV values, as discussed above. | |||

skipping to change at page 24, line 49 | skipping to change at page 27, line 5 | |||

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, because a wide range of spacings are reflected in any PDV | Hb, because a wide range of spacings are reflected in any PDV | |||

distribution. | distribution. | |||

7. One-to-group metrics definitions | RFC 5644 Spatial and Multicast Metrics October 2009 | |||

7. One-to-Group Metrics Definitions | ||||

This section defines performance metrics between a source and a group | This section defines performance metrics between a source and a group | |||

of receivers. | of receivers. | |||

7.1. A Definition for One-to-group Delay | 7.1. A Definition for One-to-Group Delay | |||

This section defines a metric for one-way delay between a source and | This section defines a metric for one-way delay between a source and | |||

a group of receivers. | a group of receivers. | |||

7.1.1. Metric Name | 7.1.1. Metric Name | |||

Type-P-One-to-group-Delay-Vector | Type-P-One-to-group-Delay-Vector | |||

7.1.2. Metric Parameters | 7.1.2. Metric Parameters | |||

skipping to change at page 25, line 18 | skipping to change at page 27, line 24 | |||

This section defines a metric for one-way delay between a source and | This section defines a metric for one-way delay between a source and | |||

a group of receivers. | a group of receivers. | |||

7.1.1. Metric Name | 7.1.1. Metric Name | |||

Type-P-One-to-group-Delay-Vector | Type-P-One-to-group-Delay-Vector | |||

7.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 times. | o dT1,...,dTn a list of times. | |||

o Type-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 for this 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. | |||

7.1.3. Metric Units | 7.1.3. Metric Units | |||

The value of a Type-P-One-to-group-Delay-Vector is a set of Type-P- | The value of a Type-P-One-to-group-Delay-Vector is a set of Type-P- | |||

One-way-Delay singletons [RFC2679], which is a sequence of times (a | One-way-Delay singletons [RFC2679], that is a sequence of times (a | |||

real number in the dimension of seconds with sufficient resolution to | real number in the dimension of seconds with sufficient resolution to | |||

convey the results). | convey the results). | |||

7.1.4. Definition | 7.1.4. Definition | |||

Given a Type-P packet sent by the source Src at time T, and 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 }, or the packet does not pass a receiver within a | T+dT1,...,T+dTn }, or the packet does not pass a receiver within a | |||

specified loss threshold time, then the Type-P-One-to-group-Delay- | specified loss threshold time, then the Type-P-One-to-group-Delay- | |||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

Vector is defined as the set of the Type-P-One-way-Delay singletons | 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 }, | between Src and each receiver with value of { dT1, dT2,...,dTn }, | |||

where any of the singletons may be undefined if the packet did not | where any of the singletons may be undefined if the packet did not | |||

pass the corresponding receiver within a specified loss threshold | pass the corresponding receiver within a specified loss threshold | |||

time. | time. | |||

7.2. A Definition for One-to-group Packet Loss | 7.2. A Definition for One-to-Group Packet Loss | |||

7.2.1. Metric Name | 7.2.1. Metric Name | |||

Type-P-One-to-group-Packet-Loss-Vector | Type-P-One-to-group-Packet-Loss-Vector | |||

7.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 Type-P, the specification of the packet type. | o Type-P, the specification of the packet type. | |||

o Gr, the receiving group identifier, OPTIONAL. | o Gr, the receiving group identifier, OPTIONAL. | |||

7.2.3. Metric Units | 7.2.3. Metric Units | |||

The value of a Type-P-One-to-group-Packet-Loss-Vector is a set of | The value of a Type-P-One-to-group-Packet-Loss-Vector is a set of | |||

Type-P-One-way-Packet-Loss singletons [RFC2680]. | Type-P-One-way-Packet-Loss singletons [RFC2680]. | |||

o T, time the source packet was sent | o T, time the source packet was sent. | |||

o L1,...,LN a list of boolean values | ||||

o L1,...,LN a list of Boolean values. | ||||

7.2.4. Definition | 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, the Type-P-One-to-group-Packet-Loss-Vector is | Recv1,...,RecvN, the Type-P-One-to-group-Packet-Loss-Vector is | |||

defined as a set of the Type-P-One-way-Packet-Loss singletons between | defined as a set of the Type-P-One-way-Packet-Loss singletons between | |||

Src and each of the receivers | Src and each of the receivers: | |||

{T, <L1=0|1>,<L2=0|1>,..., <LN=0|1>}, | {T, <L1=0|1>,<L2=0|1>,..., <LN=0|1>}, | |||

where the boolean value 0|1 depends on receiving the packet at a | where the Boolean value 0|1 depends on receiving the packet at a | |||

particular receiver within a loss threshold time. | particular receiver within a loss threshold time. | |||

7.3. A Definition for One-to-group ipdv | RFC 5644 Spatial and Multicast Metrics October 2009 | |||

7.3. A Definition for One-to-Group ipdv | ||||

7.3.1. Metric Name | 7.3.1. Metric Name | |||

Type-P-One-to-group-ipdv-Vector | Type-P-One-to-group-ipdv-Vector | |||

7.3.2. Metric Parameters | 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 times. | o ddT1, ...,ddTn, a list of times. | |||

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

o F, a selection function non-ambiguously defining the two packets | 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. | |||

7.3.3. Metric Units | 7.3.3. Metric Units | |||

The value of a Type-P-One-to-group-ipdv-Vector is a set of Type-P- | The value of a Type-P-One-to-group-ipdv-Vector is a set of Type-P- | |||

One-way-ipdv singletons [RFC3393]. | One-way-ipdv singletons [RFC3393]. | |||

7.3.4. Definition | 7.3.4. Definition | |||

Given a Type-P packet stream, Type-P-One-to-group-ipdv-Vector is | Given a Type-P packet stream, Type-P-One-to-group-ipdv-Vector is | |||

defined for two packets transferred from the source Src to the N | defined for two packets transferred from the source Src to the N | |||

hosts {Recv1,...,RecvN }, which are selected by the selection | hosts {Recv1,...,RecvN }, which are selected by the selection | |||

function F as the difference between the value of the Type-P-One-to- | function F as the difference between the value of the Type-P-One-to- | |||

group-Delay-Vector from Src to { Recv1,..., RecvN } at time T1 and | group-Delay-Vector from Src to { Recv1,..., RecvN } at time T1 and | |||

the value of the Type-P-One-to-group-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 | |||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

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-Delay-Vector metric. | from the Type-P-One-to-group-Delay-Vector metric. | |||

For a set of real numbers {ddT1,...,ddTn}, the Type-P-One-to-group- | For a set of real numbers {ddT1,...,ddTn}, the Type-P-One-to-group- | |||

ipdv-Vector from Src to { Recv1,...,RecvN } at T1, T2 is | ipdv-Vector from Src to { Recv1,...,RecvN } at T1, T2 is | |||

{ddT1,...,ddTn} means that Src sent two packets, the first at wire- | {ddT1,...,ddTn} means that Src sent two packets, the first at wire- | |||

time T1 (first bit), and the second at wire-time T2 (first bit) and | time T1 (first bit), and the second at wire-time T2 (first bit) and | |||

the packets were received by { Recv1,...,RecvN } at wire-time {dT1+ | the packets were received by { Recv1,...,RecvN } at wire-time {dT1+ | |||

T1,...,dTn+T1}(last bit of the first packet), and at wire-time {dT'1+ | T1,...,dTn+T1}(last bit of the first packet), and at wire-time {dT'1+ | |||

skipping to change at page 27, line 48 | skipping to change at page 30, line 22 | |||

ipdv-Vector from Src to { Recv1,...,RecvN } at T1, T2 is | ipdv-Vector from Src to { Recv1,...,RecvN } at T1, T2 is | |||

{ddT1,...,ddTn} means that Src sent two packets, the first at wire- | {ddT1,...,ddTn} means that Src sent two packets, the first at wire- | |||

time T1 (first bit), and the second at wire-time T2 (first bit) and | time T1 (first bit), and the second at wire-time T2 (first bit) and | |||

the packets were received by { Recv1,...,RecvN } at wire-time {dT1+ | the packets were received by { Recv1,...,RecvN } at wire-time {dT1+ | |||

T1,...,dTn+T1}(last bit of the first packet), and at wire-time {dT'1+ | T1,...,dTn+T1}(last bit of the first packet), and at wire-time {dT'1+ | |||

T2,...,dT'n+T2} (last bit of the second packet), and that {dT'1- | T2,...,dT'n+T2} (last bit of the second packet), and that {dT'1- | |||

dT1,...,dT'n-dTn} ={ddT1,...,ddTn}. | dT1,...,dT'n-dTn} ={ddT1,...,ddTn}. | |||

For any pair of selected packets, the difference dT'n-dTn is | For any pair of selected packets, the difference dT'n-dTn is | |||

undefined if: | undefined if: | |||

o the delay dTn to Receiver n is undefined, OR | o the delay dTn to Receiver n is undefined, OR | |||

o the delay dT'n to Receiver n is undefined. | o the delay dT'n to Receiver n is undefined. | |||

8. One-to-group Sample Statistics | 8. One-to-Group Sample Statistics | |||

The one-to-group metrics defined above are directly achieved by | The one-to-group metrics defined above are directly achieved by | |||

collecting relevant unicast one-way metrics measurements results and | collecting relevant unicast one-way metrics measurements results and | |||

by gathering them per group of receivers. They produce network | by gathering them per group of receivers. They produce network | |||

performance information which guides engineers toward potential | performance information that guides engineers toward potential | |||

problems which may have happened on any branch of a multicast routing | problems that may have happened on any branch of a multicast routing | |||

tree. | tree. | |||

The results of these metrics are not directly usable to present the | 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 | performance of a group because each result is made of a huge number | |||

of singletons which are difficult to read and analyze. As an | of singletons that are difficult to read and analyze. As an example, | |||

example, delays are not comparable because the distance between | delays are not comparable because the distance between receiver and | |||

receiver and sender differs. Furthermore they don't capture relative | sender differs. Furthermore, they don't capture relative performance | |||

performance situation a multiparty communication. | situations in 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 support of absolute performance | services not only require the support of absolute performance | |||

information but also information on "relative performance". The | information but also information on "relative performance". | |||

relative performance means the difference between absolute | "Relative performance" means the difference between absolute | |||

performance of all users. Directly using the one-way metrics cannot | performance of all users. Directly using the one-way metrics cannot | |||

present the relative performance situation. However, if we use the | present the relative performance situation. However, if we use the | |||

variations of all users one-way parameters, we can have new metrics | variations of all users' one-way parameters, we can have new metrics | |||

to measure the difference of the absolute performance and hence | to measure the difference of the absolute performance and hence | |||

provide the threshold value of relative performance that a multiparty | provide the threshold value of relative performance that a multiparty | |||

service might demand. A very good example of the high relative | service might demand. A very good example of the high relative | |||

performance requirement is online gaming. A very small difference in | performance requirement is online gaming. A very small difference in | |||

delay might result in failure in the game. We have to use multicast | delay might result in failure in the game. We have to use multicast- | |||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

specific statistic metrics to define the relative delay required by | specific statistic metrics to define the relative delay required by | |||

online gaming. There are many other services, e.g. online biding, | online gaming. There are many other services, e.g., online biding, | |||

online stock market, etc., that require multicast metrics in order to | online stock market, etc., that require multicast metrics in order to | |||

evaluate the network against their requirements. Therefore, we can | evaluate the network against their requirements. Therefore, we can | |||

see the importance of new, multicast specific, statistic metrics to | see the importance of new, multicast specific, statistic metrics to | |||

feed this need. | 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 | |||

later one can have statistics over both time and space dimensions. | later one can have statistics over both time and space dimensions. | |||

This space dimension is introduced by the Matrix concept as | This space dimension is introduced by the Matrix concept as | |||

illustrated in Figure 4. For a Matrix M each row is a set of One-way | illustrated in Figure 4. For a Matrix M, each row is a set of one- | |||

singletons spreading over the time dimension and each column is | way singletons spreading over the time dimension and each column is | |||

another set of One-way singletons spreading over the space dimension. | another set of One-way singletons spreading over the space dimension. | |||

Receivers | Receivers | |||

Space | Space | |||

^ | ^ | |||

1 | / R1dT1 R1dT2 R1dT3 ... R1dTk \ | 1 | / R1dT1 R1dT2 R1dT3 ... R1dTk \ | |||

| | | | | | | | |||

2 | | R2dT1 R2dT2 R2dT3 ... R2dTk | | 2 | | R2dT1 R2dT2 R2dT3 ... R2dTk | | |||

| | | | | | | | |||

3 | | R3dT1 R3dT2 R3dT3 ... R3dTk | | 3 | | R3dT1 R3dT2 R3dT3 ... R3dTk | | |||

. | | | | . | | | | |||

. | | | | . | | | | |||

. | | | | . | | | | |||

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

+--------------------------------------------> time | +--------------------------------------------> time | |||

T0 | T0 | |||

Figure 4: Matrix M (n*m) | Figure 4: Matrix M (n*m) | |||

In Matrix M, each element is a one-way delay singleton. Each column | In Matrix M, each element is a one-way delay singleton. Each column | |||

is a delay vector. It contains the One-way delays of the same packet | is a delay vector. It contains the one-way delays of the same packet | |||

observed at n points of interest. It implies the geographical factor | observed at n points of interest. It implies the geographical factor | |||

of the performance within a group. Each row is a set of One-way | of the performance within a group. Each row is a set of one-way | |||

delays observed during a sampling interval at one of the points of | delays observed during a sampling interval at one of the points of | |||

interest. It presents the delay performance at a receiver over the | interest. It presents the delay performance at a receiver over the | |||

time dimension. | time dimension. | |||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

Therefore, one can either calculate statistics by rows over the space | Therefore, one can either calculate statistics by rows over the space | |||

dimension or by columns over the time dimension. It's up to the | dimension or by columns over the time dimension. It's up to the | |||

operators or service provides which dimension they are interested in. | operators or service providers in which dimension they are | |||

For example, a TV broadcast service provider might want to know the | interested. For example, a TV broadcast service provider might want | |||

statistical performance of each user in a long term run to make sure | to know the statistical performance of each user in a long-term run | |||

their services are acceptable and stable. While for an online gaming | to make sure their services are acceptable and stable. While for an | |||

service provider, he might be more interested to know if all users | online gaming service provider, he might be more interested in | |||

are served fairly by calculating the statistics over the space | knowing if all users are served fairly by calculating the statistics | |||

dimension. This memo does not intend to recommend which of the | over the space dimension. This memo does not intend to recommend | |||

statistics are better than the other. | which of the statistics are better than the others. | |||

To save the report transmission bandwidth, each point of interest can | To save the report transmission bandwidth, each point of interest can | |||

send statistics in a pre-defined time interval to the reference point | send statistics in a pre-defined time interval to the reference point | |||

rather than sending every one-way singleton it observed. As long as | rather than sending every one-way singleton it observed. As long as | |||

an appropriate time interval is decided, appropriate statistics can | an appropriate time interval is decided, appropriate statistics can | |||

represent the performance in a certain accurate scale. How to decide | represent the performance in a certain accurate scale. How to decide | |||

the time interval and how to bootstrap all points of interest and the | the time interval and how to bootstrap all points of interest and the | |||

reference point depend on applications. For instance, applications | reference point depend on applications. For instance, applications | |||

with lower transmission rate can have the time interval longer and | with a lower transmission rate can have the time interval be longer, | |||

ones with higher transmission rate can have the time interval | and ones with higher transmission rate can have the time interval be | |||

shorter. However, this is out of the scope of this memo. | shorter. However, this is out of the scope of this memo. | |||

Moreover, after knowing the statistics over the time dimension, one | Moreover, after knowing the statistics over the time dimension, one | |||

might want to know how these statistics are distributed over the | might want to know how these statistics are distributed over the | |||

space dimension. For instance, a TV broadcast service provider had | space dimension. For instance, a TV broadcast service provider had | |||

the performance Matrix M and calculated the One-way delay mean over | the performance Matrix M and calculated the one-way delay mean over | |||

the time dimension to obtain a delay Vector as {V1,V2,..., VN}. He | the time dimension to obtain a delay Vector as {V1,V2,..., VN}. He | |||

then calculated the mean of all the elements in the Vector to see | then calculated the mean of all the elements in the Vector to see | |||

what level of delay he has served to all N users. This new delay | what level of delay he has served to all N users. This new delay | |||

mean gives information on how good the service has been delivered to | mean gives information on how well the service has been delivered to | |||

a group of users during a sampling interval in terms of delay. It | a group of users during a sampling interval in terms of delay. It | |||

requires twice as much calculation to have this statistic over both | requires twice as much calculation to have this statistic over both | |||

time and space dimensions. These kinds of statistics are referred to | time and space dimensions. These kinds of statistics are referred to | |||

as 2-level statistics to distinguish them from 1-level statistics | as 2-level statistics to distinguish them from 1-level statistics | |||

calculated over either space or time dimension. It can be easily | calculated over either space or time dimension. It can be easily | |||

proven that no matter over which dimension a 2-level statistic is | proven that no matter over which dimension a 2-level statistic is | |||

calculated first, the results are the same. I.e. one can calculate | calculated first, the results are the same. That is, one can | |||

the 2-level delay mean using the Matrix M by having the 1-level delay | calculate the 2-level delay mean using the Matrix M by having the | |||

mean over the time dimension first and then calculate the mean of the | 1-level delay mean over the time dimension first and then calculate | |||

obtained vector to find out the 2-level delay mean. Or, he can do | the mean of the obtained vector to find out the 2-level delay mean. | |||

the 1-level statistic calculation over the space dimension first and | Or, he can do the 1-level statistic calculation over the space | |||

then have the 2-level delay mean. Both two results will be exactly | dimension first and then have the 2-level delay mean. Both results | |||

the same. Therefore, when defining a 2-level statistic there is no | will be exactly the same. Therefore, when defining a 2-level | |||

need to specify the order in which the calculation is executed. | statistic, there is no need to specify the order in which the | |||

calculation is executed. | ||||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

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 the space dimension, the time dimension, or both. This memo | |||

memo treats the case where a stream of packets from the Source | treats the case where a stream of packets from the Source results in | |||

results in a sample at each of the Receivers in the Group, and these | a sample at each of the Receivers in the Group, and these samples are | |||

samples are each summarized with the usual statistics employed in | each summarized with the usual statistics employed in one-to-one | |||

one-to-one communication. New statistic definitions are presented, | communication. New statistic definitions are presented, which | |||

which summarize the one-to-one statistics over all the Receivers in | summarize the one-to-one statistics over all the Receivers in the | |||

the Group. | Group. | |||

8.1. Discussion on the Impact of packet loss on statistics | 8.1. Discussion on the Impact of Packet Loss on Statistics | |||

Packet loss does have effects on one-way metrics and their | Packet loss does have effects on one-way metrics and their | |||

statistics. For example, a lost packet can result in an infinite | statistics. For example, a lost packet can result in an infinite | |||

one-way delay. It is easy to handle the problem by simply ignoring | one-way delay. It is easy to handle the problem by simply ignoring | |||

the 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 such a strong | corresponding statistics. However, the packet loss has such a 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 complexity of building a matrix, which | metrics. This is due to the complexity of building a matrix, which | |||

is 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 to be 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 a | |||

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

point will not be able to use these two results to build up the group | point will not be able to use these two results to build up the group | |||

Matrix and can not calculate the statistics. The extreme situation | Matrix and cannot calculate the statistics. The extreme situation | |||

being the case when no packets arrive at any user. One of the | being the case when no packets arrive at any user. One of the | |||

possible solutions is to replace the infinite/undefined delay value | possible solutions is to replace the infinite/undefined delay value | |||

by the average of the two adjacent values. For example, if the | by the average of the two adjacent values. For example, if the | |||

result reported by user1 is { R1dT1 R1dT2 R1dT3 ... R1dTK-1 UNDEF | result reported by User1 is { R1dT1 R1dT2 R1dT3 ... R1dTK-1 UNDEF | |||

R1dTK+1... R1DM } where "UNDEF" is an undefined value, the reference | R1dTK+1... R1MD } where "UNDEF" is an undefined value, the reference | |||

point can replace it by R1dTK = {(R1dTK-1)+( R1dTK+1)}/2. Therefore, | point can replace it by R1dTK = {(R1dTK-1)+( R1dTK+1)}/2. Therefore, | |||

this result can be used to build up the group Matrix with an | this result can be used to build up the group Matrix with an | |||

estimated value R1dTK. There are other possible solutions such as | estimated value R1dTK. There are other possible solutions, such as | |||

using the overall mean of the whole result to replace the infinite/ | using the overall mean of the whole result to replace the infinite/ | |||

undefined value, and so on. However this is out of the scope of this | undefined value, and so on. However, this is out of the scope of | |||

memo. | this memo. | |||

For the distributed calculation, the reported statistics might have | For the distributed calculation, the reported statistics might have | |||

different "weight" to present the group performance, which is | different "weight" to present the group performance, which is | |||

especially true for delay and ipdv relevant metrics. For example, | especially true for delay and ipdv relevant metrics. For example, | |||

User1 calculates the Type-P-Finite-One-way-Delay-Mean R1DM as shown | ||||

in Figure. 8 without any packet loss and User2 calculates the R2DM | RFC 5644 Spatial and Multicast Metrics October 2009 | |||

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 | User1 calculates the Type-P-Finite-One-way-Delay-Mean R1MD as shown | |||

in the whole sample interval. One possible solution is to use a | in Figure 7 without any packet loss, and User2 calculates the R2MD | |||

weight factor to mark every statistic value sent by users and use | with N-2 packet loss. The R1MD and R2MD should not be treated with | |||

equal weight because R2MD was calculated only based on two delay | ||||

values in the whole sample interval. One possible solution is to use | ||||

a weight factor to mark every statistic value sent by users and use | ||||

this factor for further statistic calculation. | this factor for further statistic calculation. | |||

8.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 N, the number of Receivers (Recv1, Recv2, ... RecvN); | o G, the receiving group identifier. | |||

o T, a time (start of test interval); | ||||

o Tf, a time (end of test interval); | o N, the number of Receivers (Recv1, Recv2, ... RecvN). | |||

o T, a time (start of test interval). | ||||

o Tf, a time (end of test interval). | ||||

o K, the number of packets sent from the source during the test | o K, the number of packets sent from the source during the test | |||

interval; | interval. | |||

o J[n], the number of packets received at a particular Receiver, n, | o J[n], the number of packets received at a particular Receiver, n, | |||

where 1<=n<=N; | where 1<=n<=N. | |||

o lambda, a rate in reciprocal seconds (for Poisson Streams); | ||||

o lambda, a rate in reciprocal seconds (for Poisson Streams). | ||||

o incT, the nominal duration of inter-packet interval, first bit to | o incT, the nominal duration of inter-packet interval, first bit to | |||

first bit (for Periodic Streams); | first bit (for Periodic Streams). | |||

o T0, a time that MUST be selected at random from the interval [T, | o T0, a time that MUST be selected at random from the interval [T, | |||

T+I] to start generating packets and taking measurements (for | T+I] to start generating packets and taking measurements (for | |||

Periodic Streams); | Periodic Streams). | |||

o TstampSrc, the wire time of the packet as measured at MP(Src) (the | ||||

Source Measurement Point); | o TstampSrc, the wire-time of the packet as measured at MP(Src) (the | |||

o TstampRecv, the wire time of the packet as measured at MP(Recv), | Source Measurement Point). | |||

assigned to packets that arrive within a "reasonable" time; | ||||

o TstampRecv, the wire-time of the packet as measured at MP(Recv), | ||||

assigned to packets that arrive within a "reasonable" time. | ||||

o Tmax, a maximum waiting time for packets at the destination, set | o Tmax, a maximum waiting time for packets at the destination, set | |||

sufficiently long to disambiguate packets with long delays from | sufficiently long to disambiguate packets with long delays from | |||

packets that are discarded (lost), thus the distribution of delay | packets that are discarded (lost); thus, the distribution of delay | |||

is not truncated; | is not truncated. | |||

o dT, shorthand notation for a one-way delay singleton value; | ||||

o dT, shorthand notation for a one-way delay singleton value. | ||||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

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

8.3. One-to-group 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 R1MD \ | 1 R1dT1 R1dT2 R1dT3 ... R1dTk R1MD \ | |||

| | | | |||

2 R2dT1 R2dT2 R2dT3 ... R2dTk R2MD | | 2 R2dT1 R2dT2 R2dT3 ... R2dTk R2MD | | |||

| | | | |||

3 R3dT1 R3dT2 R3dT3 ... R3dTk R3MD > Group delay | 3 R3dT1 R3dT2 R3dT3 ... R3dTk R3MD > Group Delay | |||

. | | . | | |||

. | | . | | |||

. | | . | | |||

n RndT1 RndT2 RndT3 ... RndTk RnMD / | 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 three significant digits. | |||

8.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 RnMD. | Delay Mean, at each Receiver N, also named RnMD. | |||

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

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

J[n] | J[n] | |||

--- | --- | |||

1 \ | 1 \ | |||

RnMD = --- * > TstampRecv[i] - TstampSrc[i] | RnMD = --- * > TstampRecv[i] - TstampSrc[i] | |||

J[n] / | J[n] / | |||

--- | --- | |||

i = 1 | i = 1 | |||

Note: RnMD value is Undefined when J[n] = 0 for all n. | Note: RnMD value is Undefined when J[n] = 0 for all n. | |||

Figure 6: Type-P-One-to-group-Receiver-N-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. | |||

8.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 = - * > RnMD | GMD = - * > RnMD | |||

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

8.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 (R1MD, R2MD...RnMD). | receivers in the Group (R1MD, R2MD...RnMD). | |||

Type-P-One-to-group-Range-Mean-Delay = GRMD = max(RnMD) - min(RnMD) | Type-P-One-to-group-Range-Mean-Delay = GRMD = max(RnMD) - min(RnMD) | |||

8.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 (R1MD, R2MD,...RnMD). | N receivers in the Group (R1MD, R2MD,...RnMD). | |||

Type-P-One-to-group-Max-Mean-Delay = GMMD = max(RnMD) | Type-P-One-to-group-Max-Mean-Delay = GMMD = max(RnMD) | |||

8.4. One-to-group Packet Loss Statistics | RFC 5644 Spatial and Multicast Metrics October 2009 | |||

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

8.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 | |||

skipping to change at page 35, line 17 | skipping to change at page 38, line 5 | |||

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

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

8.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. The numerator | receiver for the sample and test interval of interest. The numerator | |||

is the sum of the losses at receiver n. | is the sum of the losses at receiver n. | |||

The Comparative Loss Ratio, also named, RnCLR, is defined as | The Comparative Loss Ratio, also named, RnCLR, is defined as | |||

skipping to change at page 36, line 7 | skipping to change at page 38, line 40 | |||

| --- | | | --- | | |||

\ k=1 / N | \ k=1 / N | |||

Note: Ln is a set of one-way loss values at receiver n. | Note: Ln is a set of one-way loss values at receiver n. | |||

There is one value for each of the K packets sent. | There is one value for each of the K packets sent. | |||

Figure 10: Type-P-One-to-group-Receiver-n-Comp-Loss-Ratio | Figure 10: Type-P-One-to-group-Receiver-n-Comp-Loss-Ratio | |||

8.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 = --- * > Ln(k) | GLR = --- * > Ln(k) | |||

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

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

Where the sum includes all of the Loss singletons, Ln(k), over the N | Where the sum includes all of the Loss singletons, Ln(k), over the N | |||

receivers and K packets sent, in a ratio with the total packets over | receivers and K packets sent, in a ratio with the total packets over | |||

all receivers. | all receivers. | |||

8.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 maximum | |||

minimum loss ratios for the Group, rather than only reporting the | and minimum loss ratios for the Group, rather than only reporting the | |||

difference between them. | difference between them. | |||

8.5. One-to-group 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 \ | |||

skipping to change at page 37, line 5 | skipping to change at page 39, line 40 | |||

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

Variation singletons of the group delay variation matrix above where | singletons of the group delay variation matrix above where RnddTk is | |||

RnddTk is the Type-P-One-way-Delay-Variation singleton evaluated at | the Type-P-One-way-ipdv singleton evaluated at Receiver n for the | |||

Receiver n for the packet k and where RnDV is the point-to-point one- | packet k and where RnDV is the point-to-point one-way packet delay | |||

way packet delay variation for Receiver n. | 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 three significant digits. | |||

8.5.1. Type-P-One-to-group-Range-Delay-Variation | 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 Delay Variation over | |||

all N receivers in the Group. | all N receivers in the Group. | |||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

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-Range-Delay-Variation = GRDV = | 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. | |||

9. 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 | |||

skipping to change at page 38, line 17 | skipping to change at page 41, line 4 | |||

as the reference point. However, both the storage and transfer | as the reference point. However, both the storage and transfer | |||

capacity can be reduced if the points of interest are capable of | capacity can be reduced if the points of interest are capable of | |||

computing the summary statistics that describe each measurement | computing the summary statistics that describe each measurement | |||

interval. This is consistent with many operational monitoring | interval. This is consistent with many operational monitoring | |||

architectures today, where even the individual singletons may not be | architectures today, where even the individual singletons may not be | |||

stored at each point of interest. | stored at each point of interest. | |||

In recognition of the likely need to minimize the form of the results | In recognition of the likely need to minimize the form of the results | |||

for storage and communication, the Group metrics above have been | for 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 | |||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

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). | |||

9.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 is a | |||

centralized statistic calculation method and the latter one is a | centralized statistic calculation method and the latter 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 | |||

bandwidth than the transmission of the statistics that should include | bandwidth than the transmission of the statistics that should include | |||

all statistic parameters specified by policies and the additional | all statistic parameters specified by policies and the additional | |||

information about the whole sample, such as the size of the sample, | information about the whole sample, such as the size of the sample, | |||

the group address, the address of the point of interest, the ID of | the group address, the address of the point of interest, the ID of | |||

the sample session, and so on. Apparently, the centralized | the sample session, and so on. Apparently, the centralized | |||

calculation method can require much more bandwidth than the | calculation method can require much more bandwidth than the | |||

distributed calculation method when the sample size is big. This is | distributed calculation method when the sample size is big. This is | |||

especially true when the measurement has a very large number of the | especially true when the measurement has a very large number of the | |||

points of interest. It can lead to a scalability issue at the | points of interest. It can lead to a scalability issue at the | |||

skipping to change at page 39, line 17 | skipping to change at page 42, line 5 | |||

to the reference point first to obtain the general information of the | to the reference point first to obtain the general information of the | |||

group performance. If detailed results are required, the reference | group performance. If detailed 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. | |||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

9.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 more packets will to be | measure must take into consideration that more packets will be routed | |||

routed than sent (copies of a packet sent are expected to arrive at | than sent (copies of a packet sent are expected to arrive at many | |||

many destination points) and selects a test packets rate that will | destination points) and select a test packet rate that will not | |||

not impact the network performance. | impact the network performance. | |||

9.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 not co-located and that results are | hypothesis that receivers are not co-located and that results are | |||

gathered in a point of reference for further usages. | gathered in a point of reference for further usages. | |||

Multimetrics samples are represented in a matrix as illustrated below | Multimetric 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 | |||

. | | . | | |||

. | | . | | |||

. | | . | | |||

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 | Stats over Space and Time | |||

Figure 13: Impact of space aggregation on multimetrics Stat | Figure 13: Impact of Space Aggregation on Multimetrics Stats | |||

Two methods are available to compute statistics on a matrix: | Two methods are available to compute statistics on a matrix: | |||

o Method 1: The statistic metric is computed over time and then over | o Method 1: The statistic metric is computed over time and then over | |||

space; | space; or | |||

o Method 2: The statistic metric is computed over space and then | o Method 2: The statistic metric is computed over space and then | |||

over time. | over time. | |||

These 2 methods differ only by the order of the aggregation. The | RFC 5644 Spatial and Multicast Metrics October 2009 | |||

These two methods differ only by the order of the aggregation. The | ||||

order does not impact the computation resources required. It does | order does not impact the computation resources required. It does | |||

not change the value of the result. However, it impacts severely the | not change the value of the result. However, it impacts severely the | |||

minimal volume of data to report: | minimal volume of data to report: | |||

o Method 1: Each point of interest computes periodically statistics | ||||

o Method 1: Each point of interest periodically computes statistics | ||||

over time to lower the volume of data to report. They are | over time to lower the volume of data to report. They are | |||

reported to the reference point for for subsequent computations | reported to the reference point for subsequent computations over | |||

over the spatial dimension. This volume no longer depends on the | the spatial dimension. This volume no longer depends on the | |||

number of samples. It is only proportional to the computation | number of samples. It is only proportional to the computation | |||

period; | period. | |||

o Method 2: The volume of data to report is proportional to the | o Method 2: The volume of data to report is proportional to the | |||

number of samples. Each sample, RiSi, must be reported to the | number of samples. Each sample, RiSi, must be reported to the | |||

reference point for computing statistic over space and statistic | reference point for computing statistic over space and statistic | |||

over time. The volume increases with the number of samples. It | over time. The volume increases with the number of samples. It | |||

is proportional to the number of test packets; | is proportional to the number of test packets; | |||

Method 2 has severe drawbacks in terms of security and dimensioning: | Method 2 has severe drawbacks in terms of security and dimensioning: | |||

o Increasing the rate of the test packets may result in a Denial of | o Increasing the rate of the test packets may result in a Denial of | |||

Service toward the points of reference; | Service (DoS) toward the points of reference; | |||

o The dimensioning of a measurement system is quite impossible to | o The dimensioning of a measurement system is quite impossible to | |||

validate because any increase of the rate of the test packets will | validate because any increase of the rate of the test packets will | |||

increase the bandwidth requested to collect the raw results. | increase the bandwidth requested to collect the raw results. | |||

The computation period over time period (commonly named aggregation | The computation period over time period (commonly named the | |||

period) provides the reporting side with a control of various | aggregation period) provides the reporting side with a control of | |||

collecting aspects such as bandwidth, computation and storage | various collecting aspects such as bandwidth, computation, and | |||

capacities. So this draft defines metrics based on method 1. | storage capacities. So this document defines metrics based on method | |||

1. | ||||

9.3.1. Impact on spatial statistics | 9.3.1. Impact on Spatial Statistics | |||

Two methods are available to compute spatial statistics: | Two 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 for each points of interest; | computed over time for 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 Method 2 whenever | |||

instantaneous metrics information is needed. | instantaneous metrics information is needed. | |||

9.3.2. Impact on one-to-group statistics | RFC 5644 Spatial and Multicast Metrics October 2009 | |||

9.3.2. Impact on One-to-Group Statistics | ||||

Two methods are available to compute group statistics: | Two methods are available to compute group statistics: | |||

o Method1: Figure 5 and Figure 8 illustrate the method chosen: the | ||||

one-to-one statistic is computed per interval of time before the | o Method 1: Figure 5 and Figure 8 illustrate the method. The one- | |||

computation of the mean over the group of receivers; | to-one statistic is computed per interval of time before the | |||

o Method2: Figure 13 presents the second one, metric is computed | computation of the mean over the group of receivers. | |||

over space and then over time. | ||||

o Method 2: Figure 13 presents the second method. The metric is | ||||

computed over space and then over time. | ||||

10. Manageability Considerations | 10. Manageability Considerations | |||

This section defines the reporting of all the metrics introduced in | This section defines the reporting of all the metrics introduced in | |||

the document. | the document. | |||

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 except 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. | interest. | |||

10.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 RFC | |||

RFC2679-80. New ones are common to all the definitions and are | 2679 and RFC 2680. New ones are common to all the definitions and | |||

mostly related to the reporting of the path and of methodology | are 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 SHOULD be reported. | that SHOULD be reported. | |||

10.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 | the fact that IPPM RFCs recommend it be reported (see section 3.8.4 | |||

[RFC2679]). Spatial metrics vectors provide this path. The report | of [RFC2679]). Spatial metrics vectors provide this path. The | |||

of a spatial vector MUST include the points of interests involved: | report of a spatial vector MUST include the points of interests | |||

the sub set of the routers of the path participating to the | involved: the sub-set of the routers of the path participating to the | |||

instantaneous measure. | instantaneous measure. | |||

10.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. The ordering MAY be based on information from the | order in the path. The ordering MAY be based on information from the | |||

TTL in IPv4, the Hop Limit in IPv6 or the corresponding information | TTL in IPv4, the Hop Limit in IPv6, or the corresponding information | |||

in MPLS. | in MPLS. | |||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

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

10.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 three milliseconds; | |||

the minimal uncertainty reported be 3 ms if the internal delay is | then the minimal uncertainty reported be 3 ms if the internal delay | |||

unknown at the time of the timestamping. | is 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. | |||

10.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 | |||

Section 3.6 of [RFC2679]. The same apply for packet loss and ipdv. | section 3.6 of [RFC2679]. The same applies for packet loss and ipdv. | |||

10.2. Reporting One-to-group metric | 10.2. Reporting One-to-Group Metric | |||

All reporting rules described in [RFC2679] and [RFC2680] 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. The following are specific | |||

parameters that SHOULD be reported. | parameters that SHOULD be reported. | |||

10.2.1. Path | 10.2.1. Path | |||

As suggested by the [RFC2679] and [RFC2680], the path traversed by | As suggested by [RFC2679] and [RFC2680], the path traversed by the | |||

the packet SHOULD be reported, if possible. For One-to-group | packet SHOULD be reported, if possible. For One-to-group metrics, | |||

metrics, the path tree between the source and the destinations or the | the path tree between the source and the destinations or the set of | |||

set of paths between the source and each destination SHOULD be | paths between the source and each destination SHOULD be reported. | |||

reported. | ||||

Path tree might not be as valuable as individual paths because an | The path tree might not be as valuable as individual paths because an | |||

incomplete path might be difficult to identify in the path tree. For | incomplete path might be difficult to identify in the path tree. For | |||

example, how many points of interest are reached by a packet | example, how many points of interest are reached by a packet | |||

travelling along an incomplete path? | traveling along an incomplete path? | |||

10.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. One-to-group metrics, unlike spatial metrics, don't | parameters. One-to-group metrics, unlike spatial metrics, don't | |||

require the ordering of the points of interests because group members | require the ordering of the points of interests because group members | |||

receive the packets in parallel. | receive the packets in parallel. | |||

10.2.3. Timestamping bias | 10.2.3. Timestamping Bias | |||

It is the same as described in section 10.1.3. | It is the same as described in section 10.1.3. | |||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

10.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 10.1.4. | It is the same as described in section 10.1.4. | |||

10.2.5. Measurement method | 10.2.5. Measurement Method | |||

As explained in section 9, 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. | |||

10.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 a unique identifier | |||

identifier as per [RFC4148] in the IANA-IPPM-METRICS-REGISTRY-MIB. | as per [RFC4148] in the IANA-IPPM-METRICS-REGISTRY-MIB. | |||

10.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 built with pieces of information introduced | The information model is built with pieces of information introduced | |||

and explained in one-way delay definitions [RFC2679], in packet loss | and explained in the sections of [RFC2679] , [RFC2680] , [RFC3393], | |||

definitions [RFC2680] and in IPDV definitions of [RFC3393] and | and [RFC3432] that define the IPPM metrics and from any of the | |||

[RFC3432]. It includes not only information given by "Reporting the | sections named "Reporting the metric" , "Methodology", and "Errors | |||

metric" sections but by sections "Methodology" and "Errors and | and Uncertainties" whenever they exist in these documents. | |||

Uncertainties". | ||||

Following are the elements of information taken from end-to-end | The following are the elements of information taken from end-to-end | |||

metrics definitions referred in this memo and from spatial and | metrics definitions referred to in this memo and from spatial and | |||

multicast metrics it defines: | multicast metrics it defines: | |||

o Packet_type, The Type-P of test packets (Type-P); | o Packet_type, the Type-P of test packets (Type-P). | |||

o Packet_length, a packet length in bits (L); | ||||

o Src_host, the IP address of the sender; | o Packet_length, a packet length in bits (L). | |||

o Dst_host, the IP address of the receiver; | ||||

o Hosts_serie: <H1, H2,..., Hn>, a list of points of interest | o Src_host, the IP address of the sender. | |||

participating to the instantaneous measure. They are routers in | ||||

o Dst_host, the IP address of the receiver. | ||||

o Hosts_series: <H1, H2,..., Hn>, a list of points of interest | ||||

participating in the instantaneous measure. They are routers in | ||||

the case of spatial metrics or receivers in the case of one-to- | the case of spatial metrics or receivers in the case of one-to- | |||

group metrics; | group metrics. | |||

o Loss_threshold: The threshold of infinite delay; | ||||

o Systematic_error: constant delay between wire time and | o Loss_threshold, the threshold of infinite delay. | |||

timestamping; | ||||

o Calibration_error: maximal uncertainty; | RFC 5644 Spatial and Multicast Metrics October 2009 | |||

o Src_time, the sending time for a measured packet; | ||||

o Dst_time, the receiving time for a measured packet; | o Systematic_error, constant delay between wire-time and | |||

o Result_status : an indicator of usability of a result 'Resource | timestamping. | |||

exhaustion' 'infinite', 'lost'; | ||||

o Delays_serie: <dT1,..., dTn> a list of delays; | o Calibration_error, maximal uncertainty. | |||

o Losses_serie: <B1, B2, ..., Bi, ..., Bn>, a list of Boolean values | ||||

(spatial) or a set of Boolean values (one-to-group); | o Src_time, the sending time for a measured packet. | |||

o Result_status_serie: a list of results status; | ||||

o dT: a delay; | o Dst_time, the receiving time for a measured packet. | |||

o Singleton_number: a number of singletons; | ||||

o Observation_duration: An observation duration; | o Result_status, an indicator of usability of a result 'Resource | |||

exhaustion' 'infinite', 'lost'. | ||||

o Delays_series, <dT1,..., dTn>, a list of delays. | ||||

o Losses_series, <B1, B2, ..., Bi, ..., Bn>, a list of Boolean | ||||

values (spatial) or a set of Boolean values (one-to-group). | ||||

o Result_status_series, a list of results status. | ||||

o dT, a delay. | ||||

o Singleton_number, a number of singletons. | ||||

o Observation_duration, an observation duration. | ||||

o metric_identifier. | o metric_identifier. | |||

Following is the information of each vector that SHOULD be available | The following is the information of each vector that SHOULD be | |||

to compute samples: | available to compute samples: | |||

o Packet_type; | o Packet_type; | |||

o Packet_length; | o Packet_length; | |||

o Src_host, the sender of the packet; | o Src_host, the sender of the packet; | |||

o Dst_host, the receiver of the packet, apply only for spatial | o Dst_host, the receiver of the packet, apply only for spatial | |||

vectors; | vectors; | |||

o Hosts_serie: not ordered for one-to-group; | ||||

o Hosts_series, not ordered for one-to-group; | ||||

o Src_time, the sending time for the measured packet; | o Src_time, the sending time for the measured packet; | |||

o dT, the end-to-end one-way delay for the measured packet, apply | o dT, the end-to-end one-way delay for the measured packet, apply | |||

only for spatial vectors; | only for spatial vectors; | |||

o Delays_serie: apply only for delays and ipdv vector, not ordered | ||||

o Delays_series, apply only for delays and ipdv vector, not ordered | ||||

for one-to-group; | for one-to-group; | |||

o Losses_serie: apply only for packets loss vector, not ordered for | ||||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

o Losses_series, apply only for packets loss vector, not ordered for | ||||

one-to-group; | one-to-group; | |||

o Result_status_serie; | ||||

o Observation_duration: the difference between the time of the last | o Result_status_series; | |||

o Observation_duration, the difference between the time of the last | ||||

singleton and the time of the first singleton. | singleton and the time of the first singleton. | |||

o Following is the context information (measure, points of | ||||

interests) that SHOULD be available to compute samples : | ||||

* Loss threshold; | Following is the context information (measure, points of interests) | |||

* Systematic error: constant delay between wire time and | that SHOULD be available to compute samples: | |||

timestamping; | ||||

* Calibration error: maximal uncertainty; | o Loss threshold; | |||

o Systematic error, constant delay between wire-time and | ||||

timestamping; | ||||

o Calibration error, maximal uncertainty. | ||||

A spatial or a one-to-group sample is a collection of singletons | A spatial or a one-to-group sample is a collection of singletons | |||

giving the performance from the sender to a single point of interest. | giving the performance from the sender to a single point of interest. | |||

Following is the information that SHOULD be available for each sample | ||||

to compute statistics: | The following is the information that SHOULD be available for each | |||

sample to compute statistics: | ||||

o Packet_type; | o Packet_type; | |||

o Packet_length; | o Packet_length; | |||

o Src_host, the sender of the packet; | o Src_host, the sender of the packet; | |||

o Dst_host, the receiver of the packet; | o Dst_host, the receiver of the packet; | |||

o Start_time, the sending time of the first packet; | o Start_time, the sending time of the first packet; | |||

o Delays_serie: apply only for delays and ipdv samples; | ||||

o Losses_serie: apply only for packets loss samples; | o Delays_series, apply only for delays and ipdv samples; | |||

o Result_status_serie; | ||||

o Observation_duration: the difference between the time of the last | o Losses_series, apply only for packets loss samples; | |||

o Result_status_series; | ||||

o Observation_duration, the difference between the time of the last | ||||

singleton of the last sample and the time of the first singleton | singleton of the last sample and the time of the first singleton | |||

of the first sample. | of the first sample. | |||

o Following is the context information (measure, points of | ||||

interests) that SHOULD be available to compute statistics : | ||||

* Loss threshold; | ||||

* Systematic error: constant delay between wire time and | ||||

timestamping; | ||||

* Calibration error: maximal uncertainty; | ||||

Following is the information of each statistic that SHOULD be | The following is the context information (measure, points of | |||

interests) that SHOULD be available to compute statistics: | ||||

o Loss threshold; | ||||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

o Systematic error, constant delay between wire-time and | ||||

timestamping; | ||||

o Calibration error, maximal uncertainty; | ||||

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

computed on; | o Singleton_number, the number of singletons on which the statistic | |||

is computed; | ||||

11. 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 the one-way delay | |||

definitions of [RFC2679] , in packet loss metrics definitions of | metrics definitions of [RFC2679], in packet loss metrics definitions | |||

[RFC2680] and in IPDV metrics definitions of[RFC3393] and [RFC3432] | of [RFC2680] and in IPDV metrics definitions of [RFC3393] and | |||

apply to metrics defined in this memo. | [RFC3432] apply to metrics defined in this memo. | |||

Someone may spoof the identity of a Point of interest identity and | Someone may spoof the identity of a point of interest identity and | |||

intentionally send corrupt results in order to remotely orient the | intentionally send corrupt results in order to remotely orient the | |||

traffic engineering decisions. | traffic engineering decisions. | |||

A point of interest could intentionally corrupt its results in order | A point of interest could intentionally corrupt its results in order | |||

to remotely orient the traffic engineering decisions. | to remotely orient the traffic engineering decisions. | |||

11.1. Spatial metrics | 11.1. Spatial Metrics | |||

Malicious generation of packets which match systematically the hash | Malicious generation of packets that systematically match 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. | |||

Spatial measurement results carry the performance of individual | Spatial measurement results carry the performance of individual | |||

segments of the path and the identity of nodes. An attacker may | segments of the path and the identity of nodes. An attacker may | |||

infer from this information the points of weakness of a network (e.g. | infer from this information the points of weakness of a network | |||

congested node) which would require the least amount of additional | (e.g., congested node) that would require the least amount of | |||

attacking traffic to exploit. Therefore, monitoring information | additional attacking traffic to exploit. Therefore, monitoring | |||

should be carried in a way which prevents unintended recipients from | information should be carried in a way that prevents unintended | |||

inspecting the measurement reports. A straight forward solution is | ||||

to restrict access to the reports using encrypted sessions or secured | ||||

networks. | ||||

11.2. One-to-group metrics | RFC 5644 Spatial and Multicast Metrics October 2009 | |||

recipients from inspecting the measurement reports. A | ||||

straightforward solution is to restrict access to the reports using | ||||

encrypted sessions or secured networks. | ||||

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 resources (network, network interfaces, | overload reference point resources (network, network interfaces, | |||

computation capacities ...). | computation capacities, etc.). | |||

The configuration of a measurement must take in consideration that | The configuration of a measurement must take into consideration that | |||

implicitly more packets will be routed than sent and selects a test | implicitly more packets will be routed than sent and select a test | |||

packets rate accordingly. Collecting statistics from a huge number | packet rate accordingly. Collecting statistics from a huge number of | |||

of probes may overload any combination of the network where the | probes may overload any combination of the network to which the | |||

measurement controller is attached to, measurement controller network | measurement controller is attached, measurement controller network | |||

interfaces and measurement controller computation capacities. | interfaces, and measurement controller computation capacities. | |||

One-to-group metrics measurement should consider using source | One-to-group metric measurements 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 denial-of-service | |||

attacks. | attacks. | |||

A point of interest could intentionally degrade its results in order | A point of interest could intentionally degrade its results in order | |||

to remotely increase the quality of the network on the branches of | to remotely increase the quality of the network on the branches of | |||

the multicast tree it is connected to. | the multicast tree to which it is connected. | |||

12. Acknowledgments | 12. Acknowledgments | |||

Lei would like to acknowledge Prof. Zhili Sun from CCSR, University | Lei would like to acknowledge Professor Zhili Sun from CCSR, | |||

of Surrey, for his instruction and helpful comments on this work. | University of Surrey, for his instruction and helpful comments on | |||

this work. | ||||

13. IANA Considerations | 13. IANA Considerations | |||

Metrics defined in this memo are designed to be registered in the | Metrics defined in this memo have been registered in the IANA IPPM | |||

IANA IPPM METRICS REGISTRY as described in initial version of the | METRICS REGISTRY as described in the initial version of the registry | |||

registry [RFC4148] : | [RFC4148]: | |||

IANA is asked to register the following metrics in the IANA-IPPM- | IANA has registered the following metrics in the IANA-IPPM-METRICS- | |||

METRICS-REGISTRY-MIB : | REGISTRY-MIB: | |||

ietfSpatialOneWayDelayVector OBJECT-IDENTITY | ietfSpatialOneWayDelayVector OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

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

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 5.1." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | "RFC 5644, section 5.1." | |||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics 52 } | |||

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 5.2." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | "RFC 5644, section 5.2." | |||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics 53 } | |||

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 5.3." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | "RFC 5644, section 5.3." | |||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics 54 } | |||

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 6.1." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | "RFC 5644, section 6.1." | |||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | RFC 5644 Spatial and Multicast Metrics October 2009 | |||

:= { ianaIppmMetrics 55 } | ||||

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 6.2." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | "RFC 5644, section 6.2." | |||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics 56 } | |||

ietfSegmentIpdvPrevStream OBJECT-IDENTITY | ietfSegmentIpdvPrevStream OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-Segment-ipdv-prev-Stream" | "Type-P-Segment-ipdv-prev-Stream" | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 6.3." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | "RFC 5644, section 6.3." | |||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics 57 } | |||

ietfSegmentIpdvMinStream OBJECT-IDENTITY | ietfSegmentIpdvMinStream OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-Segment-ipdv-min-Stream" | "Type-P-Segment-ipdv-min-Stream" | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 6.4." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | "RFC 5644, section 6.4." | |||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics 58 } | |||

-- One-to-group metrics | -- One-to-group metrics | |||

ietfOneToGroupDelayVector OBJECT-IDENTITY | ietfOneToGroupDelayVector OBJECT-IDENTITY | |||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-One-to-group-Delay-Vector" | "Type-P-One-to-group-Delay-Vector" | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 7.1." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | "RFC 5644, section 7.1." | |||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics 59 } | |||

ietfOneToGroupPacketLossVector OBJECT-IDENTITY | ietfOneToGroupPacketLossVector OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-One-to-group-Packet-Loss-Vector" | "Type-P-One-to-group-Packet-Loss-Vector" | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 7.2." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | "RFC 5644, section 7.2." | |||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics 60 } | |||

ietfOneToGroupIpdvVector OBJECT-IDENTITY | ietfOneToGroupIpdvVector OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-One-to-group-ipdv-Vector" | "Type-P-One-to-group-ipdv-Vector" | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 7.3." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | "RFC 5644, section 7.3." | |||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics 61 } | |||

-- One to group statistics | -- One to group statistics | |||

-- | -- | |||

ietfOnetoGroupReceiverNMeanDelay OBJECT-IDENTITY | ietfOnetoGroupReceiverNMeanDelay OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

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 8.3.1." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | "RFC 5644, section 8.3.1." | |||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics 62 } | |||

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 8.3.2." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | "RFC 5644, section 8.3.2." | |||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics 63 } | |||

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 8.3.3." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | "RFC 5644, section 8.3.3." | |||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics 64 } | |||

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 8.3.4." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | RFC 5644 Spatial and Multicast Metrics October 2009 | |||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | "RFC 5644, section 8.3.4." | |||

:= { ianaIppmMetrics 65 } | ||||

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 8.4.1." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | "RFC 5644, section 8.4.1." | |||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics 66 } | |||

-- | -- | |||

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 8.4.2." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | "RFC 5644, section 8.4.2." | |||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics 67 } | |||

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 8.4.3." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | "RFC 5644, section 8.4.3." | |||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics 68 } | |||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

-- | -- | |||

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 8.4.4." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | "RFC 5644, section 8.4.4." | |||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics 69 } | |||

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 8.5.1." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | "RFC 5644, section 8.5.1." | |||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics 70 } | |||

-- | -- | |||

14. References | 14. References | |||

14.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. | |||

RFC 5644 Spatial and Multicast Metrics October 2009 | ||||

[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics | [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics | |||

Registry", BCP 108, RFC 4148, August 2005. | Registry", BCP 108, RFC 4148, August 2005. | |||

14.2. Informative References | 14.2. Informative References | |||

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

Morton, A. and E. Stephan, "Spatial Composition of | ||||

Metrics", draft-ietf-ippm-spatial-composition-09 (work in | ||||

progress), June 2009. | ||||

[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. | |||

[SPATIAL] Morton, A. and E. Stephan, "Spatial Composition of | ||||

Metrics", Work in Progress, June 2009. | ||||

Authors' Addresses | Authors' Addresses | |||

Stephan Emile | Stephan Emile | |||

France Telecom Division R&D | France Telecom Division R&D | |||

2 avenue Pierre Marzin | 2 avenue Pierre Marzin | |||

Lannion, F-22307 | Lannion F-22307 | |||

France | ||||

Fax: +33 2 96 05 18 52 | Fax: +33 2 96 05 18 52 | |||

Email: emile.stephan@orange-ftgroup.com | EMail: emile.stephan@orange-ftgroup.com | |||

Lei Liang | Lei Liang | |||

CCSR, University of Surrey | CCSR, University of Surrey | |||

Guildford | Guildford | |||

Surrey, GU2 7XH | Surrey GU2 7XH | |||

UK | ||||

Fax: +44 1483 683641 | Fax: +44 1483 683641 | |||

Email: L.Liang@surrey.ac.uk | EMail: L.Liang@surrey.ac.uk | |||

Al Morton | Al Morton | |||

200 Laurel Ave. South | 200 Laurel Ave. South | |||

Middletown, NJ 07748 | Middletown, NJ 07748 | |||

USA | USA | |||

Phone: +1 732 420 1571 | Phone: +1 732 420 1571 | |||

Email: acmorton@att.com | EMail: acmorton@att.com | |||

End of changes. 507 change blocks. | ||||

607 lines changed or deleted | | 1031 lines changed or added | ||

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