draft-ietf-ippm-2679-bis-00.txt		draft-ietf-ippm-2679-bis-01.txt
	Network Working Group G. Almes		Network Working Group G. Almes
	Internet-Draft Texas A&M		Internet-Draft Texas A&M
	Obsoletes: 2679 (if approved) S. Kalidindi		Obsoletes: 2679 (if approved) S. Kalidindi
	Intended status: Standards Track Ixia		Intended status: Standards Track Ixia
	Expires: April 26, 2015 M. Zekauskas		Expires: July 30, 2015 M. Zekauskas
	Internet2		Internet2
	A. Morton, Ed.		A. Morton, Ed.
	AT&T Labs		AT&T Labs
	October 23, 2014		January 26, 2015
	A One-Way Delay Metric for IPPM		A One-Way Delay Metric for IPPM
	draft-ietf-ippm-2679-bis-00		draft-ietf-ippm-2679-bis-01
	Abstract		Abstract
	This memo (RFC 2679 bis) defines a metric for one-way delay of		This memo (RFC 2679 bis) defines a metric for one-way delay of
	packets across Internet paths. It builds on notions introduced and		packets across Internet paths. It builds on notions introduced and
	discussed in the IPPM Framework document, RFC 2330; the reader is		discussed in the IPPM Framework document, RFC 2330; the reader is
	assumed to be familiar with that document.		assumed to be familiar with that document.
	Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	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		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 26, 2015.		This Internet-Draft will expire on July 30, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 3, line 14		skipping to change at page 3, line 4
	5.1. Type-P-One-way-Delay-Percentile . . . . . . . . . . . . . 19		5.1. Type-P-One-way-Delay-Percentile . . . . . . . . . . . . . 19
	5.2. Type-P-One-way-Delay-Median . . . . . . . . . . . . . . . 20		5.2. Type-P-One-way-Delay-Median . . . . . . . . . . . . . . . 20
	5.3. Type-P-One-way-Delay-Minimum . . . . . . . . . . . . . . 21		5.3. Type-P-One-way-Delay-Minimum . . . . . . . . . . . . . . 21
	5.4. Type-P-One-way-Delay-Inverse-Percentile . . . . . . . . . 21		5.4. Type-P-One-way-Delay-Inverse-Percentile . . . . . . . . . 21
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 21		6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
	9.1. Normative References . . . . . . . . . . . . . . . . . . 22		9.1. Normative References . . . . . . . . . . . . . . . . . . 22
	9.2. Informative References . . . . . . . . . . . . . . . . . 23		9.2. Informative References . . . . . . . . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
	1. RFC 2679 bis		1. RFC 2679 bis
	The following text constitutes RFC 2769 bis proposed for advancement		The following text constitutes RFC 2769 bis proposed for advancement
	on the IETF Standards Track. This section tracks the changes from		on the IETF Standards Track. This section tracks the changes from
	[RFC2679].		[RFC2679].
	[RFC6808] provides the test plan and results supporting [RFC2679]		[RFC6808] provides the test plan and results supporting [RFC2679]
	advancement along the standards track, according to the process in		advancement along the standards track, according to the process in
	[RFC6576]. The conclusions of [RFC6808] list four minor		[RFC6576]. The conclusions of [RFC6808] list four minor
	skipping to change at page 4, line 4		skipping to change at page 3, line 42
	incorporate recent experience where appropriate (see the last		incorporate recent experience where appropriate (see the last
	list item of section 3.6, section 3.8, and section 5 below).		list item of section 3.6, section 3.8, and section 5 below).
	4. There is currently one erratum with status "Held for document		4. There is currently one erratum with status "Held for document
	update" for [RFC2679], and it appears this minor revision and		update" for [RFC2679], and it appears this minor revision and
	additional text should be incorporated in RFC2679bis (see section		additional text should be incorporated in RFC2679bis (see section
	5.1).		5.1).
	A number of updates to the [RFC2679] text have been implemented in		A number of updates to the [RFC2679] text have been implemented in
	the text below, to reference key IPPM RFCs that were approved after		the text below, to reference key IPPM RFCs that were approved after
	[RFC2679], and to address comments on the IPPM mailing list		[RFC2679], and to address comments on the IPPM mailing list
	describing current conditions and experience.		describing current conditions and experience.
	1. Near the end of section 2.1, update of a network example using		1. Add that RFC2330 was updated by RFC7312 in the Introduction
			(section 2).
			2. Near the end of section 2.1, update of a network example using
	ATM and clarification of TCP's affect on queue occupation and		ATM and clarification of TCP's affect on queue occupation and
	importance of one-way delay measurement.		importance of one-way delay measurement.
	2. Explicit inclusion of the maximum waiting time input parameter		3. Explicit inclusion of the maximum waiting time input parameter
	in section 3.2 and 4.2, reflecting recognition of this parameter		in section 3.2 and 4.2, reflecting recognition of this parameter
	in more recent RFCs and ITU-T Recommendation Y.1540.		in more recent RFCs and ITU-T Recommendation Y.1540.
	3. Addition of reference to RFC6703 in the discussion of packet		4. Addition of reference to RFC6703 in the discussion of packet
	life time and application timeouts in section 3.5.		life time and application timeouts in section 3.5.
	4. Addition of reference to the default requirement (that packets		5. Addition of reference to the default requirement (that packets
	be standard-formed) from RFC2330 as a new list item in section		be standard-formed) from RFC2330 as a new list item in section
	3.5.		3.5.
	5. GPS-based NTP experience replaces "to be tested" in section 3.5.		6. GPS-based NTP experience replaces "to be tested" in section 3.5.
	6. Added parenthetical guidance on minimizing interval between		7. Replaced "precedence" with updated terminology (DS Field) in 3.6
			and 3.8.1 (with reference).
			8. Added parenthetical guidance on minimizing interval between
	timestamp placement to send time in section 3.6.		timestamp placement to send time in section 3.6.
	7. Added text recognizing the impending deployment of transport		9. Added text recognizing the impending deployment of transport
	layer encryption in section 3.6.		layer encryption in section 3.6.
	8. Section 3.7.2 notes that some current systems perform host time		10. Section 3.7.2 notes that some current systems perform host time
	stamping on the network interface hardware.		stamping on the network interface hardware.
	9. "instrument" replaced by the defined term "host" in sections		11. "instrument" replaced by the defined term "host" in sections
	3.7.3 and 3.8.3.		3.7.3 and 3.8.3.
	10. Added reference to RFC 3432 Periodic sampling alongside Poisson		12. Added reference to RFC 3432 Periodic sampling alongside Poisson
	sampling in section 4, and also noting that a truncated Poisson		sampling in section 4, and also noting that a truncated Poisson
	distribution may be needed with modern networks as described in		distribution may be needed with modern networks as described in
	the IPPM Framework update, RFC7312.		the IPPM Framework update, RFC7312.
	11. Add reference to RFC 4737 Reordering metric in the related		13. Add reference to RFC 4737 Reordering metric in the related
	discussion of section 4.6, Methodologies.		discussion of section 4.6, Methodologies.
	12. Clarifying the conclusions on two related points on harm to		14. Formatting of Example in section 5.1 modified to match the
			original (issue with conversion to XML in bis version).
			15. Clarifying the conclusions on two related points on harm to
	measurements (recognition of measurement traffic for unexpected		measurements (recognition of measurement traffic for unexpected
	priority treatment and attacker traffic which emulates		priority treatment and attacker traffic which emulates
	measurement) in section 6, Security Considerations.		measurement) in section 6, Security Considerations.
	Section 5.4.4 of [RFC6390] suggests a common template for performance		Section 5.4.4 of [RFC6390] suggests a common template for performance
	metrics partially derived from previous IPPM and BMWG RFCs, but also		metrics partially derived from previous IPPM and BMWG RFCs, but also
	contains some new items. All of the [RFC6390] Normative points are		contains some new items. All of the [RFC6390] Normative points are
	covered, but not quite in the same section names or orientation.		covered, but not quite in the same section names or orientation.
	Several of the Informative points are covered. Maintaining the		Several of the Informative points are covered. Maintaining the
	familiar outline of IPPM literature has both value and minimizes		familiar outline of IPPM literature has both value and minimizes
	unnecessary differences between this revised RFC and current/future		unnecessary differences between this revised RFC and current/future
	IPPM RFCs.		IPPM RFCs.
	The publication of RFC 6921 suggested an area where this memo might		The publication of RFC 6921 suggested an area where this memo might
	need updating. Packet transfer on Faster-Than-Light (FTL) networks		need updating. Packet transfer on Faster-Than-Light (FTL) networks
	could result in negative delays and packet reordering, however both		could result in negative delays and packet reordering, however both
	are covered as possibilities in the current text and no revisions are		are covered as possibilities in the current text and no revisions are
	deemed necessary (we also note that this is an April 1st RFC).		deemed necessary (we also note that this is an April 1st RFC).
	skipping to change at page 5, line 21		skipping to change at page 5, line 21
	need updating. Packet transfer on Faster-Than-Light (FTL) networks		need updating. Packet transfer on Faster-Than-Light (FTL) networks
	could result in negative delays and packet reordering, however both		could result in negative delays and packet reordering, however both
	are covered as possibilities in the current text and no revisions are		are covered as possibilities in the current text and no revisions are
	deemed necessary (we also note that this is an April 1st RFC).		deemed necessary (we also note that this is an April 1st RFC).
	2. Introduction		2. Introduction
	This memo defines a metric for one-way delay of packets across		This memo defines a metric for one-way delay of packets across
	Internet paths. It builds on notions introduced and discussed in the		Internet paths. It builds on notions introduced and discussed in the
	IPPM Framework document, [RFC2330]; the reader is assumed to be		IPPM Framework document, [RFC2330]; the reader is assumed to be
	familiar with that document.		familiar with that document, and its recent update [RFC7312].
	This memo is intended to be parallel in structure to a companion		This memo is intended to be parallel in structure to a companion
	document for Packet Loss ("A One-way Packet Loss Metric for IPPM")		document for Packet Loss ("A One-way Packet Loss Metric for IPPM")
	[RFC2680].		[RFC2680].
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in RFC 2119 [RFC2119].
	Although [RFC2119] was written with protocols in mind, the key words		Although [RFC2119] 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.
	The structure of the memo is as follows:		The structure of the memo is as follows:
	+ A 'singleton' analytic metric, called Type-P-One-way-Delay, will be		+ A 'singleton' analytic metric, called Type-P-One-way-Delay, will be
	introduced to measure a single observation of one-way delay.		introduced to measure a single observation of one-way delay.
	skipping to change at page 10, line 16		skipping to change at page 10, line 16
	does not occur, then the packet will be deemed lost.		does not occur, then the packet will be deemed lost.
	+ The packet is standard-formed, the default criteria for all metric		+ The packet is standard-formed, the default criteria for all metric
	definitions defined in Section 15 of [RFC2330], otherwise the packet		definitions defined in Section 15 of [RFC2330], otherwise the packet
	will be deemed lost.		will be deemed lost.
	3.6. Methodologies:		3.6. Methodologies:
	As with other Type-P-* metrics, the detailed methodology will depend		As with other Type-P-* metrics, the detailed methodology will depend
	on the Type-P (e.g., protocol number, UDP/TCP port number, size,		on the Type-P (e.g., protocol number, UDP/TCP port number, size,
	precedence).		Differentiated Services (DS) Field [RFC2780]).
	Generally, for a given Type-P, the methodology would proceed as		Generally, for a given Type-P, the methodology would proceed as
	follows:		follows:
	+ Arrange that Src and Dst are synchronized; that is, that they have		+ Arrange that Src and Dst are synchronized; that is, that they have
	clocks that are very closely synchronized with each other and each		clocks that are very closely synchronized with each other and each
	fairly close to the actual time.		fairly close to the actual time.
	+ At the Src host, select Src and Dst IP addresses, and form a test		+ At the Src host, select Src and Dst IP addresses, and form a test
	packet of Type-P with these addresses. Any 'padding' portion of the		packet of Type-P with these addresses. Any 'padding' portion of the
	skipping to change at page 15, line 50		skipping to change at page 15, line 50
	interpreting applications of the metrics should also be reported (see		interpreting applications of the metrics should also be reported (see
	[RFC6703] for extensive discussion of reporting considerations for		[RFC6703] for extensive discussion of reporting considerations for
	different audiences).		different audiences).
	3.8.1. Type-P		3.8.1. Type-P
	As noted in the Framework document [RFC2330], the value of the metric		As noted in the Framework document [RFC2330], the value of the metric
	may depend on the type of IP packets used to make the measurement, or		may depend on the type of IP packets used to make the measurement, or
	"type-P". The value of Type-P-One-way-Delay could change if the		"type-P". The value of Type-P-One-way-Delay could change if the
	protocol (UDP or TCP), port number, size, or arrangement for special		protocol (UDP or TCP), port number, size, or arrangement for special
	treatment (e.g., IP precedence or RSVP) changes. The exact Type-P		treatment (e.g., IP DS Field [RFC2780] or RSVP) changes. The exact
	used to make the measurements MUST be accurately reported.		Type-P used to make the measurements MUST be accurately reported.
	3.8.2. Loss Threshold		3.8.2. Loss Threshold
	In addition, the threshold (or methodology to distinguish) between a		In addition, the threshold (or methodology to distinguish) between a
	large finite delay and loss MUST be reported.		large finite delay and loss MUST be reported.
	3.8.3. Calibration Results		3.8.3. Calibration Results
	+ If the systematic error can be determined, it SHOULD be removed		+ If the systematic error can be determined, it SHOULD be removed
	from the measured values.		from the measured values.
	skipping to change at page 17, line 13		skipping to change at page 17, line 13
	Poisson process of rate lambda, whose values fall between T0 and Tf.		Poisson process of rate lambda, whose values fall between T0 and Tf.
	The time interval between successive values of T will then average 1/		The time interval between successive values of T will then average 1/
	lambda.		lambda.
	Note that Poisson sampling is only one way of defining a sample.		Note that Poisson sampling is only one way of defining a sample.
	Poisson has the advantage of limiting bias, but other methods of		Poisson has the advantage of limiting bias, but other methods of
	sampling will be appropriate for different situations. For example,		sampling will be appropriate for different situations. For example,
	a truncated Poisson distribution may be needed to avoid reactive		a truncated Poisson distribution may be needed to avoid reactive
	network state changes during intervals of inactivity, see section 4.6		network state changes during intervals of inactivity, see section 4.6
	of [RFC7321]. Sometimes, the goal is sampling with a known bias, and		of [RFC7312]. Sometimes, the goal is sampling with a known bias, and
	[RFC3432] describes a method for periodic sampling with random start		[RFC3432] describes a method for periodic sampling with random start
	times.		times.
	4.1. Metric Name:		4.1. Metric Name:
	Type-P-One-way-Delay-Poisson-Stream		Type-P-One-way-Delay-Poisson-Stream
	4.2. Metric Parameters:		4.2. Metric Parameters:
	+ Src, the IP address of a host		+ Src, the IP address of a host
	skipping to change at page 20, line 43		skipping to change at page 20, line 43
	treated as infinitely large. As with Type-P-One-way-Delay-		treated as infinitely large. As with Type-P-One-way-Delay-
	Percentile, Type-P-One-way-Delay-Median is undefined if the sample is		Percentile, Type-P-One-way-Delay-Median is undefined if the sample is
	empty.		empty.
	As noted in the Framework document, the median differs from the 50th		As noted in the Framework document, the median differs from the 50th
	percentile only when the sample contains an even number of values, in		percentile only when the sample contains an even number of values, in
	which case the mean of the two central values is used.		which case the mean of the two central values is used.
	Example: suppose we take a sample and the results are:		Example: suppose we take a sample and the results are:
	Stream2 = < <T1, 100 msec> <T2, 110 msec> <T3, undefined> <T4, 90		Stream2 = <
	msec> >
			<T1, 100 msec>
			<T2, 110 msec>
			<T3, undefined>
			<T4, 90 msec>
			>
	Then the median would be 105 msec, the mean of 100 msec and 110 msec,		Then the median would be 105 msec, the mean of 100 msec and 110 msec,
	the two central values.		the two central values.
	5.3. Type-P-One-way-Delay-Minimum		5.3. Type-P-One-way-Delay-Minimum
	Given a Type-P-One-way-Delay-Poisson-Stream, the minimum of all the		Given a Type-P-One-way-Delay-Poisson-Stream, the minimum of all the
	dT values in the Stream. In computing this, undefined values are		dT values in the Stream. In computing this, undefined values are
	treated as infinitely large. Note that this means that the minimum		treated as infinitely large. Note that this means that the minimum
	could thus be undefined (informally, infinite) if all the dT values		could thus be undefined (informally, infinite) if all the dT values
	skipping to change at page 23, line 14		skipping to change at page 23, line 18
	[RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring		[RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring
	Connectivity", RFC 2678, September 1999.		Connectivity", RFC 2678, September 1999.
	[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way		[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
	Delay Metric for IPPM", RFC 2679, September 1999.		Delay Metric for IPPM", RFC 2679, September 1999.
	[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way		[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
	Packet Loss Metric for IPPM", RFC 2680, September 1999.		Packet Loss Metric for IPPM", RFC 2680, September 1999.
			[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
			Values In the Internet Protocol and Related Headers", BCP
			37, RFC 2780, March 2000.
	[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network		[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network
	performance measurement with periodic streams", RFC 3432,		performance measurement with periodic streams", RFC 3432,
	November 2002.		November 2002.
	[RFC6576] Geib, R., Morton, A., Fardid, R., and A. Steinmitz, "IP		[RFC6576] Geib, R., Morton, A., Fardid, R., and A. Steinmitz, "IP
	Performance Metrics (IPPM) Standard Advancement Testing",		Performance Metrics (IPPM) Standard Advancement Testing",
	BCP 176, RFC 6576, March 2012.		BCP 176, RFC 6576, March 2012.
	[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting		[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting
	IP Network Performance Metrics: Different Points of View",		IP Network Performance Metrics: Different Points of View",
	RFC 6703, August 2012.		RFC 6703, August 2012.
	[RFC7321] McGrew, D. and P. Hoffman, "Cryptographic Algorithm		[RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling
	Implementation Requirements and Usage Guidance for		Framework for IP Performance Metrics (IPPM)", RFC 7312,
	Encapsulating Security Payload (ESP) and Authentication		August 2014.
	Header (AH)", RFC 7321, August 2014.
	9.2. Informative References		9.2. Informative References
	[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov,		[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov,
	S., and J. Perser, "Packet Reordering Metrics", RFC 4737,		S., and J. Perser, "Packet Reordering Metrics", RFC 4737,
	November 2006.		November 2006.
	[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New		[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
	Performance Metric Development", BCP 170, RFC 6390,		Performance Metric Development", BCP 170, RFC 6390,
	October 2011.		October 2011.
	[RFC6808] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, "Test		[RFC6808] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, "Test
	Plan and Results Supporting Advancement of RFC 2679 on the		Plan and Results Supporting Advancement of RFC 2679 on the
	Standards Track", RFC 6808, December 2012.		Standards Track", RFC 6808, December 2012.
	Authors' Addresses		Authors' Addresses
	Guy Almes		Guy Almes
	Texas A&M		Texas A&M
	Email: galmes@tamu.edu		Email: almes@acm.org
	Sunil Kalidindi		Sunil Kalidindi
	Ixia		Ixia
	Email: skalidindi@ixiacom.com		Email: skalidindi@ixiacom.com
	Matt Zekauskas		Matt Zekauskas
	Internet2		Internet2
	Email: matt@internet2.edu		Email: matt@internet2.edu
End of changes. 30 change blocks.
	37 lines changed or deleted		56 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/