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

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

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

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

Expires: April 3, 2009 University of Surrey | Expires: April 18, 2009 University of Surrey | |||

A. Morton | A. Morton | |||

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

September 30, 2008 | October 15, 2008 | |||

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

draft-ietf-ippm-multimetrics-08 | draft-ietf-ippm-multimetrics-09 | |||

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This Internet-Draft will expire on April 3, 2009. | This Internet-Draft will expire on April 18, 2009. | |||

Abstract | Abstract | |||

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

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

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

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

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

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

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

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

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

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

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

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

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

| | | | | | |||

: ; | : ; | |||

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

: ; | : ; | |||

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

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

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

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

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

destination. | destination. | |||

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

\ | \ | |||

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

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

x | x | |||

/ | / | |||

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

/ | / | |||

x | x | |||

\ | \ | |||

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

\ | \ | |||

\ | \ | |||

\ | \ | |||

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

\ | \ | |||

\ | \ | |||

\ | \ | |||

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

performance requirement is the online gaming. A very light | performance requirement is the online gaming. A very light | |||

difference in delay might result in failure in the game. We have to | difference in delay might result in failure in the game. We have to | |||

use multicast specific statistic metrics to define exactly how small | use multicast specific statistic metrics to define the relative delay | |||

the relative delay the online gaming requires. There are many other | required by online gaming. There are many other services, e.g. | |||

services, e.g. online biding, online stock market, etc., that require | online biding, online stock market, etc., that require multicast | |||

multicast metrics in order to evaluate the network against their | metrics in order to evaluate the network against their requirements. | |||

requirements. Therefore, we can see the importance of new, multicast | Therefore, we can see the importance of new, multicast specific, | |||

specific, statistic metrics to feed this need. | statistic metrics to feed this need. | |||

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

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

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

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

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

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

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

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

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

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

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

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

time dimension to obtain a delay Vector as {V1,V2,..., VN}. He then | time dimension to obtain a delay Vector as {V1,V2,..., VN}. He then | |||

calculated the mean of all the elements in the Vector to see what | calculated the mean of all the elements in the Vector to see what | |||

level of delay he has served to all N users. This new delay mean | level of delay he has served to all N users. This new delay mean | |||

gives information on how good the service has been delivered to a | gives information on how good the service has been delivered to a | |||

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

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

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

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

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

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

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

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

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

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

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

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

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

procedure the calculation should follow. | order in which the calculation is executed. | |||

Many statistics can be defined for the proposed one-to-group metrics | Many statistics can be defined for the proposed one-to-group metrics | |||

over either the space dimension or the time dimension or both. This | over either the space dimension or the time dimension or both. This | |||

memo treats the case where a stream of packets from the Source | memo treats the case where a stream of packets from the Source | |||

results in a sample at each of the Receivers in the Group, and these | results in a sample at each of the Receivers in the Group, and these | |||

samples are each summarized with the usual statistics employed in | samples are each summarized with the usual statistics employed in | |||

one-to-one communication. New statistic definitions are presented, | one-to-one communication. New statistic definitions are presented, | |||

which summarize the one-to-one statistics over all the Receivers in | which summarize the one-to-one statistics over all the Receivers in | |||

the Group. | the Group. | |||

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

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

receiver and for an entire group as illustrated by the matrix below. | receiver and for an entire group as illustrated by the matrix below. | |||

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

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

| | | | |||

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

| | | | |||

3 R3dT1 R3dT2 R3dT3 ... R3dTk R2MD > Group delay | 3 R3dT1 R3dT2 R3dT3 ... R3dTk R3MD > Group delay | |||

. | | . | | |||

. | | . | | |||

. | | . | | |||

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

Receiver-n | Receiver-n | |||

delay | delay | |||

Figure 5: One-to-group Mean Delay | Figure 5: One-to-group Mean Delay | |||

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

a single reference point with connectivity to all the points of | a single reference point with connectivity to all the points of | |||

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

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

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

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

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

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

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

stored at each point of interest. | stored at each point of interest. | |||

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

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

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

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

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

number of packets received). | number of packets received). | |||

9.1. Computation methods | 9.1. Computation methods | |||

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

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

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

End of changes. 13 change blocks. | ||||

20 lines changed or deleted | | 20 lines changed or added | ||

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |