draft-ietf-ippm-2679-bis-02.txt		draft-ietf-ippm-2679-bis-03.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: December 22, 2015 M. Zekauskas		Expires: January 25, 2016 M. Zekauskas
	Internet2		Internet2
	A. Morton, Ed.		A. Morton, Ed.
	AT&T Labs		AT&T Labs
	June 20, 2015		July 24, 2015
	A One-Way Delay Metric for IPPM		A One-Way Delay Metric for IPPM
	draft-ietf-ippm-2679-bis-02		draft-ietf-ippm-2679-bis-03
	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 December 22, 2015.		This Internet-Draft will expire on January 25, 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
	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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. RFC 2679 bis . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Changes from RFC 2679 . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 6		2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 6
	2.2. General Issues Regarding Time . . . . . . . . . . . . . . 7		2.2. General Issues Regarding Time . . . . . . . . . . . . . . 7
	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
	skipping to change at page 3, line 5		skipping to change at page 3, line 5
	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. Changes from RFC 2679
			Note: This section's placement currently preserves minimal
			differencer between this memo and RFC 2679. The RFC Editor should
			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:
	skipping to change at page 3, line 45		skipping to change at page 3, line 49
	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. Add that RFC2330 was updated by RFC7312 in the Introduction		1. Near the end of section 2.1, update of a network example using
	(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.
	3. Explicit inclusion of the maximum waiting time input parameter		2. 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.
	4. Addition of reference to RFC6703 in the discussion of packet		3. 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.
	5. Addition of reference to the default requirement (that packets		4. 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.
	6. GPS-based NTP experience replaces "to be tested" in section 3.5.		5. GPS-based NTP experience replaces "to be tested" in section 3.5.
	7. Replaced "precedence" with updated terminology (DS Field) in 3.6		6. Replaced "precedence" with updated terminology (DS Field) in 3.6
	and 3.8.1 (with reference).		and 3.8.1 (with reference).
	8. Added parenthetical guidance on minimizing interval between		7. 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.
	9. Added text recognizing the impending deployment of transport		8. Added text recognizing the impending deployment of transport
	layer encryption in section 3.6.		layer encryption in section 3.6.
	10. Section 3.7.2 notes that some current systems perform host time		9. Section 3.7.2 notes that some current systems perform host time
	stamping on the network interface hardware.		stamping on the network interface hardware.
	11. "instrument" replaced by the defined term "host" in sections		10. "instrument" replaced by the defined term "host" in sections
	3.7.3 and 3.8.3.		3.7.3 and 3.8.3.
	12. Added reference to RFC 3432 Periodic sampling alongside Poisson		11. 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.
	13. Add reference to RFC 4737 Reordering metric in the related		12. Add reference to RFC 4737 Reordering metric in the related
	discussion of section 4.6, Methodologies.		discussion of section 4.6, Methodologies.
	14. Formatting of Example in section 5.1 modified to match the		13. Formatting of Example in section 5.1 modified to match the
	original (issue with conversion to XML in bis version).		original (issue with conversion to XML in bis version).
	15. Clarifying the conclusions on two related points on harm to		14. 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
	skipping to change at page 6, line 48		skipping to change at page 6, line 48
	performance difference between the two paths which may traverse		performance difference between the two paths which may traverse
	different Internet service providers, and even radically different		different Internet service providers, and even radically different
	types of networks (for example, research versus commodity networks,		types of networks (for example, research versus commodity networks,
	or networks with asymmetric link capacities, or wireless vs. wireline		or networks with asymmetric link capacities, or wireless vs. wireline
	access).		access).
	+ Even when the two paths are symmetric, they may have radically		+ Even when the two paths are symmetric, they may have radically
	different performance characteristics due to asymmetric queueing.		different performance characteristics due to asymmetric queueing.
	+ Performance of an application may depend mostly on the performance		+ Performance of an application may depend mostly on the performance
	in one direction. For example, a TCP-based communication may		in one direction. For example, a TCP-based communication will
	experience reduced throughput if congestion occurs in one direction		experience reduced throughput if congestion occurs in one direction
	of its communication. Trouble shooting may be simplified if the		of its communication. Trouble shooting may be simplified if the
	congested direction of TCP transmission can be identified.		congested direction of TCP transmission can be identified.
	+ In quality-of-service (QoS) enabled networks, provisioning in one		+ In quality-of-service (QoS) enabled networks, provisioning in one
	direction may be radically different than provisioning in the reverse		direction may be radically different than provisioning in the reverse
	direction, and thus the QoS guarantees differ. Measuring the paths		direction, and thus the QoS guarantees differ. Measuring the paths
	independently allows the verification of both guarantees.		independently allows the verification of both guarantees.
	It is outside the scope of this document to say precisely how delay		It is outside the scope of this document to say precisely how delay
	skipping to change at page 10, line 32		skipping to change at page 10, line 32
	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
	packet needed only to make the test packet a given size should be		packet needed only to make the test packet a given size should be
	filled with randomized bits to avoid a situation in which the		filled with randomized bits to avoid a situation in which the
	measured delay is lower than it would otherwise be due to compression		measured delay is lower than it would otherwise be due to compression
	techniques along the path. Note that use of transport layer		techniques along the path. Note that use of transport layer
	encryption will counteract the deployment of network-based analysis		encryption will counteract the deployment of network-based analysis
	and may reduce the adoption of payload optimizations like		and may reduce the adoption of network-based payload optimizations
	compression.		like compression.
	+ At the Dst host, arrange to receive the packet.		+ At the Dst host, arrange to receive the packet.
	+ At the Src host, place a timestamp in the prepared Type-P packet,		+ At the Src host, place a timestamp in the prepared Type-P packet,
	and send it towards Dst (ideally minimizing time before sending).		and send it towards Dst (ideally minimizing time before sending).
	+ If the packet arrives within a reasonable period of time, take a		+ If the packet arrives within a reasonable period of time, take a
	timestamp as soon as possible upon the receipt of the packet. By		timestamp as soon as possible upon the receipt of the packet. By
	subtracting the two timestamps, an estimate of one-way delay can be		subtracting the two timestamps, an estimate of one-way delay can be
	computed. Error analysis of a given implementation of the method		computed. Error analysis of a given implementation of the method
	skipping to change at page 22, line 44		skipping to change at page 22, line 44
	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.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September		[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
	1981.		DOI 10.17487/RFC0791, September 1981,
			<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
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
	[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,		[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
	"Framework for IP Performance Metrics", RFC 2330, May		"Framework for IP Performance Metrics", RFC 2330,
	1998.		DOI 10.17487/RFC2330, May 1998,
			<http://www.rfc-editor.org/info/rfc2330>.
	[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, DOI 10.17487/RFC2678, September
			1999, <http://www.rfc-editor.org/info/rfc2678>.
	[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, DOI 10.17487/RFC2679,
			September 1999, <http://www.rfc-editor.org/info/rfc2679>.
	[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,
			DOI 10.17487/RFC2680, September 1999,
			<http://www.rfc-editor.org/info/rfc2680>.
	[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For		[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
	Values In the Internet Protocol and Related Headers", BCP		Values In the Internet Protocol and Related Headers",
	37, RFC 2780, March 2000.		BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000,
			<http://www.rfc-editor.org/info/rfc2780>.
	[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.		DOI 10.17487/RFC3432, November 2002,
			<http://www.rfc-editor.org/info/rfc3432>.
	[RFC6576] Geib, R., Morton, A., Fardid, R., and A. Steinmitz, "IP		[RFC6576] Geib, R., Ed., Morton, A., Fardid, R., and A. Steinmitz,
	Performance Metrics (IPPM) Standard Advancement Testing",		"IP Performance Metrics (IPPM) Standard Advancement
	BCP 176, RFC 6576, March 2012.		Testing", BCP 176, RFC 6576, DOI 10.17487/RFC6576, March
			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,
	August 2014.		DOI 10.17487/RFC7312, August 2014,
			<http://www.rfc-editor.org/info/rfc7312>.
	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.		DOI 10.17487/RFC4737, November 2006,
			<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,
	October 2011.		DOI 10.17487/RFC6390, October 2011,
			<http://www.rfc-editor.org/info/rfc6390>.
	[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, DOI 10.17487/RFC6703, August 2012,
			<http://www.rfc-editor.org/info/rfc6703>.
	[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, DOI 10.17487/RFC6808, December
			2012, <http://www.rfc-editor.org/info/rfc6808>.
	Authors' Addresses		Authors' Addresses
	Guy Almes		Guy Almes
	Texas A&M		Texas A&M
	Email: almes@acm.org		Email: almes@acm.org
	Sunil Kalidindi		Sunil Kalidindi
	Ixia		Ixia
	Email: skalidindi@ixiacom.com		Email: skalidindi@ixiacom.com
End of changes. 38 change blocks.
	46 lines changed or deleted		64 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/