< draft-ietf-ippm-delay-06.txt   draft-ietf-ippm-delay-07.txt >
Network Working Group G. Almes Network Working Group G. Almes
Internet Draft S. Kalidindi Internet Draft S. Kalidindi
Expiration Date: August 1999 M. Zekauskas Expiration Date: November 1999 M. Zekauskas
Advanced Network & Services Advanced Network & Services
February 1999 May 1999
A One-way Delay Metric for IPPM A One-way Delay Metric for IPPM
<draft-ietf-ippm-delay-06.txt> <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 is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 46 skipping to change at page 1, line 45
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 Packet Loss Metric for IPPM"
<draft-ietf-ippm-loss-06.txt>) [2]. <draft-ietf-ippm-loss-07.txt>) [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 5, line 21 skipping to change at page 5, line 21
3.2. Metric Parameters: 3.2. Metric Parameters:
+ Src, the IP address of a host + Src, the IP address of a host
+ Dst, the IP address of a host + Dst, the IP address of a host
+ T, a time + T, a time
3.3. Metric Units: 3.3. Metric Units:
The value of a Type-P-One-way-Delay is either a non-negative real The value of a Type-P-One-way-Delay is either a real number, or an
number, or an undefined (informally, infinite) number of seconds. undefined (informally, infinite) number of seconds.
3.4. Definition: 3.4. Definition:
For a non-negative real number dT, >>the *Type-P-One-way-Delay* from For a real number dT, >>the *Type-P-One-way-Delay* from Src to Dst at
Src to Dst at T is dT<< means that Src sent the first bit of a Type-P T is dT<< means that Src sent the first bit of a Type-P packet to Dst
packet to Dst at wire-time* T and that Dst received the last bit of at wire-time* T and that Dst received the last bit of that packet at
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 Type-
P packet to Dst at wire-time T and that Dst did not receive that 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.
The following issues are likely to come up in practice: 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 + 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 range, it will be important for Src and Dst to synchronize very
closely. GPS systems afford one way to achieve synchronization to closely. GPS systems afford one way to achieve synchronization to
within several 10s of usec. Ordinary application of NTP may allow within several 10s of usec. Ordinary application of NTP may allow
synchronization to within several msec, but this depends on the synchronization to within several msec, but this depends on the
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.
skipping to change at page 14, line 23 skipping to change at page 14, line 23
+ Tf, a time + Tf, a time
+ lambda, a rate in reciprocal seconds + lambda, a rate in reciprocal seconds
4.3. Metric Units: 4.3. Metric Units:
A sequence of pairs; the elements of each pair are: A sequence of pairs; the elements of each pair are:
+ T, a time, and + T, a time, and
+ dT, either a non-negative real number or an undefined number of + dT, either a real number or an undefined number of seconds.
seconds.
The values of T in the sequence are monotonic increasing. Note that 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 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. would be a valid value of Type-P-One-way-Delay.
4.4. Definition: 4.4. Definition:
Given T0, Tf, and lambda, we compute a pseudo-random Poisson process Given T0, Tf, and lambda, we compute a pseudo-random Poisson process
beginning at or before T0, with average arrival rate lambda, and 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 ending at or after Tf. Those time values greater than or equal to T0
skipping to change at page 18, line 7 skipping to change at page 18, line 7
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
undefined if the sample is empty. undefined if the sample is empty.
In the above example, the minimum would be 90 msec. In the above example, the minimum would be 90 msec.
5.4. Type-P-One-way-Delay-Inverse-Percentile 5.4. Type-P-One-way-Delay-Inverse-Percentile
Given a Type-P-One-way-Delay-Poisson-Stream and a non-negative time Given a Type-P-One-way-Delay-Poisson-Stream and a time duration
duration threshold, the fraction of all the dT values in the Stream threshold, the fraction of all the dT values in the Stream less than
less than or equal to the threshold. The result could be as low as or equal to the threshold. The result could be as low as 0% (if all
0% (if all the dT values exceed threshold) or as high as 100%. Type- the dT values exceed threshold) or as high as 100%. Type-P-One-way-
P-One-way-Delay-Inverse-Percentile is undefined if the sample is Delay-Inverse-Percentile is undefined if the sample is empty.
empty.
In the above example, the Inverse-Percentile of 103 msec would be In the above example, the Inverse-Percentile of 103 msec would be
50%. 50%.
6. Security Considerations 6. Security Considerations
Conducting Internet measurements raises both security and privacy Conducting Internet measurements raises both security and privacy
concerns. This memo does not specify an implementation of the concerns. This memo does not specify an implementation of the
metrics, so it does not directly affect the security of the Internet metrics, so it does not directly affect the security of the Internet
nor of applications which run on the Internet. However, nor of applications which run on the Internet. However,
skipping to change at page 19, line 18 skipping to change at page 19, line 18
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] V. Paxson, G. Almes, J. Mahdavi, 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] G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Packet Loss
Metric for IPPM", Internet-Draft <draft-ietf-ippm-loss-06.txt>, Metric for IPPM", Internet-Draft <draft-ietf-ippm-loss-07.txt>,
February 1999. May 1999.
[3] D. Mills, "Network Time Protocol (v3)", RFC 1305, April 1992. [3] D. Mills, "Network Time Protocol (v3)", RFC 1305, April 1992.
[4] J. Mahdavi and V. Paxson, "IPPM Metrics for Measuring [4] J. Mahdavi and V. Paxson, "IPPM Metrics for Measuring
Connectivity", RFC 2498, January 1999. Connectivity", RFC 2498, January 1999.
[5] J. Postel, "Internet Protocol", RFC 791, September 1981. [5] J. Postel, "Internet Protocol", RFC 791, September 1981.
[6] S. Bradner, "Key words for use in RFCs to Indicate Requirement [6] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997. Levels", RFC 2119, March 1997.
skipping to change at page 20, line 22 skipping to change at page 20, line 22
Matthew J. Zekauskas Matthew J. Zekauskas
Advanced Network & Services, Inc. Advanced Network & Services, Inc.
200 Buisiness Park Drive 200 Buisiness 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: August, 1999 Expiration date: November, 1999
 End of changes. 12 change blocks. 
21 lines changed or deleted 24 lines changed or added

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