summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2679.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2679.txt')
-rw-r--r--doc/rfc/rfc2679.txt1123
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc2679.txt b/doc/rfc/rfc2679.txt
new file mode 100644
index 0000000..a315770
--- /dev/null
+++ b/doc/rfc/rfc2679.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group G. Almes
+Request for Comments: 2679 S. Kalidindi
+Category: Standards Track M. Zekauskas
+ Advanced Network & Services
+ September 1999
+
+
+ A One-way Delay Metric for IPPM
+
+1. Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+2. Introduction
+
+ This memo defines a metric for one-way delay of packets across
+ Internet paths. It builds on notions introduced and discussed in the
+ IPPM Framework document, RFC 2330 [1]; the reader is assumed to be
+ familiar with that document.
+
+ This memo is intended to be parallel in structure to a companion
+ document for Packet Loss ("A One-way Packet Loss Metric for IPPM")
+ [2].
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [6].
+ Although RFC 2119 was written with protocols in mind, the key words
+ are used in this document for similar reasons. They are used to
+ ensure the results of measurements from two different implementations
+ are comparable, and to note instances when an implementation could
+ perturb the network.
+
+ The structure of the memo is as follows:
+
+ + A 'singleton' analytic metric, called Type-P-One-way-Delay, will
+ be introduced to measure a single observation of one-way delay.
+
+
+
+
+
+
+Almes, et al. Standards Track [Page 1]
+
+RFC 2679 A One-way Delay Metric for IPPM September 1999
+
+
+ + Using this singleton metric, a 'sample', called Type-P-One-way-
+ Delay-Poisson-Stream, will be introduced to measure a sequence of
+ singleton delays measured at times taken from a Poisson process.
+
+ + Using this sample, several 'statistics' of the sample will be
+ defined and discussed.
+
+ This progression from singleton to sample to statistics, with clear
+ separation among them, is important.
+
+ Whenever a technical term from the IPPM Framework document is first
+ used in this memo, it will be tagged with a trailing asterisk. For
+ example, "term*" indicates that "term" is defined in the Framework.
+
+2.1. Motivation:
+
+ One-way delay of a Type-P* packet from a source host* to a
+ destination host is useful for several reasons:
+
+ + Some applications do not perform well (or at all) if end-to-end
+ delay between hosts is large relative to some threshold value.
+
+ + Erratic variation in delay makes it difficult (or impossible) to
+ support many real-time applications.
+
+ + The larger the value of delay, the more difficult it is for
+ transport-layer protocols to sustain high bandwidths.
+
+ + The minimum value of this metric provides an indication of the
+ delay due only to propagation and transmission delay.
+
+ + The minimum value of this metric provides an indication of the
+ delay that will likely be experienced when the path* traversed is
+ lightly loaded.
+
+ + Values of this metric above the minimum provide an indication of
+ the congestion present in the path.
+
+ The measurement of one-way delay instead of round-trip delay is
+ motivated by the following factors:
+
+ + In today's Internet, the path from a source to a destination may
+ be different than the path from the destination back to the source
+ ("asymmetric paths"), such that different sequences of routers are
+ used for the forward and reverse paths. Therefore round-trip
+ measurements actually measure the performance of two distinct
+ paths together. Measuring each path independently highlights the
+ performance difference between the two paths which may traverse
+
+
+
+Almes, et al. Standards Track [Page 2]
+
+RFC 2679 A One-way Delay Metric for IPPM September 1999
+
+
+ different Internet service providers, and even radically different
+ types of networks (for example, research versus commodity
+ networks, or ATM versus packet-over-SONET).
+
+ + Even when the two paths are symmetric, they may have radically
+ different performance characteristics due to asymmetric queueing.
+
+ + Performance of an application may depend mostly on the performance
+ in one direction. For example, a file transfer using TCP may
+ depend more on the performance in the direction that data flows,
+ rather than the direction in which acknowledgements travel.
+
+ + In quality-of-service (QoS) enabled networks, provisioning in one
+ direction may be radically different than provisioning in the
+ reverse direction, and thus the QoS guarantees differ. Measuring
+ the paths independently allows the verification of both
+ guarantees.
+
+ It is outside the scope of this document to say precisely how delay
+ metrics would be applied to specific problems.
+
+2.2. General Issues Regarding Time
+
+ {Comment: the terminology below differs from that defined by ITU-T
+ documents (e.g., G.810, "Definitions and terminology for
+ synchronization networks" and I.356, "B-ISDN ATM layer cell transfer
+ performance"), but is consistent with the IPPM Framework document.
+ In general, these differences derive from the different backgrounds;
+ the ITU-T documents historically have a telephony origin, while the
+ authors of this document (and the Framework) have a computer systems
+ background. Although the terms defined below have no direct
+ equivalent in the ITU-T definitions, after our definitions we will
+ provide a rough mapping. However, note one potential confusion: our
+ definition of "clock" is the computer operating systems definition
+ denoting a time-of-day clock, while the ITU-T definition of clock
+ denotes a frequency reference.}
+
+ Whenever a time (i.e., a moment in history) is mentioned here, it is
+ understood to be measured in seconds (and fractions) relative to UTC.
+
+ As described more fully in the Framework document, there are four
+ distinct, but related notions of clock uncertainty:
+
+
+
+
+
+
+
+
+
+Almes, et al. Standards Track [Page 3]
+
+RFC 2679 A One-way Delay Metric for IPPM September 1999
+
+
+ synchronization*
+
+ measures the extent to which two clocks agree on what time it
+ is. For example, the clock on one host might be 5.4 msec ahead
+ of the clock on a second host. {Comment: A rough ITU-T
+ equivalent is "time error".}
+
+ accuracy*
+
+ measures the extent to which a given clock agrees with UTC.
+ For example, the clock on a host might be 27.1 msec behind UTC.
+ {Comment: A rough ITU-T equivalent is "time error from UTC".}
+
+ resolution*
+
+ measures the precision of a given clock. For example, the
+ clock on an old Unix host might tick only once every 10 msec,
+ and thus have a resolution of only 10 msec. {Comment: A very
+ rough ITU-T equivalent is "sampling period".}
+
+ skew*
+
+ measures the change of accuracy, or of synchronization, with
+ time. For example, the clock on a given host might gain 1.3
+ msec per hour and thus be 27.1 msec behind UTC at one time and
+ only 25.8 msec an hour later. In this case, we say that the
+ clock of the given host has a skew of 1.3 msec per hour
+ relative to UTC, which threatens accuracy. We might also speak
+ of the skew of one clock relative to another clock, which
+ threatens synchronization. {Comment: A rough ITU-T equivalent
+ is "time drift".}
+
+3. A Singleton Definition for One-way Delay
+
+3.1. Metric Name:
+
+ Type-P-One-way-Delay
+
+3.2. Metric Parameters:
+
+ + Src, the IP address of a host
+
+ + Dst, the IP address of a host
+
+ + T, a time
+
+
+
+
+
+
+Almes, et al. Standards Track [Page 4]
+
+RFC 2679 A One-way Delay Metric for IPPM September 1999
+
+
+3.3. Metric Units:
+
+ The value of a Type-P-One-way-Delay is either a real number, or an
+ undefined (informally, infinite) number of seconds.
+
+3.4. Definition:
+
+ For a real number dT, >>the *Type-P-One-way-Delay* from Src to Dst at
+ T is dT<< means that Src sent the first bit of a Type-P packet to Dst
+ at wire-time* T and that Dst received the last bit of that packet at
+ wire-time T+dT.
+
+ >>The *Type-P-One-way-Delay* from Src to Dst at T is undefined
+ (informally, infinite)<< means that Src sent the first bit of a
+ Type-P packet to Dst at wire-time T and that Dst did not receive that
+ packet.
+
+ Suggestions for what to report along with metric values appear in
+ Section 3.8 after a discussion of the metric, methodologies for
+ measuring the metric, and error analysis.
+
+3.5. Discussion:
+
+ Type-P-One-way-Delay is a relatively simple analytic metric, and one
+ that we believe will afford effective methods of measurement.
+
+ The following issues are likely to come up in practice:
+
+ + Real delay values will be positive. Therefore, it does not make
+ sense to report a negative value as a real delay. However, an
+ individual zero or negative delay value might be useful as part of
+ a stream when trying to discover a distribution of a stream of
+ delay values.
+
+ + Since delay values will often be as low as the 100 usec to 10 msec
+ range, it will be important for Src and Dst to synchronize very
+ closely. GPS systems afford one way to achieve synchronization to
+ within several 10s of usec. Ordinary application of NTP may allow
+ synchronization to within several msec, but this depends on the
+ stability and symmetry of delay properties among those NTP agents
+ used, and this delay is what we are trying to measure. A
+ combination of some GPS-based NTP servers and a conservatively
+ designed and deployed set of other NTP servers should yield good
+ results, but this is yet to be tested.
+
+ + 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
+
+
+
+Almes, et al. Standards Track [Page 5]
+
+RFC 2679 A One-way Delay Metric for IPPM September 1999
+
+
+ Mahdavi and Paxson [4], simple upper bounds (such as the 255
+ seconds theoretical upper bound on the lifetimes of IP packets
+ [5]) 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
+ 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.}
+
+ + If the packet is duplicated along the path (or paths) so that
+ multiple non-corrupt copies arrive at the destination, then the
+ packet is counted as received, and the first copy to arrive
+ determines the packet's one-way delay.
+
+ + If the packet is fragmented and if, for whatever reason,
+ reassembly does not occur, then the packet will be deemed lost.
+
+3.6. Methodologies:
+
+ As with other Type-P-* metrics, the detailed methodology will depend
+ on the Type-P (e.g., protocol number, UDP/TCP port number, size,
+ precedence).
+
+ Generally, for a given Type-P, the methodology would proceed as
+ follows:
+
+ + Arrange that Src and Dst are synchronized; that is, that they have
+ clocks that are very closely synchronized with each other and each
+ fairly close to the actual time.
+
+ + At the Src host, select Src and Dst IP addresses, and form a test
+ packet of Type-P 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.
+
+ + At the Dst host, arrange to receive the packet.
+
+ + At the Src host, place a timestamp in the prepared Type-P 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 one-way delay can
+ be computed. Error analysis of a given implementation of the
+ method must take into account the closeness of synchronization
+ between Src and Dst. If the delay between Src's timestamp and the
+
+
+
+Almes, et al. Standards Track [Page 6]
+
+RFC 2679 A One-way Delay Metric for IPPM September 1999
+
+
+ actual sending of the packet is known, then the estimate could be
+ adjusted by subtracting this amount; uncertainty in this value
+ must be taken into account in error analysis. Similarly, if the
+ delay between the actual receipt of the packet and Dst's timestamp
+ is known, then the estimate could be adjusted by subtracting this
+ amount; uncertainty in this value must be taken into account in
+ error analysis. See the next section, "Errors and Uncertainties",
+ for a more detailed discussion.
+
+ + If the packet fails to arrive within a reasonable period of time,
+ the one-way delay is taken to be undefined (informally, infinite).
+ Note that the threshold of 'reasonable' is a parameter of the
+ methodology.
+
+ Issues such as the packet format, the means by which Dst knows when
+ to expect the test packet, and the means by which Src and Dst are
+ synchronized are outside the scope of this document. {Comment: We
+ plan to document elsewhere our own work in describing such more
+ detailed implementation techniques and we encourage others to as
+ well.}
+
+3.7. Errors and Uncertainties:
+
+ The description of any specific measurement method should include an
+ accounting and analysis of various sources of error or uncertainty.
+ The Framework document provides general guidance on this point, but
+ we note here the following specifics related to delay metrics:
+
+ + Errors or uncertainties due to uncertainties in the clocks of the
+ Src and Dst hosts.
+
+ + Errors or uncertainties due to the difference between 'wire time'
+ and 'host time'.
+
+ In addition, the loss threshold may affect the results. Each of
+ these are discussed in more detail below, along with a section
+ ("Calibration") on accounting for these errors and uncertainties.
+
+3.7.1. Errors or uncertainties related to Clocks
+
+ The uncertainty in a measurement of one-way delay is related, in
+ part, to uncertainties in the clocks of the Src and Dst hosts. In
+ the following, we refer to the clock used to measure when the packet
+ was sent from Src as the source clock, we refer to the clock used to
+ measure when the packet was received by Dst as the destination clock,
+ we refer to the observed time when the packet was sent by the source
+ clock as Tsource, and the observed time when the packet was received
+ by the destination clock as Tdest. Alluding to the notions of
+
+
+
+Almes, et al. Standards Track [Page 7]
+
+RFC 2679 A One-way Delay Metric for IPPM September 1999
+
+
+ synchronization, accuracy, resolution, and skew mentioned in the
+ Introduction, we note the following:
+
+ + Any error in the synchronization between the source clock and the
+ destination clock will contribute to error in the delay
+ measurement. We say that the source clock and the destination
+ clock have a synchronization error of Tsynch if the source clock
+ is Tsynch ahead of the destination clock. Thus, if we know the
+ value of Tsynch exactly, we could correct for clock
+ synchronization by adding Tsynch to the uncorrected value of
+ Tdest-Tsource.
+
+ + The accuracy of a clock is important only in identifying the time
+ at which a given delay was measured. Accuracy, per se, has no
+ importance to the accuracy of the measurement of delay. When
+ computing delays, we are interested only in the differences
+ between clock values, not the values themselves.
+
+ + The resolution of a clock adds to uncertainty about any time
+ measured with it. Thus, if the source clock has a resolution of
+ 10 msec, then this adds 10 msec of uncertainty to any time value
+ measured with it. We will denote the resolution of the source
+ clock and the destination clock as Rsource and Rdest,
+ respectively.
+
+ + The skew of a clock is not so much an additional issue as it is a
+ realization of the fact that Tsynch is itself a function of time.
+ Thus, if we attempt to measure or to bound Tsynch, this needs to
+ be done periodically. Over some periods of time, this function
+ can be approximated as a linear function plus some higher order
+ terms; in these cases, one option is to use knowledge of the
+ linear component to correct the clock. Using this correction, the
+ residual Tsynch is made smaller, but remains a source of
+ uncertainty that must be accounted for. We use the function
+ Esynch(t) to denote an upper bound on the uncertainty in
+ synchronization. Thus, |Tsynch(t)| <= Esynch(t).
+
+ Taking these items together, we note that naive computation Tdest-
+ Tsource will be off by Tsynch(t) +/- (Rsource + Rdest). Using the
+ notion of Esynch(t), we note that these clock-related problems
+ introduce a total uncertainty of Esynch(t)+ Rsource + Rdest. This
+ estimate of total clock-related uncertainty should be included in the
+ error/uncertainty analysis of any measurement implementation.
+
+
+
+
+
+
+
+
+Almes, et al. Standards Track [Page 8]
+
+RFC 2679 A One-way Delay Metric for IPPM September 1999
+
+
+3.7.2. Errors or uncertainties related to Wire-time vs Host-time
+
+ As we have defined one-way delay, we would like to measure the time
+ between when the test packet leaves the network interface of Src and
+ when it (completely) arrives at the network interface of Dst, and we
+ refer to these as "wire times." If the timings are themselves
+ performed by software on Src and Dst, however, then this software can
+ only directly measure the time between when Src grabs a timestamp
+ just prior to sending the test packet and when Dst grabs a timestamp
+ just after having received the test packet, and we refer to these two
+ points as "host times".
+
+ To the extent that the difference between wire time and host time is
+ accurately known, this knowledge can be used to correct for host time
+ measurements and the corrected value more accurately estimates the
+ desired (wire time) metric.
+
+ To the extent, however, that the difference between wire time and
+ host time is uncertain, this uncertainty must be accounted for in an
+ analysis of a given measurement method. We denote by Hsource an
+ upper bound on the uncertainty in the difference between wire time
+ and host time on the Src host, and similarly define Hdest for the Dst
+ host. We then note that these problems introduce a total uncertainty
+ of Hsource+Hdest. This estimate of total wire-vs-host uncertainty
+ should be included in the error/uncertainty analysis of any
+ measurement implementation.
+
+3.7.3. Calibration
+
+ Generally, the measured values can be decomposed as follows:
+
+ measured value = true value + systematic error + random error
+
+ If the systematic error (the constant bias in measured values) can be
+ determined, it can be compensated for in the reported results.
+
+ reported value = measured value - systematic error
+
+ therefore
+
+ reported value = true value + random error
+
+ The goal of calibration is to determine the systematic and random
+ error generated by the instruments themselves in as much detail as
+ possible. At a minimum, a bound ("e") should be found such that the
+ reported value is in the range (true value - e) to (true value + e)
+ at least 95 percent of the time. We call "e" the calibration error
+ for the measurements. It represents the degree to which the values
+
+
+
+Almes, et al. Standards Track [Page 9]
+
+RFC 2679 A One-way Delay Metric for IPPM September 1999
+
+
+ produced by the measurement instrument are repeatable; that is, how
+ closely an actual delay of 30 ms is reported as 30 ms. {Comment: 95
+ percent was chosen because (1) some confidence level is desirable to
+ be able to remove outliers, which will be found in measuring any
+ physical property; (2) a particular confidence level should be
+ specified so that the results of independent implementations can be
+ compared; and (3) even with a prototype user-level implementation,
+ 95% was loose enough to exclude outliers.}
+
+ From the discussion in the previous two sections, the error in
+ measurements could be bounded by determining all the individual
+ uncertainties, and adding them together to form
+
+ Esynch(t) + Rsource + Rdest + Hsource + Hdest.
+
+ However, reasonable bounds on both the clock-related uncertainty
+ captured by the first three terms and the host-related uncertainty
+ captured by the last two terms should be possible by careful design
+ techniques and calibrating the instruments using a known, isolated,
+ network in a lab.
+
+ For example, the clock-related uncertainties are greatly reduced
+ through the use of a GPS time source. The sum of Esynch(t) + Rsource
+ + Rdest is small, and is also bounded for the duration of the
+ measurement because of the global time source.
+
+ The host-related uncertainties, Hsource + Hdest, could be bounded by
+ connecting two instruments back-to-back with a high-speed serial link
+ or isolated LAN segment. In this case, repeated measurements are
+ measuring the same one-way delay.
+
+ If the test packets are small, such a network connection has a
+ minimal delay that may be approximated by zero. The measured delay
+ therefore contains only systematic and random error in the
+ instrumentation. The "average value" of repeated measurements is the
+ systematic error, and the variation is the random error.
+
+ One way to compute the systematic error, and the random error to a
+ 95% confidence is to repeat the experiment many times - at least
+ hundreds of tests. The systematic error would then be the median.
+ The random error could then be found by removing the systematic error
+ from the measured values. The 95% confidence interval would be the
+ range from the 2.5th percentile to the 97.5th percentile of these
+ deviations from the true value. The calibration error "e" could then
+ be taken to be the largest absolute value of these two numbers, plus
+ the clock-related uncertainty. {Comment: as described, this bound is
+ relatively loose since the uncertainties are added, and the absolute
+ value of the largest deviation is used. As long as the resulting
+
+
+
+Almes, et al. Standards Track [Page 10]
+
+RFC 2679 A One-way Delay Metric for IPPM September 1999
+
+
+ value is not a significant fraction of the measured values, it is a
+ reasonable bound. If the resulting value is a significant fraction
+ of the measured values, then more exact methods will be needed to
+ compute the calibration error.}
+
+ Note that random error is a function of measurement load. For
+ example, if many paths will be measured by one instrument, this might
+ increase interrupts, process scheduling, and disk I/O (for example,
+ recording the measurements), all of which may increase the random
+ error in measured singletons. Therefore, in addition to minimal load
+ measurements to find the systematic error, calibration measurements
+ should be performed with the same measurement load that the
+ instruments will see in the field.
+
+ We wish to reiterate that this statistical treatment refers to the
+ calibration of the instrument; it is used to "calibrate the meter
+ stick" and say how well the meter stick reflects reality.
+
+ In addition to calibrating the instruments for finite one-way delay,
+ two checks should be made to ensure that packets reported as losses
+ were really lost. First, the threshold for loss should be verified.
+ In particular, ensure the "reasonable" threshold is reasonable: that
+ it is very unlikely a packet will arrive after the threshold value,
+ and therefore the number of packets lost over an interval is not
+ sensitive to the error bound on measurements. Second, consider the
+ possibility that a packet arrives at the network interface, but is
+ lost due to congestion on that interface or to other resource
+ exhaustion (e.g. buffers) in the instrument.
+
+3.8. Reporting the metric:
+
+ The calibration and context in which the metric is measured MUST be
+ carefully considered, and SHOULD always be reported along with metric
+ results. We now present four items to consider: the Type-P of test
+ packets, the threshold of infinite delay (if any), error calibration,
+ and the path traversed by the test packets. This list is not
+ exhaustive; any additional information that could be useful in
+ interpreting applications of the metrics should also be reported.
+
+3.8.1. Type-P
+
+ As noted in the Framework document [1], the value of the metric may
+ depend on the type of IP packets used to make the measurement, or
+ "type-P". The value of Type-P-One-way-Delay could change if the
+ protocol (UDP or TCP), port number, size, or arrangement for special
+ treatment (e.g., IP precedence or RSVP) changes. The exact Type-P
+ used to make the measurements MUST be accurately reported.
+
+
+
+
+Almes, et al. Standards Track [Page 11]
+
+RFC 2679 A One-way Delay Metric for IPPM September 1999
+
+
+3.8.2. Loss threshold
+
+ In addition, the threshold (or methodology to distinguish) between a
+ large finite delay and loss MUST be reported.
+
+3.8.3. Calibration results
+
+ + If the systematic error can be determined, it SHOULD be removed
+ from the measured values.
+
+ + You SHOULD also report the calibration error, e, such that the
+ true value is the reported value plus or minus e, with 95%
+ confidence (see the last section.)
+
+ + If possible, the conditions under which a test packet with finite
+ delay is reported as lost due to resource exhaustion on the
+ measurement instrument SHOULD be reported.
+
+3.8.4. Path
+
+ Finally, the path traversed by the packet SHOULD be reported, if
+ possible. In general it is impractical to know the precise path a
+ given packet takes through the network. The precise path may be
+ known for certain Type-P on short or stable paths. If Type-P
+ includes the record route (or loose-source route) option in the IP
+ header, and the path is short enough, and all routers* on the path
+ support record (or loose-source) route, then the path will be
+ precisely recorded. This is impractical because the route must be
+ short enough, many routers do not support (or are not configured for)
+ record route, and use of this feature would often artificially worsen
+ the performance observed by removing the packet from common-case
+ processing. However, partial information is still valuable context.
+ For example, if a host can choose between two links* (and hence two
+ separate routes from Src to Dst), then the initial link used is
+ valuable context. {Comment: For example, with Merit's NetNow setup,
+ a Src on one NAP can reach a Dst on another NAP by either of several
+ different backbone networks.}
+
+4. A Definition for Samples of One-way Delay
+
+ Given the singleton metric Type-P-One-way-Delay, we now define one
+ particular sample of such singletons. The idea of the sample is to
+ select a particular binding of the parameters Src, Dst, and Type-P,
+ then define a sample of values of parameter T. The means for
+ defining the values of T is to select a beginning time T0, a final
+ time Tf, and an average rate lambda, then define a pseudo-random
+
+
+
+
+
+Almes, et al. Standards Track [Page 12]
+
+RFC 2679 A One-way Delay Metric for IPPM September 1999
+
+
+ Poisson process of rate lambda, whose values fall between T0 and Tf.
+ The time interval between successive values of T will then average
+ 1/lambda.
+
+ {Comment: Note that Poisson sampling is only one way of defining a
+ sample. Poisson has the advantage of limiting bias, but other
+ methods of sampling might be appropriate for different situations.
+ We encourage others who find such appropriate cases to use this
+ general framework and submit their sampling method for
+ standardization.}
+
+4.1. Metric Name:
+
+ Type-P-One-way-Delay-Poisson-Stream
+
+4.2. Metric 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
+
+4.3. Metric Units:
+
+ A sequence of pairs; the elements of each pair are:
+
+ + T, a time, and
+
+ + dT, either a real number or an undefined number of seconds.
+
+ The values of T in the sequence are monotonic increasing. Note that
+ T would be a valid parameter to Type-P-One-way-Delay, and that dT
+ would be a valid value of Type-P-One-way-Delay.
+
+4.4. Definition:
+
+ Given T0, Tf, and lambda, we compute a pseudo-random Poisson process
+ beginning at or before T0, with average arrival rate lambda, and
+ ending at or after Tf. Those time values greater than or equal to T0
+ and less than or equal to Tf are then selected. At each of the times
+ in this process, we obtain the value of Type-P-One-way-Delay at this
+ time. The value of the sample is the sequence made up of the
+ resulting <time, delay> pairs. If there are no such pairs, the
+
+
+
+Almes, et al. Standards Track [Page 13]
+
+RFC 2679 A One-way Delay Metric for IPPM September 1999
+
+
+ sequence is of length zero and the sample is said to be empty.
+
+4.5. Discussion:
+
+ The reader should be familiar with the in-depth discussion of Poisson
+ sampling in the Framework document [1], which includes methods to
+ compute and verify the pseudo-random Poisson process.
+
+ We specifically do not constrain the value of lambda, except to note
+ the extremes. If the rate is too large, then the measurement traffic
+ will perturb the network, and itself cause congestion. If the rate
+ is too small, then you might not capture interesting network
+ behavior. {Comment: We expect to document our experiences with, and
+ suggestions for, lambda elsewhere, culminating in a "best current
+ practices" document.}
+
+ Since a pseudo-random number sequence is employed, the sequence of
+ times, and hence the value of the sample, is not fully specified.
+ Pseudo-random number generators of good quality will be needed to
+ achieve the desired qualities.
+
+ The sample is defined in terms of a Poisson process both to avoid the
+ effects of self-synchronization and also capture a sample that is
+ statistically as unbiased as possible. {Comment: there is, of
+ course, no claim that real Internet traffic arrives according to a
+ Poisson arrival process.} The Poisson process is used to schedule
+ the delay measurements. The test packets will generally not arrive
+ at Dst according to a Poisson distribution, since they are influenced
+ by the network.
+
+ All the singleton Type-P-One-way-Delay metrics in the sequence will
+ have the same values of Src, Dst, and Type-P.
+
+ Note also that, given one sample that runs from T0 to Tf, and given
+ new time values T0' and Tf' such that T0 <= T0' <= Tf' <= Tf, the
+ subsequence of the given sample whose time values fall between T0'
+ and Tf' are also a valid Type-P-One-way-Delay-Poisson-Stream sample.
+
+4.6. Methodologies:
+
+ The methodologies follow directly from:
+
+ + the selection of specific times, using the specified Poisson
+ arrival process, and
+
+ + the methodologies discussion already given for the singleton
+ Type-P-One-way-Delay metric.
+
+
+
+
+Almes, et al. Standards Track [Page 14]
+
+RFC 2679 A One-way Delay Metric for IPPM September 1999
+
+
+ Care must, of course, be given to correctly handle out-of-order
+ arrival of test packets; it is possible that the Src could send one
+ test packet at TS[i], then send a second one (later) at TS[i+1],
+ while the Dst could receive the second test packet at TR[i+1], and
+ then receive the first one (later) at TR[i].
+
+4.7. Errors and Uncertainties:
+
+ In addition to sources of errors and uncertainties associated with
+ methods employed to measure the singleton values that make up the
+ sample, care must be given to analyze the accuracy of the Poisson
+ process with respect to the wire-times of the sending of the test
+ packets. Problems with this process could be caused by several
+ things, including problems with the pseudo-random number techniques
+ used to generate the Poisson arrival process, or with jitter in the
+ value of Hsource (mentioned above as uncertainty in the singleton
+ delay metric). The Framework document shows how to use the
+ Anderson-Darling test to verify the accuracy of a Poisson process
+ over small time frames. {Comment: The goal is to ensure that test
+ packets are sent "close enough" to a Poisson schedule, and avoid
+ periodic behavior.}
+
+4.8. Reporting the metric:
+
+ You MUST report the calibration and context for the underlying
+ singletons along with the stream. (See "Reporting the metric" for
+ Type-P-One-way-Delay.)
+
+5. Some Statistics Definitions for One-way Delay
+
+ Given the sample metric Type-P-One-way-Delay-Poisson-Stream, we now
+ offer several statistics of that sample. These statistics are
+ offered mostly to be illustrative of what could be done.
+
+5.1. Type-P-One-way-Delay-Percentile
+
+ Given a Type-P-One-way-Delay-Poisson-Stream and a percent X between
+ 0% and 100%, the Xth percentile of all the dT values in the Stream.
+ In computing this percentile, undefined values are treated as
+ infinitely large. Note that this means that the percentile could
+ thus be undefined (informally, infinite). In addition, the Type-P-
+ One-way-Delay-Percentile is undefined if the sample is empty.
+
+
+
+
+
+
+
+
+
+Almes, et al. Standards Track [Page 15]
+
+RFC 2679 A One-way Delay Metric for IPPM September 1999
+
+
+ Example: suppose we take a sample and the results are:
+
+ Stream1 = <
+ <T1, 100 msec>
+ <T2, 110 msec>
+ <T3, undefined>
+ <T4, 90 msec>
+ <T5, 500 msec>
+ >
+
+ Then the 50th percentile would be 110 msec, since 90 msec and 100
+ msec are smaller and 110 msec and 'undefined' are larger.
+
+ Note that if the possibility that a packet with finite delay is
+ reported as lost is significant, then a high percentile (90th or
+ 95th) might be reported as infinite instead of finite.
+
+5.2. Type-P-One-way-Delay-Median
+
+ Given a Type-P-One-way-Delay-Poisson-Stream, the median of all the dT
+ values in the Stream. In computing the median, undefined values are
+ treated as infinitely large. As with Type-P-One-way-Delay-
+ Percentile, Type-P-One-way-Delay-Median is undefined if the sample is
+ empty.
+
+ As noted in the Framework document, the median differs from the 50th
+ percentile only when the sample contains an even number of values, in
+ which case the mean of the two central values is used.
+
+ Example: suppose we take a sample and the results are:
+
+ Stream2 = <
+ <T1, 100 msec>
+ <T2, 110 msec>
+ <T3, undefined>
+ <T4, 90 msec>
+ >
+
+ Then the median would be 105 msec, the mean of 100 msec and 110 msec,
+ the two central values.
+
+5.3. Type-P-One-way-Delay-Minimum
+
+ Given a Type-P-One-way-Delay-Poisson-Stream, the minimum of all the
+ dT values in the Stream. In computing this, undefined values are
+ treated as infinitely large. Note that this means that the minimum
+ could thus be undefined (informally, infinite) if all the dT values
+ are undefined. In addition, the Type-P-One-way-Delay-Minimum is
+
+
+
+Almes, et al. Standards Track [Page 16]
+
+RFC 2679 A One-way Delay Metric for IPPM September 1999
+
+
+ undefined if the sample is empty.
+
+ In the above example, the minimum would be 90 msec.
+
+5.4. Type-P-One-way-Delay-Inverse-Percentile
+
+ Given a Type-P-One-way-Delay-Poisson-Stream and a time duration
+ threshold, the fraction of all the dT values in the Stream less than
+ or equal to the threshold. The result could be as low as 0% (if all
+ the dT values exceed threshold) or as high as 100%. Type-P-One-way-
+ Delay-Inverse-Percentile is undefined if the sample is empty.
+
+ In the above example, the Inverse-Percentile of 103 msec would be
+ 50%.
+
+6. Security Considerations
+
+ Conducting Internet measurements raises both security and privacy
+ concerns. This memo does not specify an implementation of the
+ metrics, so it does not directly affect the security of the Internet
+ nor of applications which run on the Internet. However,
+ implementations of these metrics must be mindful of security and
+ privacy concerns.
+
+ There are two types of security concerns: potential harm caused by
+ the measurements, and potential harm to the measurements. The
+ measurements could cause harm because they are active, and inject
+ packets into the network. The measurement parameters MUST be
+ carefully selected so that the measurements inject trivial amounts of
+ additional traffic into the networks they measure. If they inject
+ "too much" traffic, they can skew the results of the measurement, and
+ in extreme cases cause congestion and denial of service.
+
+ The measurements themselves could be harmed by routers giving
+ measurement traffic a different priority than "normal" traffic, or by
+ an attacker injecting artificial measurement traffic. If routers can
+ recognize measurement traffic and treat it separately, the
+ measurements will not reflect actual user traffic. If an attacker
+ injects artificial traffic that is accepted as legitimate, the loss
+ rate will be artificially lowered. Therefore, the measurement
+ methodologies SHOULD include appropriate techniques to reduce the
+ probability measurement traffic can be distinguished from "normal"
+ traffic. Authentication techniques, such as digital signatures, may
+ be used where appropriate to guard against injected traffic attacks.
+
+ The privacy concerns of network measurement are limited by the active
+ measurements described in this memo. Unlike passive measurements,
+ there can be no release of existing user data.
+
+
+
+Almes, et al. Standards Track [Page 17]
+
+RFC 2679 A One-way Delay Metric for IPPM September 1999
+
+
+7. Acknowledgements
+
+ Special thanks are due to Vern Paxson of Lawrence Berkeley Labs for
+ his helpful comments on issues of clock uncertainty and statistics.
+ Thanks also to Garry Couch, Will Leland, Andy Scherrer, Sean Shapira,
+ and Roland Wittig for several useful suggestions.
+
+8. References
+
+ [1] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for
+ IP Performance Metrics", RFC 2330, May 1998.
+
+ [2] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Packet
+ Loss Metric for IPPM", RFC 2680, September 1999.
+
+ [3] Mills, D., "Network Time Protocol (v3)", RFC 1305, April 1992.
+
+ [4] Mahdavi J. and V. Paxson, "IPPM Metrics for Measuring
+ Connectivity", RFC 2678, September 1999.
+
+ [5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
+
+ [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [7] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+ 9, RFC 2026, October 1996.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Almes, et al. Standards Track [Page 18]
+
+RFC 2679 A One-way Delay Metric for IPPM September 1999
+
+
+9. Authors' Addresses
+
+ Guy Almes
+ Advanced Network & Services, Inc.
+ 200 Business Park Drive
+ Armonk, NY 10504
+ USA
+
+ Phone: +1 914 765 1120
+ EMail: almes@advanced.org
+
+
+ Sunil Kalidindi
+ Advanced Network & Services, Inc.
+ 200 Business Park Drive
+ Armonk, NY 10504
+ USA
+
+ Phone: +1 914 765 1128
+ EMail: kalidindi@advanced.org
+
+
+ Matthew J. Zekauskas
+ Advanced Network & Services, Inc.
+ 200 Business Park Drive
+ Armonk, NY 10504
+ USA
+
+ Phone: +1 914 765 1112
+ EMail: matt@advanced.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Almes, et al. Standards Track [Page 19]
+
+RFC 2679 A One-way Delay Metric for IPPM September 1999
+
+
+10. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Almes, et al. Standards Track [Page 20]
+