draft-ietf-ippm-delay-07.txt   rfc2679.txt 
Network Working Group G. Almes Network Working Group G. Almes
Internet Draft S. Kalidindi Request for Comments: 2679 S. Kalidindi
Expiration Date: November 1999 M. Zekauskas Category: Standards Track M. Zekauskas
Advanced Network & Services Advanced Network & Services
May 1999 September 1999
A One-way Delay Metric for IPPM A One-way Delay Metric for IPPM
<draft-ietf-ippm-delay-07.txt>
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet-Drafts are working documents of the Internet Engineering Official Protocol Standards" (STD 1) for the standardization state
Task Force (IETF), its areas, and its working groups. Note that and status of this protocol. Distribution of this memo is unlimited.
other groups may also distribute working documents as Internet-
Drafts.
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
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft shadow directories can be accessed at Copyright Notice
http://www.ietf.org/shadow.html
This memo provides information for the Internet community. This memo Copyright (C) The Internet Society (1999). All Rights Reserved.
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
2. Introduction 2. Introduction
This memo defines a metric for one-way delay of packets across This memo defines a metric for one-way delay of packets across
Internet paths. It builds on notions introduced and discussed in the Internet paths. It builds on notions introduced and discussed in the
IPPM Framework document, RFC 2330 [1]; the reader is assumed to be IPPM Framework document, RFC 2330 [1]; the reader is assumed to be
familiar with that document. familiar with that document.
This memo is intended to be parallel in structure to a companion This memo is intended to be parallel in structure to a companion
document for Packet Loss ("A Packet Loss Metric for IPPM" document for Packet Loss ("A One-way Packet Loss Metric for IPPM")
<draft-ietf-ippm-loss-07.txt>) [2]. [2].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [6]. document are to be interpreted as described in RFC 2119 [6].
Although RFC 2119 was written with protocols in mind, the key words Although RFC 2119 was written with protocols in mind, the key words
are used in this document for similar reasons. They are used to are used in this document for similar reasons. They are used to
ensure the results of measurements from two different implementations ensure the results of measurements from two different implementations
are comparable, and to note instances when an implementation could are comparable, and to note instances when an implementation could
perturb the network. perturb the network.
skipping to change at page 4, line 17 skipping to change at page 4, line 7
denotes a frequency reference.} denotes a frequency reference.}
Whenever a time (i.e., a moment in history) is mentioned here, it is 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. understood to be measured in seconds (and fractions) relative to UTC.
As described more fully in the Framework document, there are four As described more fully in the Framework document, there are four
distinct, but related notions of clock uncertainty: distinct, but related notions of clock uncertainty:
synchronization* synchronization*
measures the extent to which two clocks agree on what time it 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 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 of the clock on a second host. {Comment: A rough ITU-T
equivalent is "time error".} equivalent is "time error".}
accuracy* accuracy*
measures the extent to which a given clock agrees with UTC. For measures the extent to which a given clock agrees with UTC.
example, the clock on a host might be 27.1 msec behind 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".} {Comment: A rough ITU-T equivalent is "time error from UTC".}
resolution* resolution*
measures the precision of a given clock. For example, the clock measures the precision of a given clock. For example, the
on an old Unix host might tick only once every 10 msec, and thus clock on an old Unix host might tick only once every 10 msec,
have a resolution of only 10 msec. {Comment: A very rough ITU-T and thus have a resolution of only 10 msec. {Comment: A very
equivalent is "sampling period".} rough ITU-T equivalent is "sampling period".}
skew* skew*
measures the change of accuracy, or of synchronization, with measures the change of accuracy, or of synchronization, with
time. For example, the clock on a given host might gain 1.3 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 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 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 clock of the given host has a skew of 1.3 msec per hour
to UTC, which threatens accuracy. We might also speak of the relative to UTC, which threatens accuracy. We might also speak
skew of one clock relative to another clock, which threatens of the skew of one clock relative to another clock, which
synchronization. {Comment: A rough ITU-T equivalent is "time threatens synchronization. {Comment: A rough ITU-T equivalent
drift".} is "time drift".}
3. A Singleton Definition for One-way Delay 3. A Singleton Definition for One-way Delay
3.1. Metric Name: 3.1. Metric Name:
Type-P-One-way-Delay Type-P-One-way-Delay
3.2. Metric Parameters: 3.2. Metric Parameters:
+ Src, the IP address of a host + Src, the IP address of a host
skipping to change at page 5, line 32 skipping to change at page 5, line 18
undefined (informally, infinite) number of seconds. undefined (informally, infinite) number of seconds.
3.4. Definition: 3.4. Definition:
For a real number dT, >>the *Type-P-One-way-Delay* from Src to Dst at 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 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 at wire-time* T and that Dst received the last bit of that packet at
wire-time T+dT. wire-time T+dT.
>>The *Type-P-One-way-Delay* from Src to Dst at T is undefined >>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- (informally, infinite)<< means that Src sent the first bit of a
P packet to Dst at wire-time T and that Dst did not receive that Type-P packet to Dst at wire-time T and that Dst did not receive that
packet. packet.
Suggestions for what to report along with metric values appear in Suggestions for what to report along with metric values appear in
Section 3.8 after a discussion of the metric, methodologies for Section 3.8 after a discussion of the metric, methodologies for
measuring the metric, and error analysis. measuring the metric, and error analysis.
3.5. Discussion: 3.5. Discussion:
Type-P-One-way-Delay is a relatively simple analytic metric, and one Type-P-One-way-Delay is a relatively simple analytic metric, and one
that we believe will afford effective methods of measurement. that we believe will afford effective methods of measurement.
skipping to change at page 6, line 26 skipping to change at page 6, line 5
stability and symmetry of delay properties among those NTP agents stability and symmetry of delay properties among those NTP agents
used, and this delay is what we are trying to measure. A used, and this delay is what we are trying to measure. A
combination of some GPS-based NTP servers and a conservatively combination of some GPS-based NTP servers and a conservatively
designed and deployed set of other NTP servers should yield good designed and deployed set of other NTP servers should yield good
results, but this is yet to be tested. results, but this is yet to be tested.
+ A given methodology will have to include a way to determine + A given methodology will have to include a way to determine
whether a delay value is infinite or whether it is merely very 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 large (and the packet is yet to arrive at Dst). As noted by
Mahdavi and Paxson [4], simple upper bounds (such as the 255 Mahdavi and Paxson [4], simple upper bounds (such as the 255
seconds theoretical upper bound on the lifetimes of IP seconds theoretical upper bound on the lifetimes of IP packets
packets [5]) could be used, but good engineering, including an [5]) could be used, but good engineering, including an
understanding of packet lifetimes, will be needed in practice. 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 harm in treating a large delay as infinite might be zero or very
small. A TCP data packet, for example, that arrives only after 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.}
+ If the packet is duplicated along the path (or paths) so that + If the packet is duplicated along the path (or paths) so that
multiple non-corrupt copies arrive at the destination, then the multiple non-corrupt copies arrive at the destination, then the
packet is counted as received, and the first copy to arrive packet is counted as received, and the first copy to arrive
determines the packet's one-way delay. determines the packet's one-way delay.
skipping to change at page 10, line 11 skipping to change at page 9, line 36
and host time on the Src host, and similarly define Hdest for the Dst 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 host. We then note that these problems introduce a total uncertainty
of Hsource+Hdest. This estimate of total wire-vs-host uncertainty of Hsource+Hdest. This estimate of total wire-vs-host uncertainty
should be included in the error/uncertainty analysis of any should be included in the error/uncertainty analysis of any
measurement implementation. measurement implementation.
3.7.3. Calibration 3.7.3. Calibration
Generally, the measured values can be decomposed as follows: Generally, the measured values can be decomposed as follows:
measured value = true value + systematic error + random error measured value = true value + systematic error + random error
If the systematic error (the constant bias in measured values) can be If the systematic error (the constant bias in measured values) can be
determined, it can be compensated for in the reported results. determined, it can be compensated for in the reported results.
reported value = measured value - systematic error reported value = measured value - systematic error
therefore therefore
reported value = true value + random error reported value = true value + random error
The goal of calibration is to determine the systematic and random The goal of calibration is to determine the systematic and random
error generated by the instruments themselves in as much detail as error generated by the instruments themselves in as much detail as
possible. At a minimum, a bound ("e") should be found such that the 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) 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 at least 95 percent of the time. We call "e" the calibration error
for the measurements. It represents the degree to which the values for the measurements. It represents the degree to which the values
produced by the measurement instrument are repeatable; that is, how produced by the measurement instrument are repeatable; that is, how
closely an actual delay of 30 ms is reported as 30 ms. {Comment: 95 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 percent was chosen because (1) some confidence level is desirable to
be able to remove outliers which will be found in measuring any be able to remove outliers, which will be found in measuring any
physical property; (2) a particular confidence level should be physical property; (2) a particular confidence level should be
specified so that the results of independent implementations can be specified so that the results of independent implementations can be
compared; and (3) even with a prototype user-level implementation, compared; and (3) even with a prototype user-level implementation,
95% was loose enough to exclude outliers.} 95% was loose enough to exclude outliers.}
From the discussion in the previous two sections, the error in From the discussion in the previous two sections, the error in
measurements could be bounded by determining all the individual measurements could be bounded by determining all the individual
uncertainties, and adding them together to form uncertainties, and adding them together to form
Esynch(t) + Rsource + Rdest + Hsource + Hdest. Esynch(t) + Rsource + Rdest + Hsource + Hdest.
However, reasonable bounds on both the clock-related uncertainty However, reasonable bounds on both the clock-related uncertainty
captured by the first three terms and the host-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 captured by the last two terms should be possible by careful design
techniques and calibrating the instruments using a known, isolated, techniques and calibrating the instruments using a known, isolated,
network in a lab. network in a lab.
For example, the clock-related uncertainties are greatly reduced For example, the clock-related uncertainties are greatly reduced
through the use of a GPS time source. The sum of Esynch(t) + Rsource 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 + Rdest is small, and is also bounded for the duration of the
measurement because of the global time source. measurement because of the global time source.
skipping to change at page 15, line 37 skipping to change at page 14, line 49
subsequence of the given sample whose time values fall between T0' 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. and Tf' are also a valid Type-P-One-way-Delay-Poisson-Stream sample.
4.6. Methodologies: 4.6. Methodologies:
The methodologies follow directly from: The methodologies follow directly from:
+ the selection of specific times, using the specified Poisson + the selection of specific times, using the specified Poisson
arrival process, and arrival process, and
+ the methodologies discussion already given for the singleton Type- + the methodologies discussion already given for the singleton
P-One-way-Delay metric. Type-P-One-way-Delay metric.
Care must, of course, be given to correctly handle out-of-order 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 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], 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 while the Dst could receive the second test packet at TR[i+1], and
then receive the first one (later) at TR[i]. then receive the first one (later) at TR[i].
4.7. Errors and Uncertainties: 4.7. Errors and Uncertainties:
In addition to sources of errors and uncertainties associated with In addition to sources of errors and uncertainties associated with
methods employed to measure the singleton values that make up the methods employed to measure the singleton values that make up the
sample, care must be given to analyze the accuracy of the Poisson 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 process with respect to the wire-times of the sending of the test
packets. Problems with this process could be caused by several packets. Problems with this process could be caused by several
things, including problems with the pseudo-random number techniques things, including problems with the pseudo-random number techniques
used to generate the Poisson arrival process, or with jitter in the used to generate the Poisson arrival process, or with jitter in the
value of Hsource (mentioned above as uncertainty in the singleton value of Hsource (mentioned above as uncertainty in the singleton
delay metric). The Framework document shows how to use the Anderson- delay metric). The Framework document shows how to use the
Darling test to verify the accuracy of a Poisson process over small Anderson-Darling test to verify the accuracy of a Poisson process
time frames. {Comment: The goal is to ensure that test packets are over small time frames. {Comment: The goal is to ensure that test
sent "close enough" to a Poisson schedule, and avoid periodic packets are sent "close enough" to a Poisson schedule, and avoid
behavior.} periodic behavior.}
4.8. Reporting the metric: 4.8. Reporting the metric:
You MUST report the calibration and context for the underlying You MUST report the calibration and context for the underlying
singletons along with the stream. (See "Reporting the metric" for singletons along with the stream. (See "Reporting the metric" for
Type-P-One-way-Delay.) Type-P-One-way-Delay.)
5. Some Statistics Definitions for One-way Delay 5. Some Statistics Definitions for One-way Delay
Given the sample metric Type-P-One-way-Delay-Poisson-Stream, we now Given the sample metric Type-P-One-way-Delay-Poisson-Stream, we now
skipping to change at page 17, line 26 skipping to change at page 16, line 35
values in the Stream. In computing the median, undefined values are values in the Stream. In computing the median, undefined values are
treated as infinitely large. As with Type-P-One-way-Delay- treated as infinitely large. As with Type-P-One-way-Delay-
Percentile, Type-P-One-way-Delay-Median is undefined if the sample is Percentile, Type-P-One-way-Delay-Median is undefined if the sample is
empty. empty.
As noted in the Framework document, the median differs from the 50th As noted in the Framework document, the median differs from the 50th
percentile only when the sample contains an even number of values, in percentile only when the sample contains an even number of values, in
which case the mean of the two central values is used. which case the mean of the two central values is used.
Example: suppose we take a sample and the results are: Example: suppose we take a sample and the results are:
Stream2 = <
Stream2 = <
<T1, 100 msec> <T1, 100 msec>
<T2, 110 msec> <T2, 110 msec>
<T3, undefined> <T3, undefined>
<T4, 90 msec> <T4, 90 msec>
> >
Then the median would be 105 msec, the mean of 100 msec and 110 msec, Then the median would be 105 msec, the mean of 100 msec and 110 msec,
the two central values. the two central values.
5.3. Type-P-One-way-Delay-Minimum 5.3. Type-P-One-way-Delay-Minimum
Given a Type-P-One-way-Delay-Poisson-Stream, the minimum of all the 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 dT values in the Stream. In computing this, undefined values are
treated as infinitely large. Note that this means that the minimum treated as infinitely large. Note that this means that the minimum
could thus be undefined (informally, infinite) if all the dT values could thus be undefined (informally, infinite) if all the dT values
are undefined. In addition, the Type-P-One-way-Delay-Minimum is are undefined. In addition, the Type-P-One-way-Delay-Minimum is
skipping to change at page 19, line 14 skipping to change at page 18, line 14
7. Acknowledgements 7. Acknowledgements
Special thanks are due to Vern Paxson of Lawrence Berkeley Labs for Special thanks are due to Vern Paxson of Lawrence Berkeley Labs for
his helpful comments on issues of clock uncertainty and statistics. his helpful comments on issues of clock uncertainty and statistics.
Thanks also to Garry Couch, Will Leland, Andy Scherrer, Sean Shapira, Thanks also to Garry Couch, Will Leland, Andy Scherrer, Sean Shapira,
and Roland Wittig for several useful suggestions. and Roland Wittig for several useful suggestions.
8. References 8. References
[1] V. Paxson, G. Almes, J. Mahdavi, and M. Mathis, "Framework for [1] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for
IP Performance Metrics", RFC 2330, May 1998. IP Performance Metrics", RFC 2330, May 1998.
[2] G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Packet Loss [2] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Packet
Metric for IPPM", Internet-Draft <draft-ietf-ippm-loss-07.txt>, Loss Metric for IPPM", RFC 2680, September 1999.
May 1999.
[3] D. Mills, "Network Time Protocol (v3)", RFC 1305, April 1992. [3] Mills, D., "Network Time Protocol (v3)", RFC 1305, April 1992.
[4] J. Mahdavi and V. Paxson, "IPPM Metrics for Measuring [4] Mahdavi J. and V. Paxson, "IPPM Metrics for Measuring
Connectivity", RFC 2498, January 1999. Connectivity", RFC 2678, September 1999.
[5] J. Postel, "Internet Protocol", RFC 791, September 1981. [5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[6] S. Bradner, "Key words for use in RFCs to Indicate Requirement [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[7] S. Bradner, "The Internet Standards Process -- Revision 3", RFC [7] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
2026, October 1996. 9, RFC 2026, October 1996.
9. Authors' Addresses 9. Authors' Addresses
Guy Almes Guy Almes
Advanced Network & Services, Inc. Advanced Network & Services, Inc.
200 Business Park Drive 200 Business Park Drive
Armonk, NY 10504 Armonk, NY 10504
USA USA
Phone: +1 914 765 1120 Phone: +1 914 765 1120
skipping to change at page 20, line 15 skipping to change at page 19, line 27
Advanced Network & Services, Inc. Advanced Network & Services, Inc.
200 Business Park Drive 200 Business Park Drive
Armonk, NY 10504 Armonk, NY 10504
USA USA
Phone: +1 914 765 1128 Phone: +1 914 765 1128
EMail: kalidindi@advanced.org EMail: kalidindi@advanced.org
Matthew J. Zekauskas Matthew J. Zekauskas
Advanced Network & Services, Inc. Advanced Network & Services, Inc.
200 Buisiness Park Drive 200 Business Park Drive
Armonk, NY 10504 Armonk, NY 10504
USA USA
Phone: +1 914 765 1112 Phone: +1 914 765 1112
EMail: matt@advanced.org EMail: matt@advanced.org
Expiration date: November, 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.
 End of changes. 33 change blocks. 
75 lines changed or deleted 65 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/