< draft-ietf-ippm-loss-06.txt		draft-ietf-ippm-loss-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 Packet Loss Metric for IPPM		A One-way Packet Loss Metric for IPPM
	<draft-ietf-ippm-loss-06.txt>		<draft-ietf-ippm-loss-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 packet loss across Internet		This memo defines a metric for one-way packet loss across Internet
	paths. It builds on notions introduced and discussed in the IPPM		paths. It builds on notions introduced and discussed in the IPPM
	Framework document, RFC 2330 [1]; the reader is assumed to be		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 One-way Delay (currently "A One-way Delay Metric for		document for One-way Delay (currently "A One-way Delay Metric for
	IPPM" <draft-ietf-ippm-delay-06.txt>) [2]; the reader is assumed to		IPPM" <draft-ietf-ippm-delay-07.txt>) [2]; the reader is assumed to
	be familiar with that document.		be familiar with that document.
	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 [5].		document are to be interpreted as described in RFC 2119 [5].
	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 38 ¶		skipping to change at page 5, line 38 ¶
	that Src sent the first bit of a Type-P packet to Dst at wire-time* T		that Src sent the first bit of a Type-P packet to Dst at wire-time* T
	and that Dst received that packet.		and that Dst received that packet.
	>>The *Type-P-One-way-Packet-Loss* from Src to Dst at T is 1<< means		>>The *Type-P-One-way-Packet-Loss* from Src to Dst at T is 1<< means
	that Src sent the first bit of a type-P packet to Dst at wire-time T		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.		and that Dst did not receive that packet.
	3.5. Discussion:		3.5. Discussion:
	Thus, Type-P-One-way-Packet-Loss is 0 exactly when Type-P-One-way-		Thus, Type-P-One-way-Packet-Loss is 0 exactly when Type-P-One-way-
	Delay is a finite positive value, and it is 1 exactly when Type-P-		Delay is a finite value, and it is 1 exactly when Type-P-One-way-
	One-way-Delay is undefined.		Delay is undefined.
	The following issues are likely to come up in practice:		The following issues are likely to come up in practice:
	+ A given methodology will have to include a way to distinguish		+ A given methodology will have to include a way to distinguish
	between a packet loss and a very large (but finite) delay. As		between a packet loss and a very large (but finite) delay. As
	noted by Mahdavi and Paxson [3], simple upper bounds (such as the		noted by Mahdavi and Paxson [3], simple upper bounds (such as the
	255 seconds theoretical upper bound on the lifetimes of IP		255 seconds theoretical upper bound on the lifetimes of IP
	packets [4]) could be used, but good engineering, including an		packets [4]) 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, there		{Comment: Note that, for many applications of these metrics, there
	skipping to change at page 15, line 11 ¶		skipping to change at page 15, line 11 ¶
	Thanks are due also to Vern Paxson for his valuable comments on early		Thanks are due also to Vern Paxson for his valuable comments on early
	drafts, and to Garry Couch and Will Leland for several useful		drafts, and to Garry Couch and Will Leland for several useful
	suggestions.		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 Delay		[2] G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Delay
	Metric for IPPM", Internet-Draft <draft-ietf-ippm-delay-06.txt>,		Metric for IPPM", Internet-Draft <draft-ietf-ippm-delay-07.txt>,
	February, 1999.		May, 1999.
	[3] J. Mahdavi and V. Paxson, "IPPM Metrics for Measuring		[3] J. Mahdavi and V. Paxson, "IPPM Metrics for Measuring
	Connectivity", RFC 2498, January 1999.		Connectivity", RFC 2498, January 1999.
	[4] J. Postel, "Internet Protocol", RFC 791, September 1981.		[4] J. Postel, "Internet Protocol", RFC 791, September 1981.
	[5] S. Bradner, "Key words for use in RFCs to Indicate Requirement		[5] 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		[7] S. Bradner, "The Internet Standards Process -- Revision 3", RFC
	skipping to change at page 16, line 13 ¶		skipping to change at page 16, line 13 ¶
	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 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. 8 change blocks.
	9 lines changed or deleted		8 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/