draft-ietf-ippm-multimetrics-03.txt | draft-ietf-ippm-multimetrics-04.txt | |||
---|---|---|---|---|

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

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

Intended status: Informational L. Liang | Intended status: Informational L. Liang | |||

Expires: September 2, 2007 University of Surrey | Expires: January 7, 2008 University of Surrey | |||

A. Morton | A. Morton | |||

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

March 1, 2007 | July 6, 2007 | |||

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

draft-ietf-ippm-multimetrics-03 | draft-ietf-ippm-multimetrics-04 | |||

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This Internet-Draft will expire on September 2, 2007. | This Internet-Draft will expire on January 7, 2008. | |||

Copyright Notice | Copyright Notice | |||

Copyright (C) The IETF Trust (2007). | Copyright (C) The IETF Trust (2007). | |||

Abstract | Abstract | |||

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

metrics for measuring end-to-end performance between 2 points. This | metrics for measuring end-to-end performance between 2 points. This | |||

memo defines 2 sets of metrics to extend these end-to-end ones. It | memo defines 2 sets of metrics to extend these end-to-end ones. It | |||

defines spatial metrics for measuring the performance of segments | defines spatial metrics for measuring the performance of segments | |||

along a path and metrics for measuring the performance of a group of | along a path and metrics for measuring the performance of a group of | |||

users in multiparty communications. | users in multiparty communications. | |||

Table of Contents | Table of Contents | |||

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||

2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||

2.1. Multiparty metric . . . . . . . . . . . . . . . . . . . . 6 | 2.1. Path Digest Hosts . . . . . . . . . . . . . . . . . . . . 6 | |||

2.2. Spatial metric . . . . . . . . . . . . . . . . . . . . . . 6 | 2.2. Multiparty metric . . . . . . . . . . . . . . . . . . . . 6 | |||

2.3. Spatial metric points of interest . . . . . . . . . . . . 6 | 2.3. Spatial metric . . . . . . . . . . . . . . . . . . . . . . 6 | |||

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

2.5. One-to-group metric points of interest . . . . . . . . . . 6 | 2.5. Points of interest . . . . . . . . . . . . . . . . . . . . 6 | |||

2.6. Reference point . . . . . . . . . . . . . . . . . . . . . 6 | 2.6. Reference point . . . . . . . . . . . . . . . . . . . . . 8 | |||

2.7. Vector . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.7. Vector . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||

2.8. Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.8. Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||

3. Motivations for spatial and one-to-group metrics . . . . . . . 8 | 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||

3.1. spatial metrics . . . . . . . . . . . . . . . . . . . . . 8 | 3.1. Motivations for spatial metrics . . . . . . . . . . . . . 9 | |||

3.2. One-to-group metrics . . . . . . . . . . . . . . . . . . . 9 | 3.2. Motivations for One-to-group metrics . . . . . . . . . . . 10 | |||

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

4. Spatial metrics definitions . . . . . . . . . . . . . . . . . 10 | 4. Spatial vectors metrics definitions . . . . . . . . . . . . . 11 | |||

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

4.2. A Definition of a sample of One-way Delay of a sub path . 13 | 4.2. A Definition for Spatial One-way Packet Loss Vector . . . 13 | |||

4.3. A Definition for Spatial One-way Packet Loss Vector . . . 16 | 4.3. A Definition for Spatial One-way Ipdv Vector . . . . . . . 15 | |||

4.4. A Definition for Spatial One-way Jitter Vector . . . . . . 17 | 4.4. Spatial Methodology . . . . . . . . . . . . . . . . . . . 17 | |||

4.5. Pure Passive Metrics . . . . . . . . . . . . . . . . . . . 19 | 5. Spatial Segments metrics definitions . . . . . . . . . . . . . 19 | |||

4.6. Discussion on spatial statistics . . . . . . . . . . . . . 21 | 5.1. A Definition of a sample of One-way Delay of a segment | |||

5. One-to-group metrics definitions . . . . . . . . . . . . . . . 21 | of the path . . . . . . . . . . . . . . . . . . . . . . . 19 | |||

5.1. A Definition for one-to-group One-way Delay . . . . . . . 21 | 5.2. A Definition of a sample of Packet Loss of a segment | |||

5.2. A Definition for one-to-group One-way Packet Loss . . . . 22 | of the path . . . . . . . . . . . . . . . . . . . . . . . 21 | |||

5.3. A Definition for one-to-group One-way Jitter . . . . . . . 22 | 5.3. A Definition of a sample of One-way Ipdv of a segment | |||

6. One-to-Group Sample Statistics . . . . . . . . . . . . . . . . 24 | of the path . . . . . . . . . . . . . . . . . . . . . . . 24 | |||

6.1. Discussion on the Impact of packet loss on statistics . . 26 | 5.4. Discussion on Passive Segment Metrics . . . . . . . . . . 24 | |||

6.2. General Metric Parameters . . . . . . . . . . . . . . . . 27 | 6. One-to-group metrics definitions . . . . . . . . . . . . . . . 27 | |||

6.3. One-to-Group one-way Delay Statistics . . . . . . . . . . 28 | 6.1. A Definition for one-to-group One-way Delay . . . . . . . 27 | |||

6.4. One-to-Group one-way Loss Statistics . . . . . . . . . . . 31 | 6.2. A Definition for one-to-group One-way Packet Loss . . . . 28 | |||

6.5. One-to-Group one-way Delay Variation Statistics . . . . . 33 | 6.3. A Definition for one-to-group One-way Ipdv . . . . . . . . 28 | |||

7. Measurement Methods: Scaleability and Reporting . . . . . . . 33 | 7. One-to-Group Sample Statistics . . . . . . . . . . . . . . . . 30 | |||

7.1. Computation methods . . . . . . . . . . . . . . . . . . . 34 | 7.1. Discussion on the Impact of packet loss on statistics . . 32 | |||

7.2. Measurement . . . . . . . . . . . . . . . . . . . . . . . 35 | 7.2. General Metric Parameters . . . . . . . . . . . . . . . . 33 | |||

7.3. effect of Time and Space Aggregation Order on Group | 7.3. One-to-Group one-way Delay Statistics . . . . . . . . . . 34 | |||

Stats . . . . . . . . . . . . . . . . . . . . . . . . . . 35 | 7.4. One-to-Group one-way Loss Statistics . . . . . . . . . . . 37 | |||

7.4. effect of Time and Space Aggregation Order on Spatial | 7.5. One-to-Group one-way Delay Variation Statistics . . . . . 39 | |||

Stats . . . . . . . . . . . . . . . . . . . . . . . . . . 37 | 8. Measurement Methods: Scaleability and Reporting . . . . . . . 39 | |||

8. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 37 | 8.1. Computation methods . . . . . . . . . . . . . . . . . . . 40 | |||

9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 | 8.2. Measurement . . . . . . . . . . . . . . . . . . . . . . . 41 | |||

9.1. passive measurement . . . . . . . . . . . . . . . . . . . 37 | 8.3. Effect of Time and Space Aggregation Order on Stats . . . 41 | |||

9.2. one-to-group metric . . . . . . . . . . . . . . . . . . . 37 | 9. Manageability Considerations . . . . . . . . . . . . . . . . . 43 | |||

10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 | 9.1. Reporting spatial metric . . . . . . . . . . . . . . . . . 43 | |||

11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 | 9.2. Reporting One-to-group metric . . . . . . . . . . . . . . 44 | |||

12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 | 9.3. Metric identification . . . . . . . . . . . . . . . . . . 44 | |||

12.1. Normative References . . . . . . . . . . . . . . . . . . . 42 | 9.4. Reporting data model . . . . . . . . . . . . . . . . . . . 44 | |||

12.2. Informative References . . . . . . . . . . . . . . . . . . 43 | 10. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 48 | |||

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 48 | |||

Intellectual Property and Copyright Statements . . . . . . . . . . 45 | 11.1. Spatial metrics . . . . . . . . . . . . . . . . . . . . . 48 | |||

11.2. one-to-group metric . . . . . . . . . . . . . . . . . . . 48 | ||||

12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49 | ||||

13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 | ||||

14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 | ||||

14.1. Normative References . . . . . . . . . . . . . . . . . . . 55 | ||||

14.2. Informative References . . . . . . . . . . . . . . . . . . 56 | ||||

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 | ||||

Intellectual Property and Copyright Statements . . . . . . . . . . 58 | ||||

1. Introduction | 1. Introduction | |||

The metrics specified in this memo are built on notions introduced | ||||

and discussed in the IPPM Framework document, RFC 2330 [RFC2330]. | ||||

The reader should be familiar with these documents. | ||||

This memo makes use of definitions of end-to-end One-way Delay | ||||

Metrics defined in the RFC 2679 [RFC2679] to define metrics for | ||||

decomposition of end-to-end one-way delays measurements. | ||||

This memo makes use of definitions of end-to-end One-way Packet loss | ||||

Metrics defined in the RFC 2680 [RFC2680] to define metrics for | ||||

decomposition of end-to-end one-way packet loss measurements. | ||||

The IPPM WG defined a framework for metric definitions and end-to-end | The IPPM WG defined a framework for metric definitions and end-to-end | |||

measurements: | measurements: | |||

o A general framework for defining performance metrics, described in | o A general framework for defining performance metrics, described in | |||

the Framework for IP Performance Metrics [RFC2330]; | the Framework for IP Performance Metrics [RFC2330]; | |||

o A One-way Active Measurement Protocol Requirements [RFC3763]; | o A One-way Active Measurement Protocol Requirements [RFC3763]; | |||

o A One-way Active Measurement Protocol (OWAMP) [RFC4656]; | o A One-way Active Measurement Protocol (OWAMP) [RFC4656]; | |||

skipping to change at page 4, line 51 | skipping to change at page 4, line 39 | |||

o A Framework for Defining Empirical Bulk Transfer Capacity Metrics | o A Framework for Defining Empirical Bulk Transfer Capacity Metrics | |||

[RFC3148]; | [RFC3148]; | |||

o One-way Loss Pattern Sample Metrics [RFC3357]; | o One-way Loss Pattern Sample Metrics [RFC3357]; | |||

o IP Packet Delay Variation Metric for IPPM [RFC3393]; | o IP Packet Delay Variation Metric for IPPM [RFC3393]; | |||

o Network performance measurement for periodic streams [RFC3432]; | o Network performance measurement for periodic streams [RFC3432]; | |||

o Packet Reordering Metric for IPPM [RFC4737][Work in progress]; | o Packet Reordering Metric for IPPM [RFC4737]; | |||

Based on these works, this memo defines 2 kinds of multi party | ||||

metrics. | This memo defines spatial and one-to-group metrics based on the | |||

framework and on the end-to-end metrics defined in these documents. | ||||

Firstly it defines spatial metrics: | Firstly it defines spatial metrics: | |||

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

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

spatial sequence of one-way delays. | in a spatial sequence of one-way delays. | |||

o A 'sample', called Type-P-Spatial-One-way-Packet-Loss-Vector, will | o A 'vector', called Type-P-Spatial-One-way-Packet-Loss-Vector, will | |||

be introduced to divide an end-to-end Type-P-One-way-Packet-Loss | be introduced to divide an end-to-end Type-P-One-way-Packet-Loss | |||

in a spatial sequence of packet loss. | [RFC2680] in a spatial sequence of packet loss. | |||

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 'vector', | |||

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

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

jitter. | ipdv. | |||

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-subpath-One-way-Delay-Stream, will be introduced to | called Type-P-Segment-One-way-Delay-Stream, will be introduced to | |||

define the one-way-delay between a pair of host of the path. This | define a set of one-way delays between a pair of host of the path; | |||

metric is similar to Type-P-One-way-Delay-Stream. | ||||

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

Passive-One-way-Delay-Stream will be introduced to define passive | called Type-P-Segment-Packet-Loss-Stream, will be introduced to | |||

metrics. These metrics are designed for pure passive measurement | define a set of packet losses between a pair of host of the path; | |||

methodology as introduced by PSAMP WG. | ||||

o Using the Type-P-Spatial-ipdv-Vector metric, a 'sample', called | ||||

Type-P-Segment-ipdv-Stream, will be introduced to define a set of | ||||

ipdvs between a pair of host of the path; | ||||

Then it defines one-to-group metrics. | Then it defines one-to-group metrics. | |||

o Using one test packet sent from one sender to a group of | o Using one test packet sent from one sender to a group of | |||

receivers, a 'sample', called Type-P-one-to-group-One-way-Delay- | receivers, a 'sample', called Type-P-one-to-group-One-way-Delay- | |||

Vector, will be introduced to define the list of Type-P-one-way- | Vector, will be introduced to define the list of Type-P-one-way- | |||

delay between this sender and the group of receivers. | delay [RFC2679] between this sender and the group of receivers. | |||

o Using one test packet sent from one sender to a group of | o Using one test packet sent from one sender to a group of | |||

receivers, a 'sample', called Type-P-one-to-group-One-way-Packet- | receivers, a 'sample', called Type-P-one-to-group-One-way-Packet- | |||

Loss-Vector, will be introduced to define the list of Type-P-One- | Loss-Vector, will be introduced to define the list of Type-P-One- | |||

way-Packet-Loss between this sender and the group of receivers | way-Packet-Loss [RFC2680] between this sender and the group of | |||

receivers | ||||

o Using one test packet sent from one sender to a group of | o Using one test packet sent from one sender to a group of | |||

receivers, a 'sample', called Type-P-one-to-group-One-way-Jitter- | receivers, a 'sample', called Type-P-one-to-group-One-way-ipdv- | |||

Vector, will be introduced to define the list of Type-P-One-way- | Vector, will be introduced to define the list of Type-P-One-way- | |||

ipdv between this sender and the group of receivers | ipdv between this sender and the group of receivers | |||

o Then a discussion section presents the set of statistics that may | o Then a discussion section presents the set of statistics that may | |||

be computed on the top of these metrics to present the QoS in a | be computed using these metrics to present the network performance | |||

view of a group of users as well as the requirements of relative | in the view of a group of users. The statistics may be the basis | |||

QoS on multiparty communications. | for requirements (e.g. fairness) on multiparty communications. . | |||

Reporting of metrics is defined in the section "Manageability | ||||

Consideration". | ||||

2. Terminology | 2. Terminology | |||

2.1. Multiparty metric | 2.1. Path Digest Hosts | |||

A metric is said to be multiparty if the definition involved more | The list of the hosts of a path from a source to a destination. | |||

than two sources or destinations in the measurements. All multiparty | ||||

2.2. Multiparty metric | ||||

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

one source or destination in the measurements. All multiparty | ||||

metrics define a set of hosts called "points of interest", where one | metrics define a set of hosts called "points of interest", where one | |||

host is the source and other hosts are the measurement collection | host is the source and other hosts are the measurement collection | |||

points. For example, if the set of points of interest is < ha, hb, | points. For example, if the set of points of interest is < ha, hb, | |||

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

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

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

2.2. Spatial metric | For the purposes of this memo (reflecting the scope of a single | |||

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

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

neither the source nor the destination of the metered packet. | ||||

2.3. Spatial metric points of interest | 2.3. Spatial metric | |||

Points of interest of a spatial metric are the routers or sibling in | A metric is said to be spatial if one of the hosts involved is | |||

the path between source and destination (in addition to the source | neither the source nor the destination of the measured packet. | |||

and the destination themselves). | ||||

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

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

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

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

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

server in the topology. | server in the topology. | |||

2.5. One-to-group metric points of interest | 2.5. Points of interest | |||

Points of interest of One-to-group metrics are the set of host | Points of interest are the set of hosts* (as per RFC2330 definition, | |||

destinations receiving packets from the source (in addition to the | that is including nodes) of the set of hosts involved in the delivery | |||

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

of the points of interest are (a possibly arbitrary) subset of all | ||||

the hosts involved in the path. Points of interest of One-to-group | ||||

metrics are the hosts receiving packets from the source (in addition | ||||

to the source itself). | ||||

Src Recv | ||||

`. ,-. | ||||

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

`. ; : | ||||

`. ; : | ||||

; :... 2 | ||||

| | | ||||

: ; | ||||

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

: ; | ||||

`. ,' | ||||

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

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

A points of interest of spatial metrics is a host of the set of hosts | ||||

involved in the delivery of the packets from the source. | ||||

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

\ | ||||

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

\ | ||||

x | ||||

/ | ||||

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

/ | ||||

x | ||||

\ | ||||

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

\ | ||||

\ | ||||

\ | ||||

X .... N | ||||

\ | ||||

\ | ||||

\ | ||||

`---- Dst | ||||

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

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

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

The centre/server in the one-to-group measurement that is controlled | The centre/server in the multimetrics measurement that is controlled | |||

by network operators can be a very good reference point where | by network operators can be a very good reference point where | |||

measurement data can be collected for further processing although the | measurement data can be collected for further processing although the | |||

actual measurements have to be carried out at all points of interest. | actual measurements have to be carried out at all points of interest. | |||

I.e., the measurement points will be all clients/receivers while the | Thus, we can define the reference point as the server where the | |||

reference point acts as source for the one-to-group metric. Thus, we | statistic calculation will be carried out. | |||

can define the reference point as the host while the statistic | ||||

calculation will be carried out. | ||||

2.7. Vector | 2.7. Vector | |||

A group of singletons is the set of results of the observation of the | ||||

behaviour of the same packet at different places of a network. | ||||

A Vector is a set of singletons, which are a set of results of the | A Vector is a set of singletons, which are a set of results of the | |||

observation of the behaviour of the same packet at different places | observation of the behaviour of the same packet at different places | |||

of a network at different time. For instance, if One-way delay | of a network at different time. For instance, if One-way delay | |||

singletons observed at N receivers for Packet P sent by the source | singletons observed at N receivers for Packet P sent by the source | |||

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

elements can be organized as {dT1, dT2,..., dTN}. The elements in | elements can be organized as {dT1, dT2,..., dTN}. The elements in | |||

one vector are singletons distinct with each other in terms of both | one vector are singletons distinct with each other in terms of both | |||

measurement point and time. Given the vector V as an example, the | measurement point and time. Given the vector V as an example, the | |||

element dT1 is distinct from the rest by measured at receiver 1 at | element dT1 is distinct from the rest by measured at receiver 1 at | |||

time T1. Additional to a singleton, Vector gives information over a | time T1. Additional to a singleton, Vector gives information over a | |||

space dimension. | space dimension. | |||

2.8. Matrix | 2.8. Matrix | |||

Several vectors can organize form up a Matrix, which contains results | Several vectors can form up a Matrix, which contains results observed | |||

observed in a sampling interval at different place of a network at | in a sampling interval at different place of a network at different | |||

different time. For instance, given One-way delay vectors V1={dT11, | time. For instance, given One-way delay vectors V1={dT11, dT12,..., | |||

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

dTmN} for Packet P1, P2,...,Pm, we can have a One-way delay Matrix | Packet P1, P2,...,Pm, we can have a One-way delay Matrix {V1, | |||

{V1, V2,...,Vm}. Additional to the information given by a Vector, a | V2,...,Vm}. Additional to the information given by a Vector, a | |||

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

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

The relation among Singleton, Vector and Matrix can be shown in the | The relation among Singleton, Vector and Matrix can be shown in the | |||

following Figure 1. | following Figure 3. | |||

one-to-group Singleton | Point of Singleton | |||

/ Sample | interest / Samples | |||

Src Recv .............................. | ,----. ^ / | |||

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

`:=-.._ | / \ | | | | |||

T `._ ``-..__ | ; R2........| | R2dT1 R2dT2 R2dT3 ... R3dTk | | |||

`. `-... 2 R2dT1 R2dT2 R2dT3 R2dT4 | Src | || | | | |||

`-. | | R3....| | R3dT1 R3dT2 R3dT3 ... R3dTk | | |||

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

`.... N R3dT1 R3dT2 R3dT3 R3dT4 | : ;| | | | |||

\ / | | | | ||||

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

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

Vector Matrix | Vector Matrix | |||

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

Figure 1: Relation beween Singletons, vectors and matrix | Figure 3: Relation beween Singletons, vectors and matrix | |||

3. Motivations for spatial and one-to-group metrics | 3. Motivations | |||

All IPPM metrics are defined for end-to-end measurement. These | All IPPM metrics are defined for end-to-end measurement. These | |||

metrics provide very good guides for measurement in the pair | metrics provide very good guides for measurement in the pair | |||

communications. However, further efforts should be put to define | communications. However, further efforts should be put to define | |||

metrics for multiparty measurements such as one to one trajectory | metrics for multiparty measurements such as one to one trajectory | |||

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

3.1. spatial metrics | 3.1. Motivations for spatial metrics | |||

Decomposition of instantaneous end-to-end measures is needed: | Decomposition of instantaneous end-to-end measures is needed: | |||

o Decomposing the performance of interdomain path is desirable in | o Decomposing the performance of interdomain path is desirable in | |||

interdomain to qualify per AS contribution to the performance. So | interdomain to qualify per AS contribution to the performance. So | |||

it is necessary to define standard spatial metrics before going | it is necessary to define standard spatial metrics before going | |||

further in the computation of inter domain path with QoS | further in the computation of inter domain path with QoS | |||

constraint. | constraint. | |||

o Traffic engineering and troubleshooting applications require | o Traffic engineering and troubleshooting applications require | |||

spatial views of the one-way delay consumption, identification of | spatial views of the one-way delay consumption, identification of | |||

the location of the lost of packets and the decomposition of the | the location of the lost of packets and the decomposition of the | |||

jitter over the path. | ipdv over the path. | |||

o Monitoring the QoS of a multicast tree, of MPLS point-to- | o Monitoring the QoS of a multicast tree, of MPLS point-to- | |||

multipoint and inter-domain communication require spatial | multipoint and inter-domain communication require spatial | |||

decomposition of the one-way delay, of the packet loss and of the | decomposition of the one-way delay, of the packet loss and of the | |||

jitter. | ipdv. | |||

o Composition of metrics is a need to scale in the measurement | o Composition of metrics is a need to scale in the measurement | |||

plane. Spatial measure give typically the individual performance | plane. Spatial measure give typically the individual performance | |||

of an intra domain segment. It is the elementary piece of | of an intra domain segment. It is the elementary piece of | |||

information to exchange for measuring interdomain performance | information to exchange for measuring interdomain performance | |||

based on composition of metrics. | based on composition of metrics. | |||

o The PSAMP WG defines capabilities to sample packets in a way to to | o The PSAMP WG defines capabilities to sample packets in a way to to | |||

support instantaneous measurement respecful of the IPPM framework | support instantaneous measurement respecful of the IPPM framework | |||

[RFC2330]. Consequently it is necessary to define a set of | [RFC2330]. Consequently it is necessary to define a set of | |||

spatial metrics for passive and active techniques. | spatial metrics for passive and active techniques. | |||

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

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

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

the performance of a multiparty communication in the view of a group | the performance of a multiparty communication in the view of a group | |||

with consideration that it involves a group of people rather than | with consideration that it involves a group of people rather than | |||

two. As a consequence a simple one-way metric cannot describe the | two. As a consequence a simple one-way metric cannot describe the | |||

multi-connection situation. We need some new metrics to collect | multi-connection situation. We need some new metrics to collect | |||

performance of all the connections for further statistics analysis. | performance of all the connections for further statistics analysis. | |||

A group of metrics are proposed in this stage named one-to-group | A group of metrics are proposed in this stage named one-to-group | |||

performance metrics based on the unicast metrics defined in IPPM WG. | performance metrics based on the unicast metrics defined in IPPM WG. | |||

skipping to change at page 10, line 38 | skipping to change at page 11, line 39 | |||

measurement points. However, we can always avoid this confusion by | measurement points. However, we can always avoid this confusion by | |||

treating the connections as one-to-group or group-to-one in our | treating the connections as one-to-group or group-to-one in our | |||

measurements without consideration on how the real communication will | measurements without consideration on how the real communication will | |||

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

..., hn > are acting as sources to send data to another group of | ..., hn > are acting as sources to send data to another group of | |||

hosts < Ha, Hb, Hc, ..., Hm >, we can always decompose them into n | hosts < Ha, Hb, Hc, ..., Hm >, we can always decompose them into n | |||

one-to-group communications as < ha, Ha, Hb, Hc, ..., Hm >, < hb, Ha, | one-to-group communications as < ha, Ha, Hb, Hc, ..., Hm >, < hb, Ha, | |||

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

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

4. Spatial metrics definitions | 4. Spatial vectors metrics definitions | |||

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

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

The definition of a spatial metric is coupled with the corresponding | Spatial vectors metrics are based on the decomposition of standard | |||

end-to-end metric. The methodology is based on the measure of the | end-to-end metrics defined by the IPPM WG in [RFC2679], [RFC2680], | |||

same test packet and parameters of the corresponding end-to-end | [RFC3393] and [RFC3432]. | |||

metric. | ||||

Definitions are coupled with the corresponding end-to-end metrics. | ||||

Methodology specificities are common to all the vectors defined and | ||||

are consequently discussed in a common section. | ||||

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

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

When a parameter from section 3 of [RFC2679] is first used in this | When a parameter from section 3 of [RFC2679] is first used in this | |||

section, it will be tagged with a trailing asterisk. | section, it will be 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. | |||

skipping to change at page 11, line 22 | skipping to change at page 12, line 27 | |||

Following we adapt some of them and introduce points specific to | Following we adapt some of them and introduce points specific to | |||

spatial measurement. | spatial measurement. | |||

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

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

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

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

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

+ i, An integer which ordered the hosts in the path. | o i, An integer if the list <1,2,...,n> which ordered the hosts in | |||

the path. | ||||

+ Hi, exchange points of the path digest. | o Hi, A host* of the path digest. | |||

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

a measured packet. | measured packet. | |||

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

+ dT1,..., dTn a list of delay. | o <dT1,..., dTn> a list of delay. | |||

+ P*, the specification of the packet type. | o P*, the specification of the packet type. | |||

+ <Src, H1, H2,..., Hn, Dst>, a path digest. | o <H1, H2,..., Hn>, hosts path digest. | |||

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

A sequence of times. | A sequence of times. | |||

4.1.4. Definition | 4.1.4. Definition | |||

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

T to the receiver Dst in the path <H1, H2,..., Hn>. Given the | T to the receiver Dst in the path <H1, H2,..., Hn>. Given the | |||

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

skipping to change at page 12, line 16 | skipping to change at page 13, line 23 | |||

never passes Hi. | never passes Hi. | |||

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

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

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

4.1.5. Discussion | 4.1.5. Discussion | |||

Following are specific issues which may occur: | Following are specific issues which may occur: | |||

o the delay looks to decrease: dTi > DTi+1. this seem typically du | o the delay looks to decrease: dTi > DTi+1. This seem typically du | |||

to some clock synchronisation issue. this point is discussed in | to some clock synchronisation issue. This point is discussed in | |||

the section 3.7.1. "Errors or uncertainties related to Clocks" of | the section 3.7.1. "Errors or uncertainties related to Clocks" of | |||

of [RFC2679]; | of [RFC2679]. One consequence of these uncertainties is that | |||

times of a measure at different hosts shall not be used to order | ||||

hosts on the path of a measure; | ||||

o The location of the point of interest in the device influences the | o The location of the point of interest in the device influences the | |||

result. If the packet is not observed on the input interface the | result. If the packet is not observed on the input interface the | |||

delay includes buffering time and consequently an uncertainty due | delay includes buffering time and consequently an uncertainty due | |||

to the difference between 'wire time' and 'host time'; | to the difference between 'wire time' and 'host time'; | |||

4.1.6. Interference with other test packet | 4.2. A Definition for Spatial One-way Packet Loss Vector | |||

To avoid packet collision it is preferable to include a sequence | This section is coupled with the definition of Type-P-One-way-Packet- | |||

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

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

4.1.7. loss threshold | Sections 2.5 to 2.8 of [RFC2680] give requirements and applicability | |||

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

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

Spatial packet loss measurement SHOULD be respectful of them, | ||||

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

reporting. | ||||

To determine if a dTi is defined or undefined it is necessary to | Following we define the spatial metric, then we adapt some of the | |||

define a period of time after which a packet is considered loss. | points above and introduce points specific to spatial measurement. | |||

4.1.8. Methodologies | 4.2.1. Metric Name | |||

Section 3.6 of [RFC2679] gives methodologies for end-to-end one-way- | Type-P-Spatial-One-way-Packet-Loss-Vector | |||

delay measurements. Most of them apply to each points interest Hi | ||||

and are relevant to this section. | ||||

Generally, for a given Type-P, in a given Hi, the methodology would | 4.2.2. Metric Parameters | |||

proceed as follows: | ||||

o At each Hi, prepare to capture the packet sent a time T, take a | + Src*, the IP address of the sender. | |||

timestamp Ti', determine the internal delay correction dTi', | ||||

extract the timestamp T from the packet, then compute the one-way- | ||||

delay from Src to Hi: dTi = Ti' - dTi' - T. The one-way delay is | ||||

undefined (infinite) if the packet is not detected after the 'loss | ||||

threshold' duration; | ||||

o Gather the set of dTi of each Hi and order them according to the | ||||

path to build the Type-P-Spatial-One-way-Delay-Vector metric | ||||

<T,dT1,dT2,...,dTn,dT> over the path <H1, H2,..., Hn>. | ||||

It is out of the scope of this document to define how each Hi detects | + Dst*, the IP address of the receiver. | |||

the packet. | ||||

4.1.9. Reporting the metric | + i, An integer which ordered the hosts in the path. | |||

Section 3.6 of [RFC2679] indicates the items to report. | + Hi, exchange points of the path digest. | |||

4.1.10. Path | + T*, a time, the sending (or initial observation) time for | |||

a measured packet. | ||||

It is clear that a end-to-end Type-P-One-way-Delay can't determine | + dT1,..., dTn, dT, a list of delay. | |||

the list of hosts the packet passes through. Section 3.8.4 of | ||||

[RFC2679] says that the path traversed by the packet SHOULD be | ||||

reported but is practically impossible to determine. | ||||

This part of the job is provide by Type-P-Spatial-One-way-Delay- | + P*, the specification of the packet type. | |||

Vector metric because each points of interest Hi which capture the | ||||

packet is part of the path. | ||||

4.2. A Definition of a sample of One-way Delay of a sub path | + <SH1, H2,..., Hn>, hosts path digest. | |||

This metric is similar to the metric Type-P-One-way-Delay-Poisson- | + B1, B2, ..., Bi, ..., Bn, a list of Boolean values. | |||

stream defined in [RFC2679] and to the metric Type-P-One-way-Delay- | ||||

Periodic-Stream defined in [RFC3432]. | ||||

Nevertheless its definition differs because it is based of the | 4.2.3. Metric Units | |||

division of end-to-end One-way delay using the metric Type-P-Spatial- | ||||

One-way-Delay-Vector defined above. | ||||

It aims is to define a sample of One-way-Delay between a pair of | A sequence of Boolean values. | |||

hosts of a path usable by active and passive measurements. | ||||

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

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

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

receiver Dst in the path <H1, H2, ..., Hn>. Given the sequence of | ||||

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

Dst>, | ||||

Type-P-One-way-Packet-Lost-Vector metric is defined as the sequence | ||||

of values <B1, B2, ..., Bn> such that for each Hi of the path, a | ||||

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

means that dTi is undefined. | ||||

4.2.5. Discussion | ||||

Following are specific issues which may occur: | ||||

o the result includes the sequence 1,0. This case means that the | ||||

packet was seen by a host but not by it successor on the path; | ||||

The location of the point of interest in the device influences the | ||||

result: | ||||

o Even if the packet is received by a host, it may be not observed | ||||

by the point of interest located after a buffer; | ||||

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

This section uses parameters from the definition of Type-P-One-way- | ||||

ipdv. When a parameter from section 2 of [RFC3393] is first used in | ||||

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

Following we adapt some of them and introduce points specific which | ||||

are to spatial measurement. | ||||

4.3.1. Metric Name | ||||

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

4.3.2. Metric Parameters | ||||

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

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

+ i, An integer which ordered the hosts in the path. | ||||

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

+ T1*, the time the first packet was sent. | ||||

+ T2*, the time the second packet was sent. | ||||

+ P, the specification of the packet type. | ||||

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

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

+ <H1, H2,..., Hn>, host path digest. | ||||

+ <T1,dT1.1, dT1.2,..., dT1.n,dT1>, | ||||

the Type-P-Spatial-One-way-Delay-Vector for packet sent at | ||||

time T1; | ||||

+ <T2,dT2.1, dT2.2,..., dT2.n,dT2>, | ||||

the Type-P-Spatial-One-way-Delay-Vector for packet sent at | ||||

time T2; | ||||

+ 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 is taken MUST | ||||

all be of the same length. | ||||

4.3.3. Metric Units | ||||

A sequence of times. | ||||

4.3.4. Definition | ||||

Given the Type-P packet having the size L and sent by the sender Src | ||||

at wire-time (first bit) T1 to the receiver Dst in the path <H1, | ||||

H2,..., Hn>. | ||||

Given the Type-P packet having the size L and sent by the sender Src | ||||

at wire-time (first bit) T2 to the receiver Dst in the same path. | ||||

Given the Type-P-Spatial-One-way-Delay-Vector <T1,dT1.1, dT1.2,..., | ||||

dT1,n,dT1> of the packet P1. | ||||

Given the Type-P-Spatial-One-way-Delay-Vector <T2,dT2.1, dT2.2,..., | ||||

dT2,n,dT2> of the packet P2. | ||||

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

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

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

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

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

them never passes Hi. T2-T1 is the inter-packet emission interval | ||||

and dT2-dT1 is ddT* the Type-P-One-way-ipdv at T1,T2*. | ||||

4.4. Spatial Methodology | ||||

Methodology, reporting and uncertainties points specified in section | ||||

3 of [RFC2679][RFC2679] applies to each point of interest Hi | ||||

measuring a element of a spatial delay vector. | ||||

Methodology, reporting and uncertainties points specified in section | ||||

2 of [RFC2680][RFC2680] applies to each point of interest Hi | ||||

measuring a element of a spatial packet loss vector. | ||||

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

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

Subpath one-way-delay measurement SHOULD be respectful of them, | Spatial One-way ipdv measurement SHOULD be respectful of methodology, | |||

especially those related to methodology, clock, uncertainties and | clock, uncertainties and reporting aspects given in this section. | |||

reporting. | ||||

4.2.1. Metric Name | Passive and active measurement approaches of the metrology are | |||

considered as orthogonal. Active measure differs mainly from passive | ||||

measure by the knowledge of the time the packet was send by the | ||||

source and received by the destination, making the RFC2330 framework | ||||

difficults to apply to passive measurement. On the other hand, | ||||

spatial metrics rely on passive observation of the packets involved | ||||

in the measure. | ||||

Type-P-subpath-One-way-Delay-Stream | In fact each approach compliments the other setting the base of | |||

spatial measurement methodology: Active points of interest provide | ||||

information observed at the source and at the destination while | ||||

Passive points of interests provide information observed at | ||||

intermediary hosts of the path. | ||||

4.2.2. Metric Parameters | Generally, for a given Type-P of length L, in a given Hi, the | |||

methodology for spatial vector metrics would proceed as follows: | ||||

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

a time T, take a timestamp Ti', determine the internal delay | ||||

correction dTi' (See section 3.7.1. "Errors or uncertainties | ||||

related to Clocks" of [RFC2679]), | ||||

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

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

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

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

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

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 The reference point gathers the result and time-to-live of each Hi | ||||

and order them according to the path to build the Type-P-Spatial- | ||||

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

<Src,H1, H2,..., Hn, Dst>. | ||||

4.4.1. Loss threshold | ||||

Loss threshold is the centrality of any methodology because it | ||||

determines the presence the packet in the measurement process of the | ||||

point of interest and consequently determines any ground truth metric | ||||

result. It determines the presence of an effective delay, and bias | ||||

the measure of ipdv, of packet loss and of the statistics. | ||||

This is consistent for end-to-end but impacts spatial measure: | ||||

depending on the consistency of the Loss threshold among the points | ||||

of interest, a packet may be considered loss a one host but present | ||||

in another one, or may be observed by the last host (last hop) of the | ||||

path but considered lost by Dst. The analysis of such results is not | ||||

deterministic: has the path change? Does the packet arrive at | ||||

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

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

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

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

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

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

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

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

the statistic computation process. | ||||

4.4.2. Host Path Digest | ||||

The methodology given above adds the order of the points of interest | ||||

over the path to [RFC2679] one's. | ||||

A perfect Host Path Digest (hum! of cource from the measurement point | ||||

of view only, that is, corresponding to the real path the test packet | ||||

experimented) may include several times several hosts: | ||||

o <Ha,..., Ha> coresponds to a loop in the path; | ||||

o <Ha,..,Hb,..., Ha,...,Hb> coresponds to a loop in the path which | ||||

may occurs during rerouting phases; | ||||

These cases MUST be identified before statistics computation to avoid | ||||

corrupted results' production. This applies especially to the | ||||

measure of segments which are build from results of a measure of a | ||||

vector metric. | ||||

5. Spatial Segments metrics definitions | ||||

This section defines samples to measure a sequence of delays, a | ||||

sequence of lost and a sequence of ipdv between 2 hosts of the path, | ||||

a segment. Singletons are taken from segments of vectors defined | ||||

above. | ||||

5.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 between a pair of | ||||

hosts of a path. | ||||

5.1.1. Metric Name | ||||

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

5.1.2. Metric Parameters | ||||

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

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

+ P*, the specification of the packet type; | ||||

+ i, An integer which orders exchange points in the path. | + i, An integer which orders exchange points in the path. | |||

+ k, An integer which orders the packets sent. | + k, An integer which orders the packets sent. | |||

+ <Src, H1, H2,..., Hn, Dst>, a path digest. | + Hi, a host of the path digest; | |||

+ <H1, H2,..., Hn>, host path digest. | ||||

+ Ha, a host of the path digest different from Dst and Hb; | + Ha, a host of the path digest different from Dst and Hb; | |||

+ Hb, a host of the path digest different from Src and Ha. | + Hb, a host of the path digest different from Src and Ha. | |||

Hb order in the path must greater that Ha; | Hb order in the path must greater that Ha; | |||

+ Hi, exchange points of the path digest. | + <T1, ..., Tk>, a list of time ordered by k; | |||

+ dT1,..., dTn a list of delay. | ||||

+ P*, the specification of the packet type. | ||||

4.2.3. Metric Units | ||||

A sequence of pairs <Tk,dt>. | + dT1,..., dTn a list of delay; | |||

T is one of time of the sequence T1...Tn; | 5.1.3. Metric Units | |||

dt is a delay. | A sequence of delay | |||

4.2.4. Definition | 5.1.4. Definition | |||

Given 2 hosts Ha and Hb of the path <Src, H1, H2,..., Hn, Dst>, given | Given 2 hosts Ha and Hb of the path <Src, H1, H2,..., Hn, Dst>, given | |||

a flow of packets of Type-P sent from Src to Dst at the times T1, | a flow of packets of Type-P sent from Src to Dst at the times T1, | |||

T2... Tn. At each of these times, we obtain a Type-P-Spatial-One- | T2... Tn. At each of these times, we obtain a Type-P-Spatial-One- | |||

way-Delay-Vector <T1,dT1.1, dT1.2,..., dT1.n,dT1>. We define the | way-Delay-Vector <T1,dT1.a, ..., dT1.b,...,, dT1.n,dT1>. We define | |||

value of the sample Type-P-subpath-One-way-Delay-Stream as the | the value of the sample Type-P-segment-One-way-Delay-Stream as the | |||

sequence made up of the couples <Tk,dTk.b - dTk.a>. dTk.a is the | sequence made up of the delays dTk.b - dTk.a. dTk.a is the delay | |||

delay between Src and Ha. dTk.b is the delay between Src and Hb. | between Src and Ha. dTk.b is the delay between Src and Hb. 'dTk.b - | |||

'dTk.b - dTk.a' is the one-way delay experienced by the packet sent | dTk.a' is the one-way delay experienced by the packet sent by Src at | |||

at the time Tk by Src when going from Ha to Hb. | the time Tk when going from Ha to Hb. | |||

4.2.5. Discussion | 5.1.5. Discussion | |||

Following are specific issues which may occur: | Following are specific issues which may occur: | |||

o When a is Src <Tk,dTk.b - dTk.a> is the measure of the first hop. | o When a is Src <Tk,dTk.b - dTk.a> is the measure of the first hop. | |||

o When b is Dst <Tk,dTk.b - dTk.a> is the measure of the last hop. | o When b is Dst <Tk,dTk.b - dTk.a> is the measure of the last hop. | |||

o the delay looks to decrease: dTi > DTi+1: | o the delay looks to decrease: dTi > DTi+1: | |||

* This is typically du to clock synchronisation issue. this point | * This is typically du to clock synchronisation issue. this point | |||

skipping to change at page 15, line 40 | skipping to change at page 21, line 40 | |||

o dTk.b may be observed and not dTk.a. | o dTk.b may be observed and not dTk.a. | |||

o Tk is unknown if the flow is made of end user packets, that is | o Tk is unknown if the flow is made of end user packets, that is | |||

pure passive measure. In this case Tk may be forced to Tk+dTk.a. | pure passive measure. In this case Tk may be forced to Tk+dTk.a. | |||

This motivate separate metrics names for pure passive measurement | This motivate separate metrics names for pure passive measurement | |||

or specific reporting information. | or specific reporting information. | |||

o Pure passive measure should consider packets of the same size and | o Pure passive measure should consider packets of the same size and | |||

of the same Type-P. | of the same Type-P. | |||

4.2.6. Interference with other packet | 5.2. A Definition of a sample of Packet Loss of a segment of the path | |||

4.2.7. loss threshold | ||||

To determine if a dTi is defined or undefined it is necessary to | ||||

define a period of time after which a packet is considered loss. | ||||

4.2.8. Methodologies | ||||

Both active and passive method should discussed. | ||||

4.2.9. Reporting the metric | ||||

Section 3.6 of [RFC2679] indicates the items to report. | ||||

4.2.10. Path | ||||

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

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

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

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

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

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

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

Spatial packet loss measurement SHOULD be respectful of them, | ||||

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

reporting. | ||||

Following we define the spatial metric, then we adapt some of the | This metric defines a sample of Packet lost between a pair of hosts | |||

points above and introduce points specific to spatial measurement. | of a path. | |||

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

Type-P-Spatial-One-way-Packet-Loss-Vector | Type-P-segment-Packet-loss-Stream | |||

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

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

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

+ i, An integer which ordered the hosts in the path. | ||||

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

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

a measured packet. | ||||

+ dT1,..., dTn, dT, a list of delay. | ||||

+ P*, the specification of the packet type. | + P*, the specification of the packet type. | |||

+ <Src, H1, H2,..., Hn, Dst>, a path digest. | + k, An integer which orders the packets sent. | |||

+ B1, B2, ..., Bi, ..., Bn, a list of Boolean values. | ||||

4.3.3. Metric Units | + n, An integer which orders the hosts on the path. | |||

A sequence of Boolean values. | + <H1, H2,..., Hn>, hosts path digest. | |||

4.3.4. Definition | + Ha, a host of the path digest different from Dst and Hb; | |||

Given a Type-P packet sent by the sender Src at time T to the | + Hb, a host of the path digest different from Src and Ha. | |||

receiver Dst in the path <H1, H2, ..., Hn>. Given the sequence of | Hb order in the path must greater that Ha; | |||

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

Dst>, | ||||

Type-P-One-way-Packet-Lost-Vector metric is defined as the sequence | + Hi, exchange points of the path digest. | |||

of values <B1, B2, ..., Bn> such that for each Hi of the path, a | ||||

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

means that dTi is undefined. | ||||

4.3.5. Discussion | + <B1, B2, ..., Bn> a list of bits. | |||

Following are specific issues which may occur: | + <L1, L2, ..., Ln> a list of integers. | |||

o the result includes the sequence 1,0. This case means that the | 5.2.3. Metric Units | |||

packet was seen by a host but not by it successor on the path; | ||||

o | A sequence of integers <L1, L2,..., Lk> | |||

The location of the meter in the device influences the result: | 5.2.4. Definition | |||

o Even if the packet is received by a device, it may be not observed | Given 2 hosts Ha and Hb of the path <Src, H1, H2,..., Hn, Dst>, given | |||

by a meter located after a buffer; | a flow of packets of Type-P sent from Src to Dst at the times T1, | |||

T2... Tn. At each of these times, we obtain a Type-P-Spatial- | ||||

Packet-Lost-Vector <B1.1, B1.2,..., B1.n>. We define the value of | ||||

the sample Type-P-segment-Packet-Lost-Stream between Ha and Hb as the | ||||

sequence made up of the integer <L1, L2,..., Lk> such that for each | ||||

Tk: | ||||

4.3.6. Reporting | o a value of Lk of 0 means that Bk.a has a value of 0 (observed) and | |||

that Bk.b have a value of 0 (observed); | ||||

Section in progress. | o a value of Lk of 1 means that Bk.a has a value of 0 (observed) and | |||

that Bk.b have a value of 1 (not observed); | ||||

4.4. A Definition for Spatial One-way Jitter Vector | o a value of Lk of 2 means that Bk.a has a value of 1 (not observed) | |||

and that Bk.b have a value of 0 (observed); | ||||

o a value of Lk of 3 means that Bk.a has a value of 1 (not observed) | ||||

and that Bk.b have a value of 1 (not observed). | ||||

This section uses parameters from the definition of Type-P-One-way- | 5.2.5. Discussion | |||

ipdv. When a parameter from section 2 of [RFC3393] is first used in | ||||

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

Sections 3.5 to 3.7 of [RFC3393] give requirements and applicability | The semantic of a Type-P-segment-Packet-loss-Stream is similar to the | |||

statements for end-to-end one-way-ipdv measurements. They are | one of Type-P-Packet-loss-Stream: | |||

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

Spatial one-way-ipdv measurement SHOULD be respectful of them, | ||||

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

reporting. | ||||

Following we adapt some of them and introduce points specific to | o a value of 0 means that the packet was observed by Ha (similar to | |||

spatial measurement. | 'send by Src') and not observed by Hb ( similar to 'not received | |||

by Dst'); | ||||

4.4.1. Metric Name | o a value of 1 means that it was observed by Ha (similar to 'send by | |||

Src') and observed by Hb ( similar to 'received by Dst'). | ||||

Type-P-Spatial-One-way-Jitter-Vector | This definition of Type-P-segment-Packet-loss-Stream is similar to | |||

the Type-P-Packet-loss-Stream defined in [RFC2680] excepted that in a | ||||

Type-P-segment-Packet-loss-Stream the rules of the point of interests | ||||

Ha and Hb are symetrical: The asumption that a set of packets are | ||||

going from Ha to Hb does not apply to Type-P-segment-Packet-loss- | ||||

Stream because as the host path digest is dynamic each packet has its | ||||

own host path digest. | ||||

4.4.2. Metric Parameters | Making the asumption that the host path digest of a Type-P-spatial- | |||

Packet-loss-vector does not change and that the set of (Hk, Hk+1) | ||||

tuples is mostly stable over time lead to unusable results and to the | ||||

introduction of mistakes in the metrics aggregation processes. The | ||||

right approach consists in carefully scrutening the path ordering | ||||

information to build sample with elements of vectors sharing the same | ||||

properties in term of Ha and Hb and 'Ha to Hb'. So a measure of | ||||

Type-P-spatial-Packet-loss-vector differs from a Type-P-Packet-loss | ||||

one in that it produces different samples of packet loss over time. | ||||

+ Src*, the IP address of the sender. | The semantic of a Type-P-segment-Packet-loss-Stream defines 2 new | |||

results: | ||||

+ Dst*, the IP address of the receiver. | o A value of Lk of 2 (1,0) corresponds to a mistake in the ordering | |||

of Ha and Hb over the path coming either from the configuration | ||||

(asumption on the path) or from the processing of the vectors: bad | ||||

scrutening of the path ordering information, or some other mistake | ||||

in the measure or the reporting. It is not in the scope of this | ||||

document to go in further details which are mostly implementation | ||||

dependent. This value MUST not be used to compute packet lost | ||||

statistics. | ||||

+ i, An integer which ordered the hosts in the path. | o A value of Lk of 3 (1,1) corresponds to a lost of the packet in | |||

upper segment of the path. | ||||

+ Hi, exchange points of the path digest. | 5.3. A Definition of a sample of One-way Ipdv of a segment of the path | |||

+ T1*, the time the first packet was sent. | This metric defines a sample of ipdv between a pair of hosts of a | |||

path. | ||||

+ T2*, the time the second packet was sent. | Editor note: work in progress | |||

+ P, the specification of the packet type. | 5.3.1. Metric Name | |||

+ P1, the first packet sent at time T1. | Type-P-Segment-Ipdv-Stream | |||

+ P2, the second packet sent at time T2. | 5.3.2. Metric Parameters | |||

+ <Src, H1, H2,..., Hn, Dst>, a path digest. | 5.3.3. Metric Units | |||

+ <T1,dT1.1, dT1.2,..., dT1.n,dT1>, | 5.3.4. Definition | |||

the Type-P-Spatial-One-way-Delay-Vector for packet sent at | ||||

time T1; | ||||

+ <T2,dT2.1, dT2.2,..., dT2.n,dT2>, | 5.3.5. Discussion | |||

the Type-P-Spatial-One-way-Delay-Vector for packet sent at | ||||

time T2; | ||||

+ L*, a packet length in bits. The packets of a Type P | 5.4. Discussion on Passive Segment Metrics | |||

packet stream from which the | ||||

Type-P-Spatial-One-way-Delay-Vector metric is taken MUST | ||||

all be of the same length. | ||||

4.4.3. Metric Units | A pure passive spatial measure is the measure of a spatial metric | |||

based on the observation of user traffic instead of packets dedicated | ||||

to the measure. | ||||

A sequence of times. | This section discusses the applicability of pure passive measurement | |||

methodology (e.g. without injecting test traffic as described by | ||||

PSAMP documents [draft-ietf-psamp-sample-tech-10.txt]) to measure | ||||

spatial metrics. | ||||

4.4.4. Definition | To permit comparison and discussion, we firstly define pure passive | |||

measurement methodology following the spirit of IPPM framework | ||||

[RFC2330] and the methodology of [RFC2679]. Then we propose several | ||||

passive metrics complying to this framework. | ||||

Given the Type-P packet having the size L and sent by the sender Src | 5.4.1. A methodololy for passive segment metrics | |||

at wire-time (first bit) T1 to the receiver Dst in the path <H1, | ||||

H2,..., Hn>. | ||||

Given the Type-P packet having the size L and sent by the sender Src | The following starts from the point that the time a packet is sent is | |||

at wire-time (first bit) T2 to the receiver Dst in the same path. | not needed to measure the delay from one host Ha of the path to | |||

another host Hb. | ||||

Given the Type-P-Spatial-One-way-Delay-Vector <T1,dT1.1, dT1.2,..., | Generally, for the packets of Type-P and length L sent a time <T1, | |||

dT1,n,dT1> of the packet P1. | T2,..., Tn> by the source Src pure passive methodology might proceed | |||

as follows: | ||||

Given the Type-P-Spatial-One-way-Delay-Vector <T2,dT2.1, dT2.2,..., | o Each point of interest Ha and Hb prepares to capture these | |||

dT2,n,dT2> of the packet P2. | packets; | |||

o Each point of interest Ha and Hb takes a timestamp Ti', determines | ||||

the internal delay correction dTi' (See section 3.7.1. "Errors or | ||||

uncertainties related to Clocks" of [RFC2679]), | ||||

Type-P-Spatial-One-way-Jitter-Vector metric is defined as the | o Each points of interest Ha and Hb extracts the path ordering | |||

sequence of values <T2-T1,dT2.1-dT1.1,dT2.2-dT1.2,...,dT2.n- | information from the packet (e.g. time-to-live) | |||

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

dT2.i-dT1.i is either a real number if the packets P1 and P2 passes | ||||

Hi at wire-time (last bit) dT1.i, respectively dT2.i, or undefined if | ||||

at least one of them never passes Hi. T2-T1 is the inter-packet | ||||

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

T1,T2*. | ||||

4.4.5. Sections in progress | o Each points of interest Ha and Hb computes the wiretime fSrom Src | |||

to Hi: Ti = Ti' - dTi'. ; | ||||

See sections 3.5 to 3.7 of [RFC3393]. | o The reference point gathers individual information for the packets | |||

sent a time <T1, T2,..., Tn> from each point of interest Ha and Hb | ||||

and proceeds as follow: | ||||

4.5. Pure Passive Metrics | * Orders them according to the path ordering information; | |||

Spatial metrics may be measured without injecting test traffic. | * Extracts the timestamps Ti.a and Ti+1.b. This arrival time is | |||

undefined (infinite) if the packet is not detected; | ||||

4.5.1. Discussion on Passive measurement | * Computes the one-way-delay from Ha to Hb as (Ti+1.b - Ti.a). | |||

The delay is undefined (infinite) if the packet is not detected | ||||

in Ha or Hb; | ||||

One might says that most of the operational issues occur in the last | o The reference point builds the segment sample <T1.b - T1.a, T2.b - | |||

mile and that consequently such measure are less useful than active | T2.a,..., Tn.b - Tn.a> from Ha to Hb; | |||

measurement. Nevertheless they are usable for network TE and | ||||

interdomain QoS monitoring, and composition of metric. | ||||

Such a technique have some limitations that are discussed below. | 5.4.2. Discussion on passive methodololy | |||

4.5.1.1. Passive One way delay | Intrinsically passive methodololy does not known (neither in the | |||

points of interest nor in the point of reference) the time each | ||||

packet is sent <T1, T2,..., Tn> and the time each packet it received. | ||||

As the packet is not a test packet, it does not include the time it | Section 5.4.1 shows that a passive segment one-way delay measure does | |||

was sent. | not rely on the time T the packet is sent to compute the delay from a | |||

host Ha to a host Hb. | ||||

Consequently a point of interest Hi ignores the time the packet was | Intuitively, packets loss measurement does not require any time | |||

send. So It is not possible to measure the delay between Src and Hi | information and only expects the packet was sent. Passive packet | |||

in the same manner it is not possible to measure the delay betwwen Hi | loss methodology relies on the detection of the packet by one point | |||

and Dst. | of interest and not by another. This relies on asumptions similar to | |||

spatial methodology: | ||||

4.5.1.2. Passive Packet loss | o The knowledge of the path and the order of the points of interest | |||

over the path; | ||||

The packet is not a test packet, so it does not include a sequence | o The packet is observed by one point of interest and not by | |||

number. | another; | |||

Nevertheless, passive packet loss measure is limited by the fact that | ||||

information that neither a packet has be sent nor that the packet was | ||||

received is never available: | ||||

Packet lost measurement doe not require time synchronization and | when the path changes and the packet is not observed it is not | |||

require only one point of observation. Nevertheless it requires the | deterministic to state that the packet is lost because the measure | |||

point of interest Hi to be expecting the packet. Practically Hi may | does not known that the packet is received by Dst. | |||

not detect a lost of packet that occurs between Src and Hi. | ||||

A point of interest Hi ignores the time the packet is send because | when the measure does not observe any packets it is not possible | |||

the packet does not carry the time it was injected in the network. | to state that all packets are lost because the measure does not | |||

So a probe Hi can not compute dTi. | known that any packets were sent. | |||

An alternative to these issues consist in considering sample spatial | The drawback is that monitoring finely these events is crucial for | |||

One-way delay that T is the time when H1 (the first passive probe of | troubleshooting workflow. | |||

the path) observed the packet. | ||||

4.5.2. Reporting and composition | IPPM framework relies on the mesure of the behavior of packets of the | |||

same size. Consequently a passive metric sample MUST not mix | ||||

information of packets of different sizes. | ||||

To avoid misunderstanding and to address specific reporting | Segment metrics may be measured using pure passive technics. Passive | |||

constraint a proposal consists in defining distinct metrics for pure | segment metrics definitions are very closed to spatial segment | |||

passive measurement based on the definition above. | metrics definitions. Therefore below we just name passive segment | |||

metrics to distinguish the methodology used. Having distinct metrics | ||||

identifiers for spatial metrics and passive spatial metrics in the | ||||

[RFC4148] will avoid interoperability issues especially during | ||||

composition of metrics the IPPM WG is currently defining. | ||||

It is crucial to know the methodologies used because of the | 5.4.3. Passive Segment metrics | |||

difference of method of detection (expecting Seq++); because of the | ||||

difference of source of time (H1 vs Src) and because of the | ||||

difference of behaviour of the source (Poisson/unknown). | ||||

4.5.3. naming and registry | 5.4.3.1. Passive Segment One way Delay metric | |||

Having distinct metrics identifiers for spatial metrics and passive | This metric definition is based on the top of the Type-P-spatial- | |||

spatial metrics in the [RFC4148] will avoid interoperability issues | segment-One-way-Delay-Stream metric definition. | |||

especially during composition of metrics. | ||||

4.5.4. Passive One way delay metrics | name: Type-P-Passive-Segment-One-way-Delay-Stream | |||

4.5.5. Passive One way PacketLoss metrics | 5.4.3.2. Passive Segment Packet Loss metric | |||

4.5.6. Passive One way jitter metrics | This metric definition is based on the top of the Type-P-spatial- | |||

segment-Packet-Loss-Stream metric definition. | ||||

4.6. Discussion on spatial statistics | name: Type-P-Passive-Segment-Packet-Loss-Stream | |||

Do we define min, max, avg of spatial metrics ? | 5.4.3.3. Passive Segment One-way Ipdv metric | |||

having the maximum loss metric value could be interesting. Say, | This metric definition is based on the top of the Type-P-Segment- | |||

the segment between router A and B always contributes loss metric | Ipdv-Stream metric definition. | |||

value of "1" means it could be the potential problem segment. | ||||

Uploading dTi of each Hi consume a lot of bandwidth. Computing | name: Type-P-Passive-Segment-One-way-Ipdv-Stream | |||

statistics (min, max and avg) of dTi locally in each Hi reduce the | ||||

bandwidth consumption. | ||||

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

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

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

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

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

o Src, the IP address of a host acting as the source. | o Src, the IP address of a host acting as the source. | |||

o Recv1,..., RecvN, the IP addresses of the N hosts acting as | o Recv1,..., RecvN, the IP addresses of the N hosts acting as | |||

receivers. | receivers. | |||

o T, a time. | o T, a time. | |||

o dT1,...,dTn a list of time. | o dT1,...,dTn a list of time. | |||

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

o Gr, the multicast group address (optional). The parameter Gr is | o Gr, the multicast group address (optional). The parameter Gr is | |||

the multicast group address if the measured packets are | the multicast group address if the measured packets are | |||

transmitted by multicast. This parameter is to identify the | transmitted by multicast. This parameter is to identify the | |||

measured traffic from other unicast and multicast traffic. It is | measured traffic from other unicast and multicast traffic. It is | |||

set to be optional in the metric to avoid losing any generality, | set to be optional in the metric to avoid losing any generality, | |||

i.e. to make the metric also applicable to unicast measurement | i.e. to make the metric also applicable to unicast measurement | |||

where there is only one receivers. | where there is only one receivers. | |||

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

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

singletons metrics Type-P-One-way-Delay [RFC2679]. | singletons metrics Type-P-One-way-Delay [RFC2679]. | |||

5.1.4. Definition | 6.1.4. Definition | |||

Given a Type P packet sent by the source Src at Time T, given the N | Given a Type P packet sent by the source Src at Time T, given the N | |||

hosts { Recv1,...,RecvN } which receive the packet at the time { | hosts { Recv1,...,RecvN } which receive the packet at the time { | |||

T+dT1,...,T+dTn }, a Type-P-one-to-group-One-way-Delay-Vector is | T+dT1,...,T+dTn }, a Type-P-one-to-group-One-way-Delay-Vector is | |||

defined as the set of the Type-P-One-way-Delay singleton between Src | defined as the set of the Type-P-One-way-Delay singleton between Src | |||

and each receiver with value of { dT1, dT2,...,dTn }. | and each receiver with value of { dT1, dT2,...,dTn }. | |||

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

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

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

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

o Src, the IP address of a host acting as the source. | o Src, the IP address of a host acting as the source. | |||

o Recv1,..., RecvN, the IP addresses of the N hosts acting as | o Recv1,..., RecvN, the IP addresses of the N hosts acting as | |||

receivers. | receivers. | |||

o T, a time. | o T, a time. | |||

o T1,...,Tn a list of time. | o T1,...,Tn a list of time. | |||

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

o Gr, the multicast group address (optional). | o Gr, the multicast group address (optional). | |||

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

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

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

5.2.4. Definition | 6.2.4. Definition | |||

Given a Type P packet sent by the source Src at T and the N hosts, | Given a Type P packet sent by the source Src at T and the N hosts, | |||

Recv1,...,RecvN, which should receive the packet at T1,...,Tn, a | Recv1,...,RecvN, which should receive the packet at T1,...,Tn, a | |||

Type-P-one-to-group-One-way-Packet-Loss-Vector is defined as a set of | Type-P-one-to-group-One-way-Packet-Loss-Vector is defined as a set of | |||

the Type-P-One-way-Packet-Loss singleton between Src and each of the | the Type-P-One-way-Packet-Loss singleton between Src and each of the | |||

receivers {<T1,0|1>,<T2,0|1>,..., <Tn,0|1>}. | receivers {<T1,0|1>,<T2,0|1>,..., <Tn,0|1>}. | |||

5.3. A Definition for one-to-group One-way Jitter | 6.3. A Definition for one-to-group One-way Ipdv | |||

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

Type-P-one-to-group-One-way-Jitter-Vector | Type-P-One-to-group-One-way-ipdv-Vector | |||

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

+ Src, the IP address of a host acting as the source. | + Src, the IP address of a host acting as the source. | |||

+ Recv1,..., RecvN, the IP addresses of the N hosts acting as | + Recv1,..., RecvN, the IP addresses of the N hosts acting as | |||

receivers. | receivers. | |||

+ T1, a time. | + T1, a time. | |||

+ T2, a time. | + T2, a time. | |||

+ ddT1,...,ddTn, a list of time. | + ddT1,...,ddTn, a list of time. | |||

+ P, the specification of the packet type. | + P, the specification of the packet type. | |||

+ F, a selection function defining unambiguously the two | + F, a selection function defining unambiguously the two | |||

packets from the stream selected for the metric. | packets from the stream selected for the metric. | |||

+ Gr, the multicast group address (optional) | + Gr, the multicast group address (optional) | |||

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

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

singletons metrics Type-P-One-way-ipdv [RFC3393]. | singletons metrics Type-P-One-way-ipdv [RFC3393]. | |||

5.3.4. Definition | 6.3.4. Definition | |||

Given a Type P packet stream, Type-P-one-to-group-One-way-Jitter- | Given a Type P packet stream, Type-P-one-to-group-One-way-ipdv-Vector | |||

Vector is defined for two packets from the source Src to the N hosts | is defined for two packets from the source Src to the N hosts | |||

{Recv1,...,RecvN },which are selected by the selection function F, as | {Recv1,...,RecvN },which are selected by the selection function F, as | |||

the difference between the value of the Type-P-one-to-group-One-way- | the difference between the value of the Type-P-one-to-group-One-way- | |||

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

value of the Type-P-one-to-group- One-way-Delay-Vector from Src to { | value of the Type-P-one-to-group- One-way-Delay-Vector from Src to { | |||

Recv1,...,RecvN } at time T2. T1 is the wire-time at which Src sent | Recv1,...,RecvN } at time T2. T1 is the wire-time at which Src sent | |||

the first bit of the first packet, and T2 is the wire-time at which | the first bit of the first packet, and T2 is the wire-time at which | |||

Src sent the first bit of the second packet. This metric is derived | Src sent the first bit of the second packet. This metric is derived | |||

from the Type-P-one-to- group-One-way-Delay-Vector metric. | from the Type-P-one-to- group-One-way-Delay-Vector metric. | |||

Therefore, for a set of real number {ddT1,...,ddTn},Type-P-one- to- | Therefore, for a set of real number {ddT1,...,ddTn},Type-P-one- to- | |||

group-One-way-Jitter-Vector from Src to { Recv1,...,RecvN } at T1, T2 | group-One-way-ipdv-Vector from Src to { Recv1,...,RecvN } at T1, T2 | |||

is {ddT1,...,ddTn} means that Src sent two packets, the first at | is {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) | wire-time T1 (first bit), and the second at wire-time T2 (first bit) | |||

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

{dT1+T1,...,dTn+T1}(last bit of the first packet), and at wire-time | {dT1+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}. | {dT'1-dT1,...,dT'n-dTn} ={ddT1,...,ddTn}. | |||

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

The defined one-to-group metrics above can all be directly achieved | The defined one-to-group metrics above can all be directly achieved | |||

from the relevant unicast one-way metrics. They managed to collect | from the relevant unicast one-way metrics. They managed to collect | |||

all unicast measurement results of one-way metrics together in one | all unicast measurement results of one-way metrics together in one | |||

profile and sort them by receivers and packets in a multicast group. | profile and sort them by receivers and packets in a multicast group. | |||

They can provide sufficient information regarding the network | They can provide sufficient information regarding the network | |||

performance in terms of each receiver and guide engineers to identify | performance in terms of each receiver and guide engineers to identify | |||

potential problem happened on each branch of a multicast routing | potential problem happened on each branch of a multicast routing | |||

tree. However, these metrics can not be directly used to | tree. However, these metrics can not be directly used to | |||

conveniently present the performance in terms of a group and neither | conveniently present the performance in terms of a group and neither | |||

skipping to change at page 24, line 40 | skipping to change at page 30, line 40 | |||

metrics to define exactly how small the relative delay the online | metrics to define exactly how small the relative delay the online | |||

gaming requires. There are many other services, e.g. online biding, | gaming requires. 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 FRCs. 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 7. For a Matrix M each row is a set of One-way | illustrated in Figure 9. For a Matrix M each row is a set of One-way | |||

singletons spreading over the time dimension and each column is | 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 ... R3dTk \ | 1 | / R1dT1 R1dT2 R1dT3 ... R3dTk \ | |||

| | | | | | | | |||

2 | | R2dT1 R2dT2 R2dT3 ... R3dTk | | 2 | | R2dT1 R2dT2 R2dT3 ... R3dTk | | |||

| | | | | | | | |||

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 7: Matrix M (n*m) | Figure 9: 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 contains the One-way delays of the same packet | is a delay vector contains the One-way delays of the same packet | |||

observed at M points of interest. It implies the geographical factor | observed at M 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. | |||

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

skipping to change at page 26, line 38 | skipping to change at page 32, line 38 | |||

Many statistics can be defined for the proposed one-to-group metrics | Many statistics can be defined for the proposed one-to-group metrics | |||

over either the space dimension or the time dimension or both. This | over either the space dimension or the time dimension or both. This | |||

memo treats the case where a stream of packets from the Source | memo treats the case where a stream of packets from the Source | |||

results in a sample at each of the Receivers in the Group, and these | results in a sample at each of the Receivers in the Group, and these | |||

samples are each summarized with the usual statistics employed in | samples are each summarized with the usual statistics employed in | |||

one-to-one communication. New statistic definitions are presented, | one-to-one communication. New statistic definitions are presented, | |||

which summarize the one-to-one statistics over all the Receivers in | which summarize the one-to-one statistics over all the Receivers in | |||

the Group. | the Group. | |||

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

The packet loss does have effects on one-way metrics and their | The packet loss does have effects on one-way metrics and their | |||

statistics. For example, the lost packet can result an infinite one- | statistics. For example, the lost packet can result an infinite one- | |||

way delay. It is easy to handle the problem by simply ignoring the | way delay. It is easy to handle the problem by simply ignoring the | |||

infinite value in the metrics and in the calculation of the | infinite value in the metrics and in the calculation of the | |||

corresponding statistics. However, the packet loss has so strong | corresponding statistics. However, the packet loss has so strong | |||

impact on the statistics calculation for the one-to-group metrics | impact on the statistics calculation for the one-to-group metrics | |||

that it can not be solved by the same method used for one-way | that it can not be solved by the same method used for one-way | |||

metrics. This is due to the complex of building a Matrix, which is | metrics. This is due to the complex of building a Matrix, which is | |||

needed for calculation of the statistics proposed in this memo. | needed for calculation of the statistics proposed in this memo. | |||

skipping to change at page 27, line 27 | skipping to change at page 33, line 27 | |||

R1dT1 R1dT2 R1dT3 ... R1dTK-1 UNDEF R1dTK+1... R1DM } where "UNDEF" | R1dT1 R1dT2 R1dT3 ... R1dTK-1 UNDEF R1dTK+1... R1DM } where "UNDEF" | |||

is an undefined value, the reference point can replace it by R1dTK = | is an undefined value, the reference point can replace it by R1dTK = | |||

{(R1dTK-1)+( R1dTK+1)}/2. Therefore, this result can be used to | {(R1dTK-1)+( R1dTK+1)}/2. Therefore, this result can be used to | |||

build up the group Matrix with an estimated value R1dTK. There are | build up the group Matrix with an estimated value R1dTK. There are | |||

other possible solutions such as using the overall mean of the whole | other possible solutions such as using the overall mean of the whole | |||

result to replace the infinite/undefined value, and so on. It is out | result to replace the infinite/undefined value, and so on. It is out | |||

of the scope of this memo. | of the scope of this memo. | |||

For the distributed calculation, the reported statistics might have | For the distributed calculation, the reported statistics might have | |||

different "weight" to present the group performance, which is | different "weight" to present the group performance, which is | |||

especially true for delay and jitter relevant metrics. For example, | especially true for delay and ipdv relevant metrics. For example, | |||

User1 calculates the Type-P-Finite-One-way-Delay-Mean R1DM as shown | User1 calculates the Type-P-Finite-One-way-Delay-Mean R1DM as shown | |||

in Figure. 8 without any packet loss and User2 calculates the R2DM | in Figure. 8 without any packet loss and User2 calculates the R2DM | |||

with N-2 packet loss. The R1DM and R2DM should not be treated with | with N-2 packet loss. The R1DM and R2DM should not be treated with | |||

equal weight because R2DM was calculated only based on 2 delay values | equal weight because R2DM was calculated only based on 2 delay values | |||

in the whole sample interval. One possible solution is to use a | in the whole sample interval. One possible solution is to use a | |||

weight factor to mark every statistic value sent by users and use | weight factor to mark every statistic value sent by users and use | |||

this factor for further statistic calculation. | this factor for further statistic calculation. | |||

6.2. General Metric Parameters | 7.2. General Metric Parameters | |||

o Src, the IP address of a host | o Src, the IP address of a host | |||

o G, the Group IP address | o G, the Group IP address | |||

o N, the number of Receivers (Recv1, Recv2, ... RecvN) | o N, the number of Receivers (Recv1, Recv2, ... RecvN) | |||

o T, a time (start of test interval) | o T, a time (start of test interval) | |||

o Tf, a time (end of test interval) | o Tf, a time (end of test interval) | |||

skipping to change at page 28, line 37 | skipping to change at page 34, line 37 | |||

o dT, shorthand notation for a one-way delay singleton value | o dT, shorthand notation for a one-way delay singleton value | |||

o L, shorthand notation for a one-way loss singleton value, either | o L, shorthand notation for a one-way loss singleton value, either | |||

zero or one, where L=1 indicates loss and L=0 indicates arrival at | zero or one, where L=1 indicates loss and L=0 indicates arrival at | |||

the destination within TstampSrc + Tmax, may be indexed over n | the destination within TstampSrc + Tmax, may be indexed over n | |||

Receivers | Receivers | |||

o DV, shorthand notation for a one-way delay variation singleton | o DV, shorthand notation for a one-way delay variation singleton | |||

value | value | |||

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

This section defines the overall one-way delay statistics for an | This section defines the overall one-way delay statistics for an | |||

entire Group or receivers. For example, we can define the group mean | entire Group or receivers. For example, we can define the group mean | |||

delay, as illustrated below. This is a metric designed to summarize | delay, as illustrated below. This is a metric designed to summarize | |||

the entire Matrix. | the whole matrix. | |||

Recv /----------- Sample -------------\ Stats Group Stat | Recv /----------- Sample -------------\ Stats Group Stat | |||

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

| | | | |||

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

| | | | |||

3 R3dT1 R3dT2 R3dT3 ... R3dTk R2DM > GMD | 3 R3dT1 R3dT2 R3dT3 ... R3dTk R2DM > GMD | |||

. | | . | | |||

. | | . | | |||

. | | . | | |||

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

Figure 8: One-to-GroupGroup Mean Delay | Figure 10: One-to-GroupGroup Mean Delay | |||

where: | where: | |||

R1dT1 is the Type-P-Finite-One-way-Delay singleton evaluated at | R1dT1 is the Type-P-Finite-One-way-Delay singleton evaluated at | |||

Receiver 1 for packet 1. | Receiver 1 for packet 1. | |||

R1DM is the Type-P-Finite-One-way-Delay-Mean evaluated at Receiver 1 | R1DM is the Type-P-Finite-One-way-Delay-Mean evaluated at Receiver 1 | |||

for the sample of packets (1,...K). | for the sample of packets (1,...K). | |||

GMD is the mean of the sample means over all Receivers (1, ...N). | GMD is the mean of the sample means over all Receivers (1, ...N). | |||

6.3.1. Definition and Metric Units | 7.3.1. Definition and Metric Units | |||

Using the parameters above, we obtain the value of Type-P-One-way- | Using the parameters above, we obtain the value of Type-P-One-way- | |||

Delay singleton for all packets sent during the test interval at each | Delay singleton for all packets sent during the test interval at each | |||

Receiver (Destination), as per [RFC2679]. For each packet that | Receiver (Destination), as per [RFC2679]. For each packet that | |||

arrives within Tmax of its sending time, TstampSrc, the one-way delay | arrives within Tmax of its sending time, TstampSrc, the one-way delay | |||

singleton (dT) will be a finite value in units of seconds. | singleton (dT) will be a finite value in units of seconds. | |||

Otherwise, the value of the singleton is Undefined. | Otherwise, the value of the singleton is Undefined. | |||

For each packet [i] that has a finite One-way Delay at Receiver n (in | For each packet [i] that has a finite One-way Delay at Receiver n (in | |||

other words, excluding packets which have undefined one-way delay): | other words, excluding packets which have undefined one-way delay): | |||

Type-P-Finite-One-way-Delay-Receiver-n-[i] = | Type-P-Finite-One-way-Delay-Receiver-n-[i] = | |||

= TstampRecv[i] - TstampSrc[i] | = TstampRecv[i] - TstampSrc[i] | |||

The units of Finite one-way delay are seconds, with sufficient | The units of Finite one-way delay are seconds, with sufficient | |||

resolution to convey 3 significant digits. | resolution to convey 3 significant digits. | |||

6.3.2. Sample Mean Statistic | 7.3.2. Sample Mean Statistic | |||

This section defines the Sample Mean at each of N Receivers. | This section defines the Sample Mean at each of N Receivers. | |||

Type-P-Finite-One-way-Delay-Mean-Receiver-n = RnDM = | Type-P-Finite-One-way-Delay-Mean-Receiver-n = RnDM = | |||

J[n] | J[n] | |||

--- | --- | |||

1 \ | 1 \ | |||

--- * > Type-P-Finite-One-way-Delay-Receiver-n-[i] | --- * > Type-P-Finite-One-way-Delay-Receiver-n-[i] | |||

J[n] / | J[n] / | |||

--- | --- | |||

i = 1 | i = 1 | |||

Figure 9: Type-P-Finite-One-way-Delay-Mean-Receiver-n | Figure 11: Type-P-Finite-One-way-Delay-Mean-Receiver-n | |||

where all packets i= 1 through J[n] have finite singleton delays. | where all packets i= 1 through J[n] have finite singleton delays. | |||

6.3.3. One-to-Group Mean Delay Statistic | 7.3.3. One-to-Group Mean Delay Statistic | |||

This section defines the Mean One-way Delay calculated over the | This section defines the Mean One-way Delay calculated over the | |||

entire Group (or Matrix). | entire Group (or Matrix). | |||

Type-P-One-to-Group-Mean-Delay = GMD = | Type-P-One-to-Group-Mean-Delay = GMD = | |||

N | N | |||

--- | --- | |||

1 \ | 1 \ | |||

- * > RnDM | - * > RnDM | |||

N / | N / | |||

--- | --- | |||

n = 1 | n = 1 | |||

Figure 10: Type-P-One-to-Group-Mean-Delay | Figure 12: 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. | |||

6.3.4. One-to-Group Range of Mean Delays | 7.3.4. One-to-Group Range of Mean Delays | |||

This section defines a metric for the range of mean delays over all N | This section defines a metric for the range of mean delays over all N | |||

receivers in the Group, (R1DM, R2DM,...RnDM). | receivers in the Group, (R1DM, R2DM,...RnDM). | |||

Type-P-One-to-Group-Range-Mean-Delay = GRMD = max(RnDM) - min(RnDM) | Type-P-One-to-Group-Range-Mean-Delay = GRMD = max(RnDM) - min(RnDM) | |||

6.3.5. One-to-Group Maximum of Mean Delays | 7.3.5. One-to-Group Maximum of Mean Delays | |||

This section defines a metrics for the maximum of mean delays over | This section defines a metrics for the maximum of mean delays over | |||

all N receivers in the Group, (R1DM, R2DM,...RnDM). | all N receivers in the Group, (R1DM, R2DM,...RnDM). | |||

Type-P-One-to-Group-Max-Mean-Delay = GMMD = max(RnDM) | Type-P-One-to-Group-Max-Mean-Delay = GMMD = max(RnDM) | |||

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

This section defines the overall 1-way loss statistics for an entire | This section defines the overall 1-way loss statistics for an entire | |||

Group. For example, we can define the group loss ratio, as | Group. For example, we can define the group loss ratio, as | |||

illustrated below. This is a metric designed to summarize the entire | illustrated below. This is a metric designed to summarize the entire | |||

Matrix. | Matrix. | |||

Recv /----------- Sample ----------\ Stats Group Stat | Recv /----------- Sample ----------\ Stats Group Stat | |||

1 R1L1 R1L2 R1L3 ... R1Lk R1LR \ | 1 R1L1 R1L2 R1L3 ... R1Lk R1LR \ | |||

| | | | |||

2 R2L1 R2L2 R2L3 ... R2Lk R2LR | | 2 R2L1 R2L2 R2L3 ... R2Lk R2LR | | |||

| | | | |||

3 R3L1 R3L2 R3L3 ... R3Lk R3LR > GLR | 3 R3L1 R3L2 R3L3 ... R3Lk R3LR > GLR | |||

. | | . | | |||

. | | . | | |||

. | | . | | |||

n RnL1 RnL2 RnL3 ... RnLk RnLR / | n RnL1 RnL2 RnL3 ... RnLk RnLR / | |||

Figure 11: One-to-Group Loss Ratio | Figure 13: One-to-Group Loss Ratio | |||

where: | where: | |||

R1L1 is the Type-P-One-way-Loss singleton (L) evaluated at Receiver 1 | R1L1 is the Type-P-One-way-Loss singleton (L) evaluated at Receiver 1 | |||

for packet 1. | for packet 1. | |||

R1LR is the Type-P-One-way-Loss-Ratio evaluated at Receiver 1 for the | R1LR is the Type-P-One-way-Loss-Ratio evaluated at Receiver 1 for the | |||

sample of packets (1,...K). | sample of packets (1,...K). | |||

GLR is the loss ratio over all Receivers (1, ..., N). | GLR is the loss ratio over all Receivers (1, ..., N). | |||

6.4.1. One-to-Group Loss Ratio | 7.4.1. One-to-Group Loss Ratio | |||

The overall Group loss ratio id defined as | The overall Group loss ratio id defined as | |||

Type-P-One-to-Group-Loss-Ratio = | Type-P-One-to-Group-Loss-Ratio = | |||

K,N | K,N | |||

--- | --- | |||

1 \ | 1 \ | |||

= --- * > L(k,n) | = --- * > L(k,n) | |||

K*N / | K*N / | |||

--- | --- | |||

k,n = 1 | k,n = 1 | |||

Figure 12 | Figure 14 | |||

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

6.4.2. One-to-Group Loss Ratio Range | 7.4.2. One-to-Group Loss Ratio Range | |||

Given a Matrix of loss singletons as illustrated above, determine the | Given a Matrix of loss singletons as illustrated above, determine the | |||

Type-P-One-way-Packet-Loss-Average for the sample at each receiver, | Type-P-One-way-Packet-Loss-Average for the sample at each receiver, | |||

according to the definitions and method of [RFC2680]. The Type-P- | according to the definitions and method of [RFC2680]. The Type-P- | |||

One-way-Packet-Loss-Average, RnLR for receiver n, and the Type-P-One- | One-way-Packet-Loss-Average, RnLR for receiver n, and the Type-P-One- | |||

way-Loss-Ratio illustrated above are equivalent metrics. In terms of | way-Loss-Ratio illustrated above are equivalent metrics. In terms of | |||

the parameters used here, these metrics definitions can be expressed | the parameters used here, these metrics definitions can be expressed | |||

as | as | |||

Type-P-One-way-Loss-Ratio-Receiver-n = RnLR = | Type-P-One-way-Loss-Ratio-Receiver-n = RnLR = | |||

K | K | |||

--- | --- | |||

1 \ | 1 \ | |||

- * > RnLk | - * > RnLk | |||

K / | K / | |||

--- | --- | |||

k = 1 | k = 1 | |||

Figure 13: Type-P-One-way-Loss-Ratio-Receiver-n | Figure 15: Type-P-One-way-Loss-Ratio-Receiver-n | |||

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-Loss-Ratio-Range = max(RnLR) - min(RnLR) | Type-P-One-to-Group-Loss-Ratio-Range = max(RnLR) - min(RnLR) | |||

It is most effective to indicate the range by giving both the max and | It is most effective to indicate the range by giving both the max and | |||

minimum loss ratios for the Group, rather than only reporting the | minimum loss ratios for the Group, rather than only reporting the | |||

difference between them. | difference between them. | |||

6.4.3. Comparative Loss Ratio | 7.4.3. Comparative Loss Ratio | |||

Usually, the number of packets sent is used in the denominator of | Usually, the number of packets sent is used in the denominator of | |||

packet loss ratio metrics. For the comparative metrics defined here, | packet loss ratio metrics. For the comparative metrics defined here, | |||

the denominator is the maximum number of packets received at any | the denominator is the maximum number of packets received at any | |||

receiver for the sample and test interval of interest. | receiver for the sample and test interval of interest. | |||

The Comparative Loss Ratio is defined as | The Comparative Loss Ratio is defined as | |||

Type-P-Comp-Loss-Ratio-Receiver-n = RnCLR = | Type-P-Comp-Loss-Ratio-Receiver-n = RnCLR = | |||

K | K | |||

skipping to change at page 33, line 24 | skipping to change at page 39, line 24 | |||

k=1 | k=1 | |||

= ----------------------------- | = ----------------------------- | |||

/ K \ | / K \ | |||

| --- | | | --- | | |||

| \ | | | \ | | |||

K - Min | > Ln(k) | | K - Min | > Ln(k) | | |||

| / | | | / | | |||

| --- | | | --- | | |||

\ k=1 / N | \ k=1 / N | |||

Figure 14: Type-P-Comp-Loss-Ratio-Receiver-n | Figure 16: Type-P-Comp-Loss-Ratio-Receiver-n | |||

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

There is are two delay variation (DV) statistics to summarize the | There are two delay variation (DV) statistics that summarize the | |||

performance over the Group: the maximum DV over all receivers and the | performance over the Group: the maximum DV over all receivers and the | |||

range of DV over all receivers. | minimum DV over all receivers (where DV is a point-to-point metric). | |||

For each receiver, the DV is usually expressed as the 1-10^(-3) | ||||

The detailed definitions are T0 BE PROVIDED. | quantile of one-way delay minus the minimum one-way delay. | |||

7. Measurement Methods: Scaleability and Reporting | 8. Measurement Methods: Scaleability and Reporting | |||

Virtually all the guidance on measurement processes supplied by the | Virtually all the guidance on measurement processes supplied by the | |||

earlier IPPM RFCs (such as [RFC2679] and [RFC2680]) for one-to-one | earlier IPPM RFCs (such as [RFC2679] and [RFC2680]) for one-to-one | |||

scenarios is applicable here in the spatial and multiparty | scenarios is applicable here in the spatial and multiparty | |||

measurement scenario. The main difference is that the spatial and | measurement scenario. The main difference is that the spatial and | |||

multiparty configurations require multiple measurement points where a | multiparty configurations require multiple measurement points where a | |||

stream of singletons will be collected. The amount of information | stream of singletons will be collected. The amount of information | |||

requiring storage grows with both the number of metrics and the | requiring storage grows with both the number of metrics and the | |||

number of measurement points, so the scale of the measurement | number of measurement points, so the scale of the measurement | |||

architecture multiplies the number of singleton results that must be | architecture multiplies the number of singleton results that must be | |||

skipping to change at page 34, line 18 | skipping to change at page 40, line 18 | |||

architectures today, where even the individual singletons may not be | architectures today, where even the individual singletons may not be | |||

stored at each measurement point. | stored at each measurement point. | |||

In recognition of the likely need to minimize form of the results for | In recognition of the likely need to minimize form of the results for | |||

storage and communication, the Group metrics above have been | storage and communication, the Group metrics above have been | |||

constructed to allow some computations on a per-Receiver basis. This | constructed to allow some computations on a per-Receiver basis. This | |||

means that each Receiver's statistics would normally have an equal | means that each Receiver's statistics would normally have an equal | |||

weight with all other Receivers in the Group (regardless of the | weight with all other Receivers in the Group (regardless of the | |||

number of packets received). | number of packets received). | |||

7.1. Computation methods | 8.1. Computation methods | |||

The scalability issue can be raised when there are thousands of | The scalability issue can be raised when there are thousands of | |||

points of interest in a group who are trying to send back the | points of interest in a group who are trying to send back the | |||

measurement results to the reference point for further processing and | measurement results to the reference point for further processing and | |||

analysis. The points of interest can send either the whole measured | analysis. The points of interest can send either the whole measured | |||

sample or only the calculated statistics. The former one is a | sample or only the calculated statistics. The former one is a | |||

centralized statistic calculation method and the latter one is a | centralized statistic calculation method and the latter one is a | |||

distributed statistic calculation method. The sample should include | distributed statistic calculation method. The sample should include | |||

all metrics parameters, the values and the corresponding sequence | all metrics parameters, the values and the corresponding sequence | |||

numbers. The transmission of the whole sample can cost much more | numbers. The transmission of the whole sample can cost much more | |||

skipping to change at page 35, line 11 | skipping to change at page 41, line 11 | |||

the reference point first to obtain the general information of the | the reference point first to obtain the general information of the | |||

group performance. If the detail results are required, the reference | group performance. If the detail results are required, the reference | |||

point should send the requests to the points of interest, which could | point should send the requests to the points of interest, which could | |||

be particular ones or the whole group. This procedure can happen in | be particular ones or the whole group. This procedure can happen in | |||

the off peak time and can be well scheduled to avoid delivery of too | the off peak time and can be well scheduled to avoid delivery of too | |||

many points of interest at the same time. Compression techniques can | many points of interest at the same time. Compression techniques can | |||

also be used to minimize the bandwidth required by the transmission. | also be used to minimize the bandwidth required by the transmission. | |||

This could be a measurement protocol to report the measurement | This could be a measurement protocol to report the measurement | |||

results. It is out of the scope of this memo. | results. It is out of the scope of this memo. | |||

7.2. Measurement | 8.2. Measurement | |||

To prevent any biais in the result, the configuration of a one-to- | To prevent any bias in the result, the configuration of a one-to-many | |||

many measure must take in consideration that implicitly more packets | measure must take in consideration that implicitly more packets will | |||

will to be routed than send and selects a test packets rate that will | to be routed than send and selects a test packets rate that will not | |||

not impact the network performance. | impact the network performance. | |||

7.3. effect of Time and Space Aggregation Order on Group Stats | 8.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 the computation. It makes | scalability of the reporting and of the computation. It makes the | |||

the hypothesis that receivers are managed remotly and not co-located. | hypothesis that receivers are managed remotely and not co-located. | |||

2 methods are available to compute group statistics: | ||||

Figure 8and (Figure 11) illustrate the method method choosen: the | ||||

one-to-one statistic is computed per interval of time before the | ||||

computation of the mean over the group of receivers [method1]; | ||||

Figure 15 presents the second one, metric is computed over space | ||||

and then over time [method2]. | ||||

They differ only by the order of the time and of the space | ||||

aggregation. View as a matrix this order is neutral as it does not | ||||

impact the result, but the impact on a measurement deployement is | ||||

critical. | ||||

Recv | multimetrics samples represented a matrix as illustrated below | |||

Point of | ||||

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

\------------- ------------/ | \------------- ------------/ | |||

\/ | \/ | |||

Group Stat over space and time | Stat over space and time | |||

Figure 15: Impact of space aggregation on Group Stat | Figure 17: Impact of space aggregation on multimetrics Stat | |||

2 methods are available to compute statistics on the resulting | ||||

matrix: | ||||

o metric is computed over time and then over space; | ||||

o metric is computed over space and then over time. | ||||

They differ only by the order of the time and of the space | ||||

aggregation. View as a matrix this order is neutral as does not | ||||

impact the result, but the impact on a measurement deployment is | ||||

critical. | ||||

In both cases the volume of data to report is proportional to the | In both cases the volume of data to report is proportional to the | |||

number of probes. But there is a major difference between these 2 | number of probes. But there is a major difference between these 2 | |||

methods: | methods: | |||

method2: In space and time aggregation mode the volume of data to | method2: In space and time aggregation mode the volume of data to | |||

collect is proportionnal to the number of test packets received; | collect is proportional to the number of test packets received; | |||

Each received packet RiSi triggers out a block of data that must | Each received packet RiSi triggers out a block of data that must | |||

be reported to a common place for computing the stat over space; | be reported to a common place for computing the stat over space; | |||

method1: In time and space aggregation mode the volume of data to | method1: In time and space aggregation mode the volume of data to | |||

collect is proportionnal to the period of aggregation, so it does | collect is proportional to the period of aggregation, so it does | |||

not depend on the number of packet received; | not depend on the number of packet received; | |||

Method 2 property has severe drawbacks in terms of security and | Method 2 property has severe drawbacks in terms of security and | |||

dimensionning: | dimensioning: | |||

The increasing of the rate of the test packets may result in a | The increasing of the rate of the test packets may result in a | |||

sort of DoS toward the computation points; | sort of DoS toward the computation points; | |||

The dimensioning of a measurement system is quite impossible to | The dimensioning of a measurement system is quite impossible to | |||

validate. | validate. | |||

The time agregation interval provides the reporting side with a | The time aggregation interval provides the reporting side with a | |||

control of various collecting aspects such as bandwidth and | control of various collecting aspects such as bandwidth and | |||

computation and storage capacities. So this draft defines metrics | computation and storage capacities. So this draft defines metrics | |||

based on method 1. | based on method 1. | |||

Note: In some specific cases one may need sample of singletons over | Note: In some specific cases one may need sample of singletons over | |||

space. To adress this need it is suggested firstly to limit the | space. To address this need it is suggested firstly to limit the | |||

number of test and the number of test packets per seconds. Then | number of test and the number of test packets per seconds. Then | |||

reducing the size of the sample over time to one packet give sample | reducing the size of the sample over time to one packet give sample | |||

of singleton over space.. | of singleton over space.. | |||

7.4. effect of Time and Space Aggregation Order on Spatial Stats | 8.3.1. Impact on group stats | |||

TBD | 2 methods are available to compute group statistics: | |||

8. Open issues | o method1: Figure 10 andFigure 13 illustrate the method chosen: the | |||

one-to-one statistic is computed per interval of time before the | ||||

computation of the mean over the group of receivers; | ||||

o method2: Figure 17 presents the second one, metric is computed | ||||

over space and then over time. | ||||

9. Security Considerations | 8.3.2. Impact on spatial stats | |||

Active measurement: (TODO: security considerations of owd pl, jitter | 2 methods are available to compute group statistics: | |||

rfcs applies (editor notes: add references). | ||||

9.1. passive measurement | o method 1: spatial segment metrics and statistics are preferably | |||

computed over time by each points of interest; | ||||

The generation of packets which match systematically the hash | o method 2: Vectors metrics are intrinsecally instantaneous space | |||

function may lead to a DoS attack toward the collector. | metrics which must be reported using method2 whenever | |||

instantaneous metrics information is needed. Pure passive | ||||

measurement approach has no choice but to use this method because | ||||

delay and losses may not be computed in each point of interest. | ||||

The generation of packets with spoofing addresses may corrupt the | 9. Manageability Considerations | |||

results without any possibility to detect the spoofing. | ||||

9.2. one-to-group metric | Usually IPPM WG documents defines each metric reporting within its | |||

definition. This document defines the reporting of all the metrics | ||||

introduced in a single section to provide consistent information | ||||

while avoiding repetitions. the aim is to contribute to the work of | ||||

the WG on the reporting and to satisfy IESG recommendation of | ||||

gathering manageability considerations in a dedicated section. | ||||

Data models of spatial and one-to-group metrics are similar excepted | ||||

that points of interests of spatial vectors must be ordered. | ||||

The complexity of the reporting relies on the number of points of | ||||

interests. | ||||

9.1. Reporting spatial metric | ||||

The reporting of spatial metrics shares a lot of aspects with | ||||

RFC2679-80. New ones are common to all the definitions and are | ||||

mostly related to the reporting of the path and of methodology | ||||

parameters that may bias raw results analysis. This section presents | ||||

these specific parameters and then lists exhaustively the parameters | ||||

that shall be reported. | ||||

9.1.1. Path | ||||

End-to-end metrics can't determine the path of the measure despite | ||||

IPPM RFCs recommend it to be reported (Section 3.8.4 of [RFC2679]). | ||||

Spatial metrics vectors provide this path. The report of a spatial | ||||

vector must include the points of interests involved: the sub set of | ||||

the hosts of the path participating to the instantaneous measure. | ||||

9.1.2. Host order | ||||

A spatial vector must order the points of interest according to their | ||||

order in the path. It is highly suggested to use the TTL in IPv4, | ||||

the Hop Limit in IPv6 or the corresponding information in MPLS. | ||||

The report of a spatial vector must include the ordered list of the | ||||

hosts involved in the instantaneous measure. | ||||

9.1.3. Timestamping bias | ||||

The location of the point of interest inside a node influences the | ||||

timestamping skew and accuracy. As an example, consider that some | ||||

internal machinery delays the timestamping up to 3 milliseconds then | ||||

the minimal uncertainty reported be 3 ms if the internal delay is | ||||

unknown at the time of the timestamping. | ||||

The report of a spatial vector must include the uncertainty of the | ||||

timestamping compared to wire time. | ||||

9.1.4. Reporting spatial One-way Delay | ||||

The reporting includes information to report for one-way-delay as | ||||

perthe Section 3.6 of [RFC2679].the same apply for packet loss and | ||||

ipdv | ||||

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

9.3. Metric identification | ||||

IANA assigns each metric defined by the IPPM WG with a unique | ||||

identifier as per [RFC4148] in the IANA-IPPM-METRICS-REGISTRY-MIB. | ||||

To avoid misunderstanding and to address specific reporting | ||||

constraints, section Section 5.4.3 of this memo gives distinct names | ||||

to passive metrics and Section 13 requests a distinct metric | ||||

identifier for each metrics the memo defines. | ||||

As it is crucial for composition of metrics to know the methodology | ||||

used (e.g. generation method, detection method...), the report of a | ||||

metric result used in composition of metrics MUST alway include its | ||||

metric identifier. | ||||

9.4. Reporting data model | ||||

This section presents the elements of the datamodel and the usage of | ||||

the information reported for real network performance analysis. It | ||||

is out of the scope of this section to define how the information is | ||||

reported. | ||||

The data model is build with pieces of information introduced and | ||||

explained in one-way delay definitions [RFC2679], in packet loss | ||||

definitions [RFC2680] and in IPDV definitions[RFC3393][RFC3432]. It | ||||

includes not only information given by "Reporting the metric" | ||||

sections but by sections "Methodology" and "Errors and Uncertainties" | ||||

sections. | ||||

Following are the elements of the datamodel taken from end-to-end | ||||

definitions referred in this memo and from spatial and multicast | ||||

metrics it defines: | ||||

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 Dst_host, the IP address of the receiver; | ||||

o Hosts_serie: <H1, H2,..., Hn>, a list of points of interest; | ||||

o Loss_threshold: The threshold of infinite delay; | ||||

o Systematic_error: constant delay between wire time and | ||||

timestamping; | ||||

o Calibration_error: maximal uncertainty; | ||||

o Src_time, the sending time for a measured packet; | ||||

o Dst_time, the receiving time for a measured packet; | ||||

o Result_status : an indicator of usability of a result 'Resource | ||||

exhaustion' 'infinite', 'lost'; | ||||

o Delays_serie: <dT1,..., dTn> a list of delays; | ||||

o Losses_serie: <B1, B2, ..., Bi, ..., Bn>, a list of Boolean values | ||||

(spatial) or a set of Boolean values (one-to-group); | ||||

o Result_status_serie: 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. | ||||

Following is the information of each vector that should be available | ||||

to compute samples: | ||||

o Packet_type; | ||||

o Packet_length; | ||||

o Src_host, the sender of the packet; | ||||

o Dst_host, the receiver of the packet, apply only for spatial | ||||

vectors; | ||||

o Hosts_serie: not ordered for one-to-group; | ||||

o Src_time, the sending time for the measured packet; | ||||

o dT, the end-to-end one-way delay for the measured packet, apply | ||||

only for spatial vectors; | ||||

o Delays_serie: apply only for delays and ipdv vector, not ordered | ||||

for one-to-group; | ||||

o Losses_serie: apply only for packets loss vector, not ordered for | ||||

one-to-group; | ||||

o Result_status_serie; | ||||

o Observation_duration: the difference between the time of the last | ||||

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

* Systematic error: constant delay between wire time and | ||||

timestamping; | ||||

* Calibration error: maximal uncertainty; | ||||

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

Following is the information that should be available for each sample | ||||

to compute statistics: | ||||

o Packet_type; | ||||

o Packet_length; | ||||

o Src_host, the sender of the packet; | ||||

o Dst_host, the receiver of the 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 Result_status_serie; | ||||

o Observation_duration: the difference between the time of the last | ||||

singleton of the last sample and the time of the first singleton | ||||

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

reported: | ||||

o Result; | ||||

o Start_time; | ||||

o Duration; | ||||

o Result_status; | ||||

o Singleton_number, the number of singletons the statistic is | ||||

computed on; | ||||

10. Open issues | ||||

Do we define min, max, avg of for each segment metrics ? | ||||

having the maximum loss metric value could be interesting. Say, | ||||

the segment between router A and B always contributes loss metric | ||||

value of "1" means it could be the potential problem segment. | ||||

Uploading dTi of each Hi consume a lot of bandwidth. Computing | ||||

statistics (min, max and avg) of dTi locally in each Hi reduce the | ||||

bandwidth consumption. | ||||

11. Security Considerations | ||||

Spatial and one-to-group metrics are defined on the top of end-to-end | ||||

metrics. Security considerations discussed in One-way delay metrics | ||||

definitions of [RFC2679] , in packet loss metrics definitions | ||||

of[RFC2680] and in IPDV metrics definitions of[RFC3393] and [RFC3432] | ||||

apply to multimetrics. | ||||

11.1. Spatial metrics | ||||

Malicious generation of packets with spoofing addresses may corrupt | ||||

the results without any possibility to detect the spoofing. | ||||

Malicious generation of packets which match systematically the hash | ||||

function used to detect the packets may lead to a DoS attack toward | ||||

the point of reference. | ||||

11.2. one-to-group metric | ||||

The reporting of measurement results from a huge number of probes may | ||||

overload the network the reference point is attach to, the reference | ||||

point network interfaces and the reference point computation | ||||

capacities. | ||||

The configuration of a measure must take in consideration that | The configuration of a measure must take in consideration that | |||

implicitly more packets will to be routed than send and selects a | implicitly more packets will to be routed than send and selects a | |||

test packets rate accordingly. | test packets rate accordingly. Collecting statistics from a huge | |||

number of probes may overload any combination of the network where | ||||

Collecting statistics from a huge number of probes may overload any | the measurement controller is attach to, measurement controller | |||

combination of the network the measurement controller is attach to, | network interfaces and measurement controller computation capacities. | |||

measurement controller network interfaces and measurement controller | ||||

computation capacities. | ||||

one-to-group metrics: | one-to-group metrics measurement should consider using source | |||

authentication protocols, standardized in the MSEC group, to avoid | ||||

fraud packet in the sampling interval. The test packet rate could be | ||||

negotiated before any measurement session to avoid deny of service | ||||

attacks. | ||||

10. Acknowledgments | 12. Acknowledgments | |||

Lei would like to acknowledge Zhili Sun from CCSR, University of | Lei would like to acknowledge Prof. Zhili Sun from CCSR, University | |||

Surrey, for his instruction and helpful comments on this work. | of Surrey, for his instruction and helpful comments on this work. | |||

11. IANA Considerations | 13. IANA Considerations | |||

Metrics defined in this memo Metrics defined in this memo are | Metrics defined in this memo Metrics defined in this memo are | |||

designed to be registered in the IANA IPPM METRICS REGISTRY as | designed to be registered in the IANA IPPM METRICS REGISTRY as | |||

described in initial version of the registry [RFC4148] : | described in initial version of the registry [RFC4148] : | |||

IANA is asked to register the following metrics in the IANA-IPPM- | IANA is asked to register the following metrics in the IANA-IPPM- | |||

METRICS-REGISTRY-MIB : | METRICS-REGISTRY-MIB : | |||

Spatial-One-way-Delay-Vector OBJECT-IDENTITY | Spatial-One-way-Delay-Vector OBJECT-IDENTITY | |||

skipping to change at page 38, line 31 | skipping to change at page 49, line 37 | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 4.1." | "Reference "RFCyyyy, section 4.1." | |||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | -- RFC Ed.: replace yyyy with actual RFC number & remove this | |||

note | note | |||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics nn } -- IANA assigns nn | |||

subpath-One-way-Delay-Stream OBJECT-IDENTITY | Spatial-Packet-Loss-Vector OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-subpath-One-way-Delay-Stream" | "Type-P-Spatial-Packet-Loss-Vector" | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 4.2." | "Reference "RFCyyyy, section 4.2." | |||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | -- RFC Ed.: replace yyyy with actual RFC number & remove this | |||

note | note | |||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics nn } -- IANA assigns nn | |||

Spatial-One-way-Packet-Loss-Vector OBJECT-IDENTITY | Spatial-One-way-ipdv-Vector OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

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

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 4.3." | "Reference "RFCyyyy, section 4.3." | |||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | -- RFC Ed.: replace yyyy with actual RFC number & remove this | |||

note | note | |||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics nn } -- IANA assigns nn | |||

Spatial-One-way-Jitter-Vector OBJECT-IDENTITY | Spatial-Segment-One-way-Delay-Stream OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-Spatial-One-way-Jitter-Vector" | "Type-P-Spatial-Segment-One-way-Delay-Stream" | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 4.4." | "Reference "RFCyyyy, section 5.1." | |||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | -- RFC Ed.: replace yyyy with actual RFC number & remove this | |||

note | note | |||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics nn } -- IANA assigns nn | |||

Spatial-Segment-Packet-Loss-Stream OBJECT-IDENTITY | ||||

STATUS current | ||||

DESCRIPTION | ||||

"Type-P-Spatial-Segment-Packet-Loss-Stream" | ||||

REFERENCE | ||||

"Reference "RFCyyyy, section 5.2." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | ||||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | ||||

Spatial-Segment-One-way-ipdv-Stream OBJECT-IDENTITY | ||||

STATUS current | ||||

DESCRIPTION | ||||

"Type-P-Spatial-Segment-ipdv-Stream" | ||||

REFERENCE | ||||

"Reference "RFCyyyy, section 5.3." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | ||||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | ||||

Passive-Segment-One-way-Delay-Stream OBJECT-IDENTITY | ||||

STATUS current | ||||

DESCRIPTION | ||||

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

REFERENCE | ||||

"Reference "RFCyyyy, section 5.4.1." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | ||||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | ||||

Passive-Segment-Packet-Loss-Stream OBJECT-IDENTITY | ||||

STATUS current | ||||

DESCRIPTION | ||||

"Type-P-Passive-Segment-Packet-Loss-Stream" | ||||

REFERENCE | ||||

"Reference "RFCyyyy, section 5.4.2." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | ||||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | ||||

Passive-Segment-One-way-ipdv-Stream OBJECT-IDENTITY | ||||

STATUS current | ||||

DESCRIPTION | ||||

"Type-P-Passive-Segment-One-way-ipdv-Stream" | ||||

REFERENCE | ||||

"Reference "RFCyyyy, section 5.4.3." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | ||||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | ||||

-- One-to-group metrics | ||||

one-to-group-One-way-Delay-Vector OBJECT-IDENTITY | one-to-group-One-way-Delay-Vector OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-one-to-group-One-way-Delay-Vector" | "Type-P-one-to-group-One-way-Delay-Vector" | |||

REFERENCE | REFERENCE | |||

skipping to change at page 40, line 21 | skipping to change at page 53, line 23 | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 5.2." | "Reference "RFCyyyy, section 5.2." | |||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | -- RFC Ed.: replace yyyy with actual RFC number & remove this | |||

note | note | |||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics nn } -- IANA assigns nn | |||

one-to-group-One-way-Jitter-Vector OBJECT-IDENTITY | one-to-group-One-way-ipdv-Vector OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-one-to-group-One-way-Jitter-Vector" | "Type-P-one-to-group-One-way-ipdv-Vector" | |||

REFERENCE | REFERENCE | |||

"Reference "RFCyyyy, section 5.3." | "Reference "RFCyyyy, section 5.3." | |||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | -- RFC Ed.: replace yyyy with actual RFC number & remove this | |||

note | note | |||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics nn } -- IANA assigns nn | |||

skipping to change at page 42, line 30 | skipping to change at page 55, line 34 | |||

"Reference "RFCyyyy, section 6.4.2." | "Reference "RFCyyyy, section 6.4.2." | |||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | -- RFC Ed.: replace yyyy with actual RFC number & remove this | |||

note | note | |||

:= { ianaIppmMetrics nn } -- IANA assigns nn | := { ianaIppmMetrics nn } -- IANA assigns nn | |||

-- | -- | |||

12. References | 14. References | |||

12.1. Normative References | 14.1. Normative References | |||

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

[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way | [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way | |||

Delay Metric for IPPM", RFC 2679, September 1999. | Delay Metric for IPPM", RFC 2679, September 1999. | |||

[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way | [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way | |||

Packet Loss Metric for IPPM", RFC 2680, September 1999. | Packet Loss Metric for IPPM", RFC 2680, September 1999. | |||

[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation | [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation | |||

Metric for IP Performance Metrics (IPPM)", RFC 3393, | Metric for IP Performance Metrics (IPPM)", RFC 3393, | |||

November 2002. | November 2002. | |||

[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics | [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics | |||

Registry", BCP 108, RFC 4148, August 2005. | Registry", BCP 108, RFC 4148, August 2005. | |||

12.2. Informative References | 14.2. Informative References | |||

[RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring | [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring | |||

Connectivity", RFC 2678, September 1999. | Connectivity", RFC 2678, September 1999. | |||

[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip | [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip | |||

Delay Metric for IPPM", RFC 2681, September 1999. | Delay Metric for IPPM", RFC 2681, September 1999. | |||

[RFC3148] Mathis, M. and M. Allman, "A Framework for Defining | [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining | |||

Empirical Bulk Transfer Capacity Metrics", RFC 3148, | Empirical Bulk Transfer Capacity Metrics", RFC 3148, | |||

July 2001. | July 2001. | |||

End of changes. 250 change blocks. | ||||

516 lines changed or deleted | | 1091 lines changed or added | ||

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