 1/draftietfippmmultimetrics03.txt 20070708 23:12:07.000000000 +0200
+++ 2/draftietfippmmultimetrics04.txt 20070708 23:12:07.000000000 +0200
@@ 1,21 +1,21 @@
Network Working Group E. Stephan
InternetDraft France Telecom
Intended status: Informational L. Liang
Expires: September 2, 2007 University of Surrey
+Expires: January 7, 2008 University of Surrey
A. Morton
AT&T Labs
 March 1, 2007
+ July 6, 2007
IP Performance Metrics (IPPM) for spatial and multicast
 draftietfippmmultimetrics03
+ draftietfippmmultimetrics04
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,101 +26,97 @@
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 September 2, 2007.
+ This InternetDraft will expire on January 7, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The IETF IP Performance Metrics (IPPM) working group has standardized
metrics for measuring endtoend performance between 2 points. This
memo defines 2 sets of metrics to extend these endtoend ones. It
defines spatial metrics for measuring the performance of segments
along a path and metrics for measuring the performance of a group of
users in multiparty communications.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
 2.1. Multiparty metric . . . . . . . . . . . . . . . . . . . . 6
 2.2. Spatial metric . . . . . . . . . . . . . . . . . . . . . . 6
 2.3. Spatial metric points of interest . . . . . . . . . . . . 6
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 2.1. Path Digest Hosts . . . . . . . . . . . . . . . . . . . . 6
+ 2.2. Multiparty metric . . . . . . . . . . . . . . . . . . . . 6
+ 2.3. Spatial metric . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Onetogroup metric . . . . . . . . . . . . . . . . . . . 6
 2.5. Onetogroup metric points of interest . . . . . . . . . . 6
 2.6. Reference point . . . . . . . . . . . . . . . . . . . . . 6
 2.7. Vector . . . . . . . . . . . . . . . . . . . . . . . . . . 7
 2.8. Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 7
 3. Motivations for spatial and onetogroup metrics . . . . . . . 8
 3.1. spatial metrics . . . . . . . . . . . . . . . . . . . . . 8
 3.2. Onetogroup metrics . . . . . . . . . . . . . . . . . . . 9
 3.3. Discussion on Grouptoone and Grouptogroup metrics . . 10
 4. Spatial metrics definitions . . . . . . . . . . . . . . . . . 10
 4.1. A Definition for Spatial Oneway Delay Vector . . . . . . 10
 4.2. A Definition of a sample of Oneway Delay of a sub path . 13
 4.3. A Definition for Spatial Oneway Packet Loss Vector . . . 16
 4.4. A Definition for Spatial Oneway Jitter Vector . . . . . . 17
 4.5. Pure Passive Metrics . . . . . . . . . . . . . . . . . . . 19
 4.6. Discussion on spatial statistics . . . . . . . . . . . . . 21
 5. Onetogroup metrics definitions . . . . . . . . . . . . . . . 21
 5.1. A Definition for onetogroup Oneway Delay . . . . . . . 21
 5.2. A Definition for onetogroup Oneway Packet Loss . . . . 22
 5.3. A Definition for onetogroup Oneway Jitter . . . . . . . 22
 6. OnetoGroup Sample Statistics . . . . . . . . . . . . . . . . 24
 6.1. Discussion on the Impact of packet loss on statistics . . 26
 6.2. General Metric Parameters . . . . . . . . . . . . . . . . 27
 6.3. OnetoGroup oneway Delay Statistics . . . . . . . . . . 28
 6.4. OnetoGroup oneway Loss Statistics . . . . . . . . . . . 31
 6.5. OnetoGroup oneway Delay Variation Statistics . . . . . 33
 7. Measurement Methods: Scaleability and Reporting . . . . . . . 33
 7.1. Computation methods . . . . . . . . . . . . . . . . . . . 34
 7.2. Measurement . . . . . . . . . . . . . . . . . . . . . . . 35
 7.3. effect of Time and Space Aggregation Order on Group
 Stats . . . . . . . . . . . . . . . . . . . . . . . . . . 35
 7.4. effect of Time and Space Aggregation Order on Spatial
 Stats . . . . . . . . . . . . . . . . . . . . . . . . . . 37
 8. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 37
 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37
 9.1. passive measurement . . . . . . . . . . . . . . . . . . . 37
 9.2. onetogroup metric . . . . . . . . . . . . . . . . . . . 37
 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
 12.1. Normative References . . . . . . . . . . . . . . . . . . . 42
 12.2. Informative References . . . . . . . . . . . . . . . . . . 43
 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
 Intellectual Property and Copyright Statements . . . . . . . . . . 45
+ 2.5. Points of interest . . . . . . . . . . . . . . . . . . . . 6
+ 2.6. Reference point . . . . . . . . . . . . . . . . . . . . . 8
+ 2.7. Vector . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 2.8. Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 3.1. Motivations for spatial metrics . . . . . . . . . . . . . 9
+ 3.2. Motivations for Onetogroup metrics . . . . . . . . . . . 10
+ 3.3. Discussion on Grouptoone and Grouptogroup metrics . . 11
+ 4. Spatial vectors metrics definitions . . . . . . . . . . . . . 11
+ 4.1. A Definition for Spatial Oneway Delay Vector . . . . . . 12
+ 4.2. A Definition for Spatial Oneway Packet Loss Vector . . . 13
+ 4.3. A Definition for Spatial Oneway Ipdv Vector . . . . . . . 15
+ 4.4. Spatial Methodology . . . . . . . . . . . . . . . . . . . 17
+ 5. Spatial Segments metrics definitions . . . . . . . . . . . . . 19
+ 5.1. A Definition of a sample of Oneway Delay of a segment
+ of the path . . . . . . . . . . . . . . . . . . . . . . . 19
+ 5.2. A Definition of a sample of Packet Loss of a segment
+ of the path . . . . . . . . . . . . . . . . . . . . . . . 21
+ 5.3. A Definition of a sample of Oneway Ipdv of a segment
+ of the path . . . . . . . . . . . . . . . . . . . . . . . 24
+ 5.4. Discussion on Passive Segment Metrics . . . . . . . . . . 24
+ 6. Onetogroup metrics definitions . . . . . . . . . . . . . . . 27
+ 6.1. A Definition for onetogroup Oneway Delay . . . . . . . 27
+ 6.2. A Definition for onetogroup Oneway Packet Loss . . . . 28
+ 6.3. A Definition for onetogroup Oneway Ipdv . . . . . . . . 28
+ 7. OnetoGroup Sample Statistics . . . . . . . . . . . . . . . . 30
+ 7.1. Discussion on the Impact of packet loss on statistics . . 32
+ 7.2. General Metric Parameters . . . . . . . . . . . . . . . . 33
+ 7.3. OnetoGroup oneway Delay Statistics . . . . . . . . . . 34
+ 7.4. OnetoGroup oneway Loss Statistics . . . . . . . . . . . 37
+ 7.5. OnetoGroup oneway Delay Variation Statistics . . . . . 39
+ 8. Measurement Methods: Scaleability and Reporting . . . . . . . 39
+ 8.1. Computation methods . . . . . . . . . . . . . . . . . . . 40
+ 8.2. Measurement . . . . . . . . . . . . . . . . . . . . . . . 41
+ 8.3. Effect of Time and Space Aggregation Order on Stats . . . 41
+ 9. Manageability Considerations . . . . . . . . . . . . . . . . . 43
+ 9.1. Reporting spatial metric . . . . . . . . . . . . . . . . . 43
+ 9.2. Reporting Onetogroup metric . . . . . . . . . . . . . . 44
+ 9.3. Metric identification . . . . . . . . . . . . . . . . . . 44
+ 9.4. Reporting data model . . . . . . . . . . . . . . . . . . . 44
+ 10. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 48
+ 11. Security Considerations . . . . . . . . . . . . . . . . . . . 48
+ 11.1. Spatial metrics . . . . . . . . . . . . . . . . . . . . . 48
+ 11.2. onetogroup metric . . . . . . . . . . . . . . . . . . . 48
+ 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49
+ 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
+ 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
+ 14.1. Normative References . . . . . . . . . . . . . . . . . . . 55
+ 14.2. Informative References . . . . . . . . . . . . . . . . . . 56
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
+ Intellectual Property and Copyright Statements . . . . . . . . . . 58
1. Introduction
 The metrics specified in this memo are built on notions introduced
 and discussed in the IPPM Framework document, RFC 2330 [RFC2330].
 The reader should be familiar with these documents.

 This memo makes use of definitions of endtoend Oneway Delay
 Metrics defined in the RFC 2679 [RFC2679] to define metrics for
 decomposition of endtoend oneway delays measurements.

 This memo makes use of definitions of endtoend Oneway Packet loss
 Metrics defined in the RFC 2680 [RFC2680] to define metrics for
 decomposition of endtoend oneway packet loss measurements.

The IPPM WG defined a framework for metric definitions and endtoend
measurements:
o A general framework for defining performance metrics, described in
the Framework for IP Performance Metrics [RFC2330];
o A Oneway Active Measurement Protocol Requirements [RFC3763];
o A Oneway Active Measurement Protocol (OWAMP) [RFC4656];
@@ 139,207 +135,259 @@
o A Framework for Defining Empirical Bulk Transfer Capacity Metrics
[RFC3148];
o Oneway Loss Pattern Sample Metrics [RFC3357];
o IP Packet Delay Variation Metric for IPPM [RFC3393];
o Network performance measurement for periodic streams [RFC3432];
 o Packet Reordering Metric for IPPM [RFC4737][Work in progress];
 Based on these works, this memo defines 2 kinds of multi party
 metrics.
+ o Packet Reordering Metric for IPPM [RFC4737];
+
+ This memo defines spatial and onetogroup metrics based on the
+ framework and on the endtoend metrics defined in these documents.
Firstly it defines spatial metrics:
 o A 'sample', called TypePSpatialOnewayDelayVector, will be
 introduced to divide an endtoend TypePOnewayDelay in a
 spatial sequence of oneway delays.
+ o A 'vector', called TypePSpatialOnewayDelayVector, will be
+ introduced to divide an endtoend TypePOnewayDelay [RFC2679]
+ in a spatial sequence of oneway delays.
 o A 'sample', called TypePSpatialOnewayPacketLossVector, will
+ o A 'vector', called TypePSpatialOnewayPacketLossVector, will
be introduced to divide an endtoend TypePOnewayPacketLoss
 in a spatial sequence of packet loss.
+ [RFC2680] in a spatial sequence of packet loss.
 o Using the TypePSpatialOnewayDelayVector metric, a 'sample',
 called TypePSpatialOnewayJitterVector, will be introduced to
+ o Using the TypePSpatialOnewayDelayVector metric, a 'vector',
+ called TypePSpatialOnewayipdvVector, will be introduced to
divide an endtoend TypePOnewayipdv in a spatial sequence of
 jitter.
+ ipdv.
o Using the TypePSpatialOnewayDelayVector metric, a 'sample',
 called TypePsubpathOnewayDelayStream, will be introduced to
 define the onewaydelay between a pair of host of the path. This
 metric is similar to TypePOnewayDelayStream.
+ called TypePSegmentOnewayDelayStream, will be introduced to
+ define a set of oneway delays between a pair of host of the path;
 o Using TypePsubpathOnewayDelayStream, a 'sample' TypeP
 PassiveOnewayDelayStream will be introduced to define passive
 metrics. These metrics are designed for pure passive measurement
 methodology as introduced by PSAMP WG.
+ o Using the TypePSpatialPacketLossVector metric, a 'sample',
+ called TypePSegmentPacketLossStream, will be introduced to
+ define a set of packet losses between a pair of host of the path;
+
+ o Using the TypePSpatialipdvVector metric, a 'sample', called
+ TypePSegmentipdvStream, will be introduced to define a set of
+ ipdvs between a pair of host of the path;
Then it defines onetogroup metrics.
o Using one test packet sent from one sender to a group of
receivers, a 'sample', called TypePonetogroupOnewayDelay
Vector, will be introduced to define the list of TypePoneway
 delay between this sender and the group of receivers.
+ delay [RFC2679] between this sender and the group of receivers.
o Using one test packet sent from one sender to a group of
receivers, a 'sample', called TypePonetogroupOnewayPacket
LossVector, will be introduced to define the list of TypePOne
 wayPacketLoss between this sender and the group of receivers
+ wayPacketLoss [RFC2680] between this sender and the group of
+ receivers
o Using one test packet sent from one sender to a group of
 receivers, a 'sample', called TypePonetogroupOnewayJitter
+ receivers, a 'sample', called TypePonetogroupOnewayipdv
Vector, will be introduced to define the list of TypePOneway
ipdv between this sender and the group of receivers
o Then a discussion section presents the set of statistics that may
 be computed on the top of these metrics to present the QoS in a
 view of a group of users as well as the requirements of relative
 QoS on multiparty communications.
+ be computed using these metrics to present the network performance
+ in the view of a group of users. The statistics may be the basis
+ for requirements (e.g. fairness) on multiparty communications. .
+
+ Reporting of metrics is defined in the section "Manageability
+ Consideration".
2. Terminology
2.1. Multiparty metric
+2.1. Path Digest Hosts
 A metric is said to be multiparty if the definition involved more
 than two sources or destinations in the measurements. All multiparty
+ The list of the hosts of a path from a source to a destination.
+
+2.2. Multiparty metric
+
+ A metric is said to be multiparty if the topology involves more than
+ one source or destination in the measurements. All multiparty
metrics define a set of hosts called "points of interest", where one
host is the source and other hosts are the measurement collection
points. For example, if the set of points of interest is < ha, hb,
hc, ..., hn >, where ha is the source and < hb, hc, ..., hn > are the
destinations, then measurements may be conducted between < ha, hb>, <
ha, hc>, ..., .
2.2. Spatial metric

 A metric is said to be spatial if one of the hosts involved is
 neither the source nor the destination of the metered packet.
+ For the purposes of this memo (reflecting the scope of a single
+ source), the only multiparty metrics are onetogroup metrics.
2.3. Spatial metric points of interest
+2.3. Spatial metric
 Points of interest of a spatial metric are the routers or sibling in
 the path between source and destination (in addition to the source
 and the destination themselves).
+ A metric is said to be spatial if one of the hosts involved is
+ neither the source nor the destination of the measured packet.
2.4. Onetogroup metric
A metric is said to be onetogroup if the measured packet is sent by
one source and (potentially) received by several destinations. Thus,
the topology of the communication group can be viewed as a centre
distributed or serverclient topology with the source as the centre/
server in the topology.
2.5. Onetogroup metric points of interest
+2.5. Points of interest
 Points of interest of Onetogroup metrics are the set of host
 destinations receiving packets from the source (in addition to the
 source itself).
+ Points of interest are the set of hosts* (as per RFC2330 definition,
+ that is including nodes) of the set of hosts involved in the delivery
+ of the packets (in addition to the source itself). Note that the set
+ of the points of interest are (a possibly arbitrary) subset of all
+ the hosts involved in the path. Points of interest of Onetogroup
+ metrics are the hosts receiving packets from the source (in addition
+ to the source itself).
+
+ Src Recv
+ `. ,.
+ `. ,' `...... 1
+ `. ; :
+ `. ; :
+ ; :... 2
+  
+ : ;
+ : ;.... 3
+ : ;
+ `. ,'
+ `'....... N
+
+ Figure 1: Onetogroup points of interest
+
+ A points of interest of spatial metrics is a host of the set of hosts
+ involved in the delivery of the packets from the source.
+
+ Src . Hosts
+ \
+ `X ... 1
+ \
+ x
+ /
+ .X .... 2
+ /
+ x
+ \
+ `X .... 3
+ \
+ \
+ \
+ X .... N
+ \
+ \
+ \
+ ` Dst
+
+ Note: 'x' are nodes which are not points of interest
+
+ Figure 2: Spatial points of interest
2.6. Reference point
 The centre/server in the onetogroup measurement that is controlled
+ The centre/server in the multimetrics measurement that is controlled
by network operators can be a very good reference point where
measurement data can be collected for further processing although the
actual measurements have to be carried out at all points of interest.
 I.e., the measurement points will be all clients/receivers while the
 reference point acts as source for the onetogroup metric. Thus, we
 can define the reference point as the host while the statistic
 calculation will be carried out.
+ Thus, we can define the reference point as the server where the
+ statistic calculation will be carried out.
2.7. Vector
 A group of singletons is the set of results of the observation of the
 behaviour of the same packet at different places of a network.

A Vector is a set of singletons, which are a set of results of the
observation of the behaviour of the same packet at different places
of a network at different time. For instance, if Oneway delay
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
elements can be organized as {dT1, dT2,..., dTN}. The elements in
one vector are singletons distinct with each other in terms of both
measurement point and time. Given the vector V as an example, the
element dT1 is distinct from the rest by measured at receiver 1 at
time T1. Additional to a singleton, Vector gives information over a
space dimension.
2.8. Matrix
 Several vectors can organize form up a Matrix, which contains results
 observed in a sampling interval at different place of a network at
 different time. For instance, given Oneway delay vectors V1={dT11,
 dT12,..., dT1N}, V2={dT21, dT22,..., dT2N},..., Vm={dTm1, dTm2,...,
 dTmN} for Packet P1, P2,...,Pm, we can have a Oneway delay Matrix
 {V1, V2,...,Vm}. Additional to the information given by a Vector, a
+ Several vectors can form up a Matrix, which contains results observed
+ in a sampling interval at different place of a network at different
+ time. For instance, given Oneway delay vectors V1={dT11, dT12,...,
+ dT1N}, V2={dT21, dT22,..., dT2N},..., Vm={dTm1, dTm2,..., dTmN} for
+ Packet P1, P2,...,Pm, we can have a Oneway delay Matrix {V1,
+ V2,...,Vm}. Additional to the information given by a Vector, a
Matrix is more powerful to present network performance in both space
and time dimensions. It normally corresponds to a sample.
The relation among Singleton, Vector and Matrix can be shown in the
 following Figure 1.
+ following Figure 3.
 onetogroup Singleton
 / Sample
 Src Recv ..............................
 .................... 1 R1dT1 R1dT2 R1dT3 R1dT4
 `:=.._
 T `._ ``..__
 `. `... 2 R2dT1 R2dT2 R2dT3 R2dT4
 `.
 `.
 `.... N R3dT1 R3dT2 R3dT3 R3dT4
+ Point of Singleton
+ interest / Samples
+ ,. ^ /
+ / R1..... / R1dT1 R1dT2 R1dT3 ... R3dTk \
+ / \   
+ ; R2........  R2dT1 R2dT2 R2dT3 ... R3dTk 
+ Src    
+  R3....  R3dT1 R3dT2 R3dT3 ... R3dTk 
+    
+ : ;  
+ \ /   
+ \ Rn...... \ RndT1 RndT2 RndT3 ... RndTk /
+ `' +> time
Vector Matrix
(space) (time)
 Figure 1: Relation beween Singletons, vectors and matrix
+ Figure 3: Relation beween Singletons, vectors and matrix
3. Motivations for spatial and onetogroup metrics
+3. Motivations
All IPPM metrics are defined for endtoend measurement. These
metrics provide very good guides for measurement in the pair
communications. However, further efforts should be put to define
metrics for multiparty measurements such as one to one trajectory
metrics and one to multipoint metrics.
3.1. spatial metrics
+3.1. Motivations for spatial metrics
Decomposition of instantaneous endtoend measures is needed:
o Decomposing the performance of interdomain path is desirable in
interdomain to qualify per AS contribution to the performance. So
it is necessary to define standard spatial metrics before going
further in the computation of inter domain path with QoS
constraint.
o Traffic engineering and troubleshooting applications require
spatial views of the oneway delay consumption, identification of
the location of the lost of packets and the decomposition of the
 jitter over the path.
+ ipdv over the path.
o Monitoring the QoS of a multicast tree, of MPLS pointto
multipoint and interdomain communication require spatial
decomposition of the oneway delay, of the packet loss and of the
 jitter.
+ ipdv.
o Composition of metrics is a need to scale in the measurement
plane. Spatial measure give typically the individual performance
of an intra domain segment. It is the elementary piece of
information to exchange for measuring interdomain performance
based on composition of metrics.
o The PSAMP WG defines capabilities to sample packets in a way to to
support instantaneous measurement respecful of the IPPM framework
[RFC2330]. Consequently it is necessary to define a set of
spatial metrics for passive and active techniques.
3.2. Onetogroup metrics
+3.2. Motivations for Onetogroup metrics
While the nodetonode based spatial measures can provide very useful
data in the view of each connection, we also need measures to present
the performance of a multiparty communication in the view of a group
with consideration that it involves a group of people rather than
two. As a consequence a simple oneway metric cannot describe the
multiconnection situation. We need some new metrics to collect
performance of all the connections for further statistics analysis.
A group of metrics are proposed in this stage named onetogroup
performance metrics based on the unicast metrics defined in IPPM WG.
@@ 397,29 +445,32 @@
measurement points. However, we can always avoid this confusion by
treating the connections as onetogroup or grouptoone in our
measurements without consideration on how the real communication will
be carried out. For example, if one group of hosts < ha, hb, hc,
..., hn > are acting as sources to send data to another group of
hosts < Ha, Hb, Hc, ..., Hm >, we can always decompose them into n
onetogroup communications as < ha, Ha, Hb, Hc, ..., Hm >, < hb, Ha,
Hb, Hc, ..., Hm >, , ..., < hn, Ha, Hb, Hc,
..., Hm >.
4. Spatial metrics definitions
+4. Spatial vectors metrics definitions
 Spatial decomposition metrics are based on standard endtoend
 metrics.
+ This section defines vectors for the decomposition of endtoend
+ singleton metrics over a path.
 The definition of a spatial metric is coupled with the corresponding
 endtoend metric. The methodology is based on the measure of the
 same test packet and parameters of the corresponding endtoend
 metric.
+ Spatial vectors metrics are based on the decomposition of standard
+ endtoend metrics defined by the IPPM WG in [RFC2679], [RFC2680],
+ [RFC3393] and [RFC3432].
+
+ Definitions are coupled with the corresponding endtoend metrics.
+ Methodology specificities are common to all the vectors defined and
+ are consequently discussed in a common section.
4.1. A Definition for Spatial Oneway Delay Vector
This section is coupled with the definition of TypePOnewayDelay.
When a parameter from section 3 of [RFC2679] is 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
statements for endtoend onewaydelay measurements. They are
applicable to each point of interest Hi involved in the measure.
@@ 429,38 +480,39 @@
Following we adapt some of them and introduce points specific to
spatial measurement.
4.1.1. Metric Name
TypePSpatialOnewayDelayVector
4.1.2. Metric Parameters
 + Src*, the IP address of the sender.
+ o Src*, the IP address of the sender.
 + Dst*, the IP address of the receiver.
+ o Dst*, the IP address of the receiver.
 + i, An integer which ordered the hosts in the path.
+ o i, An integer if the list <1,2,...,n> which ordered the hosts in
+ the path.
 + Hi, exchange points of the path digest.
+ o Hi, A host* of the path digest.
 + T*, a time, the sending (or initial observation) time for
 a measured packet.
+ o T*, a time, the sending (or initial observation) time for a
+ measured packet.
 + dT* a delay, the oneway delay for a measured packet.
+ o dT* a delay, the oneway delay for a measured packet.
 + dT1,..., dTn a list of delay.
+ o a list of delay.
 + P*, the specification of the packet type.
+ o P*, the specification of the packet type.
 + , a path digest.
+ o , hosts path digest.
4.1.3. Metric Units
A sequence of times.
4.1.4. Definition
Given a TypeP packet sent by the sender Src at wiretime (first bit)
T to the receiver Dst in the path . Given the
sequence of values such that dT is the
@@ 470,145 +522,331 @@
never passes Hi.
TypePSpatialOnewayDelayVector metric is defined for the path
as the sequence of values
.
4.1.5. Discussion
Following are specific issues which may occur:
 o the delay looks to decrease: dTi > DTi+1. this seem typically du
 to some clock synchronisation issue. this point is discussed in
+ o the delay looks to decrease: dTi > DTi+1. This seem typically du
+ to some clock synchronisation issue. This point is discussed in
the section 3.7.1. "Errors or uncertainties related to Clocks" of
 of [RFC2679];
+ of [RFC2679]. One consequence of these uncertainties is that
+ times of a measure at different hosts shall not be used to order
+ hosts on the path of a measure;
o The location of the point of interest in the device influences the
result. If the packet is not observed on the input interface the
delay includes buffering time and consequently an uncertainty due
to the difference between 'wire time' and 'host time';
4.1.6. Interference with other test packet
+4.2. A Definition for Spatial Oneway Packet Loss Vector
 To avoid packet collision it is preferable to include a sequence
 number in the packet.
+ This section is coupled with the definition of TypePOnewayPacket
+ Loss. Then when a parameter from the section 2 of [RFC2680] is first
+ used in this section, it will be tagged with a trailing asterisk.
4.1.7. loss threshold
+ Sections 2.5 to 2.8 of [RFC2680] give requirements and applicability
+ statements for endtoend onewayPacketLoss measurements. They are
+ applicable to each point of interest Hi involved in the measure.
+ Spatial packet loss measurement SHOULD be respectful of them,
+ especially those related to methodology, clock, uncertainties and
+ reporting.
 To determine if a dTi is defined or undefined it is necessary to
 define a period of time after which a packet is considered loss.
+ Following we define the spatial metric, then we adapt some of the
+ points above and introduce points specific to spatial measurement.
4.1.8. Methodologies
+4.2.1. Metric Name
 Section 3.6 of [RFC2679] gives methodologies for endtoend oneway
 delay measurements. Most of them apply to each points interest Hi
 and are relevant to this section.
+ TypePSpatialOnewayPacketLossVector
 Generally, for a given TypeP, in a given Hi, the methodology would
 proceed as follows:
+4.2.2. Metric Parameters
 o At each Hi, prepare to capture the packet sent a time T, take a
 timestamp Ti', determine the internal delay correction dTi',
 extract the timestamp T from the packet, then compute the oneway
 delay from Src to Hi: dTi = Ti'  dTi'  T. The oneway delay is
 undefined (infinite) if the packet is not detected after the 'loss
 threshold' duration;
 o Gather the set of dTi of each Hi and order them according to the
 path to build the TypePSpatialOnewayDelayVector metric
 over the path .
+ + Src*, the IP address of the sender.
 It is out of the scope of this document to define how each Hi detects
 the packet.
+ + Dst*, the IP address of the receiver.
4.1.9. Reporting the metric
+ + i, An integer which ordered the hosts in the path.
 Section 3.6 of [RFC2679] indicates the items to report.
+ + Hi, exchange points of the path digest.
4.1.10. Path
+ + T*, a time, the sending (or initial observation) time for
+ a measured packet.
 It is clear that a endtoend TypePOnewayDelay can't determine
 the list of hosts the packet passes through. Section 3.8.4 of
 [RFC2679] says that the path traversed by the packet SHOULD be
 reported but is practically impossible to determine.
+ + dT1,..., dTn, dT, a list of delay.
 This part of the job is provide by TypePSpatialOnewayDelay
 Vector metric because each points of interest Hi which capture the
 packet is part of the path.
+ + P*, the specification of the packet type.
4.2. A Definition of a sample of Oneway Delay of a sub path
+ + , hosts path digest.
 This metric is similar to the metric TypePOnewayDelayPoisson
 stream defined in [RFC2679] and to the metric TypePOnewayDelay
 PeriodicStream defined in [RFC3432].
+ + B1, B2, ..., Bi, ..., Bn, a list of Boolean values.
 Nevertheless its definition differs because it is based of the
 division of endtoend Oneway delay using the metric TypePSpatial
 OnewayDelayVector defined above.
+4.2.3. Metric Units
 It aims is to define a sample of OnewayDelay between a pair of
 hosts of a path usable by active and passive measurements.
+ A sequence of Boolean values.
 Sections 3.5 to 3.8 of [RFC2679] give requirements and applicability
 statements for endtoend onewaydelay measurements. They are
+4.2.4. Definition
+
+ Given a TypeP packet sent by the sender Src at time T to the
+ receiver Dst in the path . Given the sequence of
+ times the packet passes ,
+
+ TypePOnewayPacketLostVector metric is defined as the sequence
+ of values such that for each Hi of the path, a
+ value of Bi of 0 means that dTi is a finite value, and a value of 1
+ means that dTi is undefined.
+
+4.2.5. Discussion
+
+ Following are specific issues which may occur:
+
+ o the result includes the sequence 1,0. This case means that the
+ packet was seen by a host but not by it successor on the path;
+ The location of the point of interest in the device influences the
+ result:
+
+ o Even if the packet is received by a host, it may be not observed
+ by the point of interest located after a buffer;
+
+4.3. A Definition for Spatial Oneway Ipdv Vector
+
+ This section uses parameters from the definition of TypePOneway
+ ipdv. When a parameter from section 2 of [RFC3393] is first used in
+ this section, it will be tagged with a trailing asterisk.
+
+ Following we adapt some of them and introduce points specific which
+ are to spatial measurement.
+
+4.3.1. Metric Name
+
+ TypePSpatialOnewayipdvVector
+
+4.3.2. Metric Parameters
+
+ + Src*, the IP address of the sender.
+
+ + Dst*, the IP address of the receiver.
+
+ + i, An integer which ordered the hosts in the path.
+
+ + Hi, exchange points of the path digest.
+
+ + T1*, the time the first packet was sent.
+
+ + T2*, the time the second packet was sent.
+
+ + P, the specification of the packet type.
+
+ + P1, the first packet sent at time T1.
+
+ + P2, the second packet sent at time T2.
+
+ + , host path digest.
+
+ + ,
+ the TypePSpatialOnewayDelayVector for packet sent at
+ time T1;
+
+ + ,
+ the TypePSpatialOnewayDelayVector for packet sent at
+ time T2;
+
+ + L*, a packet length in bits. The packets of a Type P
+ packet stream from which the
+ TypePSpatialOnewayDelayVector metric is taken MUST
+ all be of the same length.
+
+4.3.3. Metric Units
+
+ A sequence of times.
+
+4.3.4. Definition
+
+ Given the TypeP packet having the size L and sent by the sender Src
+ at wiretime (first bit) T1 to the receiver Dst in the path .
+
+ Given the TypeP packet having the size L and sent by the sender Src
+ at wiretime (first bit) T2 to the receiver Dst in the same path.
+
+ Given the TypePSpatialOnewayDelayVector of the packet P1.
+
+ Given the TypePSpatialOnewayDelayVector of the packet P2.
+
+ TypePSpatialOnewayipdvVector metric is defined as the sequence
+ of values
+ Such that for each Hi of the path , dT2.idT1.i is
+ either a real number if the packets P1 and P2 passes Hi at wiretime
+ (last bit) dT1.i, respectively dT2.i, or undefined if at least one of
+ them never passes Hi. T2T1 is the interpacket emission interval
+ and dT2dT1 is ddT* the TypePOnewayipdv at T1,T2*.
+
+4.4. Spatial Methodology
+
+ Methodology, reporting and uncertainties points specified in section
+ 3 of [RFC2679][RFC2679] applies to each point of interest Hi
+ measuring a element of a spatial delay vector.
+
+ Methodology, reporting and uncertainties points specified in section
+ 2 of [RFC2680][RFC2680] applies to each point of interest Hi
+ measuring a element of a spatial packet loss vector.
+
+ Sections 3.5 to 3.7 of [RFC3393] give requirements and applicability
+ statements for endtoend Oneway ipdv measurements. They are
applicable to each point of interest Hi involved in the measure.
 Subpath onewaydelay measurement SHOULD be respectful of them,
 especially those related to methodology, clock, uncertainties and
 reporting.
+ Spatial Oneway ipdv measurement SHOULD be respectful of methodology,
+ clock, uncertainties and reporting aspects given in this section.
4.2.1. Metric Name
+ Passive and active measurement approaches of the metrology are
+ considered as orthogonal. Active measure differs mainly from passive
+ measure by the knowledge of the time the packet was send by the
+ source and received by the destination, making the RFC2330 framework
+ difficults to apply to passive measurement. On the other hand,
+ spatial metrics rely on passive observation of the packets involved
+ in the measure.
 TypePsubpathOnewayDelayStream
+ In fact each approach compliments the other setting the base of
+ spatial measurement methodology: Active points of interest provide
+ information observed at the source and at the destination while
+ Passive points of interests provide information observed at
+ intermediary hosts of the path.
4.2.2. Metric Parameters
+ Generally, for a given TypeP of length L, in a given Hi, the
+ methodology for spatial vector metrics would proceed as follows:
+
+ o At each Hi, points of interest prepare to capture the packet sent
+ a time T, take a timestamp Ti', determine the internal delay
+ correction dTi' (See section 3.7.1. "Errors or uncertainties
+ related to Clocks" of [RFC2679]),
+
+ o Each Hi extracts the path ordering information from the packet
+ (e.g. timetolive);
+
+ o Each Hi compute the wiretime from Src to Hi: Ti = Ti'  dTi'.
+ This arrival time is undefined (infinite) if the packet is not
+ detected after the 'loss threshold' duration;
+
+ o Each Hi extracts the timestamp T from the packet,
+
+ o Each Hi computes the onewaydelay from Src to Hi: dTi = Ti  T;
+
+ o The reference point gathers the result and timetolive of each Hi
+ and order them according to the path to build the TypePSpatial
+ OnewayDelayVector metric over the path
+ .
+
+4.4.1. Loss threshold
+
+ Loss threshold is the centrality of any methodology because it
+ determines the presence the packet in the measurement process of the
+ point of interest and consequently determines any ground truth metric
+ result. It determines the presence of an effective delay, and bias
+ the measure of ipdv, of packet loss and of the statistics.
+
+ This is consistent for endtoend but impacts spatial measure:
+ depending on the consistency of the Loss threshold among the points
+ of interest, a packet may be considered loss a one host but present
+ in another one, or may be observed by the last host (last hop) of the
+ path but considered lost by Dst. The analysis of such results is not
+ deterministic: has the path change? Does the packet arrive at
+ destination or was it lost during the last mile? The same applies,
+ of course, for onewaydelay measures: a delay measured may be
+ infinite at one host but a real value in another one, or may be
+ measured as a real value by the last host of the path but observed as
+ infinite by Dst. The Loss threshold should be set up with the same
+ value in each host of the path and in the destination. The Loss
+ threshold must be systematically reported to permit careful
+ introspection and to avoid the introduction of any contradiction in
+ the statistic computation process.
+
+4.4.2. Host Path Digest
+
+ The methodology given above adds the order of the points of interest
+ over the path to [RFC2679] one's.
+
+ A perfect Host Path Digest (hum! of cource from the measurement point
+ of view only, that is, corresponding to the real path the test packet
+ experimented) may include several times several hosts:
+
+ o coresponds to a loop in the path;
+
+ o coresponds to a loop in the path which
+ may occurs during rerouting phases;
+
+ These cases MUST be identified before statistics computation to avoid
+ corrupted results' production. This applies especially to the
+ measure of segments which are build from results of a measure of a
+ vector metric.
+
+5. Spatial Segments metrics definitions
+
+ This section defines samples to measure a sequence of delays, a
+ sequence of lost and a sequence of ipdv between 2 hosts of the path,
+ a segment. Singletons are taken from segments of vectors defined
+ above.
+
+5.1. A Definition of a sample of Oneway Delay of a segment of the path
+
+ This metric defines a sample of Oneway delays between a pair of
+ hosts of a path.
+
+5.1.1. Metric Name
+
+ TypePSegmentOnewayDelayStream
+
+5.1.2. Metric Parameters
+ Src*, the IP address of the sender.
+ Dst*, the IP address of the receiver.
+ + P*, the specification of the packet type;
+
+ i, An integer which orders exchange points in the path.
+ k, An integer which orders the packets sent.
 + , a path digest.
+ + Hi, a host of the path digest;
+
+ + , host path digest.
+ Ha, a host of the path digest different from Dst and Hb;
+ Hb, a host of the path digest different from Src and Ha.
Hb order in the path must greater that Ha;
 + Hi, exchange points of the path digest.

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

 + P*, the specification of the packet type.

4.2.3. Metric Units
+ + , a list of time ordered by k;
 A sequence of pairs .
+ + dT1,..., dTn a list of delay;
 T is one of time of the sequence T1...Tn;
+5.1.3. Metric Units
 dt is a delay.
+ A sequence of delay
4.2.4. Definition
+5.1.4. Definition
Given 2 hosts Ha and Hb of the path , given
a flow of packets of TypeP sent from Src to Dst at the times T1,
T2... Tn. At each of these times, we obtain a TypePSpatialOne
 wayDelayVector . We define the
 value of the sample TypePsubpathOnewayDelayStream as the
 sequence made up of the couples . dTk.a is the
 delay between Src and Ha. dTk.b is the delay between Src and Hb.
 'dTk.b  dTk.a' is the oneway delay experienced by the packet sent
 at the time Tk by Src when going from Ha to Hb.
+ wayDelayVector . We define
+ the value of the sample TypePsegmentOnewayDelayStream 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 oneway delay experienced by the packet sent by Src at
+ the time Tk when going from Ha to Hb.
4.2.5. Discussion
+5.1.5. Discussion
Following are specific issues which may occur:
o When a is Src is the measure of the first hop.
o When b is Dst is the measure of the last hop.
o the delay looks to decrease: dTi > DTi+1:
* This is typically du to clock synchronisation issue. this point
@@ 629,405 +867,398 @@
o dTk.b may be observed and not dTk.a.
o Tk is unknown if the flow is made of end user packets, that is
pure passive measure. In this case Tk may be forced to Tk+dTk.a.
This motivate separate metrics names for pure passive measurement
or specific reporting information.
o Pure passive measure should consider packets of the same size and
of the same TypeP.
4.2.6. Interference with other packet

4.2.7. loss threshold

 To determine if a dTi is defined or undefined it is necessary to
 define a period of time after which a packet is considered loss.

4.2.8. Methodologies

 Both active and passive method should discussed.

4.2.9. Reporting the metric

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

4.2.10. Path

4.3. A Definition for Spatial Oneway Packet Loss Vector

 This section is coupled with the definition of TypePOnewayPacket
 Loss. Then when a parameter from the section 2 of [RFC2680] is first
 used in this section, it will be tagged with a trailing asterisk.

 Sections 2.5 to 2.8 of [RFC2680] give requirements and applicability
 statements for endtoend onewayPacketLoss measurements. They are
 applicable to each point of interest Hi involved in the measure.
 Spatial packet loss measurement SHOULD be respectful of them,
 especially those related to methodology, clock, uncertainties and
 reporting.
+5.2. A Definition of a sample of Packet Loss of a segment of the path
 Following we define the spatial metric, then we adapt some of the
 points above and introduce points specific to spatial measurement.
+ This metric defines a sample of Packet lost between a pair of hosts
+ of a path.
4.3.1. Metric Name
+5.2.1. Metric Name
 TypePSpatialOnewayPacketLossVector
+ TypePsegmentPacketlossStream
4.3.2. Metric Parameters
+5.2.2. Metric Parameters
+ Src*, the IP address of the sender.
+ Dst*, the IP address of the receiver.
 + i, An integer which ordered the hosts in the path.

 + Hi, exchange points of the path digest.

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

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

+ P*, the specification of the packet type.
 + , a path digest.

 + B1, B2, ..., Bi, ..., Bn, a list of Boolean values.
+ + k, An integer which orders the packets sent.
4.3.3. Metric Units
+ + n, An integer which orders the hosts on the path.
 A sequence of Boolean values.
+ + , hosts path digest.
4.3.4. Definition
+ + Ha, a host of the path digest different from Dst and Hb;
 Given a TypeP packet sent by the sender Src at time T to the
 receiver Dst in the path . Given the sequence of
 times the packet passes ,
+ + Hb, a host of the path digest different from Src and Ha.
+ Hb order in the path must greater that Ha;
 TypePOnewayPacketLostVector metric is defined as the sequence
 of values such that for each Hi of the path, a
 value of Bi of 0 means that dTi is a finite value, and a value of 1
 means that dTi is undefined.
+ + Hi, exchange points of the path digest.
4.3.5. Discussion
+ + a list of bits.
 Following are specific issues which may occur:
+ + a list of integers.
 o the result includes the sequence 1,0. This case means that the
 packet was seen by a host but not by it successor on the path;
+5.2.3. Metric Units
 o
+ A sequence of integers
 The location of the meter in the device influences the result:
+5.2.4. Definition
 o Even if the packet is received by a device, it may be not observed
 by a meter located after a buffer;
+ Given 2 hosts Ha and Hb of the path , given
+ a flow of packets of TypeP sent from Src to Dst at the times T1,
+ T2... Tn. At each of these times, we obtain a TypePSpatial
+ PacketLostVector . We define the value of
+ the sample TypePsegmentPacketLostStream between Ha and Hb as the
+ sequence made up of the integer such that for each
+ Tk:
4.3.6. Reporting
+ o a value of Lk of 0 means that Bk.a has a value of 0 (observed) and
+ that Bk.b have a value of 0 (observed);
 Section in progress.
+ o a value of Lk of 1 means that Bk.a has a value of 0 (observed) and
+ that Bk.b have a value of 1 (not observed);
4.4. A Definition for Spatial Oneway Jitter Vector
+ o a value of Lk of 2 means that Bk.a has a value of 1 (not observed)
+ and that Bk.b have a value of 0 (observed);
+ o a value of Lk of 3 means that Bk.a has a value of 1 (not observed)
+ and that Bk.b have a value of 1 (not observed).
 This section uses parameters from the definition of TypePOneway
 ipdv. When a parameter from section 2 of [RFC3393] is first used in
 this section, it will be tagged with a trailing asterisk.
+5.2.5. Discussion
 Sections 3.5 to 3.7 of [RFC3393] give requirements and applicability
 statements for endtoend onewayipdv measurements. They are
 applicable to each point of interest Hi involved in the measure.
 Spatial onewayipdv measurement SHOULD be respectful of them,
 especially those related to methodology, clock, uncertainties and
 reporting.
+ The semantic of a TypePsegmentPacketlossStream is similar to the
+ one of TypePPacketlossStream:
 Following we adapt some of them and introduce points specific to
 spatial measurement.
+ o a value of 0 means that the packet was observed by Ha (similar to
+ 'send by Src') and not observed by Hb ( similar to 'not received
+ by Dst');
4.4.1. Metric Name
+ o a value of 1 means that it was observed by Ha (similar to 'send by
+ Src') and observed by Hb ( similar to 'received by Dst').
 TypePSpatialOnewayJitterVector
+ This definition of TypePsegmentPacketlossStream is similar to
+ the TypePPacketlossStream defined in [RFC2680] excepted that in a
+ TypePsegmentPacketlossStream 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 TypePsegmentPacketloss
+ Stream because as the host path digest is dynamic each packet has its
+ own host path digest.
4.4.2. Metric Parameters
+ Making the asumption that the host path digest of a TypePspatial
+ Packetlossvector does not change and that the set of (Hk, Hk+1)
+ tuples is mostly stable over time lead to unusable results and to the
+ introduction of mistakes in the metrics aggregation processes. The
+ right approach consists in carefully scrutening the path ordering
+ information to build sample with elements of vectors sharing the same
+ properties in term of Ha and Hb and 'Ha to Hb'. So a measure of
+ TypePspatialPacketlossvector differs from a TypePPacketloss
+ one in that it produces different samples of packet loss over time.
 + Src*, the IP address of the sender.
+ The semantic of a TypePsegmentPacketlossStream defines 2 new
+ results:
 + Dst*, the IP address of the receiver.
+ o A value of Lk of 2 (1,0) corresponds to a mistake in the ordering
+ of Ha and Hb over the path coming either from the configuration
+ (asumption on the path) or from the processing of the vectors: bad
+ scrutening of the path ordering information, or some other mistake
+ in the measure or the reporting. It is not in the scope of this
+ document to go in further details which are mostly implementation
+ dependent. This value MUST not be used to compute packet lost
+ statistics.
 + i, An integer which ordered the hosts in the path.
+ o A value of Lk of 3 (1,1) corresponds to a lost of the packet in
+ upper segment of the path.
 + Hi, exchange points of the path digest.
+5.3. A Definition of a sample of Oneway Ipdv of a segment of the path
 + T1*, the time the first packet was sent.
+ This metric defines a sample of ipdv between a pair of hosts of a
+ path.
 + T2*, the time the second packet was sent.
+ Editor note: work in progress
 + P, the specification of the packet type.
+5.3.1. Metric Name
 + P1, the first packet sent at time T1.
+ TypePSegmentIpdvStream
 + P2, the second packet sent at time T2.
+5.3.2. Metric Parameters
 + , a path digest.
+5.3.3. Metric Units
 + ,
 the TypePSpatialOnewayDelayVector for packet sent at
 time T1;
+5.3.4. Definition
 + ,
 the TypePSpatialOnewayDelayVector for packet sent at
 time T2;
+5.3.5. Discussion
 + L*, a packet length in bits. The packets of a Type P
 packet stream from which the
 TypePSpatialOnewayDelayVector metric is taken MUST
 all be of the same length.
+5.4. Discussion on Passive Segment Metrics
4.4.3. Metric Units
+ A pure passive spatial measure is the measure of a spatial metric
+ based on the observation of user traffic instead of packets dedicated
+ to the measure.
 A sequence of times.
+ This section discusses the applicability of pure passive measurement
+ methodology (e.g. without injecting test traffic as described by
+ PSAMP documents [draftietfpsampsampletech10.txt]) to measure
+ spatial metrics.
4.4.4. Definition
+ To permit comparison and discussion, we firstly define pure passive
+ measurement methodology following the spirit of IPPM framework
+ [RFC2330] and the methodology of [RFC2679]. Then we propose several
+ passive metrics complying to this framework.
 Given the TypeP packet having the size L and sent by the sender Src
 at wiretime (first bit) T1 to the receiver Dst in the path .
+5.4.1. A methodololy for passive segment metrics
 Given the TypeP packet having the size L and sent by the sender Src
 at wiretime (first bit) T2 to the receiver Dst in the same path.
+ The following starts from the point that the time a packet is sent is
+ not needed to measure the delay from one host Ha of the path to
+ another host Hb.
 Given the TypePSpatialOnewayDelayVector of the packet P1.
+ Generally, for the packets of TypeP and length L sent a time by the source Src pure passive methodology might proceed
+ as follows:
 Given the TypePSpatialOnewayDelayVector of the packet P2.
+ o Each point of interest Ha and Hb prepares to capture these
+ packets;
+ o Each point of interest Ha and Hb takes a timestamp Ti', determines
+ the internal delay correction dTi' (See section 3.7.1. "Errors or
+ uncertainties related to Clocks" of [RFC2679]),
 TypePSpatialOnewayJitterVector metric is defined as the
 sequence of values Such that for each Hi of the path ,
 dT2.idT1.i is either a real number if the packets P1 and P2 passes
 Hi at wiretime (last bit) dT1.i, respectively dT2.i, or undefined if
 at least one of them never passes Hi. T2T1 is the interpacket
 emission interval and dT2dT1 is ddT* the TypePOnewayipdv at
 T1,T2*.
+ o Each points of interest Ha and Hb extracts the path ordering
+ information from the packet (e.g. timetolive)
4.4.5. Sections in progress
+ o Each points of interest Ha and Hb computes the wiretime fSrom Src
+ to Hi: Ti = Ti'  dTi'. ;
 See sections 3.5 to 3.7 of [RFC3393].
+ o The reference point gathers individual information for the packets
+ sent a time from each point of interest Ha and Hb
+ and proceeds as follow:
4.5. Pure Passive Metrics
+ * Orders them according to the path ordering information;
 Spatial metrics may be measured without injecting test traffic.
+ * Extracts the timestamps Ti.a and Ti+1.b. This arrival time is
+ undefined (infinite) if the packet is not detected;
4.5.1. Discussion on Passive measurement
+ * Computes the onewaydelay from Ha to Hb as (Ti+1.b  Ti.a).
+ The delay is undefined (infinite) if the packet is not detected
+ in Ha or Hb;
 One might says that most of the operational issues occur in the last
 mile and that consequently such measure are less useful than active
 measurement. Nevertheless they are usable for network TE and
 interdomain QoS monitoring, and composition of metric.
+ o The reference point builds the segment sample from Ha to Hb;
 Such a technique have some limitations that are discussed below.
+5.4.2. Discussion on passive methodololy
4.5.1.1. Passive One way delay
+ Intrinsically passive methodololy does not known (neither in the
+ points of interest nor in the point of reference) the time each
+ packet is sent and the time each packet it received.
 As the packet is not a test packet, it does not include the time it
 was sent.
+ Section 5.4.1 shows that a passive segment oneway delay measure does
+ not rely on the time T the packet is sent to compute the delay from a
+ host Ha to a host Hb.
 Consequently a point of interest Hi ignores the time the packet was
 send. So It is not possible to measure the delay between Src and Hi
 in the same manner it is not possible to measure the delay betwwen Hi
 and Dst.
+ Intuitively, packets loss measurement does not require any time
+ information and only expects the packet was sent. Passive packet
+ loss methodology relies on the detection of the packet by one point
+ of interest and not by another. This relies on asumptions similar to
+ spatial methodology:
4.5.1.2. Passive Packet loss
+ o The knowledge of the path and the order of the points of interest
+ over the path;
 The packet is not a test packet, so it does not include a sequence
 number.
+ o The packet is observed by one point of interest and not by
+ another;
+ Nevertheless, passive packet loss measure is limited by the fact that
+ information that neither a packet has be sent nor that the packet was
+ received is never available:
 Packet lost measurement doe not require time synchronization and
 require only one point of observation. Nevertheless it requires the
 point of interest Hi to be expecting the packet. Practically Hi may
 not detect a lost of packet that occurs between Src and Hi.
+ when the path changes and the packet is not observed it is not
+ deterministic to state that the packet is lost because the measure
+ does not known that the packet is received by Dst.
 A point of interest Hi ignores the time the packet is send because
 the packet does not carry the time it was injected in the network.
 So a probe Hi can not compute dTi.
+ when the measure does not observe any packets it is not possible
+ to state that all packets are lost because the measure does not
+ known that any packets were sent.
 An alternative to these issues consist in considering sample spatial
 Oneway delay that T is the time when H1 (the first passive probe of
 the path) observed the packet.
+ The drawback is that monitoring finely these events is crucial for
+ troubleshooting workflow.
4.5.2. Reporting and composition
+ IPPM framework relies on the mesure of the behavior of packets of the
+ same size. Consequently a passive metric sample MUST not mix
+ information of packets of different sizes.
 To avoid misunderstanding and to address specific reporting
 constraint a proposal consists in defining distinct metrics for pure
 passive measurement based on the definition above.
+ Segment metrics may be measured using pure passive technics. Passive
+ segment metrics definitions are very closed to spatial segment
+ metrics definitions. Therefore below we just name passive segment
+ metrics to distinguish the methodology used. Having distinct metrics
+ identifiers for spatial metrics and passive spatial metrics in the
+ [RFC4148] will avoid interoperability issues especially during
+ composition of metrics the IPPM WG is currently defining.
 It is crucial to know the methodologies used because of the
 difference of method of detection (expecting Seq++); because of the
 difference of source of time (H1 vs Src) and because of the
 difference of behaviour of the source (Poisson/unknown).
+5.4.3. Passive Segment metrics
4.5.3. naming and registry
+5.4.3.1. Passive Segment One way Delay metric
 Having distinct metrics identifiers for spatial metrics and passive
 spatial metrics in the [RFC4148] will avoid interoperability issues
 especially during composition of metrics.
+ This metric definition is based on the top of the TypePspatial
+ segmentOnewayDelayStream metric definition.
4.5.4. Passive One way delay metrics
+ name: TypePPassiveSegmentOnewayDelayStream
4.5.5. Passive One way PacketLoss metrics
+5.4.3.2. Passive Segment Packet Loss metric
4.5.6. Passive One way jitter metrics
+ This metric definition is based on the top of the TypePspatial
+ segmentPacketLossStream metric definition.
4.6. Discussion on spatial statistics
+ name: TypePPassiveSegmentPacketLossStream
 Do we define min, max, avg of spatial metrics ?
+5.4.3.3. Passive Segment Oneway Ipdv metric
 having the maximum loss metric value could be interesting. Say,
 the segment between router A and B always contributes loss metric
 value of "1" means it could be the potential problem segment.
+ This metric definition is based on the top of the TypePSegment
+ IpdvStream metric definition.
 Uploading dTi of each Hi consume a lot of bandwidth. Computing
 statistics (min, max and avg) of dTi locally in each Hi reduce the
 bandwidth consumption.
+ name: TypePPassiveSegmentOnewayIpdvStream
5. Onetogroup metrics definitions
+6. Onetogroup metrics definitions
5.1. A Definition for onetogroup Oneway Delay
+6.1. A Definition for onetogroup Oneway Delay
5.1.1. Metric Name
+6.1.1. Metric Name
TypePonetogroupOnewayDelayVector
5.1.2. Metric Parameters
+6.1.2. Metric Parameters
o Src, the IP address of a host acting as the source.
o Recv1,..., RecvN, the IP addresses of the N hosts acting as
receivers.
o T, a time.
o dT1,...,dTn a list of time.
o P, the specification of the packet type.
o Gr, the multicast group address (optional). The parameter Gr is
the multicast group address if the measured packets are
transmitted by multicast. This parameter is to identify the
measured traffic from other unicast and multicast traffic. It is
set to be optional in the metric to avoid losing any generality,
i.e. to make the metric also applicable to unicast measurement
where there is only one receivers.
5.1.3. Metric Units
+6.1.3. Metric Units
The value of a TypePonetogroupOnewayDelayVector is a set of
singletons metrics TypePOnewayDelay [RFC2679].
5.1.4. Definition
+6.1.4. Definition
Given a Type P packet sent by the source Src at Time T, given the N
hosts { Recv1,...,RecvN } which receive the packet at the time {
T+dT1,...,T+dTn }, a TypePonetogroupOnewayDelayVector is
defined as the set of the TypePOnewayDelay singleton between Src
and each receiver with value of { dT1, dT2,...,dTn }.
5.2. A Definition for onetogroup Oneway Packet Loss
+6.2. A Definition for onetogroup Oneway Packet Loss
5.2.1. Metric Name
+6.2.1. Metric Name
TypePonetogroupOnewayPacketLossVector
5.2.2. Metric Parameters
+6.2.2. Metric Parameters
o Src, the IP address of a host acting as the source.
o Recv1,..., RecvN, the IP addresses of the N hosts acting as
receivers.
o T, a time.
o T1,...,Tn a list of time.
o P, the specification of the packet type.
o Gr, the multicast group address (optional).
5.2.3. Metric Units
+6.2.3. Metric Units
The value of a TypePonetogroupOnewayPacketLossVector is a
set of singletons metrics TypePOnewayPacketLoss [RFC2680].
5.2.4. Definition
+6.2.4. Definition
Given a Type P packet sent by the source Src at T and the N hosts,
Recv1,...,RecvN, which should receive the packet at T1,...,Tn, a
TypePonetogroupOnewayPacketLossVector is defined as a set of
the TypePOnewayPacketLoss singleton between Src and each of the
receivers {,,..., }.
5.3. A Definition for onetogroup Oneway Jitter
+6.3. A Definition for onetogroup Oneway Ipdv
5.3.1. Metric Name
+6.3.1. Metric Name
 TypePonetogroupOnewayJitterVector
+ TypePOnetogroupOnewayipdvVector
5.3.2. Metric Parameters
+6.3.2. Metric Parameters
+ Src, the IP address of a host acting as the source.
+ Recv1,..., RecvN, the IP addresses of the N hosts acting as
receivers.
+ T1, a time.
+ T2, a time.
+ ddT1,...,ddTn, a list of time.
+ P, the specification of the packet type.
+ F, a selection function defining unambiguously the two
packets from the stream selected for the metric.
+ Gr, the multicast group address (optional)
5.3.3. Metric Units
+6.3.3. Metric Units
 The value of a TypePonetogroupOnewayJitterVector is a set of
+ The value of a TypePOnetogroupOnewayipdvVector is a set of
singletons metrics TypePOnewayipdv [RFC3393].
5.3.4. Definition
+6.3.4. Definition
 Given a Type P packet stream, TypePonetogroupOnewayJitter
 Vector is defined for two packets from the source Src to the N hosts
+ Given a Type P packet stream, TypePonetogroupOnewayipdvVector
+ is defined for two packets from the source Src to the N hosts
{Recv1,...,RecvN },which are selected by the selection function F, as
the difference between the value of the TypePonetogroupOneway
DelayVector from Src to { Recv1,..., RecvN } at time T1 and the
value of the TypePonetogroup OnewayDelayVector from Src to {
Recv1,...,RecvN } at time T2. T1 is the wiretime at which Src sent
the first bit of the first packet, and T2 is the wiretime at which
Src sent the first bit of the second packet. This metric is derived
from the TypePoneto groupOnewayDelayVector metric.
Therefore, for a set of real number {ddT1,...,ddTn},TypePone to
 groupOnewayJitterVector from Src to { Recv1,...,RecvN } at T1, T2
+ groupOnewayipdvVector from Src to { Recv1,...,RecvN } at T1, T2
is {ddT1,...,ddTn} means that Src sent two packets, the first at
wiretime T1 (first bit), and the second at wiretime T2 (first bit)
and the packets were received by { Recv1,...,RecvN } at wiretime
{dT1+T1,...,dTn+T1}(last bit of the first packet), and at wiretime
{dT'1+T2,...,dT'n+T2} (last bit of the second packet), and that
{dT'1dT1,...,dT'ndTn} ={ddT1,...,ddTn}.
6. OnetoGroup Sample Statistics
+7. OnetoGroup Sample Statistics
The defined onetogroup metrics above can all be directly achieved
from the relevant unicast oneway metrics. They managed to collect
all unicast measurement results of oneway metrics together in one
profile and sort them by receivers and packets in a multicast group.
They can provide sufficient information regarding the network
performance in terms of each receiver and guide engineers to identify
potential problem happened on each branch of a multicast routing
tree. However, these metrics can not be directly used to
conveniently present the performance in terms of a group and neither
@@ 1048,48 +1279,48 @@
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.
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 FRCs. They provide the foundation of
+ 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
later one can have statistics over both time and space dimensions.
This space dimension is introduced by the Matrix concept as
 illustrated in Figure 7. For a Matrix M each row is a set of Oneway
+ illustrated in Figure 9. For a Matrix M each row is a set of Oneway
singletons spreading over the time dimension and each column is
another set of Oneway singletons spreading over the space dimension.
Receivers
Space
^
1  / R1dT1 R1dT2 R1dT3 ... R3dTk \
  
2   R2dT1 R2dT2 R2dT3 ... R3dTk 
  
3   R3dT1 R3dT2 R3dT3 ... R3dTk 
.   
.   
.   
n  \ RndT1 RndT2 RndT3 ... RndTk /
+> time
T0
 Figure 7: Matrix M (n*m)
+ Figure 9: Matrix M (n*m)
In Matrix M, each element is a Oneway delay singleton. Each column
is a delay vector contains the Oneway delays of the same packet
observed at M points of interest. It implies the geographical factor
of the performance within a group. Each row is a set of Oneway
delays observed during a sampling interval at one of the points of
interest. It presents the delay performance at a receiver over the
time dimension.
Therefore, one can either calculate statistics by rows over the space
@@ 1142,21 +1373,21 @@
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.
6.1. Discussion on the Impact of packet loss on statistics
+7.1. Discussion on the Impact of packet loss on statistics
The packet loss does have effects on oneway metrics and their
statistics. For example, the lost packet can result an infinite one
way delay. It is easy to handle the problem by simply ignoring the
infinite value in the metrics and in the calculation of the
corresponding statistics. However, the packet loss has so strong
impact on the statistics calculation for the onetogroup metrics
that it can not be solved by the same method used for oneway
metrics. This is due to the complex of building a Matrix, which is
needed for calculation of the statistics proposed in this memo.
@@ 1179,30 +1410,30 @@
R1dT1 R1dT2 R1dT3 ... R1dTK1 UNDEF R1dTK+1... R1DM } where "UNDEF"
is an undefined value, the reference point can replace it by R1dTK =
{(R1dTK1)+( R1dTK+1)}/2. Therefore, this result can be used to
build up the group Matrix with an estimated value R1dTK. There are
other possible solutions such as using the overall mean of the whole
result to replace the infinite/undefined value, and so on. It is out
of the scope of this memo.
For the distributed calculation, the reported statistics might have
different "weight" to present the group performance, which is
 especially true for delay and jitter relevant metrics. For example,
+ especially true for delay and ipdv relevant metrics. For example,
User1 calculates the TypePFiniteOnewayDelayMean R1DM as shown
in Figure. 8 without any packet loss and User2 calculates the R2DM
with N2 packet loss. The R1DM and R2DM should not be treated with
equal weight because R2DM was calculated only based on 2 delay values
in the whole sample interval. One possible solution is to use a
weight factor to mark every statistic value sent by users and use
this factor for further statistic calculation.
6.2. General Metric Parameters
+7.2. General Metric Parameters
o Src, the IP address of a host
o G, the Group IP address
o N, the number of Receivers (Recv1, Recv2, ... RecvN)
o T, a time (start of test interval)
o Tf, a time (end of test interval)
@@ 1235,200 +1466,200 @@
o dT, shorthand notation for a oneway delay singleton value
o L, shorthand notation for a oneway loss singleton value, either
zero or one, where L=1 indicates loss and L=0 indicates arrival at
the destination within TstampSrc + Tmax, may be indexed over n
Receivers
o DV, shorthand notation for a oneway delay variation singleton
value
6.3. OnetoGroup oneway Delay Statistics
+7.3. OnetoGroup oneway Delay Statistics
This section defines the overall oneway delay statistics for an
entire Group or receivers. For example, we can define the group mean
delay, as illustrated below. This is a metric designed to summarize
 the entire Matrix.
+ the whole matrix.
Recv / Sample \ Stats Group Stat
1 R1dT1 R1dT2 R1dT3 ... R1dTk R1DM \

2 R2dT1 R2dT2 R2dT3 ... R2dTk R2DM 

3 R3dT1 R3dT2 R3dT3 ... R3dTk R2DM > GMD
. 
. 
. 
n RndT1 RndT2 RndT3 ... RndTk RnDM /
 Figure 8: OnetoGroupGroup Mean Delay
+ Figure 10: OnetoGroupGroup Mean Delay
where:
R1dT1 is the TypePFiniteOnewayDelay singleton evaluated at
Receiver 1 for packet 1.
R1DM is the TypePFiniteOnewayDelayMean evaluated at Receiver 1
for the sample of packets (1,...K).
GMD is the mean of the sample means over all Receivers (1, ...N).
6.3.1. Definition and Metric Units
+7.3.1. Definition and Metric Units
Using the parameters above, we obtain the value of TypePOneway
Delay singleton for all packets sent during the test interval at each
Receiver (Destination), as per [RFC2679]. For each packet that
arrives within Tmax of its sending time, TstampSrc, the oneway delay
singleton (dT) will be a finite value in units of seconds.
Otherwise, the value of the singleton is Undefined.
For each packet [i] that has a finite Oneway Delay at Receiver n (in
other words, excluding packets which have undefined oneway delay):
TypePFiniteOnewayDelayReceivern[i] =
= TstampRecv[i]  TstampSrc[i]
The units of Finite oneway delay are seconds, with sufficient
resolution to convey 3 significant digits.
6.3.2. Sample Mean Statistic
+7.3.2. Sample Mean Statistic
This section defines the Sample Mean at each of N Receivers.
TypePFiniteOnewayDelayMeanReceivern = RnDM =
J[n]

1 \
 * > TypePFiniteOnewayDelayReceivern[i]
J[n] /

i = 1
 Figure 9: TypePFiniteOnewayDelayMeanReceivern
+ Figure 11: TypePFiniteOnewayDelayMeanReceivern
where all packets i= 1 through J[n] have finite singleton delays.
6.3.3. OnetoGroup Mean Delay Statistic
+7.3.3. OnetoGroup Mean Delay Statistic
This section defines the Mean Oneway Delay calculated over the
entire Group (or Matrix).
TypePOnetoGroupMeanDelay = GMD =
N

1 \
 * > RnDM
N /

n = 1
 Figure 10: TypePOnetoGroupMeanDelay
+ Figure 12: TypePOnetoGroupMeanDelay
Note that the Group Mean Delay can also be calculated by summing the
Finite oneway Delay singletons in the Matrix, and dividing by the
number of Finite Oneway Delay singletons.
6.3.4. OnetoGroup Range of Mean Delays
+7.3.4. OnetoGroup Range of Mean Delays
This section defines a metric for the range of mean delays over all N
receivers in the Group, (R1DM, R2DM,...RnDM).
TypePOnetoGroupRangeMeanDelay = GRMD = max(RnDM)  min(RnDM)
6.3.5. OnetoGroup Maximum of Mean Delays
+7.3.5. OnetoGroup Maximum of Mean Delays
This section defines a metrics for the maximum of mean delays over
all N receivers in the Group, (R1DM, R2DM,...RnDM).
TypePOnetoGroupMaxMeanDelay = GMMD = max(RnDM)
6.4. OnetoGroup oneway Loss Statistics
+7.4. OnetoGroup oneway Loss Statistics
This section defines the overall 1way loss statistics for an entire
Group. For example, we can define the group loss ratio, as
illustrated below. This is a metric designed to summarize the entire
Matrix.
Recv / Sample \ Stats Group Stat
1 R1L1 R1L2 R1L3 ... R1Lk R1LR \

2 R2L1 R2L2 R2L3 ... R2Lk R2LR 

3 R3L1 R3L2 R3L3 ... R3Lk R3LR > GLR
. 
. 
. 
n RnL1 RnL2 RnL3 ... RnLk RnLR /
 Figure 11: OnetoGroup Loss Ratio
+ Figure 13: OnetoGroup Loss Ratio
where:
R1L1 is the TypePOnewayLoss singleton (L) evaluated at Receiver 1
for packet 1.
R1LR is the TypePOnewayLossRatio evaluated at Receiver 1 for the
sample of packets (1,...K).
GLR is the loss ratio over all Receivers (1, ..., N).
6.4.1. OnetoGroup Loss Ratio
+7.4.1. OnetoGroup Loss Ratio
The overall Group loss ratio id defined as
TypePOnetoGroupLossRatio =
K,N

1 \
=  * > L(k,n)
K*N /

k,n = 1
 Figure 12
+ Figure 14
ALL Loss ratios are expressed in units of packets lost to total
packets sent.
6.4.2. OnetoGroup Loss Ratio Range
+7.4.2. OnetoGroup Loss Ratio Range
Given a Matrix of loss singletons as illustrated above, determine the
TypePOnewayPacketLossAverage for the sample at each receiver,
according to the definitions and method of [RFC2680]. The TypeP
OnewayPacketLossAverage, RnLR for receiver n, and the TypePOne
wayLossRatio illustrated above are equivalent metrics. In terms of
the parameters used here, these metrics definitions can be expressed
as
TypePOnewayLossRatioReceivern = RnLR =
K

1 \
 * > RnLk
K /

k = 1
 Figure 13: TypePOnewayLossRatioReceivern
+ Figure 15: TypePOnewayLossRatioReceivern
The OnetoGroup Loss Ratio Range is defined as
TypePOnetoGroupLossRatioRange = max(RnLR)  min(RnLR)
It is most effective to indicate the range by giving both the max and
minimum loss ratios for the Group, rather than only reporting the
difference between them.
6.4.3. Comparative Loss Ratio
+7.4.3. Comparative Loss Ratio
Usually, the number of packets sent is used in the denominator of
packet loss ratio metrics. For the comparative metrics defined here,
the denominator is the maximum number of packets received at any
receiver for the sample and test interval of interest.
The Comparative Loss Ratio is defined as
TypePCompLossRatioReceivern = RnCLR =
K
@@ 1440,31 +1671,31 @@
k=1
= 
/ K \
  
 \ 
K  Min  > Ln(k) 
 / 
  
\ k=1 / N
 Figure 14: TypePCompLossRatioReceivern
+ Figure 16: TypePCompLossRatioReceivern
6.5. OnetoGroup oneway Delay Variation Statistics
+7.5. OnetoGroup oneway Delay Variation Statistics
 There is are two delay variation (DV) statistics to summarize the
+ There are two delay variation (DV) statistics that summarize the
performance over the Group: the maximum DV over all receivers and the
 range of DV over all receivers.

 The detailed definitions are T0 BE PROVIDED.
+ minimum DV over all receivers (where DV is a pointtopoint metric).
+ For each receiver, the DV is usually expressed as the 110^(3)
+ quantile of oneway delay minus the minimum oneway delay.
7. Measurement Methods: Scaleability and Reporting
+8. Measurement Methods: Scaleability and Reporting
Virtually all the guidance on measurement processes supplied by the
earlier IPPM RFCs (such as [RFC2679] and [RFC2680]) for onetoone
scenarios is applicable here in the spatial and multiparty
measurement scenario. The main difference is that the spatial and
multiparty configurations require multiple measurement points where a
stream of singletons will be collected. The amount of information
requiring storage grows with both the number of metrics and the
number of measurement points, so the scale of the measurement
architecture multiplies the number of singleton results that must be
@@ 1481,21 +1712,21 @@
architectures today, where even the individual singletons may not be
stored at each measurement point.
In recognition of the likely need to minimize form of the results for
storage and communication, the Group metrics above have been
constructed to allow some computations on a 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).
7.1. Computation methods
+8.1. Computation methods
The scalability issue can be raised when there are thousands of
points of interest in a group who are trying to send back the
measurement results to the reference point for further processing and
analysis. The points of interest can send either the whole measured
sample or only the calculated statistics. The former one is a
centralized statistic calculation method and the latter one is a
distributed statistic calculation method. The sample should include
all metrics parameters, the values and the corresponding sequence
numbers. The transmission of the whole sample can cost much more
@@ 1522,138 +1753,397 @@
the reference point first to obtain the general information of the
group performance. If the detail results are required, the reference
point should send the requests to the points of interest, which could
be particular ones or the whole group. This procedure can happen in
the off peak time and can be well scheduled to avoid delivery of too
many points of interest at the same time. Compression techniques can
also be used to minimize the bandwidth required by the transmission.
This could be a measurement protocol to report the measurement
results. It is out of the scope of this memo.
7.2. Measurement
+8.2. Measurement
 To prevent any biais in the result, the configuration of a oneto
 many measure must take in consideration that implicitly more packets
 will to be routed than send and selects a test packets rate that will
 not impact the network performance.
+ To prevent any bias in the result, the configuration of a onetomany
+ measure must take in consideration that implicitly more packets will
+ to be routed than send and selects a test packets rate that will not
+ impact the network performance.
7.3. effect of Time and Space Aggregation Order on Group Stats
+8.3. Effect of Time and Space Aggregation Order on Stats
This section presents the impact of the aggregation order on the
 scalability of the reporting and of the the computation. It makes
 the hypothesis that receivers are managed remotly and not colocated.

 2 methods are available to compute group statistics:

 Figure 8and (Figure 11) illustrate the method method choosen: the
 onetoone statistic is computed per interval of time before the
 computation of the mean over the group of receivers [method1];

 Figure 15 presents the second one, metric is computed over space
 and then over time [method2].

 They differ only by the order of the time and of the space
 aggregation. View as a matrix this order is neutral as it does not
 impact the result, but the impact on a measurement deployement is
 critical.
+ scalability of the reporting and of the computation. It makes the
+ hypothesis that receivers are managed remotely and not colocated.
 Recv
+ multimetrics samples represented a matrix as illustrated below
+ Point of
+ interest
1 R1S1 R1S1 R1S1 ... R1Sk \

2 R2S1 R2S2 R2S3 ... R2Sk 

3 R3S1 R3S2 R3S3 ... R3Sk > sample over space
. 
. 
. 
n RnS1 RnS2 RnS3 ... RnSk /
S1M S2M S3M ... SnM Stats over space
\ /
\/
 Group Stat over space and time
+ Stat over space and time
 Figure 15: Impact of space aggregation on Group Stat
+ Figure 17: Impact of space aggregation on multimetrics Stat
+
+ 2 methods are available to compute statistics on the resulting
+ matrix:
+
+ o metric is computed over time and then over space;
+ o metric is computed over space and then over time.
+
+ They differ only by the order of the time and of the space
+ aggregation. View as a matrix this order is neutral as does not
+ impact the result, but the impact on a measurement deployment is
+ critical.
In both cases the volume of data to report is proportional to the
number of probes. But there is a major difference between these 2
methods:
method2: In space and time aggregation mode the volume of data to
 collect is proportionnal to the number of test packets received;
+ collect is proportional to the number of test packets received;
Each received packet RiSi triggers out a block of data that must
be reported to a common place for computing the stat over space;
method1: In time and space aggregation mode the volume of data to
 collect is proportionnal to the period of aggregation, so it does
+ collect is proportional to the period of aggregation, so it does
not depend on the number of packet received;
Method 2 property has severe drawbacks in terms of security and
 dimensionning:
+ dimensioning:
The increasing of the rate of the test packets may result in a
sort of DoS toward the computation points;
The dimensioning of a measurement system is quite impossible to
validate.
 The time agregation interval provides the reporting side with a
+ The time aggregation interval provides the reporting side with a
control of various collecting aspects such as bandwidth and
computation and storage capacities. So this draft defines metrics
based on method 1.
Note: In some specific cases one may need sample of singletons over
 space. To adress this need it is suggested firstly to limit the
+ space. To address this need it is suggested firstly to limit the
number of test and the number of test packets per seconds. Then
reducing the size of the sample over time to one packet give sample
of singleton over space..
7.4. effect of Time and Space Aggregation Order on Spatial Stats
+8.3.1. Impact on group stats
 TBD
+ 2 methods are available to compute group statistics:
8. Open issues
+ o method1: Figure 10 andFigure 13 illustrate the method chosen: the
+ onetoone statistic is computed per interval of time before the
+ computation of the mean over the group of receivers;
+ o method2: Figure 17 presents the second one, metric is computed
+ over space and then over time.
9. Security Considerations
+8.3.2. Impact on spatial stats
 Active measurement: (TODO: security considerations of owd pl, jitter
 rfcs applies (editor notes: add references).
+ 2 methods are available to compute group statistics:
9.1. passive measurement
+ o method 1: spatial segment metrics and statistics are preferably
+ computed over time by each points of interest;
 The generation of packets which match systematically the hash
 function may lead to a DoS attack toward the collector.
+ o method 2: Vectors metrics are intrinsecally instantaneous space
+ metrics which must be reported using method2 whenever
+ instantaneous metrics information is needed. Pure passive
+ measurement approach has no choice but to use this method because
+ delay and losses may not be computed in each point of interest.
 The generation of packets with spoofing addresses may corrupt the
 results without any possibility to detect the spoofing.
+9. Manageability Considerations
9.2. onetogroup metric
+ Usually IPPM WG documents defines each metric reporting within its
+ definition. This document defines the reporting of all the metrics
+ introduced in a single section to provide consistent information
+ while avoiding repetitions. the aim is to contribute to the work of
+ the WG on the reporting and to satisfy IESG recommendation of
+ gathering manageability considerations in a dedicated section.
+
+ Data models of spatial and onetogroup metrics are similar excepted
+ that points of interests of spatial vectors must be ordered.
+
+ The complexity of the reporting relies on the number of points of
+ interests.
+
+9.1. Reporting spatial metric
+
+ The reporting of spatial metrics shares a lot of aspects with
+ RFC267980. New ones are common to all the definitions and are
+ mostly related to the reporting of the path and of methodology
+ parameters that may bias raw results analysis. This section presents
+ these specific parameters and then lists exhaustively the parameters
+ that shall be reported.
+
+9.1.1. Path
+
+ Endtoend metrics can't determine the path of the measure despite
+ IPPM RFCs recommend it to be reported (Section 3.8.4 of [RFC2679]).
+ Spatial metrics vectors provide this path. The report of a spatial
+ vector must include the points of interests involved: the sub set of
+ the hosts of the path participating to the instantaneous measure.
+
+9.1.2. Host order
+
+ A spatial vector must order the points of interest according to their
+ order in the path. It is highly suggested to use the TTL in IPv4,
+ the Hop Limit in IPv6 or the corresponding information in MPLS.
+
+ The report of a spatial vector must include the ordered list of the
+ hosts involved in the instantaneous measure.
+
+9.1.3. Timestamping bias
+
+ The location of the point of interest inside a node influences the
+ timestamping skew and accuracy. As an example, consider that some
+ internal machinery delays the timestamping up to 3 milliseconds then
+ the minimal uncertainty reported be 3 ms if the internal delay is
+ unknown at the time of the timestamping.
+
+ The report of a spatial vector must include the uncertainty of the
+ timestamping compared to wire time.
+
+9.1.4. Reporting spatial Oneway Delay
+
+ The reporting includes information to report for onewaydelay as
+ perthe Section 3.6 of [RFC2679].the same apply for packet loss and
+ ipdv
+
+9.2. Reporting Onetogroup metric
+
+9.3. Metric identification
+
+ IANA assigns each metric defined by the IPPM WG with a unique
+ identifier as per [RFC4148] in the IANAIPPMMETRICSREGISTRYMIB.
+
+ To avoid misunderstanding and to address specific reporting
+ constraints, section Section 5.4.3 of this memo gives distinct names
+ to passive metrics and Section 13 requests a distinct metric
+ identifier for each metrics the memo defines.
+
+ As it is crucial for composition of metrics to know the methodology
+ used (e.g. generation method, detection method...), the report of a
+ metric result used in composition of metrics MUST alway include its
+ metric identifier.
+
+9.4. Reporting data model
+
+ This section presents the elements of the datamodel and the usage of
+ the information reported for real network performance analysis. It
+ is out of the scope of this section to define how the information is
+ reported.
+
+ The data model is build with pieces of information introduced and
+ explained in oneway delay definitions [RFC2679], in packet loss
+ definitions [RFC2680] and in IPDV definitions[RFC3393][RFC3432]. It
+ includes not only information given by "Reporting the metric"
+ sections but by sections "Methodology" and "Errors and Uncertainties"
+ sections.
+
+ Following are the elements of the datamodel taken from endtoend
+ definitions referred in this memo and from spatial and multicast
+ metrics it defines:
+
+ o Packet_type, The TypeP of test packets (TypeP);
+
+ o Packet_length, a packet length in bits (L);
+
+ o Src_host, the IP address of the sender;
+
+ o Dst_host, the IP address of the receiver;
+
+ o Hosts_serie: , a list of points of interest;
+
+ o Loss_threshold: The threshold of infinite delay;
+
+ o Systematic_error: constant delay between wire time and
+ timestamping;
+
+ o Calibration_error: maximal uncertainty;
+
+ o Src_time, the sending time for a measured packet;
+
+ o Dst_time, the receiving time for a measured packet;
+
+ o Result_status : an indicator of usability of a result 'Resource
+ exhaustion' 'infinite', 'lost';
+
+ o Delays_serie: a list of delays;
+
+ o Losses_serie: , a list of Boolean values
+ (spatial) or a set of Boolean values (onetogroup);
+
+ o Result_status_serie: a list of results status;
+
+ o dT: a delay;
+
+ o Singleton_number: a number of singletons;
+ o Observation_duration: An observation duration;
+
+ o metric_identifier.
+
+ Following is the information of each vector that should be available
+ to compute samples:
+
+ o Packet_type;
+
+ o Packet_length;
+
+ o Src_host, the sender of the packet;
+
+ o Dst_host, the receiver of the packet, apply only for spatial
+ vectors;
+
+ o Hosts_serie: not ordered for onetogroup;
+
+ o Src_time, the sending time for the measured packet;
+
+ o dT, the endtoend oneway delay for the measured packet, apply
+ only for spatial vectors;
+
+ o Delays_serie: apply only for delays and ipdv vector, not ordered
+ for onetogroup;
+
+ o Losses_serie: apply only for packets loss vector, not ordered for
+ onetogroup;
+
+ o Result_status_serie;
+
+ o Observation_duration: the difference between the time of the last
+ singleton and the time of the first singleton.
+
+ o Following is the context information (measure, points of
+ interests) that should be available to compute samples :
+
+ * Loss threshold;
+
+ * Systematic error: constant delay between wire time and
+ timestamping;
+
+ * Calibration error: maximal uncertainty;
+
+ A spatial or a onetogroup sample is a collection of singletons
+ giving the performance from the sender to a single point of interest.
+ Following is the information that should be available for each sample
+ to compute statistics:
+
+ o Packet_type;
+
+ o Packet_length;
+
+ o Src_host, the sender of the packet;
+
+ o Dst_host, the receiver of the packet;
+
+ o Start_time, the sending time of the first packet;
+
+ o Delays_serie: apply only for delays and ipdv samples;
+
+ o Losses_serie: apply only for packets loss samples;
+
+ o Result_status_serie;
+
+ o Observation_duration: the difference between the time of the last
+ singleton of the last sample and the time of the first singleton
+ of the first sample.
+
+ o Following is the context information (measure, points of
+ interests) that should be available to compute statistics :
+
+ * Loss threshold;
+
+ * Systematic error: constant delay between wire time and
+ timestamping;
+
+ * Calibration error: maximal uncertainty;
+
+ Following is the information of each statistic that should be
+ reported:
+
+ o Result;
+
+ o Start_time;
+
+ o Duration;
+
+ o Result_status;
+
+ o Singleton_number, the number of singletons the statistic is
+ computed on;
+
+10. Open issues
+
+ Do we define min, max, avg of for each segment metrics ?
+
+ having the maximum loss metric value could be interesting. Say,
+ the segment between router A and B always contributes loss metric
+ value of "1" means it could be the potential problem segment.
+
+ Uploading dTi of each Hi consume a lot of bandwidth. Computing
+ statistics (min, max and avg) of dTi locally in each Hi reduce the
+ bandwidth consumption.
+
+11. Security Considerations
+
+ Spatial and onetogroup metrics are defined on the top of endtoend
+ metrics. Security considerations discussed in Oneway delay metrics
+ definitions of [RFC2679] , in packet loss metrics definitions
+ of[RFC2680] and in IPDV metrics definitions of[RFC3393] and [RFC3432]
+ apply to multimetrics.
+
+11.1. Spatial metrics
+
+ Malicious generation of packets with spoofing addresses may corrupt
+ the results without any possibility to detect the spoofing.
+
+ Malicious generation of packets which match systematically the hash
+ function used to detect the packets may lead to a DoS attack toward
+ the point of reference.
+
+11.2. onetogroup metric
+
+ The reporting of measurement results from a huge number of probes may
+ overload the network the reference point is attach to, the reference
+ point network interfaces and the reference point computation
+ capacities.
The configuration of a measure must take in consideration that
implicitly more packets will to be routed than send and selects a
 test packets rate accordingly.

 Collecting statistics from a huge number of probes may overload any
 combination of the network the measurement controller is attach to,
 measurement controller network interfaces and measurement controller
 computation capacities.
+ test packets rate accordingly. Collecting statistics from a huge
+ number of probes may overload any combination of the network where
+ the measurement controller is attach to, measurement controller
+ network interfaces and measurement controller computation capacities.
 onetogroup metrics:
+ onetogroup metrics measurement should consider using source
+ authentication protocols, standardized in the MSEC group, to avoid
+ fraud packet in the sampling interval. The test packet rate could be
+ negotiated before any measurement session to avoid deny of service
+ attacks.
10. Acknowledgments
+12. Acknowledgments
 Lei would like to acknowledge Zhili Sun from CCSR, University of
 Surrey, for his instruction and helpful comments on this work.
+ Lei would like to acknowledge Prof. Zhili Sun from CCSR, University
+ of Surrey, for his instruction and helpful comments on this work.
11. IANA Considerations
+13. IANA Considerations
Metrics defined in this memo Metrics defined in this memo are
designed to be registered in the IANA IPPM METRICS REGISTRY as
described in initial version of the registry [RFC4148] :
IANA is asked to register the following metrics in the IANAIPPM
METRICSREGISTRYMIB :
SpatialOnewayDelayVector OBJECTIDENTITY
@@ 1665,70 +2155,155 @@
REFERENCE
"Reference "RFCyyyy, section 4.1."
 RFC Ed.: replace yyyy with actual RFC number & remove this
note
:= { ianaIppmMetrics nn }  IANA assigns nn
 subpathOnewayDelayStream OBJECTIDENTITY
+ SpatialPacketLossVector OBJECTIDENTITY
STATUS current
DESCRIPTION
 "TypePsubpathOnewayDelayStream"
+ "TypePSpatialPacketLossVector"
REFERENCE

"Reference "RFCyyyy, section 4.2."
 RFC Ed.: replace yyyy with actual RFC number & remove this
note
:= { ianaIppmMetrics nn }  IANA assigns nn
 SpatialOnewayPacketLossVector OBJECTIDENTITY
+ SpatialOnewayipdvVector OBJECTIDENTITY
+
STATUS current
DESCRIPTION
 "TypePSpatialOnewayPacketLossVector"
+ "TypePSpatialOnewayipdvVector"
REFERENCE
"Reference "RFCyyyy, section 4.3."
 RFC Ed.: replace yyyy with actual RFC number & remove this
note
:= { ianaIppmMetrics nn }  IANA assigns nn
 SpatialOnewayJitterVector OBJECTIDENTITY
+ SpatialSegmentOnewayDelayStream OBJECTIDENTITY
STATUS current
DESCRIPTION
 "TypePSpatialOnewayJitterVector"
+ "TypePSpatialSegmentOnewayDelayStream"
REFERENCE
 "Reference "RFCyyyy, section 4.4."
+ "Reference "RFCyyyy, section 5.1."
 RFC Ed.: replace yyyy with actual RFC number & remove this
note
:= { ianaIppmMetrics nn }  IANA assigns nn
+ SpatialSegmentPacketLossStream OBJECTIDENTITY
+
+ STATUS current
+
+ DESCRIPTION
+ "TypePSpatialSegmentPacketLossStream"
+
+ REFERENCE
+
+ "Reference "RFCyyyy, section 5.2."
+
+  RFC Ed.: replace yyyy with actual RFC number & remove this
+ note
+
+ := { ianaIppmMetrics nn }  IANA assigns nn
+
+ SpatialSegmentOnewayipdvStream OBJECTIDENTITY
+
+ STATUS current
+
+ DESCRIPTION
+
+ "TypePSpatialSegmentipdvStream"
+
+ REFERENCE
+
+ "Reference "RFCyyyy, section 5.3."
+
+  RFC Ed.: replace yyyy with actual RFC number & remove this
+ note
+
+ := { ianaIppmMetrics nn }  IANA assigns nn
+
+ PassiveSegmentOnewayDelayStream OBJECTIDENTITY
+
+ STATUS current
+
+ DESCRIPTION
+
+ "TypePPassiveSegmentOnewayDelayStream"
+
+ REFERENCE
+
+ "Reference "RFCyyyy, section 5.4.1."
+
+  RFC Ed.: replace yyyy with actual RFC number & remove this
+ note
+
+ := { ianaIppmMetrics nn }  IANA assigns nn
+
+ PassiveSegmentPacketLossStream OBJECTIDENTITY
+ STATUS current
+
+ DESCRIPTION
+
+ "TypePPassiveSegmentPacketLossStream"
+
+ REFERENCE
+
+ "Reference "RFCyyyy, section 5.4.2."
+
+  RFC Ed.: replace yyyy with actual RFC number & remove this
+ note
+
+ := { ianaIppmMetrics nn }  IANA assigns nn
+
+ PassiveSegmentOnewayipdvStream OBJECTIDENTITY
+
+ STATUS current
+
+ DESCRIPTION
+
+ "TypePPassiveSegmentOnewayipdvStream"
+
+ REFERENCE
+
+ "Reference "RFCyyyy, section 5.4.3."
+
+  RFC Ed.: replace yyyy with actual RFC number & remove this
+ note
+
+ := { ianaIppmMetrics nn }  IANA assigns nn
+
+  Onetogroup metrics
+
onetogroupOnewayDelayVector OBJECTIDENTITY
STATUS current
DESCRIPTION
"TypePonetogroupOnewayDelayVector"
REFERENCE
@@ 1748,27 +2323,27 @@
REFERENCE
"Reference "RFCyyyy, section 5.2."
 RFC Ed.: replace yyyy with actual RFC number & remove this
note
:= { ianaIppmMetrics nn }  IANA assigns nn
 onetogroupOnewayJitterVector OBJECTIDENTITY
+ onetogroupOnewayipdvVector OBJECTIDENTITY
STATUS current
DESCRIPTION
 "TypePonetogroupOnewayJitterVector"
+ "TypePonetogroupOnewayipdvVector"
REFERENCE
"Reference "RFCyyyy, section 5.3."
 RFC Ed.: replace yyyy with actual RFC number & remove this
note
:= { ianaIppmMetrics nn }  IANA assigns nn
@@ 1852,42 +2427,42 @@
"Reference "RFCyyyy, section 6.4.2."
 RFC Ed.: replace yyyy with actual RFC number & remove this
note
:= { ianaIppmMetrics nn }  IANA assigns nn

12. References
+14. References
12.1. Normative References
+14.1. Normative References
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330,
May 1998.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A Oneway
Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A Oneway
Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393,
November 2002.
[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics
Registry", BCP 108, RFC 4148, August 2005.
12.2. Informative References
+14.2. Informative References
[RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring
Connectivity", RFC 2678, September 1999.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Roundtrip
Delay Metric for IPPM", RFC 2681, September 1999.
[RFC3148] Mathis, M. and M. Allman, "A Framework for Defining
Empirical Bulk Transfer Capacity Metrics", RFC 3148,
July 2001.