draft-ietf-ippm-loss-pattern-00.txt		draft-ietf-ippm-loss-pattern-01.txt
	Internet-Draft		Internet-Draft
	Expiration Date: September, 1999 R. Koodli		Expiration Date: December, 1999 R. Koodli
	R. Ravikanth		R. Ravikanth
	Nokia Research Center		Nokia Research Center
	March, 1999		June, 1999
	One-way Loss Pattern Sample Metrics		One-way Loss Pattern Sample Metrics
	<draft-ietf-ippm-loss-pattern-00.txt>		<draft-ietf-ippm-loss-pattern-01.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 Engineerin 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.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference material		time. It is inappropriate to use Internet-Drafts as reference material
	or to cite them other than as "work in progress."		or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	skipping to change at page 1, line 42		skipping to change at page 1, line 41
	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.
	Abstract		Abstract
	The Internet exhibits certain specific types of behavior (e.g., bursty		The Internet exhibits certain specific types of behavior (e.g., bursty
	packet loss) that can affect the performance seen by the users as		packet loss) that can affect the performance seen by the users as
	well as the operators. Currently, the focus has been on specifying		well as the operators. Currently, the focus has been on specifying
	base metrics such as delay, loss and connectivity under the		base metrics such as delay, loss and connectivity under the
	framework described in [frame-work]. It would be useful to capture		framework described in [frame-work]. It is useful to capture
	specific Internet behaviors under the umbrella of IPPM framework,		specific Internet behaviors under the umbrella of IPPM framework,
	specifying new concepts while reusing existing guidelines as much as		specifying new concepts while reusing existing guidelines as much as
	possible. This draft proposes the use of "derived metrics" to		possible. This draft proposes the use of "derived metrics" to
	accomplish this, specifically providing means for capturing the loss		accomplish this, specifically providing means for capturing the loss
	pattern on the Internet.		pattern on the Internet.
	1. Introduction		1. Introduction
	In certain real-time applications (such as packet voice and video),		In certain real-time applications (such as packet voice and video),
	the loss pattern or loss distribution is a key parameter		the loss pattern or loss distribution is a key parameter
	that determines the performance observed by the users. For the same		that determines the performance observed by the users. For the same
	loss rate, two different loss distributions could potentially produce		loss rate, two different loss distributions could potentially produce
	widely different perceptions of performance. The impact of loss pattern		widely different perceptions of performance. The impact of loss pattern
	is also extremely important for non-real-time applications that use		is also extremely important for non-real-time applications that use
	an adaptive protocol such as TCP. There is ample evidence in the		an adaptive protocol such as TCP. There is ample evidence in the
	literature indicating the importance and existence of loss burstiness		literature indicating the importance and existence of loss burstiness
	and its effect on packet voice and video applications		and its effect on packet voice and video applications
	[Bolot], [Borella], [Handley], [Paxson], [Yajnik].		[Bolot], [Borella], [Handley], [Yajnik].
	In this document, we propose two "derived metrics" -- loss distance		In this document, we propose two derived metrics, called "loss distance"
	and loss periods -- and associated statistics which		and "loss period", with associated statistics, to capture packet loss
	capture the loss pattern and help derive statistics reflecting the same.		patterns. The loss period metric captures the frequency and length
	The loss period metric captures the frequency and length (burstiness) of		(burstiness) of loss once it starts, and the loss distance metric
	loss once it starts, and the loss distance captures the spacing between		captures the spacing between the loss periods. It is important to note
	the loss periods. It is important to note that these metrics are		that these metrics are derived based on the base metric
	derived based on the base metric Type-P-One-Way-packet-Loss.		Type-P-One-Way-packet-Loss.
	2. The Approach		2. The Approach
	This draft closely follows the guidelines specified in [frame-work].		This document closely follows the guidelines specified in [frame-work].
	Specifically, the concepts of a "singleton, sample, statistic",		Specifically, the concepts of "singleton, sample, statistic",
	measurement principles, Type P packets, as well as Standard formed		measurement principles, Type-P packets, as well as standard-formed
	packets all apply. However, since the draft proposes to capture		packets all apply. However, since the draft proposes to capture
	specific Internet behaviors, modifications to the sampling process		specific Internet behaviors, modifications to the sampling process
	may be needed. Indeed, this is mentioned in [AKZ], where it is noted		may be needed. Indeed, this is mentioned in [AKZ], where it is noted
	that alternate sampling procedures may be useful depending on specific		that alternate sampling procedures may be useful depending on specific
	circumstances. This draft proposes that the specific behaviors be		circumstances. This draft proposes that the specific behaviors be
	captured as "derived" metrics from the base metrics the behaviors		captured as "derived" metrics from the base metrics the behaviors
	are related to. The reasons for adopting this position are the		are related to. The reasons for adopting this position are the
	following		following
	- it provides consistent usage of singleton metric definition for		- it provides consistent usage of singleton metric definition for
	different behaviors (e.g., a single definition of packet loss		different behaviors (e.g., a single definition of packet loss
	is needed for capturing burst of losses, 'm out of n' losses		is needed for capturing burst of losses, 'm out of n' losses
	etc. Otherwise, the metrics would have to be fundamentally		etc. Otherwise, the metrics would have to be fundamentally
	different)		different)
	- it allows re-use of the methodologies specified for the singleton		- it allows re-use of the methodologies specified for the singleton
	metric with additions whenever necessary		metric with modifications whenever necessary
	- it clearly separates few base metrics from many Internet behaviors		- it clearly separates few base metrics from many Internet behaviors
	and provides a suitable place-holder.
	Following the guidelines in [frame-work], this		Following the guidelines in [frame-work], this
	translates to deriving *sample* metrics from the respective		translates to deriving *sample* metrics from the respective
	singletons. The process of deriving sample metrics from the singletons		singletons. The process of deriving sample metrics from the singletons
	is specified in [frame-work], [AKZ], and others.		is specified in [frame-work], [AKZ], and others.
	In the following sections, we apply this approach to a particular		In the following sections, we apply this approach to a particular
	Internet behavior, namely the packet loss process.		Internet behavior, namely the packet loss process.
	3. Basic Definitions:		3. Basic Definitions:
	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
			associate sequence numbers with test packets. In other words, from
			a timeseries sample of test packets, one may derive the sequence
			numbers. For example, assign consecutive integers to each packet in
			the time series.}
	3.3. Loss period:		3.3. Loss period:
	Define f(Pi) = 1 if a packet 'i' is lost, 0 otherwise.		Let P_i be the i'th packet.
	Then, a loss period begins if f(Pi) = 1 and f(P(i-1)) = 0		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
	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.
	r r r x r r x x x r x r r x x x		r r r x r r x x x r x r r x x x
	There are four loss periods in the above sequence.		Then, with i assigned as follows
			1 1 1 1 1 1
			i: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
			f(P_i) is,
			f(P_i): 0 0 0 1 0 1 0 0 0 1 0 1 1 0 0 0
			and there are four loss periods in the above sequence
			begining at P_3, P_6, P_10, and P_13.
	4. Definitions for Samples of One-way Loss Distance,		4. Definitions for Samples of One-way Loss Distance,
	and One-way Loss Period.		and One-way Loss Period.
	4.1 Metric Name:		4.1 Metric Name:
	4.1.1 Type-P-One-Way-Loss-Distance-Stream		4.1.1 Type-P-One-Way-Loss-Distance-Stream
	4.1.2 Type-P-One-Way-Loss-Period-Stream		4.1.2 Type-P-One-Way-Loss-Period-Stream
	4.2 Metric Parameters		4.2 Metric Parameters
	+ 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
	+ T0, a time		+ T0, a time
	+ Tf, a time		+ Tf, a time
	+ lambda, a rate in reciprocal of seconds		+ lambda, a rate in reciprocal of seconds
	+ Path, the path from Src to Dst (See [AKZ] for comments)		+ Path, the path from Src to Dst (See [AKZ] for comments)
	+ Seq, the sequence number (an integer) of test packet
	4.3 Metric Units		4.3 Metric Units
	4.3.1 Type-P-One-Way-Loss-Distance-Stream:		4.3.1 Type-P-One-Way-Loss-Distance-Stream:
	A sequence of pairs of the form <loss distance, loss>, where loss		A sequence of pairs of the form <loss distance, loss>, where loss
	is derived from the sequence of <time, loss> in [AKZ], and loss		is derived from the sequence of <time, loss> in [AKZ], and loss
	distance is either zero or a positive integer.		distance is either zero or a positive integer.
	4.3.2 Type-P-One-Way-Loss-Period-Stream		4.3.2 Type-P-One-Way-Loss-Period-Stream
	A sequence of pairs of the form <loss period, loss>, where loss is		A sequence of pairs of the form <loss period, loss>, where loss is
	derived from the sequence of <time, loss> in [AKZ], and loss period		derived from the sequence of <time, loss> in [AKZ], and loss period
	an integer.		an integer.
	4.4. Definitions:		4.4. Definitions:
	skipping to change at page 4, line 24		skipping to change at page 4, line 38
	4.4. Definitions:		4.4. Definitions:
	4.4.1 Type-P-One-Way-Loss-Distance-Stream		4.4.1 Type-P-One-Way-Loss-Distance-Stream
	When a packet is considered lost (using the definition in [AKZ]), we		When a packet is considered lost (using the definition in [AKZ]), we
	look at its sequence number and compare it with that of the		look at its sequence number and compare it with that of the
	previously lost packet. The difference is the loss distance between		previously lost packet. The difference is the loss distance between
	the lost packet and the previously lost packet. The sample would		the lost packet and the previously lost packet. The sample would
	consist of <loss distance, loss> pairs. This definition assumes that		consist of <loss distance, loss> pairs. This definition assumes that
	sequence numbers of successive test packets increase monotonically by		sequence numbers of successive test packets increase monotonically by
	one.		one. The loss distance associated with the very first packet loss is
	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
			sample collected by performing the loss measurement according to the
			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
			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.
	{Packet loss may also be considered as a result of exceeding some delay		{Packet loss may also be considered as a result of exceeding some delay
	threshold. This is particularly applicable to delay-sensitive audio		threshold. This is particularly applicable to delay-sensitive audio
	(or video) applications.		(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 [AKZ], and		"loss" is derived from the sequence of <time, loss> in
	loss period is set to zero when "loss"=0, and is set to "n"		Type-P-One-Way-Loss-Stream [AKZ], and
	when "loss"=1.		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)
			when "loss" is one in Type-P-One-Way-Loss-Stream.
	{Note: When a packet is lost, the current value of "n" indicates the		{Note: When a packet is lost, the current value of "n" indicates the
	loss period to which this packet belongs. For a packet that is		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>,
	skipping to change at page 5, line 4		skipping to change at page 5, line 28
	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.
	Packets sent at T2, T5, T7, T9, T10 are lost. The two derived metrics		Packets sent at T2, T5, T7, T9, T10 are lost. The two derived metrics
	can be obtained from this sample as follows.		can be obtained from this sample as follows.
	(i) Type-P-One-Way-Loss-Distance-Stream:		(i) Type-P-One-Way-Loss-Distance-Stream:
			Since packet 2 is the first lost packet, the associated loss distance
			is zero. For the next lost packet (packet 5), loss distance is 5-2 or 3.
			Similarly, for the remaining lost packets (packets 7, 9, and 10) their
			loss distances are 2, 2, and 1 respectively. Therefore, the
			Type-P-One-Way-Loss-Distance-Stream is:
	{<0,0>,<0,1>,<0,0>,<0,0>,<3,1>,<0,0>,<2,1>,<0,0>,<2,1>,<1,1>}		{<0,0>,<0,1>,<0,0>,<0,0>,<3,1>,<0,0>,<2,1>,<0,0>,<2,1>,<1,1>}
	(ii) The Type-P-One-Way-Loss-Period-Stream:		(ii) The Type-P-One-Way-Loss-Period-Stream:
			The packet 2 sets the counter 'n' to 1, which is incremented by one
			for packets 5, 7 and 9 according to Definition 3.3. However, for
			packet 10, the counter remains at 4 satisfying Definition 3.3 again.
			Thus, the Type-P-One-Way-Loss-Period-Stream is:
	{<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>}		{<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>}
	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
	skipping to change at page 5, line 48		skipping to change at page 6, line 33
	TCP-based applications. For real-time applications, it may be more		TCP-based applications. For real-time applications, it may be more
	appropriate to use the ON-OFF [Sriram] model, in which an ON period		appropriate to use the ON-OFF [Sriram] model, in which an ON period
	starts with certain probability 'p', during which certain number of		starts with certain probability 'p', during which certain number of
	packets are transmitted with mean 'lambda-on' according to geometric		packets are transmitted with mean 'lambda-on' according to geometric
	distribution and an OFF period starts with probability '1-p' and		distribution and an OFF period starts with probability '1-p' and
	lasts for a period of time based on exponential distribution with		lasts for a period of time based on exponential distribution with
	rate 'lambda-off'.		rate 'lambda-off'.
	For TCP-based applications, one may use the model proposed in		For TCP-based applications, one may use the model proposed in
	[Padhye1]. See [Padhye2] for an application of the model.		[Padhye1]. See [Padhye2] for an application of the model.
	4.8 Errors and Uncertainities:
	Care must be taken (if)when the sequence numbers wrap around,
	since the computation of loss distance depends on correct sequence
	numbers.
	5. Statistics:		5. Statistics:
	5.1 Type-P-One-Way-Noticeable-Loss-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 = 100. 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.
	skipping to change at page 6, line 53		skipping to change at page 7, line 28
	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		{Note: This statistic represents the number of packets lost in each
	loss period.}		loss period.}
	5.4 Example		5.4 Example
	We continue with the same example as in Section 3.4.2. The three		We continue with the same example as in Section 4.4.3. The three
	statistics defined above will have the following values.		statistics defined above will have the following values.
	Type-P-One-Way-Noticeable-Loss-Rate: 3/5		+ Let delta = 2.
			In Type-P-One-Way-Loss-Distance-Stream
			{<0,0>,<0,1>,<0,0>,<0,0>,<3,1>,<0,0>,<2,1>,<0,0>,<2,1>,<1,1>}, there
			are 3 loss distances that violate the delta of 2. Thus,
			Type-P-One-Way-Loss-Noticeable-Rate = 3/5
	(( number of noticeable losses)/(number of total losses))		(( number of noticeable losses)/(number of total losses))
	Type-P-One-Way-Loss-Period-Total: 4		+ In Type-P-One-Way-Loss-Period-Stream
	(largest of the first entry in the sequence of		{<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>}, the
	<loss period,loss> pairs).		largest of the first entry in the sequence of <loss period,loss>
			pairs is 4. Thus,
	Type-P-One-Way-Loss-Period-Lengths: The sequence		Type-P-One-Way-Loss-Period-Total = 4
	{<1,1>,<2,1>,<3,1>,<4,2>}
	6. References		+ In Type-P-One-Way-Loss-Period-Stream
			{<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>}, the
			lengths of individual loss periods are 1, 1, 1 and 2 respectively.
			Thus,
			Type-P-One-Way-Loss-Period-Lengths = {<1,1>,<2,1>,<3,1>,<4,2>}
			6. Security Considerations
			Since this draft proposes sample metrics based on the base loss metric
			defined in [AKZ], it inherits the security considerations mentioned in
			[AKZ].
			7. Acknowledgements
			Many thanks to Matt Zekauskas for the constructive feedback on the draft.
			Thanks to Guy Almes for encouraging the work, and Vern Paxson for all the
			comments during the IETF meetings.
			8. References
	[AKZ] G. Almes and S. Kalindindi and M. Zekauskas, "A One-way Packet		[AKZ] G. Almes and S. Kalindindi and M. Zekauskas, "A One-way Packet
	Loss Metric for IPPM", Internet Draft <draft-ietf-ippm-loss-05.txt>,		Loss Metric for IPPM", Internet Draft <draft-ietf-ippm-loss-07.txt>,
	November 1998		May 1999
	[Bolot] J.-C. Bolot and A. vega Garcia, "The case for FEC-based		[Bolot] J.-C. Bolot and A. vega Garcia, "The case for FEC-based
	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.
	skipping to change at line 370		skipping to change at line 418
	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		3, Burlington Woods Drive, #250
	Burlington, MA 01803		Burlington, MA 01803
	Phone: +1 781-359-5136		Phone: +1 781-359-5136
	Email: rajeev.koodli@research.nokia.com		Email: rajeev.koodli@nokia.com
	Rayadurgam Ravikanth		Rayadurgam Ravikanth
	Nokia Research Center		Nokia Research Center
	3, Burlington Woods Drive, #250		3, Burlington Woods Drive, #250
	Burlington, MA 01803		Burlington, MA 01803
	Phone: +1 781-238-4905		Phone: +1 781-238-4905
	Email: rayadurgam.ravikanth@research.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/