draft-ietf-ippm-npmps-02.txt		draft-ietf-ippm-npmps-03.txt
	Network Working Group V. Raisanen		Network Working Group V. Raisanen
	INTERNET-DRAFT Nokia		INTERNET-DRAFT Nokia
	Expiration Date: January 2001 G. Grotefeld		Expiration Date: May 2001 G. Grotefeld
	Motorola		Motorola
	July 2000		November 2000
	Network performance measurement for periodic streams		Network performance measurement for periodic streams
	<draft-ietf-ippm-npmps-02.txt>		<draft-ietf-ippm-npmps-03.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 line 37		skipping to change at line 37
	The list of Internet-Draft shadow directories can be accessed at		The list of Internet-Draft shadow directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	This memo provides information for the Internet community. This		This memo provides information for the Internet community. This
	memo does not specify an Internet standard of any		memo does not specify an Internet standard of any
	kind. Distribution of this memo is unlimited.		kind. Distribution of this memo is unlimited.
	2. Abstract		2. Abstract
	This document describes some of the issues associated with		This document describes a sample metric suitable for application-
	application-level measurements of network performance for periodic		level IP network transport measurement for periodic streams, such as
	streams. An example application would be the testing of Dst-Src routes		VoIP or streaming multimedia over IP. In this document, the reader
	for use as bearer for multimedia streams. In this document,		is assumed to be familiar with the terminology of the Framework for
	the reader is assumed to be familiar with the terminology of the		IP Performance Metrics RFC 2330 [1]. This document is parallel to
	Framework for IP Performance Metrics RFC 2330 [1]. This document is		A One-way Delay Metric for IPPM RFC 2679 [2]. Although this document
	parallel to A One-way Delay Metric for IPPM RFC 2679 [2]. A sample		is based on the delay metrics, other characteristics can be measured
	metric is described that is suitable for application-level measurement		with this approach, too. For example, packet loss rate, reordering /
	for streaming multimedia over IP. Using such a measurement,		out-of sequence, and successive delay variation are all additional
	transmission service of a network is probed with a traffic stream		metrics which can be built from this baseline set of measurements.
	similar to that of the application of interest, which is likely to be
	very dissimilar to the Poisson inter-arrival interval described in [2].
	Raisanen, Grotefeld expires January 2001 [Page 1]		Raisanen, Grotefeld expires May 2001 [Page 1]
	3. Introduction		3. Introduction
	This document discusses concepts relevant to application-level		This document discusses concepts relevant to application-level
	performance measurements of an IP network. The original driver for		performance measurements of an IP network. The original driver for
	this work is Quality of Service of interactive periodic streams such		this work is Quality of Service of interactive periodic streams such
	as multimedia conference over IP, but the idea of application-level		as multimedia conference over IP, but the idea of application-level
	measurement may have a wider scope. In the following, interactive		measurement may have a wider scope. In the following, interactive
	multimedia traffic is used as an example to illustrate the concept.		multimedia traffic is used as an example to illustrate the concept.
	skipping to change at line 96		skipping to change at line 94
	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 [4].		document are to be interpreted as described in RFC 2119 [4].
	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.
	Raisanen, Grotefeld expires January 2001 [Page 2]		Raisanen, Grotefeld expires May 2001 [Page 2]
	3.2 Considerations related to delay		3.2 Considerations related to delay
	For interactive multimedia sessions, end-to-end delay is an		For interactive multimedia sessions, end-to-end delay is an
	important factor. Too large a delay reduces the quality of the		important factor. Too large a delay reduces the quality of the
	multimedia session as perceived by the participants. One approach for		multimedia session as perceived by the participants. One approach for
	managing end-to-end delays on an Internet path involving		managing end-to-end delays on an Internet path involving
	heterogeneous link layer technologies is to use per-domain delay		heterogeneous link layer technologies is to use per-domain delay
	quotas (e.g. 50 ms for a particular IP domain). The 50 ms would		quotas (e.g. 50 ms for a particular IP domain). The 50 ms would
	then be included into a calculation of an end-to-end delay bound. A		then be included into a calculation of an end-to-end delay bound. A
	skipping to change at line 134		skipping to change at line 132
	could study the quality of a cheap, low-guarantee service		could study the quality of a cheap, low-guarantee service
	implemented using possible slack bandwidth in other classes. Such		implemented using possible slack bandwidth in other classes. Such
	measurements could be made either in studying the feasibility of a		measurements could be made either in studying the feasibility of a
	new service, or on a regular basis.		new service, or on a regular basis.
	The present draft seeks to formalize the measurements in such a way		The present draft seeks to formalize the measurements in such a way
	that interoperable results are achieved.		that interoperable results are achieved.
	3.3 Protocol level issues		3.3 Protocol level issues
			The version of the Internet Protocol used in the measurement affects
			(at least) packet sizes, and should be reported.
	Fig.1 illustrates measurements on multiple protocol levels that		Fig.1 illustrates measurements on multiple protocol levels that
	are relevant to this draft. The major focus of the present draft		are relevant to this draft. The major focus of the present draft
	is on transport quality evaluation from application point of		is on transport quality evaluation from application point of
	view. However, to properly account for quality effects of, e.g.,		view. However, to properly account for quality effects of, e.g.,
	operating system and codec on packet voice, it is beneficial to be		operating system and codec on packet voice, it is beneficial to be
	able to measure quality at IP level [5]. Link layer monitoring		able to measure quality at IP level [5]. Link layer monitoring
	provides a way of accounting for link layer characteristics such		provides a way of accounting for link layer characteristics such
	as bit error rates.		as bit error rates.
	Raisanen, Grotefeld expires January 2001 [Page 3]		Raisanen, Grotefeld expires May 2001 [Page 3]
	---------------		---------------
	| application |		| application |
	---------------		---------------
	| transport | <--		| transport | <--
	---------------		---------------
	| network | <--		| network | <--
	---------------		---------------
	| link | <--		| link | <--
	---------------		---------------
	| physical |		| physical |
	skipping to change at line 172		skipping to change at line 173
	following issues:		following issues:
	+ Lost packets: Applications may have varying tolerance to lost		+ Lost packets: Applications may have varying tolerance to lost
	packets. Another consideration is the distribution of lost		packets. Another consideration is the distribution of lost
	packets (i.e. random or bursty).		packets (i.e. random or bursty).
	+ Long delays: Many applications will consider packets delayed		+ Long delays: Many applications will consider packets delayed
	longer than a certain value to be equivalent to lost packets		longer than a certain value to be equivalent to lost packets
	(i.e. real time applications).		(i.e. real time applications).
	+ Duplicate packets: Some applications may be perturbed if		+ Duplicate packets: Some applications may be perturbed if
	duplicate packets are received.		duplicate packets are received.
	+ Out of sequence: Some applications may be perturbed if		+ Out-of-sequence: Some applications may be perturbed if packets
	packets are received out of sequence. This may be in addition		are received out of sequence. This may be in addition to the
	to the possibility of exceeding the "long" delay threshold as a		possibility of exceeding the "long" delay threshold as a result
	result of being out of sequence.		of being out of sequence. An out-of-sequence packet outcome
			occurs when a single IP packet received at a DST measurement
			point has a sequence number higher than that which is
			expected, and therefore, the packet is OOS due to re-ordering.
	+ Corrupt packet header: Most applications will probably treat a		+ Corrupt packet header: Most applications will probably treat a
	packet with a corrupt header as equivalent to a lost packet.		packet with a corrupt header as equivalent to a lost packet.
	+ Corrupt packet payload: Some applications (e.g. digital voice		+ Corrupt packet payload: Some applications (e.g. digital voice
	codecs) may accept corrupt packet payload. In some cases, the		codecs) may accept corrupt packet payload. In some cases, the
	packet payload may contain application specific forward error		packet payload may contain application specific forward error
	correction (FEC) that can compensate for some level of		correction (FEC) that can compensate for some level of
	corruption.		corruption.
	+ Spurious packet: Dst may receive spurious packets (i.e. packets		+ Spurious packet: Dst may receive spurious packets (i.e. packets
	that are not part of the metric). Many applications may be		that are not sent by the Src as part of the metric). Many
	perturbed by spurious packets.		applications may be perturbed by spurious packets.
	Depending, e.g., on the observed protocol level, some issues listed		Depending, e.g., on the observed protocol level, some issues listed
	above may be indistinguishable from others by the application, it		above may be indistinguishable from others by the application, it
	may be important to preserve the distinction for the operators of		may be important to preserve the distinction for the operators of
	Src, Dst, and/or the intermediate network(s).		Src, Dst, and/or the intermediate network(s).
	Raisanen, Grotefeld expires January 2001 [Page 4]		Raisanen, Grotefeld expires May 2001 [Page 4]
	Because of the possible errors listed above, in most cases it is		Because of the possible errors listed above, in most cases it is
	recommended to use a packet identifier for each packet generated at		recommended to use a packet identifier for each packet generated at
	Src. Identifiers for the metric sample may be those used by the		Src. Identifiers for the metric sample may be those used by the
	underlying transport layer (e.g. RTP sequence number) or the same		underlying transport layer (e.g. RTP sequence number) or the same
	identifiers used by an application if the application to be modeled		identifiers used by an application if the application to be modeled
	by the metric uses an identifier. The possibility of identifier		by the metric uses an identifier. The possibility of identifier
	roll-over (reuse if intentional) during a metric collected over		roll-over (reuse if intentional) during a metric collected over
	a "long" (application dependent) time should be observed.		a "long" (application dependent) time should be observed.
	If the application does not use an identifier, it may still be		If the application does not use an identifier, it may still be
	skipping to change at line 236		skipping to change at line 240
	3.5 Measurement types		3.5 Measurement types
	Delay measurements can be one-way [2,3], paired one-way, or		Delay measurements can be one-way [2,3], paired one-way, or
	round-trip [6]. Accordingly, the measurements may be performed		round-trip [6]. Accordingly, the measurements may be performed
	either with synchronized or unsynchronized Src/Dst host clocks.		either with synchronized or unsynchronized Src/Dst host clocks.
	Different possibilities are listed below.		Different possibilities are listed below.
	The reference measurement setup for all measurement types is		The reference measurement setup for all measurement types is
	shown in Fig. 2.		shown in Fig. 2.
	Raisanen, Grotefeld expires January 2001 [Page 5]		Raisanen, Grotefeld expires May 2001 [Page 5]
	----------------< IP >--------------------		----------------< IP >--------------------
	| | | |		| | | |
	------- ------- -------- --------		------- ------- -------- --------
	| Src | | MP | | MP | | Dst |		| Src | | MP | | MP | | Dst |
	------- |(Src)| |(Dst) | --------		------- |(Src)| |(Dst) | --------
	------- --------		------- --------
	Fig. 2: Example setup for the metric usage.		Fig. 2: Example setup for the metric usage.
	An example of the use of the metric is a setup with a source host		An example of the use of the metric is a setup with a source host
	(Src), a destination host (Dst), and corresponding measurement		(Src), a destination host (Dst), and corresponding measurement
	points (MP(Src) and MP(Dst)) as shown in Figure 2. Separate equipment		points (MP(Src) and MP(Dst)) as shown in Figure 2. Separate equipment
	for measurement points may be used if having Src and/or Dst conduct		for measurement points may be used if having Src and/or Dst conduct
	the measurement may significantly affect the delay performance to be		the measurement may significantly affect the delay performance to be
	measured. MP(Src)should be placed/measured close to the egress point		measured. MP(Src)should be placed/measured close to the egress point
	of packets from Src. MP(Dst) should be placed/measure close to		of packets from Src. MP(Dst) should be placed/measure close to
	the ingress point of packets for Dst. "Close" is defined as a		the ingress point of packets for Dst. "Close" is defined as a
	distance sufficiently small so that application-level performance		distance sufficiently small so that application-level performance
	characteristics measured (such as delay) can be expected to follow		characteristics measured (such as delay) can be expected to follow
	the corresponding performance characteristic between Src and Dst to		the corresponding performance characteristic between Src and Dst to
	an adequate accuracy.		an adequate accuracy. Basic principle here is that measurement
			results between MP(Src) and MP(Dst) should be the same as for a
			measurement between Src and Dst, within the general error margin
			target of the measurement (e.g., < 1 ms; number of lost packets is
			the same). If this is not possible, the difference between MP-MP
			measurement and Src-Dst measurement should preferably be systematic.
	The test setup just described fulfills two important criteria:		The test setup just described fulfills two important criteria:
	1) Test is made with realistic stream metrics, emulating - for example -		1) Test is made with realistic stream metrics, emulating - for example -
	a full-duplex Voice over IP (VoIP) call.		a full-duplex Voice over IP (VoIP) call.
	2) Either one-way or round-trip characteristics may be obtained.		2) Either one-way or round-trip characteristics may be obtained.
	It is also possible to have intermediate measurement points between		It is also possible to have intermediate measurement points between
	MP(Src) and MP(Dst), but that is beyond the scope of this document.		MP(Src) and MP(Dst), but that is beyond the scope of this document.
	3.5.1 One way measurement		3.5.1 One way measurement
	skipping to change at line 280		skipping to change at line 289
	as possible, application-level measurements based on one-way delays		as possible, application-level measurements based on one-way delays
	are used in the example metrics. The implication of application-level		are used in the example metrics. The implication of application-level
	measurement for bi-directional applications such as interactive		measurement for bi-directional applications such as interactive
	multimedia conferencing is discussed below.		multimedia conferencing is discussed below.
	Performing a single one-way measurement only yields information on		Performing a single one-way measurement only yields information on
	network behavior in one direction. Moreover, the stream at the		network behavior in one direction. Moreover, the stream at the
	network transport level does not emulate accurately a full-duplex		network transport level does not emulate accurately a full-duplex
	multimedia connection.		multimedia connection.
	Raisanen, Grotefeld expires January 2001 [Page 6]		Raisanen, Grotefeld expires May 2001 [Page 6]
	3.5.2 Paired one way measurement		3.5.2 Paired one way measurement
	Paired one way delay refers to two multimedia streams: Src to Dst		Paired one way delay refers to two multimedia streams: Src to Dst
	and Dst to Src for the same Src and Dst. By way of example, for		and Dst to Src for the same Src and Dst. By way of example, for
	some applications, the delay performance of each one way path is		some applications, the delay performance of each one way path is
	more important than the round trip delay. This is the case for		more important than the round trip delay. This is the case for
	delay-limited signals such as VoIP. Possible reasons for the		delay-limited signals such as VoIP. Possible reasons for the
	difference between one-way delays is different routing of streams		difference between one-way delays is different routing of streams
	from Src to Dst vs. Dst to Src.		from Src to Dst vs. Dst to Src.
	skipping to change at line 327		skipping to change at line 336
	original sender may be more bursty than the one on the first "leg" of		original sender may be more bursty than the one on the first "leg" of
	the round-trip journey. The last issue, however, means in practice		the round-trip journey. The last issue, however, means in practice
	that returning stream experiences worse QoS than the other one, and		that returning stream experiences worse QoS than the other one, and
	the performance estimates thus obtained are pessimistic ones. The		the performance estimates thus obtained are pessimistic ones. The
	possibility of asymmetric routing and queuing must be taken into		possibility of asymmetric routing and queuing must be taken into
	account during analysis of the results.		account during analysis of the results.
	Please note that with suitable arrangements, round-trip measurements		Please note that with suitable arrangements, round-trip measurements
	may be performed using paired one way measurements.		may be performed using paired one way measurements.
	Raisanen, Grotefeld expires January 2001 [Page 7]		Raisanen, Grotefeld expires May 2001 [Page 7]
	4 Sample metric for multimedia stream simulation		4 Sample metric for multimedia stream simulation
	The sample metric presented here is similar to the sample metric		The sample metric presented here is similar to the sample metric
	Type-P-One-way-Delay-Poisson-Stream presented in [2]. "Singletons", as		Type-P-One-way-Delay-Poisson-Stream presented in [2]. "Singletons", as
	defined in [1] and [2] are not directly used in this document because		defined in [1] and [2] are not directly used in this document because
	certain key results (such as duplicate or out of sequence packets)		certain key results (such as duplicate or out of sequence packets)
	cannot be identified in the context of a singleton, but only as part		cannot be identified in the context of a singleton, but only as part
	of a sample.		of a sample.
	skipping to change at line 351		skipping to change at line 360
	4.2 Metric parameters		4.2 Metric parameters
	4.2.1 Global metric parameters		4.2.1 Global metric parameters
	These parameters are applicable to the metrics collected in the		These parameters are applicable to the metrics collected in the
	following sections (4.2.2, 4.2.3, and 4.2.4).		following sections (4.2.2, 4.2.3, and 4.2.4).
	+ 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
			+ IPV, the IP version (IPv4/IPv6) used in the measurement
	+ T0, a time, for starting to generate packets and taking		+ T0, a time, for starting to generate packets and taking
	measurements for a sample		measurements for a sample
	+ Tf, a time, greater than T0, for stopping generation of packets		+ Tf, a time, greater than T0, for stopping generation of packets
	for a sample		for a sample
	+ periodic packet interval incT, a time duration		+ periodic packet interval incT, a time duration
	+ packet size p(j), the number of bytes in each packet of Type-P of		+ packet size p(j), the number of bytes in each packet of Type-P of
	size j		size j
	+ dTloss, a time interval, used for determining if a packet should		+ dTloss, a time interval, used for determining if a packet should
	be considered lost		be considered lost
	+ Tcons, a time interval [optional]		+ Tcons, a time interval [optional]
	skipping to change at line 373		skipping to change at line 383
	other applications may use packets of different sizes (j > 1).		other applications may use packets of different sizes (j > 1).
	Especially in cases of congestion, it may be useful to have		Especially in cases of congestion, it may be useful to have
	packets smaller than the maximum or predominant size of packets		packets smaller than the maximum or predominant size of packets
	in the periodic stream.		in the periodic stream.
	4.2.2 Metrics collected at MP(Src)		4.2.2 Metrics collected at MP(Src)
	+ Tstamp(Src)[i], for each packet [i], the time of the packet as		+ Tstamp(Src)[i], for each packet [i], the time of the packet as
	measured at MP(Src)		measured at MP(Src)
	+ PktID [i], for each packet [i], an identification number for the		+ PktID [i], for each packet [i], an identification number for the
	the packet sent from Src to Dst		the packet sent from Src to Dst.
	Raisanen, Grotefeld expires January 2001 [Page 8]		Raisanen, Grotefeld expires May 2001 [Page 8]
	+ PktSiTy [i], for each packet [i], the packet size and/or type.		+ PktSiTy [i], for each packet [i], the packet size and/or type.
	Some applications may use packets of different size, either		Some applications may use packets of different size, either
	because of application requirements or in response to IP		because of application requirements or in response to IP
	performance experienced.		performance experienced.
	4.2.3 Metrics collected at MP (Dst)		4.2.3 Metrics collected at MP (Dst)
	+ dTstop, a time interval, used to add to time Tf to determine when to		+ dTstop, a time interval, used to add to time Tf to determine when to
	stop collecting metrics for a sample		stop collecting metrics for a sample
	+ Tstamp(Dst)[i], for each packet [i], the time of the packet as		+ Tstamp(Dst)[i], for each packet [i], the time of the packet as
	measured at MP(Dst)		measured at MP(Dst)
	+ PktID [i], for each packet [i], an identification number for the		+ PktID [i], for each packet [i], an identification number for the
	the packet received at Dst from Src. This identification number		the packet received at Dst from Src.
	may be corrupted.
	+ PktSiTy [i], for each packet [i], the packet size and/or type.		+ PktSiTy [i], for each packet [i], the packet size and/or type.
	Some applications may use packets of different size, either		Some applications may use packets of different size, either
	because of application requirements or in response to IP		because of application requirements or in response to IP
	performance experienced.		performance experienced.
	+ PktStatus [i], for each packet [i], the status of the packet		+ PktStatus [i], for each packet [i], the status of the packet
	received. Possible status includes: OK, packet header corrupt,		received. Possible status includes: OK, packet header corrupt,
	packet payload corrupt, spurious, duplicate		packet payload corrupt, spurious, duplicate, out-of-sequence.
	4.2.4 Metrics resulting when metrics collected at MP(Src) and MP(Dst)		4.2.4 Metrics resulting when metrics collected at MP(Src) and MP(Dst)
	are merged		are merged
	These parameters are only available as a complete set when the		These parameters are only available as a complete set when the
	parameters from the preceding sections (4.2.1, 4.2.2, and 4.2.3 are		parameters from the preceding sections (4.2.1, 4.2.2, and 4.2.3 are
	combined.		combined.
	+ Tstamp(Src)[i], for each packet [i], the time of the packet as		+ Tstamp(Src)[i], for each packet [i], the time of the packet as
	measured at MP(Src). This entry may be blank or noted as N/A		measured at MP(Src). This entry may be blank or noted as N/A
	skipping to change at line 418		skipping to change at line 427
	+ Tstamp(Dst)[i], for each packet [i], the time of the packet as		+ Tstamp(Dst)[i], for each packet [i], the time of the packet as
	measured at MP(Dst). This entry may be blank or noted as N/A		measured at MP(Dst). This entry may be blank or noted as N/A
	for packets not received at MP(Dst), received with corrupt		for packets not received at MP(Dst), received with corrupt
	packet headers, or for duplicate packets received at MP(Dst).		packet headers, or for duplicate packets received at MP(Dst).
	+ PktID [i], for each packet [i], an identification number for the		+ PktID [i], for each packet [i], an identification number for the
	the packet received. This identification number may be corrupted		the packet received. This identification number may be corrupted
	for certain packets received at MP (Dst).		for certain packets received at MP (Dst).
	+ PktSiTy [i], for each packet [i], the packet size and/or type.		+ PktSiTy [i], for each packet [i], the packet size and/or type.
	+ PktStatus [i], for each packet [i], the status of the packet		+ PktStatus [i], for each packet [i], the status of the packet
	received. Possible status includes: OK, packet header corrupt,		received. Possible status includes: OK, packet header corrupt,
	packet payload corrupt, spurious, duplicate, out of sequence.		packet payload corrupt, spurious, duplicate, out-of-sequence.
	Raisanen, Grotefeld expires January 2001 [Page 9]		Raisanen, Grotefeld expires May 2001 [Page 9]
	+ Delay [i], for each packet [i], the time interval Tstamp(Dst)[i] -		+ Delay [i], for each packet [i], the time interval Tstamp(Dst)[i] -
	Tstamp(Src)[i]. For the following conditions, it will not be		Tstamp(Src)[i]. For the following conditions, it will not be
	possible to be able to compute delay:		possible to be able to compute delay:
	Spurious: There will be no Tstamp(Src)[i] time		Spurious: There will be no Tstamp(Src)[i] time
	Not received: There will be no Tstamp (Dst) [i]		Not received: There will be no Tstamp (Dst) [i]
	Corrupt packet header: There will be no Tstamp (Dst) [i]		Corrupt packet header: There will be no Tstamp (Dst) [i]
	Duplicate: Only the first non-corrupt copy of the packet		Duplicate: Only the first non-corrupt copy of the packet
	received at Dst should have Delay [i] computed.		received at Dst should have Delay [i] computed.
	+ SDV[i] [optional] , for each packet [i] except the first one:		+ SDV[i] [optional] , for each packet [i] except the first one:
	momentary delay variation between successive packets, i.e., the		momentary delay variation between successive packets, i.e., the
	skipping to change at line 462		skipping to change at line 471
	packet size/type, and received status of each packet received from		packet size/type, and received status of each packet received from
	Src at Dst that is part of the sample. Optionally, at a time Tf +		Src at Dst that is part of the sample. Optionally, at a time Tf +
	Tcons, the data from MP(Src) and MP(Dst) are consolidated to derive		Tcons, the data from MP(Src) and MP(Dst) are consolidated to derive
	the results of the sample metric.		the results of the sample metric.
	To prevent stopping data collection too soon, dTcons should be greater		To prevent stopping data collection too soon, dTcons should be greater
	than or equal to dTstop. Conversely, to keep data collection		than or equal to dTstop. Conversely, to keep data collection
	reasonably efficient, dTstop should be some reasonable time interval		reasonably efficient, dTstop should be some reasonable time interval
	(seconds/minutes/hours), even if dTloss is infinite or extremely long.		(seconds/minutes/hours), even if dTloss is infinite or extremely long.
	Raisanen, Grotefeld expires January 2001 [Page 10]		Raisanen, Grotefeld expires May 2001 [Page 10]
	4.4 Discussion		4.4 Discussion
	The sample metric thus defined is intended to probe the delays and		The sample metric thus defined is intended to probe the delays and
	the delay variation as experienced by multimedia streams of		the delay variation as experienced by multimedia streams of
	an application. Subsequently, the delay is assumed to be measured at		an application. Subsequently, the delay is assumed to be measured at
	transport layer level. Since a range of packet sizes and nominal		transport layer level. Since a range of packet sizes and nominal
	interval between packets is used, the method probes only a specific		interval between packets is used, the method probes only a specific
	time scale of network QoS variations.		time scale of network QoS variations.
	skipping to change at line 509		skipping to change at line 518
	100 usec to 10 msec, whereby it may be important for Src and Dst to		100 usec to 10 msec, whereby it may be important for Src and Dst to
	synchronize very closely. GPS systems afford one way to achieve		synchronize very closely. GPS systems afford one way to achieve
	synchronization to within several 10s of usec. Ordinary application		synchronization to within several 10s of usec. Ordinary application
	of NTP may allow synchronization to within several msec, but this		of NTP may allow synchronization to within several msec, but this
	depends on the stability and symmetry of delay properties among those		depends on the stability and symmetry of delay properties among those
	NTP agents used, and this delay is what we are trying to measure. A		NTP agents 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.
	Raisanen, Grotefeld expires January 2001 [Page 11]		+ Reordering of packets is best discussed in terms of the entire
			set of measurement packets received, i.e. should be addressed in
			Sec. 4.9.1.
			Raisanen, Grotefeld expires May 2001 [Page 11]
	+ A given methodology will have to include a way to determine		+ A given methodology will have to include a way to determine
	whether packet was lost or whether delay is merely very large (and		whether packet was lost or whether delay is merely very large (and
	the packet is yet to arrive at Dst). The global metric parameter		the packet is yet to arrive at Dst). The global metric parameter
	dTloss defines a time interval such that delays larger than dTloss		dTloss defines a time interval such that delays larger than dTloss
	are interpreted as losses.		are interpreted as losses.
	{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.}
	skipping to change at line 558		skipping to change at line 571
	+ Any error in the synchronization between the MP(Src) clock and		+ Any error in the synchronization between the MP(Src) clock and
	the MP(Dst) clock will contribute to error in the delay		the MP(Dst) clock will contribute to error in the delay
	measurement. We say that the MP(Src) clock and the MP(Dst)		measurement. We say that the MP(Src) clock and the MP(Dst)
	clock have a synchronization error of Tsynch if the MP(Src) clock		clock have a synchronization error of Tsynch if the MP(Src) clock
	is Tsynch ahead of the MP(Dst) clock. Thus, if we know the		is Tsynch ahead of the MP(Dst) clock. Thus, if we know the
	value of Tsynch exactly, we could correct for clock		value of Tsynch exactly, we could correct for clock
	synchronization by adding Tsynch to the uncorrected value of		synchronization by adding Tsynch to the uncorrected value of
	Tstamp(Dst)[i] - Tstamp(Src) [i].		Tstamp(Dst)[i] - Tstamp(Src) [i].
	Raisanen, Grotefeld expires January 2001 [Page 12]		Raisanen, Grotefeld expires May 2001 [Page 12]
	+ The accuracy of a clock is important only in identifying the time		+ The accuracy of a clock is important only in identifying the time
	at which a given delay was measured. Accuracy, per se, has no		at which a given delay was measured. Accuracy, per se, has no
	importance to the accuracy of the measurement of delay. When		importance to the accuracy of the measurement of delay. When
	computing delays, we are interested only in the differences		computing delays, we are interested only in the differences
	between clock values, not the values themselves.		between clock values, not the values themselves.
	+ The resolution of a clock adds to uncertainty about any time		+ The resolution of a clock adds to uncertainty about any time
	measured with it. Thus, if the MP(Src) clock has a resolution of		measured with it. Thus, if the MP(Src) clock has a resolution of
	10 msec, then this adds 10 msec of uncertainty to any time value		10 msec, then this adds 10 msec of uncertainty to any time value
	measured with it. We will denote the resolution of the source		measured with it. We will denote the resolution of the source
	skipping to change at line 608		skipping to change at line 621
	only directly measure the time between when Src generates the packet		only directly measure the time between when Src generates the packet
	just prior to sending the test packet and when Dst has started to		just prior to sending the test packet and when Dst has started to
	process the packet after having received the test packet, and we refer		process the packet after having received the test packet, and we refer
	to these two points as "host times".		to these two points as "host times".
	To the extent that the difference between wire time and host time is		To the extent that the difference between wire time and host time is
	accurately known, this knowledge can be used to correct for wire time		accurately known, this knowledge can be used to correct for wire time
	measurements and the corrected value more accurately estimates the		measurements and the corrected value more accurately estimates the
	desired (host time) metric.		desired (host time) metric.
	Raisanen, Grotefeld expires January 2001 [Page 13]		Raisanen, Grotefeld expires May 2001 [Page 13]
	To the extent, however, that the difference between wire time and		To the extent, however, that the difference between wire time and
	host time is uncertain, this uncertainty must be accounted for in an		host time is uncertain, this uncertainty must be accounted for in an
	analysis of a given measurement method. We denote by Hsource an		analysis of a given measurement method. We denote by Hsource an
	upper bound on the uncertainty in the difference between wire time		upper bound on the uncertainty in the difference between wire time
	of MP(Src) and host time on the Src host, and similarly define Hdest		of MP(Src) and host time on the Src host, and similarly define Hdest
	for the difference between the host time on the Dst host and the wire		for the difference between the host time on the Dst host and the wire
	time of MP(Dst). We then note that these problems introduce a total		time of MP(Dst). 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		uncertainty should be included in the error/uncertainty analysis of
	any measurement implementation.		any measurement implementation.
	skipping to change at line 655		skipping to change at line 668
	remove outliers, which will be found in measuring any physical		remove outliers, which will be found in measuring any physical
	property; (2) a particular confidence level should be specified so		property; (2) a particular confidence level should be specified so
	that the results of independent implementations can be compared.}		that the results of independent implementations can be compared.}
	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) + ResMP(Src) + ResMP(Dst) + Hsource + Hdest.		Esynch(t) + ResMP(Src) + ResMP(Dst) + Hsource + Hdest.
	Raisanen, Grotefeld expires January 2001 [Page 14]		Raisanen, Grotefeld expires May 2001 [Page 14]
	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) +		through the use of a GPS time source. The sum of Esynch(t) +
	ResMP(Src) + ResMP(Dst) is small, and is also bounded for the		ResMP(Src) + ResMP(Dst) is small, and is also bounded for the
	duration of the measurement because of the global time source.		duration of the measurement because of the global time source.
	skipping to change at line 703		skipping to change at line 716
	Note that random error is a function of measurement load. For		Note that random error is a function of measurement load. For
	example, if many paths will be measured by one instrument, this might		example, if many paths will be measured by one instrument, this might
	increase interrupts, process scheduling, and disk I/O (for example,		increase interrupts, process scheduling, and disk I/O (for example,
	recording the measurements), all of which may increase the random		recording the measurements), all of which may increase the random
	error in measured singletons. Therefore, in addition to minimal load		error in measured singletons. Therefore, in addition to minimal load
	measurements to find the systematic error, calibration measurements		measurements to find the systematic error, calibration measurements
	should be performed with the same measurement load that the		should be performed with the same measurement load that the
	instruments will see in the field.		instruments will see in the field.
	Raisanen, Grotefeld expires January 2001 [Page 15]		Raisanen, Grotefeld expires May 2001 [Page 15]
	We wish to reiterate that this statistical treatment refers to the		We wish to reiterate that this statistical treatment refers to the
	calibration of the instrument; it is used to "calibrate the meter		calibration of the instrument; it is used to "calibrate the meter
	stick" and say how well the meter stick reflects reality.		stick" and say how well the meter stick reflects reality.
	4.7 Reporting the metric		4.7 Reporting the metric
	The calibration and context in which the metric is measured MUST be		The calibration and context in which the metric is measured MUST be
	carefully considered, and SHOULD always be reported along with metric		carefully considered, and SHOULD always be reported along with metric
	results. We now present five items to consider: the Type-P of test		results. We now present five items to consider: the Type-P of test
	packets, the threshold of delay equivalent to loss, error		packets, the threshold of delay equivalent to loss, error
	skipping to change at line 747		skipping to change at line 760
	from the measured values.		from the measured values.
	+ You SHOULD also report the calibration error, e, such that the		+ You SHOULD also report the calibration error, e, such that the
	true value is the reported value plus or minus e, with 95%		true value is the reported value plus or minus e, with 95%
	confidence (see the last section.)		confidence (see the last section.)
	+ If possible, the conditions under which a test packet with finite		+ If possible, the conditions under which a test packet with finite
	delay is reported as lost due to resource exhaustion on the		delay is reported as lost due to resource exhaustion on the
	measurement instrument SHOULD be reported.		measurement instrument SHOULD be reported.
	Raisanen, Grotefeld expires January 2001 [Page 16]		Raisanen, Grotefeld expires May 2001 [Page 16]
	4.7.4. Path		4.7.4. Path
	The path traversed by the packets SHOULD be reported, if possible.		The path traversed by the packets SHOULD be reported, if possible.
	In general it is impractical to know the precise path a given packet		In general it is impractical to know the precise path a given packet
	takes through the network. The precise path may be known for		takes through the network. The precise path may be known for
	certain Type-P packets on short or stable paths. If Type-P includes		certain Type-P packets on short or stable paths. If Type-P includes
	the record route (or loose-source route) option in the IP header,		the record route (or loose-source route) option in the IP header,
	and the path is short enough, and all routers* on the path support		and the path is short enough, and all routers* on the path support
	record (or loose-source) route, then the path will be precisely		record (or loose-source) route, then the path will be precisely
	skipping to change at line 796		skipping to change at line 809
	test 1,000 two-minute VoIP calls rather than a single 2,000 minute		test 1,000 two-minute VoIP calls rather than a single 2,000 minute
	VoIP call. When considering collection of a sample of samples, issues		VoIP call. When considering collection of a sample of samples, issues
	like the interval between samples (e.g. Poisson vs. periodic, time of		like the interval between samples (e.g. Poisson vs. periodic, time of
	day/day of week), composition of samples (e.g. equal (Tf-T0 duration,		day/day of week), composition of samples (e.g. equal (Tf-T0 duration,
	different packet sizes), and network considerations (e.g. run different		different packet sizes), and network considerations (e.g. run different
	samples over different intervening link-host combinations) should be		samples over different intervening link-host combinations) should be
	taken into account. For items like the interval between samples,		taken into account. For items like the interval between samples,
	the pattern of use of the application being measured should be		the pattern of use of the application being measured should be
	considered.		considered.
	Raisanen, Grotefeld expires January 2001 [Page 17]		Raisanen, Grotefeld expires May 2001 [Page 17]
	4.9 Statistics based on Type-P-One-way-Delay-Periodic-Stream		4.9 Statistics based on Type-P-One-way-Delay-Periodic-Stream
	4.9.1 Statistics calculable from one sample		4.9.1 Statistics calculable from one sample
	As a metric based on a sample representative of certain		As a metric based on a sample representative of certain
	applications, some general purpose statistics (e.g. median and		applications, some general purpose statistics (e.g. median and
	percentile) may be less applicable than ways to characterize the		percentile) may be less applicable than ways to characterize the
	range of delay values recorded during the sample metrics.		range of delay values recorded during the sample metrics.
	skipping to change at line 846		skipping to change at line 859
	5. Security Considerations		5. Security Considerations
	5.1 Denial of Service Attacks		5.1 Denial of Service Attacks
	This metric generates a periodic stream of packets from one host (Src)		This metric generates a periodic stream of packets from one host (Src)
	to another host (Dst) through intervening networks. This metric		to another host (Dst) through intervening networks. This metric
	could be abused for denial of service attacks directed at Dst and/or		could be abused for denial of service attacks directed at Dst and/or
	the intervening network(s).		the intervening network(s).
	Raisanen, Grotefeld expires January 2001 [Page 18]		Raisanen, Grotefeld expires May 2001 [Page 18]
	Administrators of Src, Dst, and the intervening network(s) should		Administrators of Src, Dst, and the intervening network(s) should
	establish bilateral or multi-lateral agreements regarding the timing,		establish bilateral or multi-lateral agreements regarding the timing,
	size, and frequency of collection of sample metrics. Use of this		size, and frequency of collection of sample metrics. Use of this
	metric in excess the terms agreed between the participants MAY BE		metric in excess the terms agreed between the participants MAY BE
	cause for immediate rejection or discard of packets or other		cause for immediate rejection or discard of packets or other
	escalation procedures defined between the affected parties.		escalation procedures defined between the affected parties.
	5.2 User data confidentiality		5.2 User data confidentiality
	This metric generates packets for a sample metric, rather than		This metric generates packets for a sample metric, rather than
	skipping to change at line 871		skipping to change at line 884
	It may be possible to identify that a certain packet or stream of		It may be possible to identify that a certain packet or stream of
	packets are part of a sample metric. With that knowledge at Dst		packets are part of a sample metric. With that knowledge at Dst
	and/or the intervening networks, it is possible to change the		and/or the intervening networks, it is possible to change the
	processing of the packets (e.g. increasing or decreasing delay)		processing of the packets (e.g. increasing or decreasing delay)
	that may distort the measured performance. It may also be		that may distort the measured performance. It may also be
	possible to generate additional packets that appear to be part of		possible to generate additional packets that appear to be part of
	the sample metric. These additional packets are likely to perturb		the sample metric. These additional packets are likely to perturb
	the results of the sample measurement.		the results of the sample measurement.
			To discourage the kind of interference mentioned above, packet
			interference checks, such as cryptographic hash, MAY be used.
	6. Acknowledgements		6. Acknowledgements
	The authors wish to thank the chairs of the IPPM WG for comments		The authors wish to thank the chairs of the IPPM WG for comments
	that have made the present draft clearer and more focused. Howard		that have made the present draft clearer and more focused. Howard
	Stanislevic and Al Morton ahave presented useful comments and		Stanislevic and Al Morton ahave presented useful comments and
	questions. The authors have also built on the substantial		questions. The authors have also built on the substantial
	foundations laid by the authors of the framework for IP		foundations laid by the authors of the framework for IP
	performance [1].		performance [1].
			Raisanen, Grotefeld expires May 2001 [Page 19]
	7. References		7. References
	[1] V.Paxson, G.Almes, J.Mahdavi, and M.Mathis: Framework for IP		[1] V.Paxson, G.Almes, J.Mahdavi, and M.Mathis: Framework for IP
	Performance Metrics, IETF RFC 2330, May 1998.		Performance Metrics, IETF RFC 2330, May 1998.
	[2] G.Almes, S.Kalidindi, and M.Zekauskas: A one-way delay metric		[2] G.Almes, S.Kalidindi, and M.Zekauskas: A one-way delay metric
	for IPPM, IETF RFC 2679, September 1999.		for IPPM, IETF RFC 2679, September 1999.
	[3] International Telecommunications Union recommendation I.380,		[3] International Telecommunications Union recommendation I.380,
	February 1999.		February 1999.
	[4] S. Bradner: Key words for use in RFCs to Indicate Requirement		[4] S. Bradner: Key words for use in RFCs to Indicate Requirement
	Levels, RFC 2119, March 1997.		Levels, RFC 2119, March 1997.
	[5] ETSI TIPHON document TS-101329-5 (to be published in July).		[5] ETSI TIPHON document TS-101329-5 (to be published in July).
	[6] G.Almes, S.Kalidindi, and M.Zekauskas: A round-trip delay		[6] G.Almes, S.Kalidindi, and M.Zekauskas: A round-trip delay
	metric for IPPM, IETF RFC 2681.		metric for IPPM, IETF RFC 2681.
	Raisanen, Grotefeld expires January 2001 [Page 19]
	8. Authors' contact information		8. Authors' contact information
	Vilho Raisanen <Vilho.Raisanen@nokia.com>		Vilho Raisanen <Vilho.Raisanen@nokia.com>
	P.O. Box 407		P.O. Box 407
	Communication Systems Laboratory		Communication Systems Laboratory
	Nokia Research Center		Nokia Research Center
	FIN-00045 Nokia Group		FIN-00045 Nokia Group
	Finland		Finland
	Phone +358 9 4376 1		Phone +358 9 4376 1
	Fax. +358 9 4376 6852		Fax. +358 9 4376 6852
	Glenn Grotefeld <g.grotefeld@motorola.com>		Glenn Grotefeld <g.grotefeld@motorola.com>
	Motorola, Inc.		Motorola, Inc.
	1303 E. Algonquin Road		1303 E. Algonquin Road
	4th Floor		4th Floor
	Schaumburg, IL 60196		Schaumburg, IL 60196
	USA		USA
	Phone +1 847 576-5992		Phone +1 847 576-5992
	Fax +1 847 538-7455		Fax +1 847 538-7455
	EXPIRES JANUARY 2001		EXPIRES May 2001
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/