< draft-ietf-ippm-owmetric-as-00.txt		draft-ietf-ippm-owmetric-as-01.txt >
	Internet Draft Henk Uijterwaal		Internet Draft Henk Uijterwaal
	Document: draft-ietf-ippm-owmetric-as-00.txt Merike Kaeo		Document: draft-ietf-ippm-owmetric-as-01.txt Merike Kaeo
	Expires: December 2002 July 2002		Expires: June 2003 November 2002
	One-Way Metric Applicability Statement		One-Way Metric Applicability Statement
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with all		This document is an Internet-Draft and is in full conformance with all
	provisions of Section 10 of RFC2026. Internet-Drafts are working		provisions of Section 10 of RFC2026. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas, and		documents of the Internet Engineering Task Force (IETF), its areas, and
	its working groups. Note that other groups may also distribute working		its working groups. Note that other groups may also distribute working
	documents as Internet-Drafts.		documents as Internet-Drafts.
	skipping to change at page 3, line 32 ¶		skipping to change at page 3, line 32 ¶
	than the MTU to avoid effects due to fragmentation and reassembly.		than the MTU to avoid effects due to fragmentation and reassembly.
	Before running any actual measurements, one should perform tests to see		Before running any actual measurements, one should perform tests to see
	if delay depends on packet size other than scaling with the packet size.		if delay depends on packet size other than scaling with the packet size.
	If this appears to be the case, one should try to estimate packet sizes		If this appears to be the case, one should try to estimate packet sizes
	for "user" data using passive measurements and adjust the packet size		for "user" data using passive measurements and adjust the packet size
	accordingly, or use a variable packet size according to the distribution		accordingly, or use a variable packet size according to the distribution
	seen in user data. These tests should be repeated when the path between		seen in user data. These tests should be repeated when the path between
	source and destination changes.		source and destination changes.
			Also note that some line card designs have buffer pools of different
			sizes. This can lead to loss being different for different packet
			sizes.
	When packets are sent larger than the minimum size required by the		When packets are sent larger than the minimum size required by the
	measurement device, the remainder of the packet should be padded with		measurement device, the remainder of the packet should be padded with
	random bits in order to avoid compression being applied to any		random bits in order to avoid compression being applied to any
	measurement packets.		measurement packets. The algorithm to generate these random bits as
			well as any seed values have to be known, in order to be able to fully
			understand any remaining issues with compression.
	3.3 Timing issues		3.3 Timing issues
	The measured metric should report experimental errors on the accuracy of		The measured metric should report experimental errors on the accuracy of
	the clocks. This has been seen to only be an issue during measurement		the clocks. This has been seen to only be an issue during measurement
	test start-up. In the case of using NTP, it starts with an estimate and		test start-up. In the case of using NTP, it starts with an estimate and
	as the clock starts to stabilize it corrects the internal clock of the		as the clock starts to stabilize it corrects the internal clock of the
	device. In the case of IPDV, there are 2 timestamps and initial errors		device.
	can be huge.
			When the IPDV metric is being measured, one use 4 time-stamps: send and
			arrival time of the first packet and, send and arrival time of the
			second packet. The difference between these time-stamps will be small.
			One should take care that sufficient accuracy for the calculation is
			available and check that the experimental error on the overall result is
			still small compared to the result.
	The clock should be checked for correct performance at regular intervals		The clock should be checked for correct performance at regular intervals
	and measurements should be discarded when there is a problem.		and measurements should be discarded when there is a problem.
	One should check if the overall experimental error is small compared to		One should check if the overall experimental error is small compared to
	the delay before further processing of the data. The errors should be		the delay before further processing of the data. The errors should be
	recorded so they are available when calculating derived metrics such as		recorded so they are available when calculating derived metrics such as
	IPDV.		IPDV.
	3.4 Test duration		3.4 Test duration
	The test duration can be infinitely long. There is a preference for		The test duration can be infinitely long depending on the metric and
	continuous measurements to more easily see traffic variations. This is		application. In order to easily see traffic variations, measurements
	especially important for performing traffic engineering and/or load		should run for a long time but have a limited life-time. The former
	balancing. The active measurements should only be started/stopped when		requirement makes it easier to use the data for traffic engineering or
	adding/removing boxes or when there are networking problems.		load balancing.
	How to report intermediate results?		The latter requirement allows for a easy failure detection: suppose one
			is measuring between A and B. At some point in time, B stops receiving
			packets. Until the measurement session times out, there is no way to
			tell if this is due to full connectivity loss between A and B, or due to
			a failure of the device A. When the measurement session ends, one can
			attempt to restart it. If one can contact the host at A, one can
			conservatively assume that A crashed.
			How to report intermediate results while the test is in progress?
	3.5. Data volumes		3.5. Data volumes
	It is important to ensure that any measurement traffic does not		It is important to ensure that any measurement traffic does not
	interfere with normal network operations. Initially, one should check		interfere with normal network operations. Initially, one should check
	if outgoing/incoming data volume for a box is small with respect to link		if outgoing/incoming data volume for a box is small with respect to link
	capacity of the first few hops to avoid measurements being affected by		capacity of the first few hops to avoid measurements being affected by
	loaded links. Also, one should check that the machine sending/receiving		loaded links. Also, one should check that the machine sending/receiving
	the data can cope with the expected offered load. Lastly, make sure that		the data can cope with the expected offered load. Lastly, make sure that
	the total test traffic volume sent or received by a machine is small		the total test traffic volume sent or received by a machine is small
	compared to total link capacity, a number of 3% of the total capacity		compared to total link capacity, a number of 3% of the total available
	seems reasonable.		capacity seems reasonable for routine monitoring of the performance of a
			link without affecting the performance of that link.
			Capacity and reordering measurements that fill a link at (almost) its
			maximum line rate should not be used on production networks except
			during scheduled maintenance or test periods.
	4. Reporting metrics		4. Reporting metrics
	4.1. When is a result different?		4.1. When is a result different?
	Given 2 sets of measurements, when is set 1 statistically different from		Given 2 sets of measurements, when is set 1 statistically different from
	set 2?		set 2?
	When do you have reasonable probability that things have not changed or		When do you have reasonable probability that things have not changed or
	are OK with your network? This might vary from application to		are OK with your network? This might vary from application to
	application of the data.		application of the data.
	4.2. Alarms		4.2. Alarms
	>From the previous paragraph, it follows when 2 results are different.		From the previous paragraph, it follows when 2 results are different.
	This can be used to define thresholds for delay alarms.		This can be used to define thresholds for delay alarms.
	4.3. Average/Sigma versus 2.5/median/97.5%		4.3. Average/Sigma versus 2.5/median/97.5%
	Since Average/Sigma for a one-way delay distribution is not well		Since Average/Sigma for a one-way delay distribution is not well
	defined, and percentiles are,we should use the latter.		defined, and percentiles are, we should use the latter.
	If it necessary to use Average/Sigma, then it should be specified how		If it necessary to use Average/Sigma, then it should be specified how
	losses are treated in the calculation.		losses are treated in the calculation.
			Question: what about the loss metrics: average/sigma or percentiles.
			Question: Larry Dunn suggest filtering theory to get a feeling for
			the shape of a curve. Anybody who wants to elaborate?
	5.0 Reporting the IPDV metric.		5.0 Reporting the IPDV metric.
	Using average/sigma for reporting the IPDV metric does not work: first		Using average/sigma for reporting the IPDV metric does not work: first
	of all, the average will almost always be close to zero. Then, the		of all, the average will almost always be close to zero. Then, the
	distribution generally is not Gaussian and the sigma is not well		distribution generally is not Gaussian and the sigma is not well defined
	defined.		for the distributions that are being seen.
	Using percentiles suffers from the same problem: the median will almost		Using percentiles suffers from the same problem: the median will almost
	always be 0, and the 2.5 and 97.5% will be the same.		always be 0, and the 2.5 and 97.5% will be the same.
	What appears to be working is 2 percentiles, for example 5 and 25%, this		What appears to be working is 2 percentiles, for example 5 and 25%, this
	gives a reasonable description of the shape of the distribution.		gives a reasonable description of the shape of the distribution.
			Question: Stas: do you have some better wording?
	6.0 Access to the data		6.0 Access to the data
	Measurement results comprise of both raw data and derived results. The		Measurement results comprise of both raw data and derived results. The
	raw data should be kept accessible to allow for historical trend		raw data should be kept accessible to allow for historical trend
	analysis.		analysis.
	A minimum set of informative fields to be stored is:		A minimum set of informative fields to be stored is:
	* IP address of source		* IP address of source
	* IP address of destination		* IP address of destination
	* Time the packet was sent (or arrived)		* Time the packet was sent (or arrived)
	skipping to change at page 6, line 16 ¶		skipping to change at page 6, line 44 ¶
	10. References		10. References
	[1] RFC2679		[1] RFC2679
	[2] RFC2680		[2] RFC2680
	[3] RFC2330		[3] RFC2330
	[4] RFC2119		[4] RFC2119
	11. Acknowledgments		11. Acknowledgments
	12. Authors' Addresses		Victor Reijs (HEANET) July 9's comments incorporated. Stanislav
			Shalunov's comments from July 26 added, Aug 8 added.
			12. Authors' Addresses
	Henk Uijterwaal		Henk Uijterwaal
	RIPE Network Coordination Centre		RIPE Network Coordination Centre
	Singel 258		Singel 258
	1016 AB Amsterdam		1016 AB Amsterdam
	The Netherlands		The Netherlands
	Phone: +31.20.5354414		Phone: +31.20.5354414
	Fax: +31.20.5354445		Fax: +31.20.5354445
	Email: henk.uijterwaal@ripe.net		Email: henk.uijterwaal@ripe.net
End of changes. 14 change blocks.
	18 lines changed or deleted		52 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/