 1/draftietfippmmultimetrics08.txt 20081015 12:12:25.000000000 +0200
+++ 2/draftietfippmmultimetrics09.txt 20081015 12:12:25.000000000 +0200
@@ 1,21 +1,21 @@
Network Working Group E. Stephan
InternetDraft France Telecom
Intended status: Standards Track L. Liang
Expires: April 3, 2009 University of Surrey
+Expires: April 18, 2009 University of Surrey
A. Morton
AT&T Labs
 September 30, 2008
+ October 15, 2008
IP Performance Metrics (IPPM) for spatial and multicast
 draftietfippmmultimetrics08
+ draftietfippmmultimetrics09
Status of this Memo
By submitting this InternetDraft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
InternetDrafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
@@ 26,21 +26,21 @@
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use InternetDrafts as reference
material or to cite them other than as "work in progress."
The list of current InternetDrafts can be accessed at
http://www.ietf.org/ietf/1idabstracts.txt.
The list of InternetDraft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
 This InternetDraft will expire on April 3, 2009.
+ This InternetDraft will expire on April 18, 2009.
Abstract
The IETF has standardized IP Performance Metrics (IPPM) for measuring
endtoend performance between two points. This memo defines two new
categories of metrics that extend the coverage to multiple
measurement points. It defines spatial metrics for measuring the
performance of segments of a source to destination path, and metrics
for measuring the performance between a source and many destinations
in multiparty communications (e.g., a multicast tree).
@@ 182,21 +182,21 @@
`. ,.
`. ,' `...... 1
`. ; :
`. ; :
; :... 2
 
: ;
: ;.... 3
: ;
`. ,'
 `'....... N
+ `'....... I
Figure 1: Onetogroup points of interest
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
destination.
Src . Hosts
\
`X ... 1
@@ 204,21 +204,21 @@
x
/
.X .... 2
/
x
\
`X .... 3
\
\
\
 X .... N
+ X .... J
\
\
\
` Dst
Note: 'x' are nodes which are not points of interest
Figure 2: Spatial points of interest
2.8. Reference point
@@ 702,26 +702,26 @@
o Each Hi extracts the timestamp T from the packet;
o Each Hi computes the onewaydelay from Src to Hi: dTi = Ti  T;
o The reference point gathers the result of each Hi and arranges
them according to the path ordering information received to build
the typeP spatial oneway vector (e.g. TypePSpatialOneway
DelayVector metric ) over the path
at time T.
5.4.1. Packet Loss Detection
 In an pure endtoend measurement, packet losses are detected by the
+ In a pure endtoend measurement, packet losses are detected by the
receiver only. A packet is lost when TypePOnewayDelay is
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
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
value or an undefined value.
In a spatial measurement, packet losses may be detected at several
measurement collection points. Depending on the consistency of the
packet loss detections among the points of interest, a packet may be
considered as lost at one point despite having a finite delay at
another one, or may be observed by the last measurement collection
point of the path but considered lost by Dst.
@@ 1200,26 +1200,26 @@
information but also information on "relative performance". The
relative performance means the difference between absolute
performance of all users. Directly using the oneway metrics cannot
present the relative performance situation. However, if we use the
variations of all users oneway parameters, we can have new metrics
to measure the difference of the absolute performance and hence
provide the threshold value of relative performance that a multiparty
service might demand. A very good example of the high relative
performance requirement is the online gaming. A very light
difference in delay might result in failure in the game. We have to
 use multicast specific statistic metrics to define exactly how small
 the relative delay the online gaming requires. There are many other
 services, e.g. online biding, online stock market, etc., that require
 multicast metrics in order to evaluate the network against their
 requirements. Therefore, we can see the importance of new, multicast
 specific, statistic metrics to feed this need.
+ use multicast specific statistic metrics to define the relative delay
+ required by online gaming. There are many other services, e.g.
+ online biding, online stock market, etc., that require multicast
+ metrics in order to evaluate the network against their requirements.
+ Therefore, we can see the importance of new, multicast specific,
+ statistic metrics to feed this need.
We might also use some onetogroup statistic conceptions to present
and report the group performance and relative performance to save the
report transmission bandwidth. Statistics have been defined for One
way metrics in corresponding RFCs. They provide the foundation of
definition for performance statistics. For instance, there are
definitions for minimum and maximum Oneway delay in [RFC2679].
However, there is a dramatic difference between the statistics for
onetoone communications and for onetomany communications. The
former one only has statistics over the time dimension while the
@@ 1281,30 +1281,30 @@
dimension. For instance, a TV broadcast service provider had the
performance Matrix M and calculated the Oneway delay mean over the
time dimension to obtain a delay Vector as {V1,V2,..., VN}. He then
calculated the mean of all the elements in the Vector to see what
level of delay he has served to all N users. This new delay mean
gives information on how good the service has been delivered to a
group of users during a sampling interval in terms of delay. It
needs twice calculation to have this statistic over both time and
space dimensions. We name this kind of statistics 2level statistics
to distinct with those 1level 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 2level statistic is calculated first, the results
are the same. I.e. one can calculate the 2level delay mean using
the Matrix M by having the 1level delay mean over the time dimension
first and then calculate the mean of the obtained vector to find out
the 2level delay mean. Or, he can do the 1level statistic
calculation over the space dimension first and then have the 2level
delay mean. Both two results will be exactly the same. Therefore,
 when define a 2level statistic, there is no need to specify in which
 procedure the calculation should follow.
+ when defining a 2level statistic there is no need to specify the
+ order in which the calculation is executed.
Many statistics can be defined for the proposed onetogroup metrics
over either the space dimension or the time dimension or both. This
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
samples are each summarized with the usual statistics employed in
onetoone communication. New statistic definitions are presented,
which summarize the onetoone statistics over all the Receivers in
the Group.
@@ 1391,21 +1391,21 @@
This section defines the overall oneway delay statistics for a
receiver and for an entire group as illustrated by the matrix below.
Recv / Sample \ Stats Group Stat
1 R1dT1 R1dT2 R1dT3 ... R1dTk R1MD \

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 /
Receivern
delay
Figure 5: Onetogroup Mean Delay
@@ 1638,22 +1638,22 @@
a single reference point with connectivity to all the points of
interest. In this case, the number of points of interest determines
both storage capacity and packet transfer capacity of the host acting
as the reference point. However, both the storage and transfer
capacity can be reduced if the points of interest are capable of
computing the summary statistics that describe each measurement
interval. This is consistent with many operational monitoring
architectures today, where even the individual singletons may not be
stored at each point of interest.
 In recognition of the likely need to minimize form of the results for
 storage and communication, the Group metrics above have been
+ In recognition of the likely need to minimize the form of the results
+ for storage and communication, the Group metrics above have been
constructed to allow some computations on a perReceiver basis. This
means that each Receiver's statistics would normally have an equal
weight with all other Receivers in the Group (regardless of the
number of packets received).
9.1. Computation methods
The scalability issue can be raised when there are thousands of
points of interest in a group who are trying to send back the
measurement results to the reference point for further processing and