draft-ietf-ippm-2679-bis-03.txt		draft-ietf-ippm-2679-bis-04.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: January 25, 2016 M. Zekauskas		Expires: February 13, 2016 M. Zekauskas
	Internet2		Internet2
	A. Morton, Ed.		A. Morton, Ed.
	AT&T Labs		AT&T Labs
	July 24, 2015		August 12, 2015
	A One-Way Delay Metric for IPPM		A One-Way Delay Metric for IPPM
	draft-ietf-ippm-2679-bis-03		draft-ietf-ippm-2679-bis-04
	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. This memo makes RFC 2679		assumed to be familiar with that document. This memo makes RFC 2679
	obsolete.		obsolete.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 39		skipping to change at page 1, line 39
	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 January 25, 2016.		This Internet-Draft will expire on February 13, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 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
	skipping to change at page 2, line 26		skipping to change at page 2, line 26
	3. A Singleton Definition for One-way Delay . . . . . . . . . . 8		3. A Singleton Definition for One-way Delay . . . . . . . . . . 8
	3.1. Metric Name: . . . . . . . . . . . . . . . . . . . . . . 8		3.1. Metric Name: . . . . . . . . . . . . . . . . . . . . . . 8
	3.2. Metric Parameters: . . . . . . . . . . . . . . . . . . . 8		3.2. Metric Parameters: . . . . . . . . . . . . . . . . . . . 8
	3.3. Metric Units: . . . . . . . . . . . . . . . . . . . . . . 8		3.3. Metric Units: . . . . . . . . . . . . . . . . . . . . . . 8
	3.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 8		3.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 8
	3.5. Discussion: . . . . . . . . . . . . . . . . . . . . . . . 9		3.5. Discussion: . . . . . . . . . . . . . . . . . . . . . . . 9
	3.6. Methodologies: . . . . . . . . . . . . . . . . . . . . . 10		3.6. Methodologies: . . . . . . . . . . . . . . . . . . . . . 10
	3.7. Errors and Uncertainties: . . . . . . . . . . . . . . . . 11		3.7. Errors and Uncertainties: . . . . . . . . . . . . . . . . 11
	3.7.1. Errors or uncertainties related to Clocks . . . . . . 11		3.7.1. Errors or uncertainties related to Clocks . . . . . . 11
	3.7.2. Errors or uncertainties related to Wire-time vs Host-		3.7.2. Errors or uncertainties related to Wire-time vs Host-
	time . . . . . . . . . . . . . . . . . . . . . . . . 12		time . . . . . . . . . . . . . . . . . . . . . . . . 13
	3.7.3. Calibration . . . . . . . . . . . . . . . . . . . . . 13		3.7.3. Calibration . . . . . . . . . . . . . . . . . . . . . 13
	3.8. Reporting the metric: . . . . . . . . . . . . . . . . . . 15		3.8. Reporting the metric: . . . . . . . . . . . . . . . . . . 15
	3.8.1. Type-P . . . . . . . . . . . . . . . . . . . . . . . 15		3.8.1. Type-P . . . . . . . . . . . . . . . . . . . . . . . 16
	3.8.2. Loss Threshold . . . . . . . . . . . . . . . . . . . 16		3.8.2. Loss Threshold . . . . . . . . . . . . . . . . . . . 16
	3.8.3. Calibration Results . . . . . . . . . . . . . . . . . 16		3.8.3. Calibration Results . . . . . . . . . . . . . . . . . 16
	3.8.4. Path . . . . . . . . . . . . . . . . . . . . . . . . 16		3.8.4. Path . . . . . . . . . . . . . . . . . . . . . . . . 16
	4. A Definition for Samples of One-way Delay . . . . . . . . . . 16		4. A Definition for Samples of One-way Delay . . . . . . . . . . 17
	4.1. Metric Name: . . . . . . . . . . . . . . . . . . . . . . 17		4.1. Metric Name: . . . . . . . . . . . . . . . . . . . . . . 17
	4.2. Metric Parameters: . . . . . . . . . . . . . . . . . . . 17		4.2. Metric Parameters: . . . . . . . . . . . . . . . . . . . 17
	4.3. Metric Units: . . . . . . . . . . . . . . . . . . . . . . 17		4.3. Metric Units: . . . . . . . . . . . . . . . . . . . . . . 17
	4.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 17		4.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 18
	4.5. Discussion: . . . . . . . . . . . . . . . . . . . . . . . 18		4.5. Discussion: . . . . . . . . . . . . . . . . . . . . . . . 18
	4.6. Methodologies: . . . . . . . . . . . . . . . . . . . . . 18		4.6. Methodologies: . . . . . . . . . . . . . . . . . . . . . 19
	4.7. Errors and Uncertainties: . . . . . . . . . . . . . . . . 19		4.7. Errors and Uncertainties: . . . . . . . . . . . . . . . . 19
	4.8. Reporting the metric: . . . . . . . . . . . . . . . . . . 19		4.8. Reporting the metric: . . . . . . . . . . . . . . . . . . 19
	5. Some Statistics Definitions for One-way Delay . . . . . . . . 19		5. Some Statistics Definitions for One-way Delay . . . . . . . . 19
	5.1. Type-P-One-way-Delay-Percentile . . . . . . . . . . . . . 19		5.1. Type-P-One-way-Delay-Percentile . . . . . . . . . . . . . 20
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 23
	9.1. Normative References . . . . . . . . . . . . . . . . . . 22		9.1. Normative References . . . . . . . . . . . . . . . . . . 23
	9.2. Informative References . . . . . . . . . . . . . . . . . 23		9.2. Informative References . . . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
	1. Changes from RFC 2679		1. Changes from RFC 2679
	Note: This section's placement currently preserves minimal		Note: This section's placement currently preserves minimal
	differencer between this memo and RFC 2679. The RFC Editor should		differencer between this memo and RFC 2679. The RFC Editor should
	place this section in an appropriate place.		place this section in an appropriate place.
	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
	modifications:		modifications:
	1. Section 6.2.3 of [RFC6808] asserts that the assumption of post-		1. Section 6.2.3 of [RFC6808] asserts that the assumption of post-
	processing to enforce a constant waiting time threshold is		processing to enforce a constant waiting time threshold is
	compliant, and that the text of the RFC should be revised		compliant, and that the text of the RFC should be revised
	slightly to include this point (see the last list item of section		slightly to include this point. The applicability of post-
	3.6, below).		processing was added in the last list item of section 3.6, below.
	2. Section 6.5 of [RFC6808] indicates that Type-P-One-way-Delay-		2. Section 6.5 of [RFC6808] indicates that Type-P-One-way-Delay-
	Inverse-Percentile statistic has been ignored in both		Inverse-Percentile statistic has been ignored in both
	implementations, so it is a candidate for removal or deprecation		implementations, so it is a candidate for removal or deprecation
	in RFC2679bis (this small discrepancy does not affect candidacy		in RFC2679bis (this small discrepancy does not affect candidacy
	for advancement) (see section 5.4, below).		for advancement). This statistic was deprecated in section 5.4,
			below.
	3. The IETF has reached consensus on guidance for reporting metrics		3. The IETF has reached consensus on guidance for reporting metrics
	in [RFC6703], and this memo should be referenced in RFC2679bis to		in [RFC6703], and this memo should be referenced in RFC2679bis to
	incorporate recent experience where appropriate (see the last		incorporate recent experience where appropriate. This reference
	list item of section 3.6, section 3.8, and section 5 below).		was added in the last list item of section 3.6, section 3.8, and
			in 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 this minor revision and additional
	additional text should be incorporated in RFC2679bis (see section		text was incorporated in RFC2679bis in section 5.1, below.
	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. 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.
	skipping to change at page 10, line 10		skipping to change at page 10, line 10
	+ If the packet is duplicated along the path (or paths) so that		+ If the packet is duplicated along the path (or paths) so that
	multiple non-corrupt copies arrive at the destination, then the		multiple non-corrupt copies arrive at the destination, then the
	packet is counted as received, and the first copy to arrive		packet is counted as received, and the first copy to arrive
	determines the packet's one-way delay.		determines the packet's one-way delay.
	+ If the packet is fragmented and if, for whatever reason, reassembly		+ If the packet is fragmented and if, for whatever reason, reassembly
	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. Note: At this time, the definition of standard-
			formed packets only applies to IPv4, but also see
			[I-D.morton-ippm-2330-stdform-typep].
	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,
	Differentiated Services (DS) Field [RFC2780]).		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:
	skipping to change at page 15, line 46		skipping to change at page 16, line 7
	results. We now present four items to consider: the Type-P of test		results. We now present four items to consider: the Type-P of test
	packets, the threshold of infinite delay (if any), error calibration,		packets, the threshold of infinite delay (if any), error calibration,
	and the path traversed by the test packets. This list is not		and the path traversed by the test packets. This list is not
	exhaustive; any additional information that could be useful in		exhaustive; any additional information that could be useful in
	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, section 13 of [RFC2330], the
	may depend on the type of IP packets used to make the measurement, or		value of the metric may depend on the type of IP packets used to make
	"type-P". The value of Type-P-One-way-Delay could change if the		the measurement, or "Type-P". The value of Type-P-One-way-Delay
	protocol (UDP or TCP), port number, size, or arrangement for special		could change if the protocol (UDP or TCP), port number, size, or
	treatment (e.g., IP DS Field [RFC2780] or RSVP) changes. The exact		arrangement for special treatment (e.g., IP DS Field [RFC2780], ECN
			[RFC3168], or RSVP) changes. Additional packet distinctions included
			in future extensions of the Type-P definition will apply. The exact
	Type-P 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
	skipping to change at page 22, line 38		skipping to change at page 22, line 49
	8. Acknowledgements		8. Acknowledgements
	For [RFC2679], special thanks are due to Vern Paxson of Lawrence		For [RFC2679], special thanks are due to Vern Paxson of Lawrence
	Berkeley Labs for his helpful comments on issues of clock uncertainty		Berkeley Labs for his helpful comments on issues of clock uncertainty
	and statistics. Thanks also to Garry Couch, Will Leland, Andy		and statistics. Thanks also to Garry Couch, Will Leland, Andy
	Scherrer, Sean Shapira, and Roland Wittig for several useful		Scherrer, Sean Shapira, and Roland Wittig for several useful
	suggestions.		suggestions.
	For RFC 2679 bis, thanks to Joachim Fabini, Ruediger Geib, Nalini		For RFC 2679 bis, thanks to Joachim Fabini, Ruediger Geib, Nalini
	Elkins, and Barry Constantine for sharing their measurement		Elkins, and Barry Constantine for sharing their measurement
	experience as part of their careful reviews.		experience as part of their careful reviews. Brian Carpenter and
			Scott Bradner provided useful feedback at IETF Last Call.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,		[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
	DOI 10.17487/RFC0791, September 1981,		DOI 10.17487/RFC0791, September 1981,
	<http://www.rfc-editor.org/info/rfc791>.		<http://www.rfc-editor.org/info/rfc791>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	skipping to change at page 23, line 45		skipping to change at page 24, line 12
	Testing", BCP 176, RFC 6576, DOI 10.17487/RFC6576, March		Testing", BCP 176, RFC 6576, DOI 10.17487/RFC6576, March
	2012, <http://www.rfc-editor.org/info/rfc6576>.		2012, <http://www.rfc-editor.org/info/rfc6576>.
	[RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling		[RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling
	Framework for IP Performance Metrics (IPPM)", RFC 7312,		Framework for IP Performance Metrics (IPPM)", RFC 7312,
	DOI 10.17487/RFC7312, August 2014,		DOI 10.17487/RFC7312, August 2014,
	<http://www.rfc-editor.org/info/rfc7312>.		<http://www.rfc-editor.org/info/rfc7312>.
	9.2. Informative References		9.2. Informative References
			[I-D.morton-ippm-2330-stdform-typep]
			Morton, A., Fabini, J., Elkins, N., Ackermann, M., and V.
			Hegde, "Updates for IPPM's Active Metric Framework:
			Packets of Type-P and Standard-Formed Packets", draft-
			morton-ippm-2330-stdform-typep-00 (work in progress),
			August 2015.
			[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
			of Explicit Congestion Notification (ECN) to IP",
			RFC 3168, DOI 10.17487/RFC3168, September 2001,
			<http://www.rfc-editor.org/info/rfc3168>.
	[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,
	DOI 10.17487/RFC4737, November 2006,		DOI 10.17487/RFC4737, November 2006,
	<http://www.rfc-editor.org/info/rfc4737>.		<http://www.rfc-editor.org/info/rfc4737>.
	[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,
	DOI 10.17487/RFC6390, October 2011,		DOI 10.17487/RFC6390, October 2011,
	<http://www.rfc-editor.org/info/rfc6390>.		<http://www.rfc-editor.org/info/rfc6390>.
End of changes. 19 change blocks.
	28 lines changed or deleted		46 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/