Network Working Group                                          A. Morton
Internet-Draft                                                 AT&T Labs
Intended status: Informational                          October 15, 2006
Expires: April 18, 2007

             Packet Delay Variation Applicability Statement

Status of this Memo

   By submitting this Internet-Draft, 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.

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

   Internet-Drafts 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 Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

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

   This Internet-Draft will expire on April 18, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   Many definitions of packet delay variation exist, and two different
   formulations have come into wide use in the context of active
   measurements.  This memo examines a range of circumstances for active
   measurements and their uses, and recommends which of these two forms
   is best matched to the conditions and task.

Morton                   Expires April 18, 2007                 [Page 1]

Internet-Draft             Delay Variation AS               October 2006

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Purpose and Scope  . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Uses of Delay Variation Metrics  . . . . . . . . . . . . . . .  4
     3.1.  Determining De-jitter Buffer Size  . . . . . . . . . . . .  4
     3.2.  Inferring Queue Occupation on a Path . . . . . . . . . . .  5
     3.3.  Spatial Composition  . . . . . . . . . . . . . . . . . . .  5
     3.4.  Challenging Circumstances  . . . . . . . . . . . . . . . .  5
     3.5.  <your favorite here> . . . . . . . . . . . . . . . . . . .  6
   4.  Formulations of IPDV and PDV . . . . . . . . . . . . . . . . .  6
     4.1.  IPDV: Inter-Packet Delay Variation . . . . . . . . . . . .  6
     4.2.  PDV: Packet Delay Variation  . . . . . . . . . . . . . . .  6
     4.3.  Examples and Initial Comparisons . . . . . . . . . . . . .  6
   5.  Earlier Comparisons  . . . . . . . . . . . . . . . . . . . . .  6
     5.1.  Demichelis' Comparison . . . . . . . . . . . . . . . . . .  7
     5.2.  Ciavattone et al.  . . . . . . . . . . . . . . . . . . . .  8
     5.3.  IPPM List Discussion from 2001 . . . . . . . . . . . . . .  8
     5.4.  Y.1540 Appendix II . . . . . . . . . . . . . . . . . . . .  9
   6.  Additional Properties and Comparisons  . . . . . . . . . . . .  9
     6.1.  Jitter in RTCP Reports . . . . . . . . . . . . . . . . . .  9
     6.2.  Path Changes . . . . . . . . . . . . . . . . . . . . . . .  9
       6.2.1.  Lossless Path Change . . . . . . . . . . . . . . . . . 10
       6.2.2.  Path Change with Loss  . . . . . . . . . . . . . . . . 11
     6.3.  Measurement Clock Issues . . . . . . . . . . . . . . . . . 11
     6.4.  Reporting a Single Number  . . . . . . . . . . . . . . . . 12
     6.5.  MAPDV2 . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  Applicability of the Delay Variation Forms with Tasks  . . . . 13
     7.1.  Challenging Circumstances  . . . . . . . . . . . . . . . . 13
     7.2.  Spatial Composition  . . . . . . . . . . . . . . . . . . . 13
     7.3.  Inferring Queue Occupancy  . . . . . . . . . . . . . . . . 14
     7.4.  Determining De-jitter Buffer Size  . . . . . . . . . . . . 14
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     11.2. Informative References . . . . . . . . . . . . . . . . . . 16
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18

Morton                   Expires April 18, 2007                 [Page 2]

Internet-Draft             Delay Variation AS               October 2006

1.  Introduction

   There are many ways to formulate delay variation metrics for packet
   networks.  The IETF itself has several specifications for delay
   variation, sometimes called jitter, and these have achieved wide
   adoption.  The International Telecommunication Union -
   Telecommunication Standardization Sector has also recommended several
   delay variation metrics (called parameters in their terminology), and
   some of these are widely cited and used.

   Most (if not all) delay variation metrics are derived metrics, in
   that their definitions rely on another fundamental metric.  In this
   case, the fundamental metric is one-way delay, and variation is
   assessed by computing the difference between two individual one-way
   delay measurements, or a pair of singletons.  One of the delay
   singletons is taken as a reference value, and the result is the
   variation with respect to the reference.  The variation is usually
   summarized for all packets in a stream (or sample) using statistics.

   Two main formulations of delay variation are preferred (according to

   1.  Inter-Packet Delay Variation, IPDV, where the reference is the
       previous packet in the stream (according to sending sequence),
       and the reference changes for each packet in the stream.
       Properties of variation and packet sequence are captured in this

   2.  Packet Delay Variation, PDV, where a single reference is chosen
       from the stream based on specific criteria, and the reference is
       fixed once selected.  The most common criterion for the reference
       is the packet with the minimum delay in the sample.

   Each of these metric formulations has certain advantages and
   disadvantages that make them more suitable for one circumstance and
   less so for another.  This memo examines a range of circumstances for
   active measurements of delay variation and their uses, and recommends
   the form that is best matched to the conditions and task.

   It is important to note that the authors of relevant standards for
   delay variation recognized there are many different users with
   varying needs, and allowed sufficient flexibility to formulate
   several metrics with different properties.  Therefore, the comparison
   is not so much between standards bodies or their specifications as it
   is between specific formulations of delay variation.  For instance,
   both Inter-Packet Delay Variation and Packet Delay Variation can be
   assessed using options of [RFC3393], especially the packet selection

Morton                   Expires April 18, 2007                 [Page 3]

Internet-Draft             Delay Variation AS               October 2006

   The IPPM framework [RFC2330] and other RFCs describing IPPM metrics
   provide a background for this memo, especially for terms such as
   singleton, sample, and statistic.

2.  Purpose and Scope

   The purpose of this memo is to compare two forms of delay variation,
   so that it will be evident which of the two is better suited for each
   of many possible uses and their related circumstances.

   The scope of this memo is limited to the two forms of delay variation
   briefly described above (Inter-Packet Delay Variation and Packet
   Delay Variation), circumstances related to active measurement, and
   uses that are deemed relevant and worthy of inclusion here through
   IPPM Working Group consensus.

   The scope excludes assessment of delay variation for packets with
   undefined delay.  The is accomplished by conditioning the delay
   distribution on arrival within a reasonable time based on an
   understanding of the path under test and packet lifetimes.  This is
   consistent with [RFC3393], where the Type-P-One-way-ipdv is undefined
   when the destination fails to receive one or both packets in the
   selected pair.  Furthermore, it is consistent with application
   performance analysis to consider only arriving packets, because a
   finite waiting time-out is a feature of many protocols.

3.  Uses of Delay Variation Metrics

   This section presents a set of tasks that call for delay variation
   measurements and their possible circumstances.  It answers the
   question, "How will the results be used?" for the delay variation

3.1.  Determining De-jitter Buffer Size

   Most Isochronous applications (a.k.a. real-time applications) employ
   a buffer to smooth out delay variation encountered on the path from
   source to destination.  The buffer must be big enough to accommodate
   (most of) the expected variation, or packet loss will result.
   However, if the buffer is too large, then some of the desired
   spontaneity of communication will be lost and conversational dynamics
   will be affected.  Therefore, application designers need to know the
   extent of delay variation they must accommodate, whether they are
   designing fixed or adaptive buffer systems.

   Network service providers also attempt to constrain delay variation

Morton                   Expires April 18, 2007                 [Page 4]

Internet-Draft             Delay Variation AS               October 2006

   to ensure the quality of real-time applications, and monitor this
   metric (possibly to compare with a numerical objective or Service
   Level Agreement).

3.2.  Inferring Queue Occupation on a Path

   As packets travel along the path from source to destination, they
   pass through a series of router queues.  Many of the sources of delay
   along the path are constant, but the latency encountered in each
   queue varies, depending on the number of packets in the queue when a
   particular packet arrives.  If one assumes that at least one of the
   packets in a test stream encounters virtually empty queues all along
   the path (and the path is stable), then the additional delay observed
   on other packets can be attributed to the time spent in one or more
   queues.  Otherwise, the delay variation observed is the variation in
   queue time experienced by the test stream.

3.3.  Spatial Composition

   In Spatial Composition, the tasks are similar to those described
   above, but with the additional complexity of a multiple network path
   where several sub-paths are measured separately, and no source to
   destination measurements are available.  In this case, the source to
   destination performance must be estimated, using Composed Metrics as
   described in [I-D.ietf-ippm-framework-compagg]

3.4.  Challenging Circumstances

   Any of the tasks above are made more "interesting" when certain
   circumstances are present.  Among these are:

   1.  Low cost or low complexity measurement systems.  These systems
       may be embedded in communication devices that do not have access
       to high stability clocks, and time errors will almost certainly
       be present.  These devices may not have sufficient memory to
       store all singletons for later processing.

   2.  Extremely dynamic network conditions.  When there is little or no
       stability in the network under test, then the devices that
       attempt to characterize the network are equally stressed,
       especially if the results displayed are used to make inferences
       which may not be valid.  Frequent path changes and prolonged
       congestion with substantial packet loss clearly make delay
       variation measurements challenging.

Morton                   Expires April 18, 2007                 [Page 5]

Internet-Draft             Delay Variation AS               October 2006

3.5.  <your favorite here>

4.  Formulations of IPDV and PDV

   This section presents the formulations of IPDV and PDV, and provides
   some illustrative examples.  We use the basic singleton definition in
   [RFC3393] (which itself is based on [RFC2679]):

   "Type-P-One-way-ipdv is defined for two packets from Src to Dst
   selected by the selection function F, as the difference between the
   value of the Type-P-One-way-delay from Src to Dst at T2 and the value
   of the Type-P-One-Way-Delay from Src to Dst at T1."

4.1.  IPDV: Inter-Packet Delay Variation

   An example selection function given in [RFC3393] is "Consecutive
   Type-P packets within the specified interval."  This is exactly the
   function needed for IPDV.  The reference packet in the pair is always
   the previous packet in the sending sequence.

   If we have packets in a stream consecutively numbered i = 1,2,3,...
   falling within the test interval, then IPDV(i) = D(i)-D(i-1) where
   D(i) denotes the one-way-delay of the ith packet of a stream.

4.2.  PDV: Packet Delay Variation

   The Selection Function for PDV requires two specific roles for the
   packets in the pair.  The first packet is any Type-P packet within
   the specified interval.  The second, or reference packet is the
   Type-P packet within the specified interval with the minimum one-way-

   Therefore, PDV(i) = D(i)-D(min) (using the nomenclature introduced in
   the IPDV section).

4.3.  Examples and Initial Comparisons

   This section will discuss the examples in slides 2 and 3 of

5.  Earlier Comparisons

   This section summarizes previous work to compare these two forms of
   delay variation.

Morton                   Expires April 18, 2007                 [Page 6]

Internet-Draft             Delay Variation AS               October 2006

5.1.  Demichelis' Comparison

   In [Demichelis], Demichelis compared the early draft versions of the
   two forms we consider here.  Although the IPDV form would eventually
   be standardized under the IETF IPPM effort, the ITU-T work cited here
   was significantly modified based on further study and analysis.
   Demichelis considered the possibilities of using the delay of the
   first packet in the stream and the mean delay of the stream as the
   PDV reference packet.  Neither of these alternative references were
   used in practice, and they are now depreciated in favor of the
   minimum delay of the stream [Y.1540] .

   Active measurements of a transcontinental path (Torino to Tokyo)
   provided the data for the comparison.  The Poisson test stream had
   0.764 second average inter-packet interval, with more than 58
   thousand packets over 13.5 hours.  Among Demichelis' observations
   about IPDV are the following:

   1.  IPDV is a measure of the network's ability to preserve the
       spacing between packets.

   2.  The distribution of IPDV is usually symmetrical about the origin,
       having a balance of negative and positive values (for the most
       part).  The mean is usually zero, unless some long-term delay
       trend is present.

   3.  IPDV distinguishes quick delay variations (on the order of the
       interval between packets) from longer term variations.

   4.  IPDV places reduced demands on the stability and skew of
       measurement clocks.

   He also notes these features of PDV:

   1.  PDV does not distinguish quick variation from variation over the
       complete test interval.

   2.  The location of the distribution is very sensitive to the delay
       of the first packet, if this packet is used as the reference.

   3.  The shape of the PDV distribution is identical to the delay
       distribution, but shifted by the reference delay.

   4.  Use of a common reference over long measurement intervals can
       indicate more PDV than would be experienced by streams that
       support shorter interval sessions.

Morton                   Expires April 18, 2007                 [Page 7]

Internet-Draft             Delay Variation AS               October 2006

   5.  PDV characterizes the range of queue occupancies along the
       measurement path (assuming the path is fixed), but the range says
       nothing about how the variation took place.

   The summary metrics used in this comparison were the number of values
   exceeding a +/-50ms range around the mean, the Inverse Percentiles,
   and the Inter-Quartile Range.

5.2.  Ciavattone et al.

   In [Cia03], the authors compared IPDV and PDV (referred to as delta)
   using a periodic packet stream conforming to [RFC3432] with inter-
   packet interval of 20 ms.

   One of the comparisons between IPDV and PDV involves a laboratory
   set-up where a queue was temporarily congested by a competing packet
   burst.  The additional queuing delay was 85ms to 95ms, much larger
   than the inter-packet interval.  The first packet in the stream that
   follows the competing burst spends the longest time enqueued, and
   others experience less and less queuing time until the queue is

   The authors observed that PDV reflects the additional queuing time of
   the packets affected by the burst, with values of 85, 65, 45, 25, and
   5ms.  Also, it is easy to determine (by looking at the PDV range)
   that a de-jitter buffer of 90 ms would have been sufficient to
   accommodate the delay variation.

   The distribution of IPDV values in the congested queue example are
   very different: 85, -20, -20, -20, -20, -5ms.  Only the positive
   excursion of IPDV gives an indication of the de-jitter buffer size
   needed.  Although the variation exceeds the inter-packet interval,
   the extent of negative IPDV values is limited by that sending
   interval.  This preference for information from the positive IPDV
   values has prompted some to ignore the negative values, or to take
   the absolute value of each IPDV measurement (sacrificing key
   properties of IPDV in the process, such as its ability to distinguish
   delay trends).

   Elsewhere, the authors considered the range as a summary statistic
   for IPDV, and the 99.9%-ile minus the minimum delay as a summary
   statistic for delay variation, or PDV.

5.3.  IPPM List Discussion from 2001

   Summary To Be Provided.  But to indicate one of the key points:

   IPDV values can be viewed as the adjustments that an adaptive de-

Morton                   Expires April 18, 2007                 [Page 8]

Internet-Draft             Delay Variation AS               October 2006

   jitter buffer would make, IF it could make adjustments on a packet-
   by-packet basis.  However, adaptive de-jitter buffers don't make
   adjustments so frequently, so in this respect IPDV provides "too much

5.4.  Y.1540 Appendix II

   This Appendix compares IPDV, PDV (referred to as 2-point PDV), and
   1-point packet delay variation (which assume a periodic stream and
   assesses variation against an ideal arrival schedule constructed at
   the single measurement point).

6.  Additional Properties and Comparisons

   This section treats some of the earlier comparison areas in more
   detail, and introduces new areas for comparison.

6.1.  Jitter in RTCP Reports

   [RFC3550] gives the calculation of the inter-arrival Jitter field for
   the RTCP report, with a sample implementation in an Appendix.

   The RTCP Jitter value can be calculated using IPDV singletons.  If
   there is packet reordering, as defined in [I-D.ietf-ippm-reordering],
   then estimates of Jitter based on IPDV may vary slightly, because
   [RFC3550] specifies the use of receive packet order.

   Just as there is no simple way to convert PDV singletons to IPDV
   singletons without returning to the original sample of delay
   singletons, there is no clear relationship between PDV and [RFC3550]

6.2.  Path Changes

   Sometimes the path characteristics change during a measurement
   interval.  The change may be due to link or router failure,
   administrative changes prior to maintenance (e.g., link cost change),
   or re-optimization of routing using new information.  All these
   causes are usually infrequent, and network providers take appropriate
   measures to ensure this.  Automatic restoration to a back-up path is
   seen as a desirable feature of IP networks.

   Path changes are usually accompanied by a persistent increase or
   decrease in one-way-delay.  [Cia03] gives one such example.  We
   assume that a restoration path either accepts a stream of packets, or
   is not used for that particular stream (e.g., no multipath for

Morton                   Expires April 18, 2007                 [Page 9]

Internet-Draft             Delay Variation AS               October 2006

   In any case, a change in the TTL (or Hop Limit) of the received
   packets indicates that the path is no longer the same.  Transient
   packet reordering may also be observed with path changes, due to use
   of non-optimal routing while updates propagate through the network
   (see [Casner] and [Cia03] )

   Many, if not all, packet streams experience packet loss in
   conjunction with a path change.  However, it is certainly possible
   that the active measurement stream does not experience loss.  This
   may be due to use of a long inter-packet sending interval with
   respect to the restoration time, and this becomes more likely as
   "fast restoration" techniques see wider deployment.

   Thus, there are two main cases to consider, path changes accompanied
   by loss, and those that are lossless from the point of view of the
   active measurement stream.

6.2.1.  Lossless Path Change

   In the lossless case, a path change will typically affect only two
   IPDV singletons.  However, if the change in delay is negative and
   larger than the inter-packet sending interval, then more than two
   IPDV singletons may be affected because packet reordering is also
   likely to occur.

   The use of the new path and its delay variation can be quantified by
   treating the PDV distribution as bi-modal, and characterizing each
   mode separately.  This would involve declaring a new path within the
   sample, and using a new local minimum delay as the PDV reference
   delay for the sub-sample (or time interval) where the new path is

   The process of detecting a bi-modal delay distribution is made
   difficult if the typical delay variation is larger than the delay
   change associated with the new path.  However, information on TTL (or
   Hop Limit) change or the presence of transient reordering can assist
   in an automated decision.

   The effect of path changes may also be reduced by making PDV
   measurements over short intervals (minutes, as opposed to hours).
   This way, a path change will affect one sample and its PDV values.
   Assuming that the mean or median one-way-delay changes appreciably on
   the new path, then subsequent measurements can confirm a path change,
   and trigger special processing on the interval containing a path
   change and the affected PDV result.

Morton                   Expires April 18, 2007                [Page 10]

Internet-Draft             Delay Variation AS               October 2006

6.2.2.  Path Change with Loss

   If the path change is accompanied by loss, such that the are no
   consecutive packet pairs that span the change, then no IPDV
   singletons will reflect the change.  This may or may not be
   desirable, depending on the ultimate use of the delay variation

   PDV will again produce a bimodal distribution.  But here, the
   decision process to define sub-intervals associated with each path is
   further assisted by the presence of loss, in addition to TTL,
   reordering information, and use of short measurement intervals
   consistent with the duration of user sessions.  It is reasonable to
   assume that at least loss and delay will be measured simultaneously
   with PDV or IPDV.

6.3.  Measurement Clock Issues

   As mentioned above, [Demichelis] observed that PDV places greater
   demands on clock synchronization than for IPDV.  This observation
   deserves more discussion.  Synchronization errors have two
   components: time of day errors and clock frequency errors (resulting
   in skew).

   Both IPDV and PDV are sensitive to time-of-day errors when attempting
   to align measurement intervals at the source and destination.  Gross
   mis-alignment of the measurement intervals can lead to lost packets,
   for example if the receiver is not ready when the first test packet
   arrives.  However, both IPDV and PDV assess time differences, so the
   error present in two one-way-delay singletons will cancel as long as
   it is constant.

   Skew is a measure of the change in clock time over an interval w.r.t.
   a reference clock.  Both IPDV and PDV are affected by skew, but the
   error sensitivity in IPDV singletons is less because the intervals
   between consecutive packets are rather small, especially when
   compared to the overall measurement interval.  Since PDV computes the
   difference between a single reference delay (the sample minimum) and
   all other delays in the measurement interval, the constraint on skew
   error is greater to attain the same accuracy as IPDV.  Again, use of
   short PDV measurement intervals (on the order of minutes, not hours)
   provides some relief from the effects of skew error.

   If skew is present in a sample of one-way-delays, its symptom is
   typically a linear growth or decline over all the one-way-delay
   values.  As a practical matter, if the same slope appears
   consistently in the measurements, then it may be possible to fit the
   slope and compensate for the skew in the one-way-delay measurements,

Morton                   Expires April 18, 2007                [Page 11]

Internet-Draft             Delay Variation AS               October 2006

   thereby avoiding the issue in the PDV calculations that follow.  See
   [RFC3393] for additional information on compensating for skew.

6.4.  Reporting a Single Number

   Despite the risk of over-summarization, measurements must often be
   displayed for easy consumption.  If the right summary report is
   prepared, then the "dashboard" view correctly indicates whether there
   is something different and worth investigating further, or that the
   status has not changed.  The dashboard model restricts every
   instrument display to a single number.  The packet network dashboard
   could have different instruments for loss, delay, delay variation,
   reordering, etc., and each must be summarized as a single number for
   each measurement interval.

   The simplicity of the PDV distribution lends itself to this
   summarization process (including use of the median or mean).
   [Y.1541] introduced the notion of a pseudo-range when setting an
   objective for the 99.9%-ile of PDV.  The conventional range (max-min)
   was avoided for several reasons, including stability of the maximum
   delay.  The 99.9%-ile of PDV is helpful to performance planners
   (seeking to meet some user-to-user objective for delay) and in design
   of de-jitter buffer sizes, even those with adaptive capabilities.

   IPDV does not lend itself to summarization so easily.  The mean IPDV
   is typically zero.  As the IPDV distribution may have two tails
   (positive and negative) the range or pseudo-range would not match the
   needed de-jitter buffer size.  Additional complexity may be
   introduced when the variation exceeds the inter-packet sending
   interval, as discussed above.  Should the Inter-Quartile Range be
   used?  Should the singletons beyond some threshold be counted (e.g.,
   mean +/- 50ms)?  A strong rationale for one of these summary
   statistics has yet to emerge.

6.5.  MAPDV2

   MAPDV2 stands for Mean Absolute Packet Delay Variation (version) 2,
   and is specified in [G.1020].  The MAPDV2 algorithm computes a
   smoothed running estimate of the mean delay using the one-way delays
   of 16 previous packets.  It compares the current one-way-delay to the
   estimated mean, separately computes the means of positive and
   negative deviations, and sums these deviation means to produce
   MAPVDV2.  In effect, there is a MAPDV2 singleton for every arriving
   packet, so further summarization is usually warranted.

   Neither IPDV or PDV assists in the computation of MAPDV2.

Morton                   Expires April 18, 2007                [Page 12]

Internet-Draft             Delay Variation AS               October 2006

7.  Applicability of the Delay Variation Forms with Tasks

   Based on the comparisons of IPDV and PDV presented above, this
   section matches the attributes of each form with the tasks described
   in section 3.  We discuss the more general circumstances first.

   Note: the conclusions of this section should be regarded as
   preliminary, pending discussion and further development by the IPPM

7.1.  Challenging Circumstances

   When appreciable skew is present between measurement system clocks,
   then IPDV has a clear advantage, since that PDV would require
   processing over the entire sample to remove the skew error.  Neither
   form of delay variation is more suited than the other to on-the-fly
   summarization without memory, and this is one of the reasons that
   [RFC3550] RTCP Jitter and MAPDV2 in [G.1020] have attained deployment
   in low-cost systems.

   If the network under test exhibits frequent path changes, on the
   order of several new routes per minute, then IPDV appears to isolate
   the delay variation on each path from the transient effect of path
   change (especially if there is packet loss at the time of path
   change).  It is possible to make meaningful PDV measurements when
   paths are unstable, but great importance would be placed on the
   algorithms that infer path change and attempt to divide the sample on
   path change boundaries.

   If the network under test exhibits frequent loss, then PDV may
   produce a larger set of singletons for the sample than IPDV.  This is
   due to IPDV requiring consecutive packet arrivals to assess delay
   variation, compared to PDV where any packet arrival is useful.  The
   worst case is when no consecutive packets arrive, and the entire IPDV
   sample would be undefined.  PDV would successfully produce a sample
   based on the arriving packets.

   Note that delay variation may not be the top concern under these
   unstable and un-reliable circumstances, as this author has pointed-
   out many times in discussion.

7.2.  Spatial Composition

   ITU-T Recommendation [Y.1541] gives a provisional method to compose a
   PDV metric using PDV measurement results from two or more sub-paths.

   PDV has a clear advantage at this time, since there is no known
   method to compose an IPDV metric.  In addition, IPDV results depend

Morton                   Expires April 18, 2007                [Page 13]

Internet-Draft             Delay Variation AS               October 2006

   greatly on the exact sequence of packets and may not lend themselves
   easily to the composition problem.

7.3.  Inferring Queue Occupancy

   The PDV distribution is anchored at the minimum delay observed in the
   measurement interval.  When the sample minimum coincides with the
   true minimum delay of the path, then the PDV distribution is
   equivalent to the queuing time distribution experienced by the test
   stream.  If the minimum delay is not the true minimum, then the PDV
   distribution captures the variation in queuing time and some
   additional amount of queuing time is experienced, but unknown.  One
   can summarize the PDV distribution with the mean, median, and other

   IPDV can capture the difference in queuing time from one packet to
   the next, but this is a different distribution from the queue
   occupancy revealed by PDV.

7.4.  Determining De-jitter Buffer Size

   This task is complimentary to the problem of inferring queue
   occupancy through measurement.  Again, use of the sample minimum as
   the reference delay for PDV yields a distribution that is very
   relevant to de-jitter buffer size.  This is because the minimum delay
   is an alignment point for the smoothing operation of de-jitter
   buffers.  A de-jitter buffer that is ideally aligned with the delay
   variation adds zero buffer time to packets with the longest
   accommodated network delay (any packets with longer delays are
   discarded).  Thus, a packet experiencing minimum network delay should
   be aligned to wait the maximum length of the de-jitter buffer.  With
   this alignment, the stream is smoothed with no unnecessary delay
   added.  [G.1020] illustrates the ideal relationship between network
   delay variation and buffer time.

   The PDV distribution is also useful for this task, but different
   statistics are preferred.  The range (max-min) or the 99.9%-ile of
   PDV (pseudo-range) are closely related to the buffer size needed to
   accommodate the observed network delay variation.

   In some cases, the positive excursions of IPDV may help to
   approximate the de-jitter buffer size, but there is no guarantee that
   a good buffer estimate will emerge, especially when the delay varies
   as a positive trend over several test packets.

Morton                   Expires April 18, 2007                [Page 14]

Internet-Draft             Delay Variation AS               October 2006

8.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an

9.  Security Considerations

   The security considerations that apply to any active measurement of
   live networks are relevant here as well.  See [RFC4656]

10.  Acknowledgements

   The author would like to thank Phil Chimento for his suggestion to
   employ the convention of conditional distributions for Delay to deal
   with packet loss, and his encouragement to "write the memo" after
   hearing the talk.

11.  References

11.1.  Normative References

              Morton, A., "Packet Reordering Metric for IPPM",
              draft-ietf-ippm-reordering-13 (work in progress),
              May 2006.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [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 One-way
              Delay Metric for IPPM", RFC 2679, September 1999.

   [RFC2680]  Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
              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.

Morton                   Expires April 18, 2007                [Page 15]

Internet-Draft             Delay Variation AS               October 2006

   [RFC3432]  Raisanen, V., Grotefeld, G., and A. Morton, "Network
              performance measurement with periodic streams", RFC 3432,
              November 2002.

   [RFC4656]  Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
              Zekauskas, "A One-way Active Measurement Protocol
              (OWAMP)", RFC 4656, September 2006.

11.2.  Informative References

   [Casner]   "A Fine-Grained View of High Performance Networking, NANOG
              22 Conf.;", May
              20-22 2001.

   [Cia03]    "Standardized Active Measurements on a Tier 1 IP Backbone,
              IEEE Communications Mag., pp 90-97.", June 2003.

              01-pap02.doc, "Packet Delay Variation Comparison between
              ITU-T and IETF Draft Definitions", November 2000.

   [G.1020]   ITU-T Recommendation G.1020, ""Performance parameter
              definitions for the quality of speech and other voiceband
              applications utilizing IP networks"", 2006.

              Morton, A. and S. Berghe, "Framework for Metric
              Composition", draft-ietf-ippm-framework-compagg-01 (work
              in progress), June 2006.

              Presentation at IPPM, IETF-64, "Jitter Definitions: What
              is What?", November 2005.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [Y.1540]   ITU-T Recommendation Y.1540, "Internet protocol data
              communication service - IP packet transfer and
              availability performance parameters", December  2002.

   [Y.1541]   ITU-T Recommendation Y.1540, "Network Performance
              Objectives for IP-Based Services", February  2006.

Morton                   Expires April 18, 2007                [Page 16]

Internet-Draft             Delay Variation AS               October 2006

Author's Address

   Al Morton
   AT&T Labs
   200 Laurel Avenue South
   Middletown,, NJ  07748

   Phone: +1 732 420 1571
   Fax:   +1 732 368 1192

Morton                   Expires April 18, 2007                [Page 17]

Internet-Draft             Delay Variation AS               October 2006

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Morton                   Expires April 18, 2007                [Page 18]