draft-ietf-ippm-delay-05.txt		draft-ietf-ippm-delay-06.txt
	Network Working Group G. Almes		Network Working Group G. Almes
	Internet Draft S. Kalidindi		Internet Draft S. Kalidindi
	Expiration Date: May 1999 M. Zekauskas		Expiration Date: August 1999 M. Zekauskas
	Advanced Network & Services		Advanced Network & Services
	November 1998		February 1999
	A One-way Delay Metric for IPPM		A One-way Delay Metric for IPPM
	<draft-ietf-ippm-delay-05.txt>		<draft-ietf-ippm-delay-06.txt>
	1. Status of this Memo		1. Status of this Memo
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft and is in full conformance with
	documents of the Internet Engineering Task Force (IETF), its areas,		all provisions of Section 10 of RFC2026.
	and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are working documents of the Internet Engineering
	months, and may be updated, replaced, or obsoleted by other documents		Task Force (IETF), its areas, and its working groups. Note that
	at any time. It is inappropriate to use Internet-Drafts as reference		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."		material or to cite them other than as "work in progress."
	To view the entire list of current Internet-Drafts, please check the		The list of current Internet-Drafts can be accessed at
	"1id-abstracts.txt" listing contained in the Internet-Drafts shadow		http://www.ietf.org/ietf/1id-abstracts.txt
	directories on ftp.is.co.za (Africa), nic.nordu.net (Northern
	Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific		The list of Internet-Draft shadow directories can be accessed at
	Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).		http://www.ietf.org/shadow.html
	This memo provides information for the Internet community. This memo		This memo provides information for the Internet community. This memo
	does not specify an Internet standard of any kind. Distribution of		does not specify an Internet standard of any kind. Distribution of
	this memo is unlimited.		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 Packet Loss Metric for IPPM"
	<draft-ietf-ippm-loss-05.txt>) [2].		<draft-ietf-ippm-loss-06.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 3, line 41		skipping to change at page 3, line 42
	direction may be radically different than provisioning in the		direction may be radically different than provisioning in the
	reverse direction, and thus the QoS guarantees differ. Measuring		reverse direction, and thus the QoS guarantees differ. Measuring
	the paths independently allows the verification of both		the paths independently allows the verification of both
	guarantees.		guarantees.
	It is outside the scope of this document to say precisely how delay		It is outside the scope of this document to say precisely how delay
	metrics would be applied to specific problems.		metrics would be applied to specific problems.
	2.2. General Issues Regarding Time		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		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.		of the clock on a second host. {Comment: A rough ITU-T
			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. For
	example, the clock on a host might be 27.1 msec behind UTC.		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*		resolution*
	measures the precision of a given clock. For example, the clock		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		on an old Unix host might tick only once every 10 msec, and thus
	have a resolution of only 10 msec.		have a resolution of only 10 msec. {Comment: A very 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 relative
	to UTC, which threatens accuracy. We might also speak of the		to UTC, which threatens accuracy. We might also speak of the
	skew of one clock relative to another clock, which threatens		skew of one clock relative to another clock, which threatens
	synchronization.		synchronization. {Comment: A rough ITU-T equivalent 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 18, line 28		skipping to change at page 19, line 9
	be used where appropriate to guard against injected traffic attacks.		be used where appropriate to guard against injected traffic attacks.
	The privacy concerns of network measurement are limited by the active		The privacy concerns of network measurement are limited by the active
	measurements described in this memo. Unlike passive measurements,		measurements described in this memo. Unlike passive measurements,
	there can be no release of existing user data.		there can be no release of existing user data.
	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 Will Leland, Andy Scherrer, Sean Shapira, and		Thanks also to Garry Couch, Will Leland, Andy Scherrer, Sean Shapira,
	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 Packet Loss Metric		[2] G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Packet Loss
	for IPPM", Internet-Draft <draft-ietf-ippm-loss-05.txt>, August		Metric for IPPM", Internet-Draft <draft-ietf-ippm-loss-06.txt>,
	1998.		February 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", Internet-Draft <draft-ietf-ippm-		Connectivity", RFC 2498, January 1999.
	connectivity-03.txt>, October 1998.
	[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.
			[7] S. Bradner, "The Internet Standards Process -- Revision 3", 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
	EMail: almes@advanced.org		EMail: almes@advanced.org
	skipping to change at page 19, line 34		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: May, 1999		Expiration date: August, 1999
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/