draft-ietf-ippm-loss-pattern-02.txt		draft-ietf-ippm-loss-pattern-03.txt
	Internet-Draft		Internet-Draft
	Expiration Date: April, 2000 R. Koodli		Expiration Date: December, 2000 R. Koodli
	R. Ravikanth		R. Ravikanth
	Nokia Research Center		Nokia Research Center
	October, 1999		July 2000
	One-way Loss Pattern Sample Metrics		One-way Loss Pattern Sample Metrics
	<draft-ietf-ippm-loss-pattern-02.txt>		<draft-ietf-ippm-loss-pattern-03.txt>
	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.		provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering Task		Internet-Drafts are working documents of the Internet Engineering Task
	Force (IETF), its areas, and its working groups. Note that other groups		Force (IETF), its areas, and its working groups. Note that other groups
	may also distribute working documents as Internet- Drafts.		may also distribute working documents as Internet- Drafts.
	skipping to change at page 3, line 21		skipping to change at page 3, line 21
	3.2. Loss Distance:		3.2. Loss Distance:
	The difference in sequence numbers of two successively lost		The difference in sequence numbers of two successively lost
	packets which may or may not be separated by successfully		packets which may or may not be separated by successfully
	received packets.		received packets.
	Example. Let packet with sequence number 50 be considered lost		Example. Let packet with sequence number 50 be considered lost
	immediately after packet with sequence number 20 was		immediately after packet with sequence number 20 was
	considered lost. The loss distance is 30.		considered lost. The loss distance is 30.
	{Comment: note that this definition does not specify exactly how to		Note that this definition does not specify exactly how to
	associate sequence numbers with test packets. In other words, from		associate sequence numbers with test packets. In other words, from
	a timeseries sample of test packets, one may derive the sequence		a timeseries sample of test packets, one may derive the sequence
	numbers. For example, assign consecutive integers to each packet in		numbers. However, these sequence numbers must be consecutive
	the time series.}		integers.
	3.3. Loss period:		3.3. Loss period:
	Let P_i be the i'th packet.		Let P_i be the i'th packet.
	Define f(P_i) = 1 if P_i is lost, 0 otherwise.		Define f(P_i) = 1 if P_i is lost, 0 otherwise.
	Then, a loss period begins if f(P_i) = 1 and f(P_(i-1)) = 0		Then, a loss period begins if f(P_i) = 1 and f(P_(i-1)) = 0
	Example. Consider the following sequence of lost (denoted by x)		Example. Consider the following sequence of lost (denoted by x)
	and received (denoted by r) packets.		and received (denoted by r) packets.
	skipping to change at page 4, line 48		skipping to change at page 4, line 48
	one. The loss distance associated with the very first packet loss is		one. The loss distance associated with the very first packet loss is
	considered to be zero.		considered to be zero.
	The sequence number of a test packet can be derived from the timeseries		The sequence number of a test packet can be derived from the timeseries
	sample collected by performing the loss measurement according to the		sample collected by performing the loss measurement according to the
	methodology in [AKZ]. For example, if a loss sample consists of		methodology in [AKZ]. For example, if a loss sample consists of
	{<T0,0>, <T1,0>, <T2,1>, <T3,0>, <T4,0>}, the sequence numbers of the		{<T0,0>, <T1,0>, <T2,1>, <T3,0>, <T4,0>}, the sequence numbers of the
	five test packets sent at T0, T1, T2, T3, and T4 can be 0, 1, 2, 3 and		five test packets sent at T0, T1, T2, T3, and T4 can be 0, 1, 2, 3 and
	4 respectively, or 100, 101, 102, 103 and 104 respectively, etc.		4 respectively, or 100, 101, 102, 103 and 104 respectively, etc.
	{Packet loss may also be considered as a result of exceeding some delay
	threshold. This is particularly applicable to delay-sensitive audio
	(or video) applications.
	}
	4.4.2 Type-P-One-Way-Loss-Period-Stream		4.4.2 Type-P-One-Way-Loss-Period-Stream
	We start a counter 'n' at an initial value of zero. This counter is		We start a counter 'n' at an initial value of zero. This counter is
	incremented by one each time a lost packet satisfies the Definition 3.3.		incremented by one each time a lost packet satisfies the Definition 3.3.
	The metric is defined as <loss period, loss> where		The metric is defined as <loss period, loss> where
	"loss" is derived from the sequence of <time, loss> in		"loss" is derived from the sequence of <time, loss> in
	Type-P-One-Way-Loss-Stream [AKZ], and		Type-P-One-Way-Loss-Stream [AKZ], and
	loss period is set to zero when "loss" is zero in		loss period is set to zero when "loss" is zero in
	Type-P-One-Way-Loss-Stream, and loss period is set to 'n' (above)		Type-P-One-Way-Loss-Stream, and loss period is set to 'n' (above)
	when "loss" is one in Type-P-One-Way-Loss-Stream.		when "loss" is one in Type-P-One-Way-Loss-Stream.
	{Note: When a packet is lost, the current value of "n" indicates the		Essentially, when a packet is lost, the current value of "n" indicates
	loss period to which this packet belongs. For a packet that is		the loss period to which this packet belongs. For a packet that is
	received successfully, the loss period is defined to be zero.}		received successfully, the loss period is defined to be zero.
	4.4.3 Example:		4.4.3 Example:
	Let the following set of pairs represent a Type-P-One-Way-Loss-Stream.		Let the following set of pairs represent a Type-P-One-Way-Loss-Stream.
	{<T1,0>,<T2,1>,<T3,0>,<T4,0>,<T5,1>,<T6,0>,<T7,1>,<T8,0>,<T9,1>,		{<T1,0>,<T2,1>,<T3,0>,<T4,0>,<T5,1>,<T6,0>,<T7,1>,<T8,0>,<T9,1>,
	<T10,1>}		<T10,1>}
	where T1, T2,..,T10 are in increasing order.		where T1, T2,..,T10 are in increasing order.
	skipping to change at page 6, line 10		skipping to change at page 6, line 10
	4.5. Methodologies:		4.5. Methodologies:
	The same methodology outlined in [AKZ] can be used to conduct the		The same methodology outlined in [AKZ] can be used to conduct the
	sample experiments.		sample experiments.
	4.6 Discussion:		4.6 Discussion:
	The Loss-Distance-Stream metric allows one to study the separation		The Loss-Distance-Stream metric allows one to study the separation
	between packet losses. This could be useful in determining a		between packet losses. This could be useful in determining a
	"spread factor" associated with the packet loss rate. For		"spread factor" associated with the packet loss rate. For
	example, for a given packet loss rate, the proposed metric		example, for a given packet loss rate, this metric
	indicates how the losses are spread. On the other hand,		indicates how the losses are spread. On the other hand,
	the Loss-Period-Stream metric allows the study of loss burstiness		the Loss-Period-Stream metric allows the study of loss burstiness
	for each occurrence of loss. Note that a single loss period of		for each occurrence of loss. Note that a single loss period of
	length 'n' can account for a significant portion of the overall		length 'n' can account for a significant portion of the overall
	loss rate. Note also that it is possible to measure distance between		loss rate. Note also that it is possible to measure distance between
	loss bursts seprated by one or more successfully received packets: See		loss bursts seprated by one or more successfully received packets: See
	Section 5.4, and 5.5		Section 5.4, and 5.5
	4.7 Sampling Considerations:		4.7 Sampling Considerations:
	skipping to change at page 6, line 44		skipping to change at page 6, line 45
	5. Statistics:		5. Statistics:
	5.1 Type-P-One-Way-Loss-Noticeable-Rate		5.1 Type-P-One-Way-Loss-Noticeable-Rate
	Define loss of a packet to be "noticeable" [RK97] if the distance		Define loss of a packet to be "noticeable" [RK97] if the distance
	between the lost packet and the previously lost packet is no		between the lost packet and the previously lost packet is no
	greater than delta, a positive integer, where delta is the		greater than delta, a positive integer, where delta is the
	"loss constraint".		"loss constraint".
	Example. Let delta = 100. Let us assume that packet 50 is lost		Example. Let delta = 99. Let us assume that packet 50 is lost
	followed by a bursty loss of length 3 starting from		followed by a bursty loss of length 3 starting from
	packet 125.		packet 125.
	All the *four* losses are noticeable.		All the *four* losses are noticeable.
	Given a Type-P-One-Way-Loss-Distance-Stream, this statistic		Given a Type-P-One-Way-Loss-Distance-Stream, this statistic
	can be computed simply as the number of losses that violate some		can be computed simply as the number of losses that violate some
	constraint delta, divided by the number of losses. (Alternately, it		constraint delta, divided by the number of losses. (Alternately, it
	can also be defined as the number of "noticeable losses" to the number		can also be defined as the number of "noticeable losses" to the number
	of successfully received packets).		of successfully received packets).
			This statistic is useful when the actual distance between successive
			losses is important. For example, many multimedia codecs can sustain
			losses by "concealing" the effect of loss by making use of past
			history information. Their ability to do so degrades with poor
			history resulting from losses separated by close distances. By chosing
			delta based on this sensitivity, one can measure how "noticeable" a
			loss might be for quality purposes. The noticeable loss requires
			a certain "spread factor" for losses in the timeseries. In the above
			example where loss constraint is equal to 99, a loss rate of one
			percent with a spread of 100 between losses (e.g., 100, 200, 300,
			400, 500 out of 500 packets) may be more desirable for some
			applications compared to the same loss rate with a spread that
			violates the loss constraint (e.g., 100, 175, 275, 290, 400: losses
			occuring at 175 and 290 violate delta = 99).
	5.2 Type-P-One-Way-Loss-Period-Total		5.2 Type-P-One-Way-Loss-Period-Total
	This represents the total number of loss periods, and can be derived		This represents the total number of loss periods, and can be derived
	from the loss period metric Type-P-One-Way-Loss-Period-Stream as		from the loss period metric Type-P-One-Way-Loss-Period-Stream as
	follows:		follows:
	Type-P-One-Way-Loss-Period-Total = maximum value of the first entry		Type-P-One-Way-Loss-Period-Total = maximum value of the first entry
	of the set of pairs, <loss period, loss>, representing the loss metric		of the set of pairs, <loss period, loss>, representing the loss metric
	Type-P-One-Way-Loss-Period-Stream.		Type-P-One-Way-Loss-Period-Stream.
	5.3 Type-P-One-Way-Loss-Period-Lengths		5.3 Type-P-One-Way-Loss-Period-Lengths
	This statistic is a sequence of pairs <loss period, length>, with the		This statistic is a sequence of pairs <loss period, length>, with the
	"loss period" entry ranging from 1 - Type-P-One-Way-Loss-Period-Total.		"loss period" entry ranging from 1 - Type-P-One-Way-Loss-Period-Total.
	Thus the total number of pairs in this statistic equals		Thus the total number of pairs in this statistic equals
	Type-P-One-Way-Loss-Period-Total. In each pair, the "length" is		Type-P-One-Way-Loss-Period-Total. In each pair, the "length" is
	obtained by counting the number of pairs, <loss period, loss>, in the		obtained by counting the number of pairs, <loss period, loss>, in the
	metric Type-P-One-Way-Loss-Period-Stream which have first entry equal		metric Type-P-One-Way-Loss-Period-Stream which have first entry equal
	to "loss period."		to "loss period."
	{Note: This statistic represents the number of packets lost in each		Thus, this statistic represents the number of packets lost in each
	loss period.}		loss period.
	5.4 Type-P-One-Way-Inter-Loss-Period-Lengths		5.4 Type-P-One-Way-Inter-Loss-Period-Lengths
	This statistic measures distance between successive loss periods. It		This statistic measures distance between successive loss periods. It
	takes the form of a set of pairs		takes the form of a set of pairs
	<loss period, inter-loss-period-length>, with the		<loss period, inter-loss-period-length>, with the
	"loss period" entry ranging from 1 - Type-P-One-Way-Loss-Period-Total,		"loss period" entry ranging from 1 - Type-P-One-Way-Loss-Period-Total,
	and "inter-loss-period-length" is the loss distance between the last		and "inter-loss-period-length" is the loss distance between the last
	packet considered lost in "loss period" 'i-1', and the first packet		packet considered lost in "loss period" 'i-1', and the first packet
	considered lost in "loss period" 'i', where 'i' ranges from 2 to		considered lost in "loss period" 'i', where 'i' ranges from 2 to
	skipping to change at page 9, line 4		skipping to change at page 9, line 18
	error control for Packet Audio in the Internet", ACM Multimedia		error control for Packet Audio in the Internet", ACM Multimedia
	Systems, 1997.		Systems, 1997.
	[Borella] M. S. Borella, D. Swider, S. Uludag, and G. B. Brewster,		[Borella] M. S. Borella, D. Swider, S. Uludag, and G. B. Brewster,
	"Internet Packet Loss: Measurement and Implications for End-to-End		"Internet Packet Loss: Measurement and Implications for End-to-End
	QoS," Proceedings, International Conference on Parallel Processing,		QoS," Proceedings, International Conference on Parallel Processing,
	August 1998.		August 1998.
	[Handley] M. Handley, "An examination of MBONE performance",		[Handley] M. Handley, "An examination of MBONE performance",
	Technical Report, USC/ISI, ISI/RR-97-450, January 1997		Technical Report, USC/ISI, ISI/RR-97-450, January 1997
	[RK97] R. Koodli, "Scheduling Support for Multi-tier Quality of		[RK97] R. Koodli, "Scheduling Support for Multi-tier Quality of
	Service in Continuous Media Applications", PhD dissertation,		Service in Continuous Media Applications", PhD dissertation,
	Electrical and Computer Engineering Department, University of		Electrical and Computer Engineering Department, University of
	Massachusetts, Amherst, MA 01003.		Massachusetts, Amherst, MA 01003.
	ftp://aurelius.ecs.umass.edu/pub/koodli/thesis.ps.Z
	[Padhye1] J. Padhye, V. Firoiu, J. Kurose and D. Towsley, "Modeling		[Padhye1] J. Padhye, V. Firoiu, J. Kurose and D. Towsley, "Modeling
	TCP throughput: a simple model and its empirical validation", in		TCP throughput: a simple model and its empirical validation", in
	Proceedings of SIGCOMM'98, 1998.		Proceedings of SIGCOMM'98, 1998.
	[Padhye2] J. Padhye, J. Kurose, D. Towsley and R. Koodli, "A		[Padhye2] J. Padhye, J. Kurose, D. Towsley and R. Koodli, "A
	TCP-friendly rate adjustment protocol for continuous media flows		TCP-friendly rate adjustment protocol for continuous media flows
	over best-effort networks", short paper presentation in		over best-effort networks", short paper presentation in
	ACM SIGMETRICS'99. Available as Umass Computer Science tech report		ACM SIGMETRICS'99. Available as Umass Computer Science tech report
	from ftp://gaia.cs.umass.edu/pub/Padhye98-tcp-friendly-TR.ps.gz		from ftp://gaia.cs.umass.edu/pub/Padhye98-tcp-friendly-TR.ps.gz
	skipping to change at page 9, line 40		skipping to change at line 451
	833-846		833-846
	[Yajnik] M. Yajnik, J. Kurose and D. Towsley, "Packet loss		[Yajnik] M. Yajnik, J. Kurose and D. Towsley, "Packet loss
	correlation in the MBONE multicast network", Proceedings of IEEE		correlation in the MBONE multicast network", Proceedings of IEEE
	Global Internet, London, UK, November 1996.		Global Internet, London, UK, November 1996.
	Author's Addresses		Author's Addresses
	Rajeev Koodli		Rajeev Koodli
	Nokia Research Center		Nokia Research Center
	3, Burlington Woods Drive, #250		313, Fairchild Drive
	Burlington, MA 01803		Mountain View, CA 94043
	Phone: +1 781-359-5136		Phone: +1 650-625-2359
	Email: rajeev.koodli@nokia.com		Email: rajeev.koodli@nokia.com
	Rayadurgam Ravikanth		Rayadurgam Ravikanth
	Nokia Research Center		Nokia Research Center
	3, Burlington Woods Drive, #250		5, Wayside Road
	Burlington, MA 01803		Burlington, MA 01803
	Phone: +1 781-238-4905		Phone: +1 781-993-4606
	Email: rayadurgam.ravikanth@nokia.com		Email: rayadurgam.ravikanth@nokia.com
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/