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/