draft-ietf-ippm-multimetrics-05.txt | draft-ietf-ippm-multimetrics-06.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: May 21, 2008 University of Surrey | Expires: August 17, 2008 University of Surrey | |||

A. Morton | A. Morton | |||

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

November 18, 2007 | February 14, 2008 | |||

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

draft-ietf-ippm-multimetrics-05 | draft-ietf-ippm-multimetrics-06 | |||

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 May 21, 2008. | This Internet-Draft will expire on August 17, 2008. | |||

Copyright Notice | Copyright Notice | |||

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

Abstract | Abstract | |||

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

metrics for measuring end-to-end performance between two points. | metrics for measuring end-to-end performance between two points. | |||

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

coverage to multiple measurement points. It defines spatial metrics | coverage to multiple measurement points. It defines spatial metrics | |||

for measuring the performance of segments of a source to destination | for measuring the performance of segments of a source to destination | |||

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

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

tree). | tree). | |||

Table of Contents | Table of Contents | |||

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

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

2.1. Path Digest Hosts . . . . . . . . . . . . . . . . . . . . 6 | 2.1. Path Digest Hosts . . . . . . . . . . . . . . . . . . . . 6 | |||

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

2.3. Spatial metric . . . . . . . . . . . . . . . . . . . . . . 6 | 2.3. Spatial metric . . . . . . . . . . . . . . . . . . . . . . 6 | |||

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

2.5. Points of interest . . . . . . . . . . . . . . . . . . . . 6 | 2.5. Points of interest . . . . . . . . . . . . . . . . . . . . 7 | |||

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

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

2.8. Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 2.8. Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||

3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||

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

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

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

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

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

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

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

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

5. Spatial Segments metrics definitions . . . . . . . . . . . . . 19 | 5. Spatial Segments metrics definitions . . . . . . . . . . . . . 18 | |||

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

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

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

of the path . . . . . . . . . . . . . . . . . . . . . . . 20 | of the path . . . . . . . . . . . . . . . . . . . . . . . 20 | |||

5.3. A Definition of a sample of One-way Ipdv of a segment | 5.3. A Definition of a sample of ipdv of a segment using | |||

of the path . . . . . . . . . . . . . . . . . . . . . . . 23 | the previous packet selection function . . . . . . . . . . 22 | |||

6. One-to-group metrics definitions . . . . . . . . . . . . . . . 23 | 5.4. A Definition of a sample of ipdv of a segment using | |||

6.1. A Definition for one-to-group One-way Delay . . . . . . . 23 | the minimum delay selection function . . . . . . . . . . . 24 | |||

6.2. A Definition for one-to-group One-way Packet Loss . . . . 24 | 6. One-to-group metrics definitions . . . . . . . . . . . . . . . 25 | |||

6.3. A Definition for one-to-group One-way Ipdv . . . . . . . . 25 | 6.1. A Definition for One-to-group One-way Delay . . . . . . . 26 | |||

7. One-to-Group Sample Statistics . . . . . . . . . . . . . . . . 26 | 6.2. A Definition for One-to-group One-way Packet Loss . . . . 26 | |||

7.1. Discussion on the Impact of packet loss on statistics . . 29 | 6.3. A Definition for One-to-group One-way Ipdv . . . . . . . . 27 | |||

7.2. General Metric Parameters . . . . . . . . . . . . . . . . 30 | 7. One-to-Group Sample Statistics . . . . . . . . . . . . . . . . 28 | |||

7.3. One-to-Group one-way Delay Statistics . . . . . . . . . . 31 | 7.1. Discussion on the Impact of packet loss on statistics . . 31 | |||

7.4. One-to-Group one-way Loss Statistics . . . . . . . . . . . 33 | 7.2. General Metric Parameters . . . . . . . . . . . . . . . . 32 | |||

7.5. One-to-Group one-way Delay Variation Statistics . . . . . 35 | 7.3. One-to-Group one-way Delay Statistics . . . . . . . . . . 33 | |||

8. Measurement Methods: Scaleability and Reporting . . . . . . . 35 | 7.4. One-to-Group one-way Loss Statistics . . . . . . . . . . . 36 | |||

8.1. Computation methods . . . . . . . . . . . . . . . . . . . 36 | 7.5. One-to-Group one-way Delay Variation Statistics . . . . . 38 | |||

8.2. Measurement . . . . . . . . . . . . . . . . . . . . . . . 37 | 8. Measurement Methods: Scalability and Reporting . . . . . . . . 38 | |||

8.3. Effect of Time and Space Aggregation Order on Stats . . . 37 | 8.1. Computation methods . . . . . . . . . . . . . . . . . . . 39 | |||

9. Manageability Considerations . . . . . . . . . . . . . . . . . 39 | 8.2. Measurement . . . . . . . . . . . . . . . . . . . . . . . 40 | |||

9.1. Reporting spatial metric . . . . . . . . . . . . . . . . . 39 | 8.3. Effect of Time and Space Aggregation Order on Stats . . . 40 | |||

9.2. Reporting One-to-group metric . . . . . . . . . . . . . . 40 | 9. Manageability Considerations . . . . . . . . . . . . . . . . . 42 | |||

9.3. Metric identification . . . . . . . . . . . . . . . . . . 41 | 9.1. Reporting spatial metric . . . . . . . . . . . . . . . . . 42 | |||

9.4. Reporting data model . . . . . . . . . . . . . . . . . . . 41 | 9.2. Reporting One-to-group metric . . . . . . . . . . . . . . 43 | |||

10. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 44 | 9.3. Metric identification . . . . . . . . . . . . . . . . . . 44 | |||

11. Security Considerations . . . . . . . . . . . . . . . . . . . 45 | 9.4. Reporting data model . . . . . . . . . . . . . . . . . . . 44 | |||

11.1. Spatial metrics . . . . . . . . . . . . . . . . . . . . . 45 | 10. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 47 | |||

11.2. one-to-group metric . . . . . . . . . . . . . . . . . . . 45 | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 47 | |||

12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45 | 11.1. Spatial metrics . . . . . . . . . . . . . . . . . . . . . 48 | |||

13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 | 11.2. one-to-group metric . . . . . . . . . . . . . . . . . . . 48 | |||

14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 | 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 | |||

14.1. Normative References . . . . . . . . . . . . . . . . . . . 51 | 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 | |||

14.2. Informative References . . . . . . . . . . . . . . . . . . 51 | 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 | |||

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 | 14.1. Normative References . . . . . . . . . . . . . . . . . . . 54 | |||

Intellectual Property and Copyright Statements . . . . . . . . . . 54 | 14.2. Informative References . . . . . . . . . . . . . . . . . . 55 | |||

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 | ||||

Intellectual Property and Copyright Statements . . . . . . . . . . 57 | ||||

1. Introduction | 1. Introduction | |||

The IP Performance Metrics (IPPM) WG has defined a framework for | The IP Performance Metrics (IPPM) WG has defined a framework for | |||

metric definitions and end-to-end, or source to destination | metric definitions and end-to-end, or source to destination | |||

measurements: | measurements: | |||

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

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

skipping to change at page 5, line 16 | skipping to change at page 5, line 16 | |||

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

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

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

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

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

ipdv metrics. | ipdv metrics. | |||

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

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

collect a nested set of one-way delay metrics between the source, | collect one-way delay metrics over time between two points of | |||

intermediate points of interest, and the destination; | interest of the path; | |||

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

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

collect a nested set of packet loss metrics between the source, | collect packet loss metrics over time between two points of | |||

intermediate points of interest, and the destination; | interest of the path; | |||

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

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

set of ipdv metrics between the source, intermediate points of | compute ipdv metrics over time between two points of interest of | |||

interest, and the destination; | the path using the previous packet selection function; | |||

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

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

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

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

Note that all these metrics are based on observations of packets | Note that all these metrics are based on observations of packets | |||

dedicated to testing, a process which is called Active measurement. | dedicated to testing, a process which is called Active measurement. | |||

Purely passive spatial measurement (for example, a spatial metric | Purely passive spatial measurement (for example, a spatial metric | |||

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

document and the current IPPM charter. | document and the current IPPM charter. | |||

Next, this memo defines one-to-group metrics. | Next, this memo defines one-to-group metrics. | |||

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

skipping to change at page 6, line 35 | skipping to change at page 6, line 40 | |||

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

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

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

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

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

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

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

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

of the measured packet. | of the measured packet. | |||

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. Points of interest | 2.5. Points of interest | |||

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

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

sub-set of the set of hosts involved in the delivery of the packets | sub-set of the set of hosts involved in the delivery of the packets | |||

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

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

path. | path. | |||

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

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

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

Src Recv | Src Recv | |||

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

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

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

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

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

| | | | | | |||

skipping to change at page 8, line 42 | skipping to change at page 8, line 42 | |||

calculations will be carried out. A centre/server in the | calculations will be carried out. A centre/server in the | |||

multimetrics measurement that is controlled by a network operator is | multimetrics measurement that is controlled by a network operator is | |||

a good example of a reference point, where measurement data can be | a good example of a reference point, where measurement data can be | |||

collected for further processing. However, the actual measurements | collected for further processing. However, the actual measurements | |||

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

2.7. Vector | 2.7. Vector | |||

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 times. For instance, if One-way delay | of a network at different times. For instance, if one-way delay | |||

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

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

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

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

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

example, the element dT1 is distinct from all others as the singleton | example, the element dT1 is distinct from all others as the singleton | |||

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

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

space. | space. | |||

2.8. Matrix | 2.8. Matrix | |||

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

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

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

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

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

Additional to the information given by a Vector, a Matrix is more | V2,...,Vm}. Additional to the information given by a Vector, a | |||

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

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

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

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

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

Point of Singleton | Point of Singleton | |||

interest / Samples | interest / Samples | |||

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

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

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

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

skipping to change at page 10, line 17 | skipping to change at page 10, line 17 | |||

o Traffic engineering and troubleshooting applications benefit from | o Traffic engineering and troubleshooting applications benefit from | |||

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

identification of the location of the lost of packets. | identification of the location of the lost of packets. | |||

o Monitoring the performance of a multicast tree composed of MPLS | o Monitoring the performance of a multicast tree composed of MPLS | |||

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

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

o Composition of metrics [I-D.ietf-ippm-spatial-composition] is | o Composition of metrics [I-D.ietf-ippm-spatial-composition] is | |||

needed to help measurement systems reach large scale coverage. | needed to help measurement systems reach large scale coverage. | |||

Spatial measure typically give the individual performance of an | Spatial measures typically give the individual performance of an | |||

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

information needed to estimate interdomain performance based on | information needed to estimate interdomain performance based on | |||

composition of metrics. | composition of metrics. | |||

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

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

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

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

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

skipping to change at page 10, line 50 | skipping to change at page 10, line 50 | |||

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

multipoint LSP; | multipoint LSP; | |||

o For evaluating and controlling of the quality of the multicast | o For evaluating and controlling of the quality of the multicast | |||

services; | services; | |||

o For controlling the performance of the inter domain multicast | o For controlling the performance of the inter domain multicast | |||

services; | services; | |||

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

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

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

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

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

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

in terms of end-to-end absolute performance. This detail can provide | in terms of end-to-end absolute performance. This detail can provide | |||

clear and helpful information for engineers to identify the sub-path | clear and helpful information for engineers to identify the sub-path | |||

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

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

skipping to change at page 11, line 25 | skipping to change at page 11, line 25 | |||

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

packets from the same source. The concept extends the "path" in the | packets 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- | one-way measurement to "path tree" to cover both one-to-one and one- | |||

to-many communications. If applied to one-to-one communications, the | to-many communications. If applied to one-to-one communications, the | |||

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

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

3.3. Discussion on Group-to-one and Group-to-group metrics | 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 | |||

point that is acting as a receiver while all of clients/receivers | point that is acting as a receiver while all of clients/receivers | |||

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

For the group-to-group connection topology, it is difficult to define | For the group-to-group connection topology, it is difficult to define | |||

skipping to change at page 12, line 15 | skipping to change at page 12, line 15 | |||

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

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

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

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

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

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

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

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

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

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

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

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

reporting. | reporting. | |||

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

spatial measurement. | ||||

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

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

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

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

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

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

the path. | path. | |||

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

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

measured packet. | measured packet. | |||

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

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

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

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

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

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

times. | ||||

4.1.4. Definition | 4.1.4. Definition | |||

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

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

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

Type-P-One-way-Delay from Src to Dst and such that for each Hi of the | Type-P-One-way-Delay from Src to Dst and such that for each Hi of the | |||

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

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

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

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

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

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

4.1.5. Discussion | 4.1.5. Discussion | |||

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

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

to some clock synchronisation issue. This point is discussed in | it does not make sense per definition: | |||

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

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

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

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

o The location of the point of interest in the device influences the | * This is frequently due to some clock synchronization issue. | |||

result. If the packet is not observed on the input interface the | This point is discussed in the section 3.7.1. "Errors or | |||

delay includes buffering time and consequently an uncertainty due | uncertainties related to Clocks" of [RFC2679]. Consequently, | |||

to the difference between 'wire time' and 'host time'; | times of a measure at different hosts do not guaranty the | |||

ordering of the hosts on the path of a measure. | ||||

* During some change of routes the order of 2 hosts may change on | ||||

the main path; | ||||

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

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

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

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

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

4.2. A Definition for Spatial One-way Packet Loss Vector | 4.2. 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, uncertainties 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.2.1. Metric Name | 4.2.1. Metric Name | |||

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

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

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

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

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

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

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

a measured packet. | ||||

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

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

+ <SH1, H2,..., Hn>, hosts path digest. | o <H1, H2,..., Hn>, hosts path digest. | |||

+ B1, B2, ..., Bi, ..., Bn, a list of Boolean values. | o <L1, L2, ...,Ln>, a list of Boolean values. | |||

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

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

of Boolean values. | ||||

4.2.4. Definition | 4.2.4. Definition | |||

Given a Type-P packet sent by the sender Src at time T to the | Given a Type-P packet sent by the 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> the packet passes in <H1, H2 ..., Hn>, | |||

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

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

Type-P-One-way-Packet-Lost-Vector metric is defined as the sequence | of 0 for Li means that dTi is a finite value, and a value of 1 means | |||

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

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

means that dTi is undefined. | ||||

4.2.5. Discussion | 4.2.5. Discussion | |||

Following are specific issues which 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 may occur under | |||

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

The location of the point of interest in the device influences the | * During some change of routes a packet may be seen by a host but | |||

result: | not by it successor on the main path; | |||

o Even if the packet is received by a host, it may be not observed | * A packet may not be observed in a host due to some buffer or | |||

by the point of interest located after a buffer; | CPU overflow in the point of interest; | |||

4.3. A Definition for Spatial One-way Ipdv Vector | 4.3. A Definition for Spatial One-way Ipdv 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. | |||

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

are to spatial measurement. | to spatial measurement. | |||

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

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

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

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

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

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

path. | ||||

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

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

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

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

+ P1, the first packet sent at time T1. | o P*, the specification of the packets type. | |||

+ P2, the second packet sent at time T2. | o P1, the first packet sent at time T1. | |||

+ <H1, H2,..., Hn>, host path digest. | o P2, the second packet sent at time T2. | |||

+ <T1,dT1.1, dT1.2,..., dT1.n,dT1>, | o <H1, H2,..., Hn>, hosts path digest. | |||

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

time T1; | ||||

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

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

time T2; | ||||

+ L*, a packet length in bits. The packets of a Type P | o <T2,dT2.1, dT2.2,..., dT2.n,dT2>, the Type-P-Spatial-One-way- | |||

packet stream from which the | Delay-Vector for packet sent at time T2. | |||

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

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

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

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

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

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

times. | ||||

4.3.4. Definition | 4.3.4. Definition | |||

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

at wire-time (first bit) T1 to the receiver Dst in the path <H1, | bit) T1 to the receiver Dst and <T1, dT1.1, dT1.2,..., dT1.n, dT1> | |||

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

Hn>. | ||||

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

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

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

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

Given the Type-P-Spatial-One-way-Delay-Vector <T2,dT2.1, dT2.2,..., | Given P2 the Type-P packet sent by the sender Src at wire-time (first | |||

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Spatial One-way ipdv measurement SHOULD be respectful of methodology, | Spatial One-way ipdv measurement SHOULD be respectful of methodology, | |||

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

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

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

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

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

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

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

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

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

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

skipping to change at page 18, line 4 | skipping to change at page 17, line 27 | |||

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

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

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

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

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

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

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

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

o The reference point gathers the result and time-to-live of each Hi | o The reference point gathers the result of each Hi and order them | |||

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

One-way-Delay-Vector metric <T,dT1,dT2,...,dTn,dT> over the path | type-P spatial one-way vector (e.g. Type-P-Spatial-One-way-Delay- | |||

<Src,H1, H2,..., Hn, Dst>. | Vector metric <T, dT1, dT2,..., dTn, dT> ) over the path <Src, H1, | |||

H2,..., Hn, Dst> at time T. | ||||

4.4.1. Loss threshold | 4.4.1. Loss threshold | |||

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

the statistic computation process. | the statistic computation process. | |||

4.4.2. Host Path Digest | 4.4.2. Host Path Digest | |||

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

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

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

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

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

o <Ha,..., Ha> coresponds to a loop in the path; | A test packets may cross several times the same host resulting in the | |||

repetition of one or several hosts in the Path Digest. | ||||

o <Ha,..,Hb,..., Ha,...,Hb> coresponds to a loop in the path which | As an example. This occurs typically during rerouting phases which | |||

may occurs during rerouting phases; | introduce temporary micro loops. During such an event the host path | |||

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

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

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

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

These cases MUST be identified before statistics computation to avoid | Consequently, duplication of hosts in the Path Digest of a vectors | |||

corrupted results' production. This applies especially to the | MUST be identified before statistics computation to avoid corrupted | |||

measure of segments which are build from results of a measure of a | results' production. | |||

vector metric. | ||||

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

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

sequence of lost and a sequence of ipdv between 2 hosts of the path, | of a path over time. Definitions rely on matrix of the spatial | |||

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

above. | ||||

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

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

loss-Stream. | ||||

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

P-Segment-One-way-ipdv-prev-Stream, uses the previous packet as the | ||||

selection function. The second metric, Type-P-Segment-One-way-ipdv- | ||||

min-Stream, uses the minimum delay as the selection. | ||||

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

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

hosts of a path. | pair of hosts of a path. | |||

As its semantic is very close to the metric Type-P-Packet-loss-Stream | ||||

defined in section 4 of [RFC2679], sections 4.5 to 4.8 of [RFC2679] | ||||

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

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

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

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

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

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

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

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

path. | ||||

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

+ Hi, a host of the path digest; | o a and b, 2 integers where b > a. | |||

+ <H1, H2,..., Hn>, host path digest. | o Hi, a host* of the path digest. | |||

+ Ha, a host of the path digest different from Dst and Hb; | o <H1,..., Ha, ..., Hb, ...., Hn>, hosts path digest. | |||

+ Hb, a host of the path digest different from Src and Ha. | o <T1, T2, ..., Tm>, a list of times. | |||

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

+ <T1, ..., Tk>, a list of time ordered by k; | 5.1.3. Metric Units | |||

+ dT1,..., dTn a list of delay; | The value of a Type-P-Segment-One-way-Delay-Stream is a pair of | |||

5.1.3. Metric Units | list of times <T1, T2, ..., Tm>; | |||

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

5.1.4. Definition | 5.1.4. Definition | |||

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

a flow of packets of Type-P sent from Src to Dst at the times T1, | Hn>, given the matrix of Type-P-Spatial-One-way-Delay-Vector for the | |||

T2... Tn. At each of these times, we obtain a Type-P-Spatial-One- | packets sent from Src to Dst at times <T1, T2, ..., Tm-1, Tm> : | |||

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

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

sequence made up of the delays dTk.b - dTk.a. dTk.a is the delay | ||||

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

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

the time Tk when going from Ha to Hb. | ||||

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

Following are specific issues which may occur: | <T2, dT2.1, dT2.2, ..., dT2.a, ..., dT2.b,..., dT2.n, dT2>; | |||

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

o When b is Dst <Tk,dTk.b - dTk.a> is the measure of the last hop. | <Tm, dTm.1, dTm.2, ..., dTm.a, ..., dTm.b,..., dTm.n, dTm>. | |||

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

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

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

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

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

5.1.5. Discussion | ||||

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

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 due to clock synchronization issue. this | |||

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

related to Clocks" of of [RFC2679]; | uncertainties 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 minimum 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 | The metric can not be performed on < T1 , T2, ..., Tm-1, Tm> in the | |||

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

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

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

o dTk.b may be observed and not dTk.a. | o Ha or Hb disappears from the path due to some change of routes; | |||

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

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

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

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

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

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

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

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

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

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

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

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

+ k, An integer which orders the packets sent. | o P*, the specification of the packet type. | |||

+ n, An integer which orders the hosts on the path. | o k, an integer which orders the packets sent. | |||

+ <H1, H2,..., Hn>, hosts path digest. | o n, an integer which orders the hosts on the path. | |||

+ Ha, a host of the path digest different from Dst and Hb; | o a and b, 2 integers where b > a. | |||

+ Hb, a host of the path digest different from Src and Ha. | o <H1, H2, ..., Ha, ..., Hb, ...,Hn>, hosts path digest. | |||

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

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

+ <B1, B2, ..., Bn> a list of bits. | o <T1, T2, ..., Tm>, a list of times. | |||

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

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

A sequence of integers <L1, L2,..., Lk> | The value of a Type-P-segment-Packet-loss-Stream is a pair of | |||

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

a sequence of booleans. | ||||

5.2.4. Definition | 5.2.4. Definition | |||

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

a flow of packets of Type-P sent from Src to Dst at the times T1, | Hn>, given the matrix of Type-P-Spatial-Packet-loss-Vector for the | |||

T2... Tn. At each of these times, we obtain a Type-P-Spatial- | packets sent from Src to Dst at times <T1, T2, ..., Tm-1, Tm> : | |||

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

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

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

Tk: | ||||

o a value of Lk of 0 means that Bk.a has a value of 0 (observed) and | <L1.1, L1.2,..., L1.a, ..., L1.b, ..., L1.n, L>, | |||

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

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

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

o a value of Lk of 2 means that Bk.a has a value of 1 (not observed) | <L2.1, L2.2,..., L2.a, ..., L2.b, ..., L2.n, L>, | |||

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

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

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

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

The semantic of a Type-P-segment-Packet-loss-Stream is similar to the | We define the value of the sample Type-P-segment-Packet-Lost-Stream | |||

one of Type-P-Packet-loss-Stream: | from Ha to Hb as the sequence of booleans <L1.ab, L2.ab,..., Lk.ab, | |||

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

o a value of 0 means that the packet was observed by Ha (similar to | o A value of Lk of 0 means that Ha and Hb observed the packet sent | |||

'send by Src') and not observed by Hb ( similar to 'not received | at time Tk (Lk.a and Lk.b have a value of 0); | |||

by Dst'); | ||||

o a value of 1 means that it was observed by Ha (similar to 'send by | o A value of Lk of 1 means that Ha observed the packet sent at time | |||

Src') and observed by Hb ( similar to 'received by Dst'). | Tk (Lk.a has a value of 0) and that Hb did not observed the packet | |||

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

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

packet; | ||||

This definition of Type-P-segment-Packet-loss-Stream is similar to | 5.2.5. Discussion | |||

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

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

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

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

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

own host path digest. | ||||

Making the asumption that the host path digest of a Type-P-spatial- | Unlike Type-P-Packet-loss-Stream, Type-P-Segment-Packet-loss-Stream | |||

Packet-loss-vector does not change and that the set of (Hk, Hk+1) | relies on the stability of the host path digest. The metric can not | |||

tuples is mostly stable over time lead to unusable results and to the | be performed on < T1 , T2, ..., Tm-1, Tm> in the following cases: | |||

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

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

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

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

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

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

The semantic of a Type-P-segment-Packet-loss-Stream defines 2 new | o Ha or Hb disappears from the path due to some change of routes; | |||

results: | ||||

o A value of Lk of 2 (1,0) corresponds to a mistake in the ordering | o the order of Ha and Hb changes in the path; | |||

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

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

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

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

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

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

statistics. | ||||

o A value of Lk of 3 (1,1) corresponds to a lost of the packet in | o Lk.a or Lk.b is undefined; | |||

upper segment of the path. | ||||

5.3. A Definition of a sample of One-way Ipdv of a segment of the path | o Lk.a has the value 1 (not observed) and Lk.b has the value 0 | |||

(observed); | ||||

This metric defines a sample of ipdv between a pair of hosts of a | o L has the value 0 (the packet was received by Dst) and Lk.ab has | |||

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

Editor note: work in progress | 5.3. A Definition of a sample of ipdv of a segment using the previous | |||

packet selection function | ||||

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

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

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

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

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

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

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

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

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

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

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

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

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

o <Tk, dTk.1, dTk.2, ..., dTk.a, ..., dTk.b,..., dTk.n, dTk>, a | ||||

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

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

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

The list of <T1, T2, ..., Tm-1, Tm>; | ||||

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

5.3.4. Definition | 5.3.4. Definition | |||

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

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

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

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

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

... | ||||

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

We define the Type-P-Segment-One-way-ipdv-prev-Stream as the sequence | ||||

of pair of packet intervals and delay variations <(dT2_1.a , dT2.ab - | ||||

dT1.ab) ,..., (dTk_k-1.a, dTk.ab - dTk-1.ab), ..., (dTm_m-1.a, dTm.ab | ||||

- dTm-1.ab)> such that for each Tk: | ||||

o dTk_k-1.a is either undefined if the delay dTk.a or the delay | ||||

dTk-1.a is undefined, or the interval of time, 'dTk.a - dTk-1.a', | ||||

between the 2 packets at Ha; | ||||

o dTk_k-1.ab, is either undefined if one of the delays dTk.b, dTk.a, | ||||

dTk-1.b or dTk-1.a is undefined, or , (dTk.b - dTk.a) - (dTk-1.b - | ||||

dTk-1.a), the delay variation from Ha to Hb between the 2 packets | ||||

sent at time Tk and Tk-1. | ||||

5.3.5. Discussion | 5.3.5. Discussion | |||

This metric belongs to the family of inter packet delay variation | ||||

metrics (IPDV in upper case) which results can be extremely sensitive | ||||

to the inter-packet interval. | ||||

The inter-packet interval of a end-to-end IPDV metric is under the | ||||

control of the ingress point of interest which corresponds exactly to | ||||

the Source of the packet. Unlikely, the inter-packet interval of a | ||||

segment IPDV metric is not under the control the ingress point of | ||||

interest of the measure, Ha. However, the interval will vary if | ||||

there is delay variation between the Source and Ha. Therefore, the | ||||

actual inter-packet interval must be known at Ha in order to fully | ||||

comprehend the delay variation between Ha and Hb. | ||||

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

delay selection function | ||||

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

pair of hosts of a path using the shortest delay as the selection | ||||

function. | ||||

5.4.1. Metric Name | ||||

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

5.4.2. Metric Parameters | ||||

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

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

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

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

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

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

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

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

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

o <Tk, dTk.1, dTk.2, ..., dTk.a, ..., dTk.b,..., dTk.n, dTk>, a | ||||

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

5.4.3. Metric Units | ||||

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

The list of <T1, T2, ..., Tm-1, Tm>; | ||||

A list of times; | ||||

5.4.4. Definition | ||||

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

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

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

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

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

... | ||||

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

We define the Type-P-Segment-One-way-ipdv-min-Stream as the sequence | ||||

of times <dT1.ab - min(dTi.ab) ,..., dTk.ab - min(dTi.ab), ..., | ||||

dTm.ab - min(dTi.ab)> such that: | ||||

min(dTi.ab) is the minimum value of the tuples (dTk.b - dTk.a); | ||||

for each time Tk, dTk.ab is undefined if dTk.a or (inclusive) | ||||

dTk.b is undefined, or the real number (dTk.b - dTk.a). | ||||

5.4.5. Discussion | ||||

This metric belongs to the family of packet delay variation metrics | ||||

(PDV). PDV distributions are less sensitive to inter-packet interval | ||||

variations than IPDV results. | ||||

In principle, the PDV distribution reflects the variation over many | ||||

different inter-packet intervals, from the smallest inter-packet | ||||

interval, up to the length of the evaluation interval, Tm - T1. | ||||

Therefore, when delay variation occurs and disturbs the packet | ||||

spacing observed at Ha, the PDV results will likely compare favorably | ||||

to a PDV measurement where the source is Ha and the destination is | ||||

Hb. | ||||

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

6.1. A Definition for one-to-group One-way Delay | This metric defines metrics to measure the performance between a | |||

source and a group of receivers. | ||||

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

This metric defines a metric to measure one-way delay between a | ||||

source and a group of receivers. | ||||

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

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

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

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

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

receivers. | receivers. | |||

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

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

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

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

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

transmitted by multicast. This parameter is to identify the | over IP multicast. This parameter is to differentiate the | |||

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

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

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

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

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

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

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

6.1.4. Definition | 6.1.4. Definition | |||

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

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

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

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

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

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

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

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

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

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

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

receivers. | receivers. | |||

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

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

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

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

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

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

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

6.2.4. Definition | 6.2.4. Definition | |||

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

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

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

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

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

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

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

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

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

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

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

receivers. | receivers. | |||

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

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

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

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

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

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

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

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

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

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

6.3.4. Definition | 6.3.4. Definition | |||

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

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

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

the difference between the value of the Type-P-one-to-group-One-way- | the difference between the value of the Type-P-One-to-group-One-way- | |||

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

value of the Type-P-one-to-group- One-way-Delay-Vector from Src to { | value of the Type-P-One-to-group-One-way-Delay-Vector from Src to { | |||

Recv1,...,RecvN } at time T2. T1 is the wire-time at which Src sent | Recv1,...,RecvN } at time T2. T1 is the wire-time at which Src sent | |||

the first bit of the first packet, and T2 is the wire-time at which | the first bit of the first packet, and T2 is the wire-time at which | |||

Src sent the first bit of the second packet. This metric is derived | Src sent the first bit of the second packet. This metric is derived | |||

from the Type-P-one-to- group-One-way-Delay-Vector metric. | from the Type-P-One-to-group-One-way-Delay-Vector metric. | |||

Therefore, for a set of real number {ddT1,...,ddTn},Type-P-one- to- | Therefore, for a set of real number {ddT1,...,ddTn},Type-P-One-to- | |||

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

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

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

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

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

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

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

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

The defined one-to-group metrics above can all be directly achieved | The defined one-to-group metrics above can all be directly achieved | |||

from the relevant unicast one-way metrics. They managed to collect | from the relevant unicast one-way metrics. They collect all unicast | |||

all unicast measurement results of one-way metrics together in one | measurement results of one-way metrics together in one profile and | |||

profile and sort them by receivers and packets in a multicast group. | sort them by receivers and packets in a receiving group. They | |||

They can provide sufficient information regarding the network | provide sufficient information regarding the network performance in | |||

performance in terms of each receiver and guide engineers to identify | terms of each receiver and guide engineers to identify potential | |||

potential problem happened on each branch of a multicast routing | problem happened on each branch of a multicast routing tree. | |||

tree. However, these metrics can not be directly used to | ||||

conveniently present the performance in terms of a group and neither | However, these metrics cannot be directly used to conveniently | |||

to identify the relative performance situation. | present the performance in terms of a group and neither to identify | |||

the relative performance situation. | ||||

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

skipping to change at page 27, line 13 | skipping to change at page 29, line 39 | |||

and report the group performance and relative performance to save the | and report the group performance and relative performance to save the | |||

report transmission bandwidth. Statistics have been defined for One- | report transmission bandwidth. Statistics have been defined for One- | |||

way metrics in corresponding RFCs. They provide the foundation of | way metrics in corresponding RFCs. They provide the foundation of | |||

definition for performance statistics. For instance, there are | definition for performance statistics. For instance, there are | |||

definitions for minimum and maximum One-way delay in [RFC2679]. | definitions for minimum and maximum One-way delay in [RFC2679]. | |||

However, there is a dramatic difference between the statistics for | However, there is a dramatic difference between the statistics for | |||

one-to-one communications and for one-to-many communications. The | one-to-one communications and for one-to-many communications. The | |||

former one only has statistics over the time dimension while the | former one only has statistics over the time dimension while the | |||

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

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

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

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

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

Receivers | Receivers | |||

Space | Space | |||

^ | ^ | |||

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

| | | | | | | | |||

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

| | | | | | | | |||

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

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

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

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

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

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

T0 | T0 | |||

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

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

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

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

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

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

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

time dimension. | time dimension. | |||

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

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

operators or service provides which dimension they are interested in. | operators or service 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 fairly by calculating the statistics over the space | are served fairly by calculating the statistics over the space | |||

dimension. This memo does not intend 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 statistics can | an appropriate time interval is decided, appropriate statistics can | |||

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

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

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

with lower transmission rate can have the time interval longer and | with 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 | |||

skipping to change at page 30, line 7 | skipping to change at page 32, line 38 | |||

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

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

with N-2 packet loss. The R1DM and R2DM should not be treated with | with N-2 packet loss. The R1DM and R2DM should not be treated with | |||

equal weight because R2DM was calculated only based on 2 delay values | equal weight because R2DM was calculated only based on 2 delay values | |||

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

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

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

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

o Src, the IP address of a host | o Src, the IP address of a host; | |||

o G, the Group IP address | o G, the receiving group identifier; | |||

o N, the number of Receivers (Recv1, Recv2, ... RecvN) | o N, the number of Receivers (Recv1, Recv2, ... RecvN); | |||

o T, a time (start of test interval) | o T, a time (start of test interval); | |||

o Tf, a time (end of test interval) | o Tf, a time (end of test interval); | |||

o K, the number of packets sent from the source during the test | o K, the number of packets sent from the source during the test | |||

interval | interval; | |||

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

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

o lambda, a rate in reciprocal seconds (for Poisson Streams) | o lambda, a rate in reciprocal seconds (for Poisson Streams); | |||

o incT, the nominal duration of inter-packet interval, first bit to | o incT, the nominal duration of inter-packet interval, first bit to | |||

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

o T0, a time that MUST be selected at random from the interval [T, | o T0, a time that MUST be selected at random from the interval [T, | |||

T+I] to start generating packets and taking measurements (for | T+I] to start generating packets and taking measurements (for | |||

Periodic Streams) | Periodic Streams); | |||

o TstampSrc, the wire time of the packet as measured at MP(Src) (the | o TstampSrc, the wire time of the packet as measured at MP(Src) (the | |||

Source Measurement Point) | Source Measurement Point); | |||

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

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

o Tmax, a maximum waiting time for packets at the destination, set | o Tmax, a maximum waiting time for packets at the destination, set | |||

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

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

is not truncated | is not truncated; | |||

o dT, shorthand notation for a one-way delay singleton value | o dT, shorthand notation for a one-way delay singleton value; | |||

o L, shorthand notation for a one-way loss singleton value, either | o L, shorthand notation for a one-way loss singleton value, either | |||

zero or one, where L=1 indicates loss and L=0 indicates arrival at | zero or one, where L=1 indicates loss and L=0 indicates arrival at | |||

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

Receivers | Receivers; | |||

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

value | value; | |||

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

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

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

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

the whole matrix. | the whole matrix. | |||

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

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

| | | | |||

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

| | | | |||

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

. | | . | | |||

. | | . | | |||

. | | . | | |||

skipping to change at page 31, line 23 | skipping to change at page 34, line 17 | |||

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

| | | | |||

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

| | | | |||

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

. | | . | | |||

. | | . | | |||

. | | . | | |||

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

Figure 10: One-to-GroupGroup Mean Delay | Figure 5: One-to-Group Mean Delay | |||

where: | where: | |||

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

Receiver 1 for packet 1. | Receiver 1 for packet 1. | |||

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

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

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

skipping to change at page 32, line 18 | skipping to change at page 35, line 14 | |||

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

J[n] | J[n] | |||

--- | --- | |||

1 \ | 1 \ | |||

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

J[n] / | J[n] / | |||

--- | --- | |||

i = 1 | i = 1 | |||

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

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

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

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

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

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

N | N | |||

--- | --- | |||

1 \ | 1 \ | |||

- * > RnDM | - * > RnDM | |||

N / | N / | |||

--- | --- | |||

n = 1 | n = 1 | |||

Figure 12: Type-P-One-to-Group-Mean-Delay | Figure 7: Type-P-One-to-Group-Mean-Delay | |||

Note that the Group Mean Delay can also be calculated by summing the | Note that the Group Mean Delay can also be calculated by summing the | |||

Finite one-way Delay singletons in the Matrix, and dividing by the | Finite one-way Delay singletons in the Matrix, and dividing by the | |||

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

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

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

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

skipping to change at page 33, line 26 | skipping to change at page 36, line 24 | |||

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

| | | | |||

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

| | | | |||

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

. | | . | | |||

. | | . | | |||

. | | . | | |||

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

Figure 13: One-to-Group Loss Ratio | Figure 8: One-to-Group Loss Ratio | |||

where: | where: | |||

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

for packet 1. | for packet 1. | |||

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

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

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

skipping to change at page 34, line 12 | skipping to change at page 37, line 12 | |||

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

K,N | K,N | |||

--- | --- | |||

1 \ | 1 \ | |||

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

K*N / | K*N / | |||

--- | --- | |||

k,n = 1 | k,n = 1 | |||

Figure 14 | Figure 9 | |||

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

packets sent. | packets sent. | |||

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

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

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

according to the definitions and method of [RFC2680]. The Type-P- | according to the definitions and method of [RFC2680]. The Type-P- | |||

One-way-Packet-Loss-Average, RnLR for receiver n, and the Type-P-One- | One-way-Packet-Loss-Average, RnLR for receiver n, and the Type-P-One- | |||

skipping to change at page 34, line 36 | skipping to change at page 37, line 36 | |||

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

K | K | |||

--- | --- | |||

1 \ | 1 \ | |||

- * > RnLk | - * > RnLk | |||

K / | K / | |||

--- | --- | |||

k = 1 | k = 1 | |||

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

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

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

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

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

difference between them. | difference between them. | |||

7.4.3. Comparative Loss Ratio | 7.4.3. Comparative Loss Ratio | |||

skipping to change at page 35, line 24 | skipping to change at page 38, line 24 | |||

k=1 | k=1 | |||

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

/ K \ | / K \ | |||

| --- | | | --- | | |||

| \ | | | \ | | |||

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

| / | | | / | | |||

| --- | | | --- | | |||

\ k=1 / N | \ k=1 / N | |||

Figure 16: Type-P-Comp-Loss-Ratio-Receiver-n | Figure 11: Type-P-Comp-Loss-Ratio-Receiver-n | |||

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

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

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

minimum DV over all receivers (where DV is a point-to-point metric). | minimum DV over all receivers (where DV is a point-to-point metric). | |||

For each receiver, the DV is usually expressed as the 1-10^(-3) | For each receiver, the DV is usually expressed as the 1-10^(-3) | |||

quantile of one-way delay minus the minimum one-way delay. | quantile of one-way delay minus the minimum one-way delay. | |||

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

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

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

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

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

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

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

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

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

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

skipping to change at page 37, line 44 | skipping to change at page 40, line 44 | |||

. | | . | | |||

. | | . | | |||

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

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

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

\/ | \/ | |||

Stat over space and time | Stat over space and time | |||

Figure 17: Impact of space aggregation on multimetrics Stat | Figure 12: Impact of space aggregation on multimetrics Stat | |||

2 methods are available to compute statistics on the resulting | 2 methods are available to compute statistics on the resulting | |||

matrix: | matrix: | |||

o metric is computed over time and then over space; | o metric is computed over time and then over space; | |||

o metric is computed over space and then over time. | o metric is computed over space and then over time. | |||

They differ only by the order of the time and of the space | They differ only by the order of the time and of the space | |||

aggregation. View as a matrix this order is neutral as does not | aggregation. View as a matrix this order is neutral as does not | |||

impact the result, but the impact on a measurement deployment is | impact the result, but the impact on a measurement deployment is | |||

skipping to change at page 38, line 48 | skipping to change at page 41, line 48 | |||

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

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

number of test and the number of test packets per seconds. Then | number of test and the number of test packets per seconds. Then | |||

reducing the size of the sample over time to one packet give sample | reducing the size of the sample over time to one packet give sample | |||

of singleton over space.. | of singleton over space.. | |||

8.3.1. Impact on group stats | 8.3.1. Impact on group stats | |||

2 methods are available to compute group statistics: | 2 methods are available to compute group statistics: | |||

o method1: Figure 10 andFigure 13 illustrate the method chosen: the | o method1: Figure 5 andFigure 8 illustrate the method chosen: the | |||

one-to-one statistic is computed per interval of time before the | one-to-one statistic is computed per interval of time before the | |||

computation of the mean over the group of receivers; | computation of the mean over the group of receivers; | |||

o method2: Figure 17 presents the second one, metric is computed | o method2: Figure 12 presents the second one, metric is computed | |||

over space and then over time. | over space and then over time. | |||

8.3.2. Impact on spatial stats | 8.3.2. Impact on spatial stats | |||

2 methods are available to compute spatial statistics: | 2 methods are available to compute spatial statistics: | |||

o method 1: spatial segment metrics and statistics are preferably | o method 1: spatial segment metrics and statistics are preferably | |||

computed over time by each points of interest; | computed over time by each points of interest; | |||

o method 2: Vectors metrics are intrinsically instantaneous space | o method 2: Vectors metrics are intrinsically instantaneous space | |||

skipping to change at page 41, line 30 | skipping to change at page 44, line 30 | |||

As explained in section 8, the measurement method will have impact on | As explained in section 8, the measurement method will have impact on | |||

the analysis of the measurement result. Therefore, it should be | the analysis of the measurement result. Therefore, it should be | |||

reported. | reported. | |||

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

IANA assigns each metric defined by the IPPM WG with a unique | IANA assigns each metric defined by the IPPM WG with a unique | |||

identifier as per [RFC4148] in the IANA-IPPM-METRICS-REGISTRY-MIB. | identifier as per [RFC4148] in the IANA-IPPM-METRICS-REGISTRY-MIB. | |||

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

constraints, section [passive_metrics] of this memo gives distinct | ||||

names to passive metrics and Section 13 requests a distinct metric | ||||

identifier for each metrics the memo defines. | ||||

As it is crucial for composition of metrics to know the methodology | ||||

used (e.g. generation method, detection method...), the report of a | ||||

metric result used in composition of metrics MUST always include its | ||||

metric identifier. | ||||

9.4. Reporting data model | 9.4. Reporting data model | |||

This section presents the elements of the datamodel and the usage of | This section presents the elements of the datamodel and the usage of | |||

the information reported for real network performance analysis. It | the information reported for real network performance analysis. It | |||

is out of the scope of this section to define how the information is | is out of the scope of this section to define how the information is | |||

reported. | reported. | |||

The data model is build with pieces of information introduced and | The data model is build with pieces of information introduced and | |||

explained in one-way delay definitions [RFC2679], in packet loss | explained in one-way delay definitions [RFC2679], in packet loss | |||

definitions [RFC2680] and in IPDV definitions[RFC3393][RFC3432]. It | definitions [RFC2680] and in IPDV definitions[RFC3393][RFC3432]. It | |||

skipping to change at page 46, line 14 | skipping to change at page 49, line 5 | |||

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

Metrics defined in this memo Metrics defined in this memo are | Metrics defined in this memo Metrics defined in this memo are | |||

designed to be registered in the IANA IPPM METRICS REGISTRY as | designed to be registered in the IANA IPPM METRICS REGISTRY as | |||

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

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

METRICS-REGISTRY-MIB : | METRICS-REGISTRY-MIB : | |||

Spatial-One-way-Delay-Vector OBJECT-IDENTITY | ietfSpatialOneWayDelayVector OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

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

REFERENCE | REFERENCE | |||

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

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

note | note | |||

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

Spatial-Packet-Loss-Vector OBJECT-IDENTITY | ietfSpatialPacketLossVector OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

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

REFERENCE | REFERENCE | |||

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

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

note | note | |||

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

Spatial-One-way-ipdv-Vector OBJECT-IDENTITY | ietfSpatialOneWayIpdvVector OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

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

REFERENCE | REFERENCE | |||

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

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

note | note | |||

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

Spatial-Segment-One-way-Delay-Stream OBJECT-IDENTITY | ietfSpatialSegmentOnewayDelayStream OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

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

REFERENCE | REFERENCE | |||

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

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

note | note | |||

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

Spatial-Segment-Packet-Loss-Stream OBJECT-IDENTITY | ietfSpatialSegmentPacketLossStream OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

"Type-P-Spatial-Segment-Packet-Loss-Stream" | "Type-P-Spatial-Segment-Packet-Loss-Stream" | |||

REFERENCE | REFERENCE | |||

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

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

note | note | |||

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

Spatial-Segment-One-way-ipdv-Stream OBJECT-IDENTITY | ||||

ietfSpatialSegmentOneWayIpdvPrevStream OBJECT-IDENTITY | ||||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

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

REFERENCE | REFERENCE | |||

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

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

note | note | |||

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

ietfSpatialSegmentOneWayIpdvMinStream OBJECT-IDENTITY | ||||

STATUS current | ||||

DESCRIPTION | ||||

"Type-P-Spatial-Segment-ipdv-minStream" | ||||

REFERENCE | ||||

"Reference "RFCyyyy, section 5.4." | ||||

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

note | ||||

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

-- One-to-group metrics | -- One-to-group metrics | |||

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

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

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

REFERENCE | REFERENCE | |||

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

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

note | note | |||

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

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

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

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

REFERENCE | REFERENCE | |||

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

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

note | note | |||

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

one-to-group-One-way-ipdv-Vector OBJECT-IDENTITY | ietfOneToGroupOneWayIpdvVector OBJECT-IDENTITY | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

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

REFERENCE | REFERENCE | |||

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

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

note | note | |||

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

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

-- | ||||

ietfOneToGroupMeanDelay OBJECT-IDENTITY | ||||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

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

REFERENCE | REFERENCE | |||

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

skipping to change at page 49, line 37 | skipping to change at page 53, line 4 | |||

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

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

REFERENCE | REFERENCE | |||

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

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

note | note | |||

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

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

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

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

REFERENCE | REFERENCE | |||

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

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

note | note | |||

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

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

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

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

REFERENCE | REFERENCE | |||

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

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

note | note | |||

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

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

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

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

REFERENCE | REFERENCE | |||

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

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

note | note | |||

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

-- | -- | |||

skipping to change at page 50, line 49 | skipping to change at page 54, line 15 | |||

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

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

note | note | |||

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

-- | -- | |||

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

STATUS current | STATUS current | |||

DESCRIPTION | DESCRIPTION | |||

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

REFERENCE | REFERENCE | |||

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

skipping to change at page 54, line 7 | skipping to change at page 57, line 7 | |||

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 IETF Trust (2007). | Copyright (C) The IETF Trust (2008). | |||

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, THE IETF TRUST AND | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | |||

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

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

End of changes. 211 change blocks. | ||||

395 lines changed or deleted | | 561 lines changed or added | ||

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |