draft-ietf-ippm-multimetrics-02.txt | draft-ietf-ippm-multimetrics-03.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: April 25, 2007 University of Surrey | Expires: September 2, 2007 University of Surrey | |||

A. Morton | A. Morton | |||

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

October 22, 2006 | March 1, 2007 | |||

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

draft-ietf-ippm-multimetrics-02 | draft-ietf-ippm-multimetrics-03 | |||

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 April 25, 2007. | This Internet-Draft will expire on September 2, 2007. | |||

Copyright Notice | Copyright Notice | |||

Copyright (C) The Internet Society (2006). | 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||

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

2.1. Multiparty metric . . . . . . . . . . . . . . . . . . . . 5 | 2.1. Multiparty metric . . . . . . . . . . . . . . . . . . . . 6 | |||

2.2. Spatial metric . . . . . . . . . . . . . . . . . . . . . . 5 | 2.2. Spatial metric . . . . . . . . . . . . . . . . . . . . . . 6 | |||

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

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

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

2.6. Reference point . . . . . . . . . . . . . . . . . . . . . 5 | 2.6. Reference point . . . . . . . . . . . . . . . . . . . . . 6 | |||

2.7. Vector . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.7. Vector . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||

2.8. Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.8. Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||

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

3.1. spatial metrics . . . . . . . . . . . . . . . . . . . . . 7 | 3.1. spatial metrics . . . . . . . . . . . . . . . . . . . . . 8 | |||

3.2. One-to-group metrics . . . . . . . . . . . . . . . . . . . 8 | 3.2. One-to-group metrics . . . . . . . . . . . . . . . . . . . 9 | |||

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

4. Spatial metrics definitions . . . . . . . . . . . . . . . . . 9 | 4. Spatial metrics definitions . . . . . . . . . . . . . . . . . 10 | |||

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

4.2. A Definition of a sample of One-way Delay of a sub path . 12 | 4.2. A Definition of a sample of One-way Delay of a sub path . 13 | |||

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

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

4.5. Pure Passive Metrics . . . . . . . . . . . . . . . . . . . 18 | 4.5. Pure Passive Metrics . . . . . . . . . . . . . . . . . . . 19 | |||

4.6. Discussion on spatial statistics . . . . . . . . . . . . . 20 | 4.6. Discussion on spatial statistics . . . . . . . . . . . . . 21 | |||

5. One-to-group metrics definitions . . . . . . . . . . . . . . . 20 | 5. One-to-group metrics definitions . . . . . . . . . . . . . . . 21 | |||

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

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

5.3. A Definition for one-to-group One-way Jitter . . . . . . . 21 | 5.3. A Definition for one-to-group One-way Jitter . . . . . . . 22 | |||

5.4. Discussion on one-to-group statistics . . . . . . . . . . 23 | 6. One-to-Group Sample Statistics . . . . . . . . . . . . . . . . 24 | |||

6. Extension from one-to-one to one-to-many measurement . . . . . 26 | 6.1. Discussion on the Impact of packet loss on statistics . . 26 | |||

7. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 27 | 6.2. General Metric Parameters . . . . . . . . . . . . . . . . 27 | |||

8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 | 6.3. One-to-Group one-way Delay Statistics . . . . . . . . . . 28 | |||

9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 | 6.4. One-to-Group one-way Loss Statistics . . . . . . . . . . . 31 | |||

10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 | 6.5. One-to-Group one-way Delay Variation Statistics . . . . . 33 | |||

11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 | 7. Measurement Methods: Scaleability and Reporting . . . . . . . 33 | |||

11.1. Normative References . . . . . . . . . . . . . . . . . . . 28 | 7.1. Computation methods . . . . . . . . . . . . . . . . . . . 34 | |||

11.2. Informative References . . . . . . . . . . . . . . . . . . 28 | 7.2. Measurement . . . . . . . . . . . . . . . . . . . . . . . 35 | |||

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 | 7.3. effect of Time and Space Aggregation Order on Group | |||

Intellectual Property and Copyright Statements . . . . . . . . . . 30 | Stats . . . . . . . . . . . . . . . . . . . . . . . . . . 35 | |||

7.4. effect of Time and Space Aggregation Order on Spatial | ||||

Stats . . . . . . . . . . . . . . . . . . . . . . . . . . 37 | ||||

8. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 37 | ||||

9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 | ||||

9.1. passive measurement . . . . . . . . . . . . . . . . . . . 37 | ||||

9.2. one-to-group metric . . . . . . . . . . . . . . . . . . . 37 | ||||

10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 | ||||

11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 | ||||

12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 | ||||

12.1. Normative References . . . . . . . . . . . . . . . . . . . 42 | ||||

12.2. Informative References . . . . . . . . . . . . . . . . . . 43 | ||||

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 | ||||

Intellectual Property and Copyright Statements . . . . . . . . . . 45 | ||||

1. Introduction | 1. Introduction | |||

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

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

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

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

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

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

This memo makes use of definitions of end-to-end One-way Packet loss | 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 | Metrics defined in the RFC 2680 [RFC2680] to define metrics for | |||

decomposition of end-to-end one-way packet loss measurements. | 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, RFC 2330 [RFC2330]; | the Framework for IP Performance Metrics [RFC2330]; | |||

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

[RFC3763]; | ||||

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

o An IP Performance Metrics Registry , RFC 4148 [RFC4148]; | o An IP Performance Metrics Registry [RFC4148]; | |||

It specified a set of end-to-end metrics, which conform to this | It specified a set of end-to-end metrics, which conform to this | |||

framework: | framework: | |||

o The IPPM Metrics for Measuring Connectivity, RFC 2678 [RFC2678]; | o The IPPM Metrics for Measuring Connectivity [RFC2678]; | |||

o The One-way Delay Metric for IPPM, RFC 2679 [RFC2679]; | o The One-way Delay Metric for IPPM [RFC2679]; | |||

o The One-way Packet Loss Metric for IPPM, RFC 2680 [RFC2680]; | o The One-way Packet Loss Metric for IPPM [RFC2680]; | |||

o The Round-trip Delay Metric for IPPM, RFC 2681 [RFC2681]; | o The Round-trip Delay Metric for IPPM [RFC2681]; | |||

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

RFC 3148 [RFC3148]; | [RFC3148]; | |||

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

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

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

[RFC3432]; | ||||

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

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

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

metrics. | metrics. | |||

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 'sample', 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 in a | |||

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

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

skipping to change at page 5, line 31 | skipping to change at page 6, line 28 | |||

2.2. Spatial metric | 2.2. Spatial metric | |||

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

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

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

Points of interest of a spatial metric are the routers or sibling in | Points of interest of a spatial metric are the routers or sibling in | |||

the path between source and destination (in addition to the source | the path between source and destination (in addition to the source | |||

and the destination themself). | 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. One-to-group metric points of interest | |||

skipping to change at page 6, line 19 | skipping to change at page 7, line 16 | |||

calculation will be carried out. | 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 | 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. | 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 abserved 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 orgnized as {dT1, dT2,..., dTN}. The elements in one | elements can be organized as {dT1, dT2,..., dTN}. The elements in | |||

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 orgnize form up a Matrix, which contains results | Several vectors can organize form up a Matrix, which contains results | |||

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

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

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

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

{V1, V2,...,Vm}. Additional to the information given by a Vector, a | {V1, 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 corresponding 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 Fig 1. | following Figure 1. | |||

one to group Singleton | one-to-group Singleton | |||

/ Sample | / Sample | |||

Src Rcvr .............................. | Src Recv .............................. | |||

..................R1dT1 R1dT2 R1dT3 R1dT4 | .................... 1 R1dT1 R1dT2 R1dT3 R1dT4 | |||

`:=-.._ | `:=-.._ | |||

T `._ ``-..__ | T `._ ``-..__ | |||

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

`-. | `-. | |||

`-. | `-. | |||

`._R3dT1 R3dT2 R3dT3 R3dT4 | `.... N R3dT1 R3dT2 R3dT3 R3dT4 | |||

Vector Matrix | Vector Matrix | |||

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

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

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

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

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

o The PCE WG is extending existing protocols to permit remote path | o Decomposing the performance of interdomain path is desirable in | |||

computation and path computation quality, including inter domain. | interdomain to qualify per AS contribution to the performance. So | |||

One may say that in intra domain the decomposing the performance | it is necessary to define standard spatial metrics before going | |||

of a path is not whished. However such decomposition is desirable | further in the computation of inter domain path with QoS | |||

in interdomain to qualify each AS computation with the initial | constraint. | |||

request. So it is necessary to define standard spatial metrics | ||||

before going further in the computation of inter domain path with | ||||

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

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. The definition of composition metrics is a work in | plane. Spatial measure give typically the individual performance | |||

progress [I-D.ietf-ippm-spatial-composition]; . Spatial measure | of an intra domain segment. It is the elementary piece of | |||

give typically the individual performance of an intra domain | information to exchange for measuring interdomain performance | |||

segment. It is the elementary piece of information to exchange | based on composition of metrics. | |||

for measuring interdomain performance 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 measurement. [I-D.boschi-ipfix-reducing-redundancy]; | support instantaneous measurement respecful of the IPPM framework | |||

defines a method to collect packets information to measure the | [RFC2330]. Consequently it is necessary to define a set of | |||

instantaneous spatial performance without injecting test traffic. | spatial metrics for passive and active techniques. | |||

Consequently it is urgent to define a set of common spatial | ||||

metrics for passive and active techniques which respect the IPPM | ||||

framework [RFC2330]. This need is emphases by the fact that end- | ||||

to-end spatial measurement involves the 2 techniques; | ||||

3.2. One-to-group metrics | 3.2. 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. | |||

skipping to change at page 9, line 18 | skipping to change at page 10, line 5 | |||

the multiparty communications. | the multiparty communications. | |||

To understand the connection situation between one source and any one | To understand the connection situation between one source and any one | |||

receiver in the multiparty communication group, we need the | receiver in the multiparty communication group, we need the | |||

collection of instantaneous end-to-end measures. It will give us | collection of instantaneous end-to-end measures. It will give us | |||

very detailed insight into each branch of the multicast tree in terms | very detailed insight into each branch of the multicast tree in terms | |||

of end-to-end absolute QoS. It can provide clear and helpful | of end-to-end absolute QoS. It can provide clear and helpful | |||

information for engineers to identify the connection with problems in | information for engineers to identify the connection with problems in | |||

a complex multiparty routing tree. | a complex multiparty routing tree. | |||

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

concerns to the IPPM working group to measure the performance of a | ||||

group of users who receiving data from the same source. The concept | ||||

extends the "path" in the one-way measurement to "path tree" to cover | ||||

both one-to-one and one-to-many communications. Nevertheless, | ||||

applied to one-to-one communications they provide exactly the same | ||||

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

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

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

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

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

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

However, we can give some clues here on these two cases. | However, we can give some clues here on these two cases. | |||

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

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

skipping to change at page 9, line 49 | skipping to change at page 10, line 44 | |||

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 metrics definitions | |||

Spatial decomposition metrics are based on standard end-to-end | Spatial decomposition metrics are based on standard end-to-end | |||

metrics. | metrics. | |||

The definition of a spatial metric is coupled with the corresponding | The definition of a spatial metric is coupled with the corresponding | |||

end-to-end metric. The methodoly is based on the measure of the same | end-to-end metric. The methodology is based on the measure of the | |||

test packet and parameters of the corresponding end-to-end metric. | same test packet and parameters of the corresponding end-to-end | |||

metric. | ||||

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 29 | skipping to change at page 12, line 22 | |||

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]; | |||

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 (see [I-D.quittek-ipfix-middlebox]). If the packet is not | result. If the packet is not observed on the input interface the | |||

observed on the input interface the delay includes buffering time | delay includes buffering time and consequently an uncertainty due | |||

and consequently an uncertainty due to the difference between | to the difference between 'wire time' and 'host time'; | |||

'wire time' and 'host time'; | ||||

4.1.6. Interference with other test packet | 4.1.6. Interference with other test packet | |||

To avoid packet collision it is preferable to include a sequence | To avoid packet collision it is preferable to include a sequence | |||

number in the packet. | number in the packet. | |||

4.1.7. loss threshold | 4.1.7. loss threshold | |||

To determine if a dTi is defined or undefined it is necessary to | 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. | define a period of time after which a packet is considered loss. | |||

skipping to change at page 12, line 26 | skipping to change at page 13, line 18 | |||

It is out of the scope of this document to define how each Hi detects | It is out of the scope of this document to define how each Hi detects | |||

the packet. | the packet. | |||

4.1.9. Reporting the metric | 4.1.9. Reporting the metric | |||

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

4.1.10. Path | 4.1.10. Path | |||

It is clear that a end-to-end Type-P-One-way-Delay can't determine | It is clear that a end-to-end Type-P-One-way-Delay can't determine | |||

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

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

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

This part of the job is provide by Type-P-Spatial-One-way-Delay- | This part of the job is provide by Type-P-Spatial-One-way-Delay- | |||

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

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

4.2. A Definition of a sample of One-way Delay of a sub path | 4.2. A Definition of a sample of One-way Delay of a sub path | |||

This metric is similar to the metric Type-P-One-way-Delay-Poisson- | This metric is similar to the metric Type-P-One-way-Delay-Poisson- | |||

skipping to change at page 14, line 20 | skipping to change at page 15, line 20 | |||

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

is discussed in the section 3.7.1. "Errors or uncertainties | is discussed in the section 3.7.1. "Errors or uncertainties | |||

related to Clocks" of of [RFC2679]; | related to Clocks" of of [RFC2679]; | |||

* This may occurs too when the clock resolution of one probe is | * This may occurs too when the clock resolution of one probe is | |||

bigger than the minimun delay of a path. As an example this | bigger than the minimum delay of a path. As an example this | |||

happen when measuring the delay of a path which is 500 km long | happen when measuring the delay of a path which is 500 km long | |||

with one probe synchronized using NTP having a clock resolution | with one probe synchronized using NTP having a clock resolution | |||

of 8ms. | of 8ms. | |||

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 (see [I-D.quittek-ipfix-middlebox]). If the packet is not | result. If the packet is not observed on the input interface the | |||

observed on the input interface the delay includes buffering time | delay includes buffering time and consequently an uncertainty due | |||

and consequently an uncertainty due to the difference between | to the difference between 'wire time' and 'host time'; | |||

'wire time' and 'host time'; | ||||

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

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

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

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

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

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

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

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

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

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

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

reporting. | reporting. | |||

Following we define the spatial metric, then we adapt some of the | Following we define the spatial metric, then we adapt some of the | |||

points above and introduce points specific to spatial measurement. | points above and introduce points specific to spatial measurement. | |||

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

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

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

skipping to change at page 15, line 50 | skipping to change at page 16, line 50 | |||

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

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

+ dT1,..., dTn, dT, a list of delay. | + 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. | + <Src, H1, H2,..., Hn, Dst>, a path digest. | |||

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

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

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

4.3.4. Definition | 4.3.4. Definition | |||

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

receiver Dst in the path <H1, H2, ..., Hn>. Given the sequence of | 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, | times <T+dT1,T+dT2,...,T+dTn,T+dT> the packet passes <H1, H2 ..., Hn, | |||

Dst>, | Dst>, | |||

Type-P-One-way-Packet-Lost-Vector metric is defined as the sequence | 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 | 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 | value of Bi of 0 means that dTi is a finite value, and a value of 1 | |||

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

4.3.5. Discussion | 4.3.5. Discussion | |||

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

o the result includes the sequence 1,0. This case means that the | 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; | packet was seen by a host but not by it successor on the path; | |||

o | o | |||

The location of the meter in the device influences the result: | The location of the meter in the device influences the result: | |||

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

by a meter located after a buffer; | by a meter located after a buffer; | |||

skipping to change at page 16, line 49 | skipping to change at page 17, line 49 | |||

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

This section uses parameters from the definition of Type-P-One-way- | 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 | ipdv. When a parameter from section 2 of [RFC3393] is first used in | |||

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

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

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

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

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

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

reporting. | reporting. | |||

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.4.1. Metric Name | 4.4.1. Metric Name | |||

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

4.4.2. Metric Parameters | 4.4.2. Metric Parameters | |||

skipping to change at page 18, line 35 | skipping to change at page 19, line 35 | |||

at least one of them never passes Hi. T2-T1 is the inter-packet | 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 | emission interval and dT2-dT1 is ddT* the Type-P-One-way-ipdv at | |||

T1,T2*. | T1,T2*. | |||

4.4.5. Sections in progress | 4.4.5. Sections in progress | |||

See sections 3.5 to 3.7 of [RFC3393]. | See sections 3.5 to 3.7 of [RFC3393]. | |||

4.5. Pure Passive Metrics | 4.5. Pure Passive Metrics | |||

Spatial metrics may be measured without injecting test traffic as | Spatial metrics may be measured without injecting test traffic. | |||

described in [I-D.boschi-ipfix-reducing-redundancy] . | ||||

4.5.1. Discussion on Passive measurement | 4.5.1. Discussion on Passive measurement | |||

One might says that most of the operational issues occur in the last | One might says that most of the operational issues occur in the last | |||

mile and that consequently such measure are less useful than active | mile and that consequently such measure are less useful than active | |||

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

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

Such a technique have some limitations that are discussed below. | Such a technique have some limitations that are discussed below. | |||

4.5.1.1. Passive One way delay | 4.5.1.1. Passive One way delay | |||

As the packet is not a test packet, it does not include the time it | As the packet is not a test packet, it does not include the time it | |||

was sent. | was sent. | |||

Consequently a point of interest Hi ignores the time the packet was | Consequently a point of interest Hi ignores the time the packet was | |||

skipping to change at page 19, line 32 | skipping to change at page 20, line 31 | |||

An alternative to these issues consist in considering sample spatial | An alternative to these issues consist in considering sample spatial | |||

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

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

4.5.2. Reporting and composition | 4.5.2. Reporting and composition | |||

To avoid misunderstanding and to address specific reporting | To avoid misunderstanding and to address specific reporting | |||

constraint a proposal consists in defining distinct metrics for pure | constraint a proposal consists in defining distinct metrics for pure | |||

passive measurement based on the definition above. | passive measurement based on the definition above. | |||

It is crucial to know the methodologie used because of the difference | It is crucial to know the methodologies used because of the | |||

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

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

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

4.5.3. naming and registry | 4.5.3. naming and registry | |||

Having distinct metrics identifiers for spatial metrics and passive | Having distinct metrics identifiers for spatial metrics and passive | |||

spatial metrics in the [RFC4148] will avoid interoperabily issues | spatial metrics in the [RFC4148] will avoid interoperability issues | |||

especially during composition of metrics. | especially during composition of metrics. | |||

4.5.4. Passive One way delay metrics | 4.5.4. Passive One way delay metrics | |||

4.5.5. Passive One way PacketLoss metrics | 4.5.5. Passive One way PacketLoss metrics | |||

4.5.6. Passive One way jitter metrics | 4.5.6. Passive One way jitter metrics | |||

4.6. Discussion on spatial statistics | 4.6. Discussion on spatial statistics | |||

skipping to change at page 22, line 38 | skipping to change at page 23, line 38 | |||

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

5.3.4. Definition | 5.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-Jitter- | |||

Vector is defined for two packets from the source Src to the N hosts | Vector 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 Scr 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-Jitter-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}. | |||

5.4. Discussion on one-to-group statistics | 6. 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 | |||

to identify the relative performance situation. | to identify the relative performance situation. | |||

One may say that no matter how many people join the communication, | ||||

the connections can still be treated as a set of one-to-one | ||||

connection. However, we might not describe a multiparty | ||||

communication by a set of one-way measurement metrics because of the | ||||

difficulty for understanding and the lack of convenience. For | ||||

instance, an engineer might not describe the connections of a | ||||

multiparty online conference in terms of one-to-group one-way delay | ||||

for user A and B, B and C, and C and A because people might be | ||||

confused. If there are more users in the same communication, the | ||||

description might be very long. And he might use the one-way metrics | ||||

with worst and the best value to give users an idea of the | ||||

performance range of the service they are providing. But it is not | ||||

clear enough and might not be accurate in a large multiparty | ||||

communication scenario. | ||||

From the performance point of view, the multiparty communication | From the performance point of view, the multiparty communication | |||

services not only require the absolute performance support but also | services not only require the absolute performance support but also | |||

the relative performance. The relative performance means the | the relative performance. The relative performance means the | |||

difference between absolute performance of all users. Directly using | difference between absolute performance of all users. Directly using | |||

the one-way metrics cannot present the relative performance | the one-way metrics cannot present the relative performance | |||

situation. However, if we use the variations of all users one-way | situation. However, if we use the variations of all users one-way | |||

parameters, we can have new metrics to measure the difference of the | parameters, we can have new metrics to measure the difference of the | |||

absolute performance and hence provide the threshold value of | absolute performance and hence provide the threshold value of | |||

relative performance that a multiparty service might demand. A very | relative performance that a multiparty service might demand. A very | |||

good example of the high relative performance requirement is the | good example of the high relative performance requirement is the | |||

online gaming. A very light worse delay will result in failure in | online gaming. A very light difference in delay might result in | |||

the game. We have to use the new statistic metrics to define exactly | failure in the game. We have to use multicast specific statistic | |||

how small the relative delay the online gaming requires. There are | metrics to define exactly how small the relative delay the online | |||

many other services, e.g. online biding, online stock market, etc., | gaming requires. There are many other services, e.g. online biding, | |||

need a rule to judge the relative performance requirement. | online stock market, etc., that require multicast metrics in order to | |||

Therefore, we can see the importance of new statistic metrics to feed | evaluate the network against their requirements. Therefore, we can | |||

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

feed this need. | ||||

We might use some one-to-group statistic conceptions to present and | We might also use some one-to-group statistic conceptions to present | |||

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 FRCs. 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] and | definitions for minimum and maximum One-way delay in [RFC2679]. | |||

One-way delay mean in [I-D.ietf-ippm-spatial-composition]. However, | However, there is a dramatic difference between the statistics for | |||

there is a dramatic difference between the statistics for one-to-one | one-to-one communications and for one-to-many communications. The | |||

communications and for one-to-many communications. The former one | former one only has statistics over the time dimension while the | |||

only has statistics over the time dimension while the later one can | later one can have statistics over both time and space dimensions. | |||

have statistics over both time dimension and space dimention. This | This space dimension is introduced by the Matrix concept as | |||

space dimension is introduced by the Matrix concept. For a Matrix M | illustrated in Figure 7. For a Matrix M each row is a set of One-way | |||

shown in the Fig. 2, each row is a set of One-way singletons | singletons spreading over the time dimension and each column is | |||

spreading over the space dimension and each colume is another set of | another set of One-way singletons spreading over the space dimension. | |||

One-way singletons spreading over the time dimension. | ||||

(preamble) | Receivers | |||

/ \ | Space | |||

| dT11, dT12,..., dT1N | | ^ | |||

| dT21, dT22,..., dT2N | | 1 | / R1dT1 R1dT2 R1dT3 ... R3dTk \ | |||

| : | | | | | | |||

| : | | 2 | | R2dT1 R2dT2 R2dT3 ... R3dTk | | |||

| dTm1, dTm2,..., dTmN | | | | | | |||

\ / | 3 | | R3dT1 R3dT2 R3dT3 ... R3dTk | | |||

. | | | | ||||

. | | | | ||||

. | | | | ||||

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

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

T0 | ||||

Fig. 2 Matrix M (m*N) | Figure 7: Matrix M (n*m) | |||

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

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 N 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 colume 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 | |||

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

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

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

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

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

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

are served farely by calculating the statistics over the space | are served fairly by calculating the statistics over the space | |||

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

statistics are better than the other. | statistics are better than the other. | |||

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

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

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

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

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

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

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

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

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

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

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

might want to know how this statistics distributed over the space | might want to know how this statistics distributed over the space | |||

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

skipping to change at page 25, line 29 | skipping to change at page 26, line 21 | |||

group of users during a sampling interval in terms of delay. It | group of users during a sampling interval in terms of delay. It | |||

needs twice calculation to have this statistic over both time and | needs twice calculation to have this statistic over both time and | |||

space dimensions. We name this kind of statistics 2-level statistics | space dimensions. We name this kind of statistics 2-level statistics | |||

to distinct with those 1-level statistics calculated over either | to distinct with those 1-level statistics calculated over either | |||

space or time dimension. It can be easily prove that no matter over | space or time dimension. It can be easily prove that no matter over | |||

which dimension a 2-level statistic is calculated first, the results | which dimension a 2-level statistic is calculated first, the results | |||

are the same. I.e. one can calculate the 2-level delay mean using | are the same. I.e. one can calculate the 2-level delay mean using | |||

the Matrix M by having the 1-level delay mean over the time dimension | the Matrix M by having the 1-level delay mean over the time dimension | |||

first and then calculate the mean of the obtained vector to find out | first and then calculate the mean of the obtained vector to find out | |||

the 2-level delay mean. Or, he can do the 1-level statistic | the 2-level delay mean. Or, he can do the 1-level statistic | |||

calculation over the space dimention first and then have the 2-level | calculation over the space dimension first and then have the 2-level | |||

delay mean. Both two results will be exactly the same. Therefore, | delay mean. Both two results will be exactly the same. Therefore, | |||

when define a 2-level statistic, it is no need to specify in which | when define a 2-level statistic, there is no need to specify in which | |||

procedure the calculation should follow. | procedure the calculation should follow. | |||

There are many statistics can be defined for the proposed one-to- | Comment: The above statement depends on whether the order of | |||

group metrics over either the space dimension or the time dimension | operations has any affect on the outcome. | |||

or both. In this memo, we define one-to-group mean and one-to-group | ||||

variation over the space dimension. These statistics are offered | ||||

mostly to be illustrative of what could be done. | ||||

One-to-group mean are trying to measure the overall performance for a | Many statistics can be defined for the proposed one-to-group metrics | |||

multicast group associated to one source. It is a reflection of the | over either the space dimension or the time dimension or both. This | |||

absolute performance of a multiparty communication service when we | memo treats the case where a stream of packets from the Source | |||

treat all receivers as one customer. It can also present the trend | results in a sample at each of the Receivers in the Group, and these | |||

of the absolute performance of all receivers, i.e., it shows that | samples are each summarized with the usual statistics employed in | |||

most of the receivers in the multiparty communication service trend | one-to-one communication. New statistic definitions are presented, | |||

to receive an absolute performance close to the mean. | which summarize the one-to-one statistics over all the Receivers in | |||

the Group. | ||||

One-to-group variation streams are trying to measure how the | 6.1. Discussion on the Impact of packet loss on statistics | |||

performance varies among all of the users in a multicast group | ||||

associated to one source. The word "variation" in this memo is the | ||||

population standard deviation. It reflects the relative | ||||

performancesituation in a multiparty communication service, i.e., the | ||||

level of the difference between the absolute performanceof each | ||||

receivers. | ||||

Using the one-to-group mean and one-to-group variation concepts, we | The packet loss does have effects on one-way metrics and their | |||

can have a much clear understand on the performanceof a multiparty | statistics. For example, the lost packet can result an infinite one- | |||

communication service in terms of its trend and range. There can be | way delay. It is easy to handle the problem by simply ignoring the | |||

mean and variation stream definitions for each of the three one-to- | infinite value in the metrics and in the calculation of the | |||

group metrics defined above. We only present the definition of Type- | corresponding statistics. However, the packet loss has so strong | |||

P-one-to-group-One-way-Delay-Space-Mean and Type-P-one-to-group- One- | impact on the statistics calculation for the one-to-group metrics | |||

way-Delay-Space-Variation as examples in this memo. | 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 | ||||

needed for calculation of the statistics proposed in this memo. | ||||

5.4.1. Type-P-one-to-group-One-way-Delay-Space-Mean | The situation is that measurement results obtained by different end | |||

users might have different packet loss pattern. For example, for | ||||

User1, packet A was observed lost. And for User2, packet A was | ||||

successfully received but packet B was lost. If the method to | ||||

overcome the packet loss for one-way metrics is applied, the two | ||||

singleton sets reported by User1 and User2 will be different in terms | ||||

of the transmitted packets. Moreover, if User1 and User2 have | ||||

different number of lost packets, the size of the results will be | ||||

different. Therefore, for the centralized calculation, the reference | ||||

point will not be able to use these two results to build up the group | ||||

Matrix and can not calculate the statistics. In an extreme | ||||

situation, no single packet arrives all users in the measurement and | ||||

the Matrix will be empty. One of the possible solutions is to | ||||

replace the infinite/undefined delay value by the average of the two | ||||

adjacent values. For example, if the result reported by user1 is { | ||||

R1dT1 R1dT2 R1dT3 ... R1dTK-1 UNDEF R1dTK+1... R1DM } where "UNDEF" | ||||

is an undefined value, the reference point can replace it by R1dTK = | ||||

{(R1dTK-1)+( R1dTK+1)}/2. Therefore, this result can be used to | ||||

build up the group Matrix with an estimated value R1dTK. There are | ||||

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

of the scope of this memo. | ||||

Given a Type-P-one-to-group-One-way-Delay-Vector, the mean { dT1, | For the distributed calculation, the reported statistics might have | |||

dT2,...,dTN } for the packet from Src at time T to { Recv1,...,RecvN | different "weight" to present the group performance, which is | |||

}. | especially true for delay and jitter relevant metrics. For example, | |||

User1 calculates the Type-P-Finite-One-way-Delay-Mean R1DM as shown | ||||

in Figure. 8 without any packet loss and User2 calculates the R2DM | ||||

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

in the whole sample interval. One possible solution is to use a | ||||

weight factor to mark every statistic value sent by users and use | ||||

this factor for further statistic calculation. | ||||

For example, suppose we take a delay vector and the results is: | 6.2. General Metric Parameters | |||

Delay_Vector = {dT1,...,dTN} | o Src, the IP address of a host | |||

Then the mean over space dimension would be: | o G, the Group IP address | |||

Delay_Space_Mean = DsM = sum{dT1,...,dTN}/N | o N, the number of Receivers (Recv1, Recv2, ... RecvN) | |||

5.4.2. Type-P-one-to-group-One-way-Delay-Variation-Stream | o T, a time (start of test interval) | |||

Given a Type-P-one-to-group-One-way-Delay-Vector, the variation { | o Tf, a time (end of test interval) | |||

dT1, dT2,...,dTN } for the packet from Src at time T to { | ||||

Recv1,...,RecvN }. | ||||

We still take the above Delay_Vector as an sample and the variation | o K, the number of packets sent from the source during the test | |||

would be: | interval | |||

o J[n], the number of packets received at a particular Receiver, n, | ||||

where 1<=n<=N | ||||

Delay_Variation_Stream = {SUM[(dT1-DsM)^2,...,(dTN- | o lambda, a rate in reciprocal seconds (for Poisson Streams) | |||

DsM)^2)}/N)^(1/2) | ||||

6. Extension from one-to-one to one-to-many measurement | o incT, the nominal duration of inter-packet interval, first bit to | |||

first bit (for Periodic Streams) | ||||

The above one-to-group metrics were defined to compose measurement | o T0, a time that MUST be selected at random from the interval [T, | |||

results of a group of users who receive the same data from one | T+I] to start generating packets and taking measurements (for | |||

source. Moreover, this is one of efforts to introducing the one-to- | Periodic Streams) | |||

many concern to the IPPM working group with respect to the fact that | ||||

all existing documents in the group are unicast oriented, which talk | ||||

about only one-to-one single "path" in measurements. This concept | ||||

can be extended from the "path" to "path tree" to cover both one-to- | ||||

one and one-to-many communications. Actually, the one-to-one | ||||

communications can be viewed as a special case of one-to-many from | ||||

the routing point of view. The one-to-many communications build up a | ||||

routing tree in the networks and one-to-one can be viewed as a | ||||

special simplified tree without branches but only the "trunk". | ||||

Therefore, the one-to-group metrics described in this memo can even | o TstampSrc, the wire time of the packet as measured at MP(Src) (the | |||

be viewed as general metrics to measure the delay, jitter and packet | Source Measurement Point) | |||

loss in IP networks. When it applies to one-to-one communications, | ||||

the metrics will have N receivers while N equal to 1. And the | ||||

statistic metrics for one-to-one communications are exactly the one- | ||||

to-group metrics themselves when calculated using the methods given. | ||||

7. Open issues | o TstampRecv, the wire time of the packet as measured at MP(Recv), | |||

assigned to packets that arrive within a "reasonable" time | ||||

8. Security Considerations | o Tmax, a maximum waiting time for packets at the destination, set | |||

sufficiently long to disambiguate packets with long delays from | ||||

packets that are discarded (lost), thus the distribution of delay | ||||

is not truncated | ||||

Active measumrement: see security section in owd pl, jitter rfcs | o dT, shorthand notation for a one-way delay singleton value | |||

(editor notes: add references). | ||||

passive measurement: | 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 | ||||

the destination within TstampSrc + Tmax, may be indexed over n | ||||

Receivers | ||||

o DV, shorthand notation for a one-way delay variation singleton | ||||

value | ||||

6.3. One-to-Group one-way Delay Statistics | ||||

This section defines the overall one-way delay statistics for an | ||||

entire Group or receivers. For example, we can define the group mean | ||||

delay, as illustrated below. This is a metric designed to summarize | ||||

the entire Matrix. | ||||

Recv /----------- Sample -------------\ Stats Group Stat | ||||

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

| | ||||

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

| | ||||

3 R3dT1 R3dT2 R3dT3 ... R3dTk R2DM > GMD | ||||

. | | ||||

. | | ||||

. | | ||||

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

Figure 8: One-to-GroupGroup Mean Delay | ||||

where: | ||||

R1dT1 is the Type-P-Finite-One-way-Delay singleton evaluated at | ||||

Receiver 1 for packet 1. | ||||

R1DM is the Type-P-Finite-One-way-Delay-Mean evaluated at Receiver 1 | ||||

for the sample of packets (1,...K). | ||||

GMD is the mean of the sample means over all Receivers (1, ...N). | ||||

6.3.1. Definition and Metric Units | ||||

Using the parameters above, we obtain the value of Type-P-One-way- | ||||

Delay singleton for all packets sent during the test interval at each | ||||

Receiver (Destination), as per [RFC2679]. For each packet that | ||||

arrives within Tmax of its sending time, TstampSrc, the one-way delay | ||||

singleton (dT) will be a finite value in units of seconds. | ||||

Otherwise, the value of the singleton is Undefined. | ||||

For each packet [i] that has a finite One-way Delay at Receiver n (in | ||||

other words, excluding packets which have undefined one-way delay): | ||||

Type-P-Finite-One-way-Delay-Receiver-n-[i] = | ||||

= TstampRecv[i] - TstampSrc[i] | ||||

The units of Finite one-way delay are seconds, with sufficient | ||||

resolution to convey 3 significant digits. | ||||

6.3.2. Sample Mean Statistic | ||||

This section defines the Sample Mean at each of N Receivers. | ||||

Type-P-Finite-One-way-Delay-Mean-Receiver-n = RnDM = | ||||

J[n] | ||||

--- | ||||

1 \ | ||||

--- * > Type-P-Finite-One-way-Delay-Receiver-n-[i] | ||||

J[n] / | ||||

--- | ||||

i = 1 | ||||

Figure 9: Type-P-Finite-One-way-Delay-Mean-Receiver-n | ||||

where all packets i= 1 through J[n] have finite singleton delays. | ||||

6.3.3. One-to-Group Mean Delay Statistic | ||||

This section defines the Mean One-way Delay calculated over the | ||||

entire Group (or Matrix). | ||||

Type-P-One-to-Group-Mean-Delay = GMD = | ||||

N | ||||

--- | ||||

1 \ | ||||

- * > RnDM | ||||

N / | ||||

--- | ||||

n = 1 | ||||

Figure 10: Type-P-One-to-Group-Mean-Delay | ||||

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

number of Finite One-way Delay singletons. | ||||

6.3.4. One-to-Group Range of Mean Delays | ||||

This section defines a metric for the range of mean delays over all N | ||||

receivers in the Group, (R1DM, R2DM,...RnDM). | ||||

Type-P-One-to-Group-Range-Mean-Delay = GRMD = max(RnDM) - min(RnDM) | ||||

6.3.5. One-to-Group Maximum of Mean Delays | ||||

This section defines a metrics for the maximum of mean delays over | ||||

all N receivers in the Group, (R1DM, R2DM,...RnDM). | ||||

Type-P-One-to-Group-Max-Mean-Delay = GMMD = max(RnDM) | ||||

6.4. One-to-Group one-way Loss Statistics | ||||

This section defines the overall 1-way loss statistics for an entire | ||||

Group. For example, we can define the group loss ratio, as | ||||

illustrated below. This is a metric designed to summarize the entire | ||||

Matrix. | ||||

Recv /----------- Sample ----------\ Stats Group Stat | ||||

1 R1L1 R1L2 R1L3 ... R1Lk R1LR \ | ||||

| | ||||

2 R2L1 R2L2 R2L3 ... R2Lk R2LR | | ||||

| | ||||

3 R3L1 R3L2 R3L3 ... R3Lk R3LR > GLR | ||||

. | | ||||

. | | ||||

. | | ||||

n RnL1 RnL2 RnL3 ... RnLk RnLR / | ||||

Figure 11: One-to-Group Loss Ratio | ||||

where: | ||||

R1L1 is the Type-P-One-way-Loss singleton (L) evaluated at Receiver 1 | ||||

for packet 1. | ||||

R1LR is the Type-P-One-way-Loss-Ratio evaluated at Receiver 1 for the | ||||

sample of packets (1,...K). | ||||

GLR is the loss ratio over all Receivers (1, ..., N). | ||||

6.4.1. One-to-Group Loss Ratio | ||||

The overall Group loss ratio id defined as | ||||

Type-P-One-to-Group-Loss-Ratio = | ||||

K,N | ||||

--- | ||||

1 \ | ||||

= --- * > L(k,n) | ||||

K*N / | ||||

--- | ||||

k,n = 1 | ||||

Figure 12 | ||||

ALL Loss ratios are expressed in units of packets lost to total | ||||

packets sent. | ||||

6.4.2. One-to-Group Loss Ratio Range | ||||

Given a Matrix of loss singletons as illustrated above, determine the | ||||

Type-P-One-way-Packet-Loss-Average for the sample at each receiver, | ||||

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

way-Loss-Ratio illustrated above are equivalent metrics. In terms of | ||||

the parameters used here, these metrics definitions can be expressed | ||||

as | ||||

Type-P-One-way-Loss-Ratio-Receiver-n = RnLR = | ||||

K | ||||

--- | ||||

1 \ | ||||

- * > RnLk | ||||

K / | ||||

--- | ||||

k = 1 | ||||

Figure 13: Type-P-One-way-Loss-Ratio-Receiver-n | ||||

The One-to-Group Loss Ratio Range is defined as | ||||

Type-P-One-to-Group-Loss-Ratio-Range = max(RnLR) - min(RnLR) | ||||

It is most effective to indicate the range by giving both the max and | ||||

minimum loss ratios for the Group, rather than only reporting the | ||||

difference between them. | ||||

6.4.3. Comparative Loss Ratio | ||||

Usually, the number of packets sent is used in the denominator of | ||||

packet loss ratio metrics. For the comparative metrics defined here, | ||||

the denominator is the maximum number of packets received at any | ||||

receiver for the sample and test interval of interest. | ||||

The Comparative Loss Ratio is defined as | ||||

Type-P-Comp-Loss-Ratio-Receiver-n = RnCLR = | ||||

K | ||||

--- | ||||

\ | ||||

> Ln(k) | ||||

/ | ||||

--- | ||||

k=1 | ||||

= ----------------------------- | ||||

/ K \ | ||||

| --- | | ||||

| \ | | ||||

K - Min | > Ln(k) | | ||||

| / | | ||||

| --- | | ||||

\ k=1 / N | ||||

Figure 14: Type-P-Comp-Loss-Ratio-Receiver-n | ||||

6.5. One-to-Group one-way Delay Variation Statistics | ||||

There is are two delay variation (DV) statistics to summarize the | ||||

performance over the Group: the maximum DV over all receivers and the | ||||

range of DV over all receivers. | ||||

The detailed definitions are T0 BE PROVIDED. | ||||

7. Measurement Methods: Scaleability and Reporting | ||||

Virtually all the guidance on measurement processes supplied by the | ||||

earlier IPPM RFCs (such as [RFC2679] and [RFC2680]) for one-to-one | ||||

scenarios is applicable here in the spatial and multiparty | ||||

measurement scenario. The main difference is that the spatial and | ||||

multiparty configurations require multiple measurement points where a | ||||

stream of singletons will be collected. The amount of information | ||||

requiring storage grows with both the number of metrics and the | ||||

number of measurement points, so the scale of the measurement | ||||

architecture multiplies the number of singleton results that must be | ||||

collected and processed. | ||||

It is possible that the architecture for results collection involves | ||||

a single aggregation point with connectivity to all the measurement | ||||

points. In this case, the number of measurement points determines | ||||

both storage capacity and packet transfer capacity of the host acting | ||||

as the aggregation point. However, both the storage and transfer | ||||

capacity can be reduced if the measurement points are capable of | ||||

computing the summary statistics that describe each measurement | ||||

interval. This is consistent with many operational monitoring | ||||

architectures today, where even the individual singletons may not be | ||||

stored at each measurement point. | ||||

In recognition of the likely need to minimize form of the results for | ||||

storage and communication, the Group metrics above have been | ||||

constructed to allow some computations on a per-Receiver basis. This | ||||

means that each Receiver's statistics would normally have an equal | ||||

weight with all other Receivers in the Group (regardless of the | ||||

number of packets received). | ||||

7.1. Computation methods | ||||

The scalability issue can be raised when there are thousands of | ||||

points of interest in a group who are trying to send back the | ||||

measurement results to the reference point for further processing and | ||||

analysis. The points of interest can send either the whole measured | ||||

sample or only the calculated statistics. The former one is a | ||||

centralized statistic calculation method and the latter one is a | ||||

distributed statistic calculation method. The sample should include | ||||

all metrics parameters, the values and the corresponding sequence | ||||

numbers. The transmission of the whole sample can cost much more | ||||

bandwidth than the transmission of the statistics that should include | ||||

all statistic parameters specified by policies and the additional | ||||

information about the whole sample, such as the size of the sample, | ||||

the group address, the address of the point of interest, the ID of | ||||

the sample session, and so on. Apparently, the centralized | ||||

calculation method can require much more bandwidth than the | ||||

distributed calculation method when the sample size is big. This is | ||||

especially true when the measurement has huge number of the points of | ||||

interest. It can lead to a scalability issue at the reference point | ||||

by over load the network resources. The distributed calculation | ||||

method can save much more bandwidth and release the pressure of the | ||||

scalability issue at the reference point side. However, it can | ||||

result in the lack of information because not all measured singletons | ||||

are obtained for building up the group matrix. The performance over | ||||

time can be hidden from the analysis. For example, the loss pattern | ||||

can be missed by simply accepting the loss ratio as well as the delay | ||||

pattern. This tradeoff between the bandwidth consuming and the | ||||

information acquiring has to be taken into account when design the | ||||

measurement campaign to optimize the measurement results delivery. | ||||

The possible solution could be to transit the statistic parameters to | ||||

the reference point first to obtain the general information of the | ||||

group performance. If the detail results are required, the reference | ||||

point should send the requests to the points of interest, which could | ||||

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

many points of interest at the same time. Compression techniques can | ||||

also be used to minimize the bandwidth required by the transmission. | ||||

This could be a measurement protocol to report the measurement | ||||

results. It is out of the scope of this memo. | ||||

7.2. Measurement | ||||

To prevent any biais in the result, the configuration of a one-to- | ||||

many measure must take in consideration that implicitly more packets | ||||

will to be routed than send and selects a test packets rate that will | ||||

not impact the network performance. | ||||

7.3. effect of Time and Space Aggregation Order on Group Stats | ||||

This section presents the impact of the aggregation order on the | ||||

scalability of the reporting and of the the computation. It makes | ||||

the hypothesis that receivers are managed remotly 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 | ||||

1 R1S1 R1S1 R1S1 ... R1Sk \ | ||||

| | ||||

2 R2S1 R2S2 R2S3 ... R2Sk | | ||||

| | ||||

3 R3S1 R3S2 R3S3 ... R3Sk > sample over space | ||||

. | | ||||

. | | ||||

. | | ||||

n RnS1 RnS2 RnS3 ... RnSk / | ||||

S1M S2M S3M ... SnM Stats over space | ||||

\------------- ------------/ | ||||

\/ | ||||

Group Stat over space and time | ||||

Figure 15: Impact of space aggregation on Group Stat | ||||

In both cases the volume of data to report is proportional to the | ||||

number of probes. But there is a major difference between these 2 | ||||

methods: | ||||

method2: In space and time aggregation mode the volume of data to | ||||

collect is proportionnal to the number of test packets received; | ||||

Each received packet RiSi triggers out a block of data that must | ||||

be reported to a common place for computing the stat over space; | ||||

method1: In time and space aggregation mode the volume of data to | ||||

collect is proportionnal to the period of aggregation, so it does | ||||

not depend on the number of packet received; | ||||

Method 2 property has severe drawbacks in terms of security and | ||||

dimensionning: | ||||

The increasing of the rate of the test packets may result in a | ||||

sort of DoS toward the computation points; | ||||

The dimensioning of a measurement system is quite impossible to | ||||

validate. | ||||

The time agregation interval provides the reporting side with a | ||||

control of various collecting aspects such as bandwidth and | ||||

computation and storage capacities. So this draft defines metrics | ||||

based on method 1. | ||||

Note: In some specific cases one may need sample of singletons over | ||||

space. To adress this need it is suggested firstly to limit the | ||||

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

of singleton over space.. | ||||

7.4. effect of Time and Space Aggregation Order on Spatial Stats | ||||

TBD | ||||

8. Open issues | ||||

9. Security Considerations | ||||

Active measurement: (TODO: security considerations of owd pl, jitter | ||||

rfcs applies (editor notes: add references). | ||||

9.1. passive measurement | ||||

The generation of packets which match systematically the hash | The generation of packets which match systematically the hash | |||

function may lead to a DoS attack toward the collector. | function may lead to a DoS attack toward the collector. | |||

The generation of packets with spoofing adresses may corrupt the | The generation of packets with spoofing addresses may corrupt the | |||

results without any possibility to detect the spoofing. | results without any possibility to detect the spoofing. | |||

one-to-group metrics require collection of singletons which may | 9.2. one-to-group metric | |||

overload the network the measurement controller is attach to. | ||||

9. Acknowledgments | The configuration of a measure must take in consideration that | |||

implicitly more packets will to be routed than send and selects a | ||||

test packets rate accordingly. | ||||

Collecting statistics from a huge number of probes may overload any | ||||

combination of the network the measurement controller is attach to, | ||||

measurement controller network interfaces and measurement controller | ||||

computation capacities. | ||||

one-to-group metrics: | ||||

10. Acknowledgments | ||||

Lei would like to acknowledge Zhili Sun from CCSR, University of | Lei would like to acknowledge Zhili Sun from CCSR, University of | |||

Surrey, for his instruction and helpful comments on this work. | Surrey, for his instruction and helpful comments on this work. | |||

10. IANA Considerations | 11. IANA Considerations | |||

Metrics defined in this memo will be registered in the IANA IPPM | Metrics defined in this memo Metrics defined in this memo are | |||

METRICS REGISTRY as described in initial version of the registry | designed to be registered in the IANA IPPM METRICS REGISTRY as | |||

[RFC4148]. | described in initial version of the registry [RFC4148] : | |||

11. References | IANA is asked to register the following metrics in the IANA-IPPM- | |||

METRICS-REGISTRY-MIB : | ||||

11.1. Normative References | Spatial-One-way-Delay-Vector OBJECT-IDENTITY | |||

STATUS current | ||||

DESCRIPTION | ||||

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

REFERENCE | ||||

"Reference "RFCyyyy, section 4.1." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | ||||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | ||||

subpath-One-way-Delay-Stream OBJECT-IDENTITY | ||||

STATUS current | ||||

DESCRIPTION | ||||

"Type-P-subpath-One-way-Delay-Stream" | ||||

REFERENCE | ||||

"Reference "RFCyyyy, section 4.2." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | ||||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | ||||

Spatial-One-way-Packet-Loss-Vector OBJECT-IDENTITY | ||||

STATUS current | ||||

DESCRIPTION | ||||

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

REFERENCE | ||||

"Reference "RFCyyyy, section 4.3." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | ||||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | ||||

Spatial-One-way-Jitter-Vector OBJECT-IDENTITY | ||||

STATUS current | ||||

DESCRIPTION | ||||

"Type-P-Spatial-One-way-Jitter-Vector" | ||||

REFERENCE | ||||

"Reference "RFCyyyy, section 4.4." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | ||||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | ||||

one-to-group-One-way-Delay-Vector OBJECT-IDENTITY | ||||

STATUS current | ||||

DESCRIPTION | ||||

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

REFERENCE | ||||

"Reference "RFCyyyy, section 5.1." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | ||||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | ||||

one-to-group-One-way-Packet-Loss-Vector OBJECT-IDENTITY | ||||

STATUS current | ||||

DESCRIPTION | ||||

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

REFERENCE | ||||

"Reference "RFCyyyy, section 5.2." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | ||||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | ||||

one-to-group-One-way-Jitter-Vector OBJECT-IDENTITY | ||||

STATUS current | ||||

DESCRIPTION | ||||

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

REFERENCE | ||||

"Reference "RFCyyyy, section 5.3." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | ||||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | ||||

One-to-Group-Mean-Delay OBJECT-IDENTITY | ||||

STATUS current | ||||

DESCRIPTION | ||||

"Type-P-One-to-Group-Mean-Delay" | ||||

REFERENCE | ||||

"Reference "RFCyyyy, section 6.3.3." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | ||||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | ||||

One-to-Group-Range-Mean-Delay OBJECT-IDENTITY | ||||

STATUS current | ||||

DESCRIPTION | ||||

"Type-P-One-to-Group-Range-Mean-Delay" | ||||

REFERENCE | ||||

"Reference "RFCyyyy, section 6.3.4." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | ||||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | ||||

One-to-Group-Max-Mean-Delay OBJECT-IDENTITY | ||||

STATUS current | ||||

DESCRIPTION | ||||

"Type-P-One-to-Group-Max-Mean-Delay" | ||||

REFERENCE | ||||

"Reference "RFCyyyy, section 6.3.5." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | ||||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | ||||

One-to-Group-Loss-Ratio OBJECT-IDENTITY | ||||

STATUS current | ||||

DESCRIPTION | ||||

"Type-P-One-to-Group-Loss-Ratio" | ||||

REFERENCE | ||||

"Reference "RFCyyyy, section 6.4.1." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | ||||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | ||||

-- | ||||

One-to-Group-Loss-Ratio-Range OBJECT-IDENTITY | ||||

STATUS current | ||||

DESCRIPTION | ||||

"Type-P-One-to-Group-Loss-Ratio-Range" | ||||

REFERENCE | ||||

"Reference "RFCyyyy, section 6.4.2." | ||||

-- RFC Ed.: replace yyyy with actual RFC number & remove this | ||||

note | ||||

:= { ianaIppmMetrics nn } -- IANA assigns nn | ||||

-- | ||||

12. References | ||||

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

11.2. Informative References | 12.2. Informative References | |||

[I-D.boschi-ipfix-reducing-redundancy] | ||||

Boschi, E., "Reducing redundancy in IPFIX and PSAMP | ||||

reports", draft-boschi-ipfix-reducing-redundancy-02 (work | ||||

in progress), June 2006. | ||||

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

Morton, A. and E. Stephan, "Spatial Composition of | ||||

Metrics", draft-ietf-ippm-spatial-composition-01 (work in | ||||

progress), June 2006. | ||||

[I-D.quittek-ipfix-middlebox] | ||||

Quittek, J., "Guidelines for IPFIX Implementations on | ||||

Middleboxes", draft-quittek-ipfix-middlebox-00 (work in | ||||

progress), February 2004. | ||||

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

skipping to change at page 29, line 13 | skipping to change at page 43, line 28 | |||

Metrics", RFC 3357, August 2002. | Metrics", RFC 3357, August 2002. | |||

[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network | [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network | |||

performance measurement with periodic streams", RFC 3432, | performance measurement with periodic streams", RFC 3432, | |||

November 2002. | November 2002. | |||

[RFC3763] Shalunov, S. and B. Teitelbaum, "One-way Active | [RFC3763] Shalunov, S. and B. Teitelbaum, "One-way Active | |||

Measurement Protocol (OWAMP) Requirements", RFC 3763, | Measurement Protocol (OWAMP) Requirements", RFC 3763, | |||

April 2004. | April 2004. | |||

[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. | ||||

Zekauskas, "A One-way Active Measurement Protocol | ||||

(OWAMP)", RFC 4656, September 2006. | ||||

[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, | ||||

S., and J. Perser, "Packet Reordering Metrics", RFC 4737, | ||||

November 2006. | ||||

Authors' Addresses | Authors' Addresses | |||

Stephan Emile | Stephan Emile | |||

France Telecom Division R&D | France Telecom Division R&D | |||

2 avenue Pierre Marzin | 2 avenue Pierre Marzin | |||

Lannion, F-22307 | Lannion, F-22307 | |||

Fax: +33 2 96 05 18 52 | Fax: +33 2 96 05 18 52 | |||

Email: emile.stephan@orange-ft.com | Email: emile.stephan@orange-ftgroup.com | |||

Lei Liang | Lei Liang | |||

CCSR, University of Surrey | CCSR, University of Surrey | |||

Guildford | Guildford | |||

Surrey, GU2 7XH | Surrey, GU2 7XH | |||

Fax: +44 1483 683641 | Fax: +44 1483 683641 | |||

Email: L.Liang@surrey.ac.uk | Email: L.Liang@surrey.ac.uk | |||

Al Morton | Al Morton | |||

200 Laurel Ave. South | 200 Laurel Ave. South | |||

Middletown, NJ 07748 | Middletown, NJ 07748 | |||

USA | USA | |||

Phone: +1 732 420 1571 | Phone: +1 732 420 1571 | |||

Email: acmorton@att.com | Email: acmorton@att.com | |||

Full Copyright Statement | Full Copyright Statement | |||

Copyright (C) The Internet Society (2006). | Copyright (C) The IETF Trust (2007). | |||

This document is subject to the rights, licenses and restrictions | This document is subject to the rights, licenses and restrictions | |||

contained in BCP 78, and except as set forth therein, the authors | contained in BCP 78, and except as set forth therein, the authors | |||

retain all their rights. | retain all their rights. | |||

This document and the information contained herein are provided on an | This document and the information contained herein are provided on an | |||

"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | |||

OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | |||

ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | |||

INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | |||

INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | |||

WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |||

Intellectual Property | Intellectual Property | |||

The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||

Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||

pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||

this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||

might or might not be available; nor does it represent that it has | might or might not be available; nor does it represent that it has | |||

made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||

End of changes. 96 change blocks. | ||||

268 lines changed or deleted | | 874 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/ |