 1/draftietfippmipdv05.txt 20060204 23:45:26.000000000 +0100
+++ 2/draftietfippmipdv06.txt 20060204 23:45:26.000000000 +0100
@@ 1,840 +1,791 @@
Network Working Group C. Demichelis
INTERNETDRAFT CSELT
Expiration Date: December 2000 P. Chimento
 CTIT
 July 2000
+Expiration Date: August 2001 P. Chimento
+ Ericsson IPI
+ February 2001
 Instantaneous Packet Delay Variation Metric for IPPM

+ IP Packet Delay Variation Metric for IPPM
+
1. Status of this Memo
 This document is an InternetDraft and is in full conformance with 
+ This document is an InternetDraft and is in full conformance with
all provisions of Section 10 of RFC2026.
InternetDrafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet
Drafts.
InternetDrafts are draft documents valid for a maximum of six months
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 current InternetDrafts can be accessed at
+ http://www.ietf.org/ietf/1idabstracts.txt
 The list of InternetDraft shadow directories can be accessed at 
+ The list of InternetDraft shadow directories can be accessed at
http://www.ietf.org/shadow.html
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
2. Abstract
This memo refers to a metric for variation in delay of packets across
 Internet paths. The metric is based on statistics of the difference
 in OnewayDelay of consecutive packets. This particular definition
 of variation is called "Instantaneous Packet Delay Variation (ipdv)".
+ Internet paths. The metric is based on the difference in the OneWay
+ Delay of selected packets. This difference in delay is called "IP
+ Packet Delay variation."
The metric is valid for measurements between two hosts both in the
case that they have synchronized clocks and in the case that they are
 not synchronized. In the second case it allows an evaluation of the
 reciprocal skew. Measurements performed on both directions (Twoway
 measurements) allow a better estimation of clock differences. The
 precision that can be obtained is evaluated.
+ not synchronized. We discuss both in this draft.
3. Introduction
 This memo is based on "A OnewayDelay metric for IPPM", RFC 2679 
 [2]. Part of the text in this memo is taken directly from that
 document.
+ This memo is based on "A OneWayDelay metric for IPPM", RFC 2679
+ [2].
 This memo defines a metric for variation in delay of packets that >
 flow from one host to another one through an IP path. This quantity >
 is sometimes called "jitter". This term, however, causes confusion >
 because it is used in different ways by different groups of people. 
 "Jitter" commonly has two meanings: The first meaning is the 
 variation of a signal with respect to some clock signal, where the 
 arrival time of the signal is expected to coincide with the arrival 
 of the clock signal. The second meaning has to do with the variation 
 of a metric (e.g. delay) with respect to some reference metric (e.g. 
 average delay or minimum delay). The form of "jitter" that we talk 
 about here has to do almost exclusively with the second meaning, 
 rather than the first. For more information see the section on the 
 relationship with other standards.
+ Part of the text in this memo is taken directly from that document.
3.1. Definition
+ This memo defines a metric for variation in delay of packets that
+ flow from one host to another one through an IP path. This quantity
+ is sometimes called "jitter". This term, however, causes confusion
+ because it is used in different ways by different groups of people.
 A definition of the Instantaneous Packet Delay Variation (ipdv) can
 be given for a pair of packets or for a packet inside a stream of
 packets.
+ "Jitter" commonly has two meanings: The first meaning is the
+ variation of a signal with respect to some clock signal, where the
+ arrival time of the signal is expected to coincide with the arrival
+ of the clock signal. The second meaning has to do with the variation
+ of a metric (e.g. delay) with respect to some reference metric (e.g.
+ average delay or minimum delay).
 For a pair of packets:
+ The first meaning is used with reference to synchronous signals and
+ might be used to measure the quality of circuit emulation, for
+ example. There is also a metric called "wander" used in this context.
+ The second meaning is frequently used by computer scientists and
+ frequently (but not always) refers to variation in delay.
 + The ipdv of a pair of IP packets, that are transmitted from the
 measurement point MP1 to the measurement point MP2, is the
 difference between the OnewayDelay measured for the second
 packet and the OnewayDelay measured for the first packet of the
 pair.
+ In this document we will avoid the term "jitter" whenever possible
+ and stick to delay variation which is more precise.
 For a stream of packets:
+3.1. Definition
 + The Instantaneous Packet Delay Variation of an IP packet, inside a
 stream of packets, going from the measurement point MP1 to the
 measurement point MP2, is the difference of the OnewayDelay of
 that packet and the OnewayDelay of the preceding packet in the
 stream.
+ A definition of the IP Packet Delay Variation (ipdv) can be given for
+ packets inside a stream of packets.
+
+ The IP Packet Delay Variation (ipdv) of a pair of packets within a
+ stream of packets is defined for a selected pair of packets in the
+ stream going from measurement point MP1 to measurement point MP2 is
+ the difference between the onewaydelay of the first of the selected
+ packets and the onewaydelay of the second of the selected packets.
3.2. Motivation
 A number of services that can be supported by IP are sensitive to the
 regular delivery of packets and can be disturbed by instantaneous
 variations in delay, while they are not disturbed by slow variations,
 that can last a relatively long time. A specific metric for quick
 variations is therefore desirable. Metrics that can be derived from
 the analysis of statistics of ipdv can also be used, for example, for 
 buffer dimensioning. The scope of this metric is to provide a way
 for measurement of the quality delivered by a path.
+ One important use of delay variation is the sizing of playout buffers
+ for applications requiring the regular delivery of packets (for
+ example, voice or video playout). What is normally important in this
+ case is the maximum delay variation, which is used to size playout
+ buffers for such applications [6]. Other uses of a delay variation
+ metric are, for example, to determine the dynamics of queues within a
+ network (or router) where the changes in delay variation can be
+ linked to changes in the queue length process at a given link or a
+ combination of links.
In addition, this type of metric is particularly robust with respect
differences and variations of the clocks of the two hosts. This
allows the use of the metric even if the two hosts that support the
measurement points are not synchronized. In the latter case
indications of reciprocal skew of the clocks can be derived from the
measurement and corrections are possible. The related precision is
often comparable with the one that can be achieved with synchronized
clocks, being of the same order of magnitude of synchronization
errors. This will be discussed below.
+ The scope of this document is to provide a way to measure the ipdv
+ delivered on a path. Our goal is to provide a metric which can be
+ parameterized so that it can be used for various purposes. Any report
+ of the metric MUST include all the parameters associated with it so
+ that the conditions and meaning of the metric can be determined
+ exactly. We specifically do not specify particular values of the
+ metrics that IP networks must meet.
+
+ The flexibility of the metric can be viewed as a disadvantage but
+ there are some arguments for making it flexible. First, though there
+ are some uses of ipdv mentioned above, to some degree the uses of
+ ipdv are still a research topic and some room should be left for
+ experimentation. Secondly, there are different views in the community
+ of what precisely the definition should be (e.g. [7],[8],[9]). The
+ idea here is to parameterize the definition, rather than write a
+ different draft for each proposed definition. As long as all the
+ parameters are reported, it will be clear what is meant by a
+ particular use of ipdv. All the remarks in the draft hold, no matter
+ which parameters are chosen.
+
3.3. General Issues Regarding Time
 Everything contained in the Section 2.2. of [2] applies also in this 
+ Everything contained in the Section 2.2. of [2] applies also in this
case.
 To summarize: As in [1] we define "skew" as the first derivative of >
 the offset of a clock with respect to "true time" and define "drift" >
 as the second derivative of the offset of a clock with respect to >
 "true time". >
+ To summarize: As in [1] we define "skew" as the first derivative of
+ the offset of a clock with respect to "true time" and define "drift"
+ as the second derivative of the offset of a clock with respect to
+ "true time".
 From there, we can construct "relative skew" and "relative drift" for >
 two clocks C1 and C2 with respect to one another. These are natural >
 extensions of the basic framework definitions of these quantities: >
+ From there, we can construct "relative skew" and "relative drift" for
+ two clocks C1 and C2 with respect to one another. These are natural
+ extensions of the basic framework definitions of these quantities:
 + Relative offset = difference in clock times >
+ + Relative offset = difference in clock times
 + Relative skew = first derivative of the difference in clock times >
+ + Relative skew = first derivative of the difference in clock times
 + Relative drift = second derivative of the difference in clock >
 times >
+ + Relative drift = second derivative of the difference in clock
+ times
NOTE: The drift of a clock, as it is above defined over a long period
must have an average value that tends to zero while the period
becomes large since the frequency of the clock has a finite (and
small) range. In order to underline the order of magnitude of this
effect, it is considered that the maximum range of drift for
commercial crystals is about 50 part per million (ppm). Since it is
mainly connected with variations in operating temperature (from 0 to
70 degrees Celsius), it is expected that a host will have a nearly
constant temperature during its operation period, and variations in
temperature, even if quick, could be less than one Celsius per
second, and range in the order of few degrees. The total range of the
drift is usually related to variations from 0 to 70 Celsius. These
are important points for evaluation of precision of ipdv
measurements, as will be seen below.
4. Structure of this memo

 The metric will be defined as applicable to a stream of packets that
 flow from a source host to a destination host (oneway ipdv). The
 initial assumption is that source and destination hosts have
 synchronized clocks. The definition of a singleton of oneway ipdv
 metric is first considered, and then a definition of samples for ipdv
 will be given.

 Then the case of application to nonsynchronized hosts will be
 discussed, and the precision will be compared with the one of
 synchronized clocks.

 A bidirectional ipdv metric will be defined, as well as the >
 methodology for error corrections. This will not be a twoway metric, >
 but a "paired" oneway in opposite directions.
+4. A singleton definition of a Oneway ipdv metric
5. A singleton definition of a Oneway ipdv metric 
+ The purpose of the singleton metric is to define what a single
+ instance of an ipdv measurement is. Note that it can only be
+ statistically significant in combination with other instances. It is
+ not intended to be meaningful as a singleton, in the sense of being
+ able to draw inferences from it.
This definition makes use of the corresponding definition of typeP
 OnewayDelay metric [2]. This section makes use of those parts of
 the Oneway Delay Draft that directly apply to the Onewayipdv
+ OneWayDelay metric [2]. This section makes use of those parts of
+ the OneWayDelay Draft that directly apply to the OneWayipdv
metric, or makes direct references to that Draft.
5.1. Metric name
+4.1. Metric name
TypePOnewayipdv
5.2. Metric parameters
+4.2. Metric parameters
+ Src, the IP address of a host
+ Dst, the IP address of a host
+ T1, a time
 + T2, a time. It is explicitly noted that also the difference T2T1
 is a parameter of the measurement though this is already implicit,
 since the times T1 and T2 exactly define the time conditions in
 which the measurement takes place.
+ + T2, a time
 Note that the packet length is an implicit parameter of both the 
 TypePOnewaydelay metric and the TypePOnewayipdv metric, since 
 this contributes to the overall oneway delay. We assume that the 
 packets sent for ipdv measurements are all of the same length.
+ + L, a packet length in bits. The packets of a Type P packet stream
+ from which the singleton ipdv metric is taken MUST all be of the
+ same length.
5.3. Metric unit
+ + F, a selection function defining unambiguously the two packets
+ from the stream selected for the metric.
+
+ + I1,I2, times which mark that beginning and ending of the interval
+ in which the packet stream from which the singleton measurement is
+ taken occurs.
+
+ + P, the specification of the packet type, over and above the source
+ and destination addresses
+
+4.3. Metric unit
The value of a TypePOnewayipdv is either a real number of seconds
(positive, zero or negative) or an undefined number of seconds.
5.4. Definition
+4.4. Definition
 TypePOnewayipdv is defined for two (consecutive) packets from Src
 to Dst, as the difference between the value of the TypePOneway
 delay from Src to Dst at T2 and the value of the TypePOnewayDelay
 from Src to Dst at T1. T1 is the wiretime at which Scr 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 therefore
 ideally derived from the OnewayDelay metric.
+ We are given a Type P packet stream and I1 and I2 such that the first
+ Type P packet to pass measurement point MP2 after I1 is given index 0
+ and the last Type P packet to pass measurement point MP2 before I2 is
+ given the highest index number.
+
+ TypePOnewayipdv is defined for two packets from Src to Dst
+ selected by the selection function F, as the difference between the
+ value of the typePOneway delay from Src to Dst at T2 and the
+ value of the typePOneWayDelay from Src to Dst at T1. T1 is the
+ wiretime at which Scr 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 OneWayDelay metric.
 NOTE: The requirement of "consecutive" packets is not essential. The
 measured value is anyway the difference in OnewayDelay at the times
 T1 and T2, which is meaningful by itself, as long as the times T1 and 
T2 denote the wire times of the packets sent from Src to Dst.
 Therefore, for a real number ddT "The TypePonewayipdv from Src to
 Dst at T1, T2 is ddT" means that Src sent two consecutive packets,
 the first at wiretime T1 (first bit), and the second at wiretime T2
 (first bit) and the packets were received by Dst at wiretime dT1+T1
 (last bit of the first packet), and at wiretime dT2+T2 (last bit of
 the second packet), and that dT2dT1=ddT.
+ Therefore, for a real number ddT "The typePonewayipdv from Src to
+ Dst at T1, T2 is ddT" 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 Dst at wiretime dT1+T1 (last bit of
+ the first packet), and at wiretime dT2+T2 (last bit of the second
+ packet), and that dT2dT1=ddT.
 "The TypePonewayipdv from Src to Dst at T1,T2 is undefined" means
+ "The typePonewayipdv from Src to Dst at T1,T2 is undefined" means
that Src sent the first bit of a packet at T1 and the first bit of a
second packet at T2 and that Dst did not receive one or both packets.
5.5. Discussion
+4.5. Discussion
 TypePOnewayipdv is a metric that makes use of the same
 measurement methods provided for delay metrics.
+ This metric definition depends on a stream of TypePOneWayDelay
+ packets that have been measured. In general this can be a stream of
+ two or more packets, delimited by the interval endpoints I1 and I2.
+ There must be a stream of at least two packets in order for a
+ singleton ipdv measurement to take place. The purpose of the
+ selection function is to specify exactly which two packets from the
+ stream are to be used for the singleton measurement. Note that the
+ selection function may involve observing the onewaydelay of all the
+ Type P packets of the stream in the specified interval. Examples of a
+ selection function are:
+
+ + Consecutive TypeP packets within the specified interval
+
+ + TypeP packets with specified indices within the specified
+ interval
+
+ + TypeP packets with the min and max onewaydelays within the
+ specified interval
+
+ + TypeP packets with specified indices from the set of all defined
+ (i.e. noninfinite) onewaydelays TypeP packets within the
+ specified interval.
The following practical issues have to be considered:
+ Being a differential measurement, this metric is less sensitive to
clock synchronization problems. This issue will be more carefully
examined in section 7 of this memo. It is pointed out that, if the
relative clock conditions change in time, the accuracy of the
 measurement will depend on the time interval T2T1 and the
+ measurement will depend on the time interval I2I1 and the
magnitude of possible errors will be discussed below.
+ A given methodology will have to include a way to determine
whether a delay value is infinite or whether it is merely very
large (and the packet is yet to arrive at Dst). As noted by
Mahdavi and Paxson, simple upper bounds (such as the 255 seconds
theoretical upper bound on the lifetimes of IP packets [Postel:
RFC 791]) could be used, but good engineering, including an
understanding of packet lifetimes, will be needed in practice.
 {Comment: Note that, for many applications of these metrics, the
+ Comment: Note that, for many applications of these metrics, the
harm in treating a large delay as infinite might be zero or very
small. A TCP data packet, for example, that arrives only after
 several multiples of the RTT may as well have been lost.}
+ several multiples of the RTT may as well have been lost.
+ As with other 'typeP' metrics, the value of the metric may depend
on such properties of the packet as protocol,(UDP or TCP) port
number, size, and arrangement for special treatment (as with IP
precedence or with RSVP).
+ If the packet is duplicated along the path (or paths!) so that
multiple noncorrupt copies arrive at the destination, then the
packet is counted as received, and the first copy to arrive
 determines the packet's OnewayDelay.
+ determines the packet's OneWayDelay.
+ If the packet is fragmented and if, for whatever reason,
reassembly does not occur, then the packet will be deemed lost.
5.6. Methodologies
+ It is assumed that the TypeP packet stream is generated according to
+ the Poisson sampling methodology described in [1].
+
+4.6. Methodologies
As with other TypeP* metrics, the detailed methodology will depend
on the TypeP (e.g., protocol number, UDP/TCP port number, size,
 precedence). Generally, for a given TypeP, the methodology would
 proceed as follows:
+ precedence).
+
+ The measurement methodology described in this section asssumes the
+ measurement and determination of ipdv in realtime as part of an
+ active measurement. Note that this can equally well be done a
+ posteriori, i.e. after the onewaydelay measurement is completed.
+
+ Generally, for a given TypeP, the methodology would proceed as
+ follows:
+ The need of synchronized clocks for Src and Dst will be discussed
 later. Here a methodology is presented that is based on
+ later. Here a methodology is supposed that is based on
synchronized clocks.
 + At the Src host, select Src and Dst IP addresses, and form two
 test packets of TypeP with these addresses. Any 'padding' portion
 of the packet needed only to make the test packet a given size
 should be filled with randomized bits to avoid a situation in
 which the measured delay is lower than it would otherwise be due
 to compression techniques along the path.
+ + After time I1, start. At the Src host, select Src and Dst IP
+ addresses, and form test packets of TypeP with these addresses
+ according to a given technique (e.g. the Poisson sampling
+ technique). Any 'padding' portion of the packet needed only to
+ make the test packet a given size should be filled with randomized
+ bits to avoid a situation in which the measured delay is lower
+ than it would otherwise be due to compression techniques along the
+ path.
+ At the Dst host, arrange to receive the packets.
 + At the Src host, place a timestamp in the first TypeP packet,
 and send it towards Dst.
+ + At the Src host, place a timestamp in the TypeP packet, and send
+ it towards Dst.
+ If the packet arrives within a reasonable period of time, take a
timestamp as soon as possible upon the receipt of the packet. By
 subtracting the two timestamps, an estimate of OnewayDelay can
+ subtracting the two timestamps, an estimate of OneWayDelay can
be computed.
 + Record this first delay value.
+ + If the packet meets the selection function criterion for the first
+ packet, record this first delay value. Otherwise, continue
+ generating the TypeP packet stream as above until the criterion
+ is met or I2, whichever comes first.
 + At the Src host, place a timestamp in the second TypeP packet,
 and send it towards Dst.
+ + At the Src host, packets continue to be generated according to the
+ given methodology. The Src host places a timestamp in the TypeP
+ packet, and send it towards Dst.
+ If the packet arrives within a reasonable period of time, take a
timestamp as soon as possible upon the receipt of the packet. By
 subtracting the two timestamps, an estimate of OnewayDelay can
+ subtracting the two timestamps, an estimate of OneWayDelay can
be computed.
 + By subtracting the second value of OnewayDelay from the first
 value the ipdv value of the pair of packets is obtained.
+ + If the packet meets the criterion for the second packet for the
+ second packet, then by subtracting the second value of OneWay
+ Delay from the first value the ipdv value of the pair of packets
+ is obtained. Otherwise, packets continue to be generated until
+ the criterion for the second packet is fulfilled or I2, whichever
+ comes first.
+ If one or both packets fail to arrive within a reasonable period
of time, the ipdv is taken to be undefined.
5.7. Errors and Uncertainties
+4.7. Errors and Uncertainties
In the singleton metric of ipdv, factors that affect the measurement
 are the same that can affect the OnewayDelay measurement, even if,
 in this case, the influence is different.
+ are the same as those affecting the OneWayDelay measurement, even
+ if, in this case, the influence is different.
The Framework document [1] provides general guidance on this point,
but we note here the following specifics related to delay metrics:
+ Errors/uncertainties due to uncertainties in the clocks of the Src
and Dst hosts.
+ Errors/uncertainties due to the difference between 'wire time' and
'host time'.
 Each of these errors is discussed in more detail in the next
+ Each of these errors is discussed in more detail in the following
paragraphs.
5.7.1. Errors/Uncertainties related to Clocks
+4.7.1. Errors/Uncertainties related to Clocks
If, as a first approximation, the error that affects the first
 measurement of OnewayDelay were the same of the one affecting the
+ measurement of OneWayDelay were the same as the one affecting the
second measurement, they will cancel each other when calculating
ipdv. The residual error related to clocks is the difference of the
 errors that are supposed to change from the time T1, at which the
 first measurement is performed, to the time T2 at which the second
 measure ment is performed. Synchronization, skew, accuracy and
 resolution are here considered with the following notes:
+ errors that are supposed to change from time T1, at which the first
+ measurement is performed, to time T2 at which the second measurement
+ is performed. Synchronization, skew, accuracy and resolution are
+ here considered with the following notes:
+ Errors in synchronization between source and destination clocks
contribute to errors in both of the delay measurements required
for calculating ipdv.
 + The effect of drift and skew errors on ipdv measurements can be >
 quantified as follows: Suppose that the skew and drift functions >
 are known. Assume first that the skew function is linear in time. >
 Clock offset if then also a function of time and the error evolves >
 as e(t) = K*t + O, where K is a constant and O is the offset at >
 time 0. In this case, the error added to the subtraction two >
 different time stamps (t2 > t1) is e(t2)e(t1) = K*(t2  t1) which >
 will be added to the time difference (t2  t1). If the drift >
 cannot be ignored, but we assume that the drift is a linear >
 function of time, then the skew is given by s(t) = M*(t**2) + N*t >
 + S0, where M and N are constants and S0 is the skew at time 0. >
 The error added by the variable skew/drift process in this case >
 becomes e(t) = O + s(t) and the error added to the difference in >
 time stamps is e(t2)e(t1) = N*(t2t1) + M*{(t2t1)**2}. >
 It is the claim here (see remarks in section 3.3) that the effects >
 of skew are rather small over the time scales that we are >
 discussing here, since temperature variations in a system tend to >
 be slow relative to packet intertransmission times and the range >
+ + The effect of drift and skew errors on ipdv measurements can be
+ quantified as follows: Suppose that the skew and drift functions
+ are known. Assume first that the skew function is linear in time.
+ Clock offset if then also a function of time and the error evolves
+ as e(t) = K*t + O, where K is a constant and O is the offset at
+ time 0. In this case, the error added to the subtraction two
+ different time stamps (t2 > t1) is e(t2)e(t1) = K*(t2  t1) which
+ will be added to the time difference (t2  t1). If the drift
+ cannot be ignored, but we assume that the drift is a linear
+ function of time, then the skew is given by s(t) = M*(t**2) + N*t
+ + S0, where M and N are constants and S0 is the skew at time 0.
+ The error added by the variable skew/drift process in this case
+ becomes e(t) = O + s(t) and the error added to the difference in
+ time stamps is e(t2)e(t1) = N*(t2t1) + M*{(t2t1)**2}.
+
+ It is the claim here (see remarks in section 3.3) that the effects
+ of skew are rather small over the time scales that we are
+ discussing here, since temperature variations in a system tend to
+ be slow relative to packet intertransmission times and the range
of drift is so small.
+ As far as accuracy and resolution are concerned, what is noted in
the onewaydelay document [2] in section 3.7.1, applies also in
this case, with the further consideration, about resolution, that
in this case the uncertainty introduced is two times the one of a
single delay measurement. Errors introduced by these effects are
often larger than the ones introduced by the drift.
5.7.2. Errors/uncertainties related to Wiretime vs Hosttime
+4.7.2. Errors/uncertainties related to Wiretime vs Hosttime
The content of sec. 3.7.2 of [2] applies also in this case, with the
following further consideration: The difference between Hosttime and
Wiretime can be in general decomposed into two components, of which
one is constant and the other is variable. Only the variable
components will produce measurement errors, while the constant one
 will be canceled while calculating ipdv. However, in most cases, the >
 fixed and variable components are not known exactly.
+ will be canceled while calculating ipdv.
6. Definitions for Samples of Oneway ipdv
+ However, in most cases, the fixed and variable components are not
+ known exactly.
 Starting from the definition of the singleton metric of oneway ipdv, 
 we define a sample of such singletons. In the following, the two 
 packets needed for a singleton measurement will be called a "pair". 
+5. Definitions for Samples of Oneway ipdv
 A stream of test packets is generated where the second packet of a 
 pair is, at the same time, the first packet of the next pair. 
+ The goal of the sample definition is to make it possible to compute
+ the statistics of sequences of ipdv measurements. The singleton
+ definition is applied to a stream of test packets generated according
+ to a pseudorandom Poisson process with average arrival rate lambda.
+ If necessary, the interval in which the stream is generated can be
+ divided into subintervals on which the singleton definition of ipdv
+ can be applied. The result of this is a sequence of ipdv measurements
+ that can be analyzed by various statistical procedures.
 + Given particular binding of the parameters Src, Dst and TypeP, a 
 sample of values of parameter T1 is defined. To define the values 
 of T1, select a beginning time T0, a final time Tf, and an average 
 rate lambda, then define a pseudorandom Poisson arrival process 
 of rate lambda, whose values fall between T0 and Tf. The time 
 interval between successive values of T1 will then average 
 1/lambda. From the second value on, T1 value of the pair n 
 coincides with T2 of the pair n1, and the first packet of pair n 
 coincides with the second packet of the pair n1. 
+ Starting from the definition of the singleton metric of oneway ipdv,
+ we define a sample of such singletons. In the following, the two
+ packets needed for a singleton measurement will be called a "pair".
6.1. Metric name
+5.1. Metric name
TypePOnewayipdvstream
6.2. Parameters
+5.2. Parameters
+ Src, the IP address of a host
+ Dst, the IP address of a host
+ T0, a time
+ Tf, a time
+ lambda, a rate in reciprocal seconds
6.3. Metric Units:
+ + L, a packet length in bits. The packets of a Type P packet stream
+ from which the sample ipdv metric is taken MUST all be of the same
+ length.
 A sequence of triads whose elements are:
+ + F, a selection function defining unambiguously the packets from
+ the stream selected for the metric.
 + T, a time
+ + I(i),I(i+1), i >=0, pairs of times which mark the beginning and
+ ending of the intervals in which the packet stream from which the
+ measurement is taken occurs. I(0) >= T0 and assuming that n is the
+ largest index, I(n) <= Tf.
 + Ti, a time interval.
+ + P, the specification of the packet type, over and above the source
+ and destination addresses
+
+5.3. Metric Units:
+
+ A sequence of triples whose elements are:
+
+ + T1, T2,times
+ dT a real number or an undefined number of seconds
6.4. Definition
+5.4. Definition
A pseudorandom Poisson process is defined such that it begins at or
before T0, with average arrival rate lambda, and ends at or after Tf.
Those time values T(i) greater than or equal to T0 and less than or
 equal to Tf are then selected. Starting from time T0, at each pair of
 times T(i), T(i+1) of this process a value of TypePOnewayipdv is
 obtained. The value of the sample is the sequence made up of the
 resulting