< draft-morton-ippm-2330-update-00.txt		draft-morton-ippm-2330-update-01.txt >
	Network Working Group J. Fabini		Network Working Group J. Fabini
	Internet-Draft Vienna University of Technology		Internet-Draft Vienna University of Technology
	Intended status: Informational A. Morton		Intended status: Informational A. Morton
	Expires: April 11, 2013 AT&T Labs		Expires: August 26, 2013 AT&T Labs
	October 8, 2012		February 22, 2013
	Advanced Stream and Sampling Framework for IPPM		Advanced Stream and Sampling Framework for IPPM
	draft-morton-ippm-2330-update-00		draft-morton-ippm-2330-update-01
	Abstract		Abstract
	To obtain repeatable results in modern networks, test descriptions		To obtain repeatable results in modern networks, test descriptions
	need an expanded stream parameter framework that also augments		need an expanded stream parameter framework that also augments
	aspects specified as Type-P for test packets. This memo proposes to		aspects specified as Type-P for test packets. This memo proposes to
	update the IP Performance Metrics (IPPM) Framework with advanced		update the IP Performance Metrics (IPPM) Framework with advanced
	considerations for measurement methodology and testing. The existing		considerations for measurement methodology and testing. The existing
	framework mostly assumes deterministic connectivity, and that a		framework mostly assumes deterministic connectivity, and that a
	single test stream will represent the characteristics of the path		single test stream will represent the characteristics of the path
	skipping to change at page 1, line 48 ¶		skipping to change at page 1, line 48 ¶
	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 11, 2013.		This Internet-Draft will expire on August 26, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2013 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Definition: Reactive Network Behavior . . . . . . . . . . 3
	3. New Stream Parameters . . . . . . . . . . . . . . . . . . . . 3		2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
			3. New Stream Parameters . . . . . . . . . . . . . . . . . . . . 4
	3.1. Test Packet Type-P . . . . . . . . . . . . . . . . . . . . 5		3.1. Test Packet Type-P . . . . . . . . . . . . . . . . . . . . 5
	3.1.1. Test Packet Length . . . . . . . . . . . . . . . . . . 5		3.1.1. Test Packet Length . . . . . . . . . . . . . . . . . . 6
	3.1.2. Test Packet Payload Content Optimization . . . . . . . 5		3.1.2. Test Packet Payload Content Optimization . . . . . . . 6
	3.2. Packet History . . . . . . . . . . . . . . . . . . . . . . 6		3.2. Packet History . . . . . . . . . . . . . . . . . . . . . . 6
	3.3. Access Technology Change . . . . . . . . . . . . . . . . . 6		3.3. Access Technology Change . . . . . . . . . . . . . . . . . 7
	3.4. Time-Slotted Network Paths . . . . . . . . . . . . . . . . 6		3.4. Time-Slotted Network Paths . . . . . . . . . . . . . . . . 7
	4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7		4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 8		5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 8		8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
	8.2. Informative References . . . . . . . . . . . . . . . . . . 9		8.2. Informative References . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	The IETF IP Performance Metrics (IPPM) working group first created a		The IETF IP Performance Metrics (IPPM) working group first created a
	framework for metric development in [RFC2330]. This framework has		framework for metric development in [RFC2330]. This framework has
	stood the test of time and enabled development of many fundamental		stood the test of time and enabled development of many fundamental
	metrics, while only being updated once in a specific area [RFC5835].		metrics, while only being updated once in a specific area [RFC5835].
	The IPPM framework [RFC2330] generally relies on several assumptions,		The IPPM framework [RFC2330] generally relies on several assumptions,
	skipping to change at page 3, line 37 ¶		skipping to change at page 3, line 37 ¶
	[RFC2330] must be extended to capture the reactive nature of these		[RFC2330] must be extended to capture the reactive nature of these
	networks. Although the proposed extensions can support methodologies		networks. Although the proposed extensions can support methodologies
	to fulfill the continuity requirement stated in section 6.2 of		to fulfill the continuity requirement stated in section 6.2 of
	[RFC2330], there is no guarantee. Practical measurements confirm		[RFC2330], there is no guarantee. Practical measurements confirm
	that some link types exhibit distinct responses to repeated		that some link types exhibit distinct responses to repeated
	measurements with identical stimulus, i.e., identical traffic		measurements with identical stimulus, i.e., identical traffic
	patterns. If feasible, appropriate fine-tuning of measurement		patterns. If feasible, appropriate fine-tuning of measurement
	traffic patterns can improve measurement continuity and repeatability		traffic patterns can improve measurement continuity and repeatability
	for these link types as shown in [IBD].		for these link types as shown in [IBD].
			1.1. Definition: Reactive Network Behavior
			Reactive behavior is present when link-or host-internal sensing of
			packet arrival for the flow of interest indicates that traffic is
			absent or present, or that traffic during an assessment interval is
			above or below a threshold, and the results of one or more successive
			assessments cause one or more network components to process future
			packets using a different mode of operation than for other assessment
			outcomes.
			Reactive network behavior must be observable by the measurement flow
			as a repeatable phenomenon where packet transfer performance
			characteristics *change* according to prior node- or link-internal
			observations of the packet flow of interest. Therefore, reactive
			network behavior is deterministic with respect to the flow of
			interest. Other flows or traffic load conditions may result in
			additional performance-affecting reactions, but these are external to
			the characteristics of the flow of interest.
			Other than the size of the payload at the layer of interest and the
			header itself, packet content does not influence the measurement.
			Reactive behavior at the IP layer is not influenced by the TCP ports
			in use, for example. Therefore, the finding of reactive behavior
			must specify the layer at which assessment leading to reaction
			appears to be taking place. In any case, the full packet Type-P used
			in measurement should always be specified.
			Examples include links with Active/In-active state detectors, and
			network devices or links that revise their traffic serving and
			forwarding rates (up or down) based on packet arrival history.
			A network or network path is said to be reactive when at least one of
			the links or hosts comprising the path exhibits reactive behavior.
	2. Scope		2. Scope
	The scope of his memo is to describe useful stream parameters in		The scope of his memo is to describe useful stream parameters in
	addition to the information in Section 11.1 of [RFC2330] and		addition to the information in Section 11.1 of [RFC2330] and
	described in [RFC3432] for periodic streams. The purpose is to		described in [RFC3432] for periodic streams. The purpose is to
	foster repeatable measurement results in modern networks by		foster repeatable measurement results in modern networks by
	highlighting the key aspects of test streams and packets and make		highlighting the key aspects of test streams and packets and make
	them part of the IPPM performance metric framework.		them part of the IPPM performance metric framework.
	3. New Stream Parameters		3. New Stream Parameters
	skipping to change at page 6, line 29 ¶		skipping to change at page 7, line 15 ¶
	changes in history, e.g., because of lost packets along the path, can		changes in history, e.g., because of lost packets along the path, can
	be the cause of large performance variations.		be the cause of large performance variations.
	For instance delay in reactive 3G networks like High Speed Packet		For instance delay in reactive 3G networks like High Speed Packet
	Access (HSPA) depends to a large extent on the test traffic data		Access (HSPA) depends to a large extent on the test traffic data
	rate. The reactive resource allocation strategy in these networks		rate. The reactive resource allocation strategy in these networks
	affects the uplink direction in particular. Small changes in data		affects the uplink direction in particular. Small changes in data
	rate can be the reason of more than 200% increase in delay, depending		rate can be the reason of more than 200% increase in delay, depending
	on the specific packet size.		on the specific packet size.
			The reactive behavior of a network under test may require to "pre-
			load" paths with traffic, or to separate early traffic that captures
			the reactive network performance signature from steady conditions
			that follow.
	3.3. Access Technology Change		3.3. Access Technology Change
	[RFC2330] discussed the scenario of multi-homed hosts. If hosts		[RFC2330] discussed the scenario of multi-homed hosts. If hosts
	become aware of access technology changes (e.g., because of IP		become aware of access technology changes (e.g., because of IP
	address changes or lower layer information) and make this information		address changes or lower layer information) and make this information
	available, measurement methodologies can use this information to		available, measurement methodologies can use this information to
	improve measurement representativeness and relevance.		improve measurement representativeness and relevance.
	However, today's various access network technologies can present the		However, today's various access network technologies can present the
	same physical interface to the host. A host may or may not become		same physical interface to the host. A host may or may not become
	skipping to change at page 8, line 25 ¶		skipping to change at page 9, line 17 ¶
	The security considerations that apply to any active measurement of		The security considerations that apply to any active measurement of
	live networks are relevant here as well. See [RFC4656] and		live networks are relevant here as well. See [RFC4656] and
	[RFC5357].		[RFC5357].
	6. IANA Considerations		6. IANA Considerations
	This memo makes no requests of IANA.		This memo makes no requests of IANA.
	7. Acknowledgements		7. Acknowledgements
	The authors thank folks for reading and commenting on this draft.		The authors thank Rudiger Geib and Matt Mathis for their helpful
			comments on this draft.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC2026] Bradner, S., "The Internet Standards Process -- Revision		[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
	3", BCP 9, RFC 2026, October 1996.		3", BCP 9, RFC 2026, October 1996.
	[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, March 1997.
	skipping to change at page 9, line 38 ¶		skipping to change at page 10, line 29 ¶
	[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.
	8.2. Informative References		8.2. Informative References
	[I-D.ietf-bmwg-imix-genome]		[I-D.ietf-bmwg-imix-genome]
	Morton, A., "IMIX Genome: Specification of variable packet		Morton, A., "IMIX Genome: Specification of variable packet
	sizes for additional testing",		sizes for additional testing",
	draft-ietf-bmwg-imix-genome-02 (work in progress),		draft-ietf-bmwg-imix-genome-04 (work in progress),
	July 2012.		December 2012.
	[IBD] Fabini, J., "The Illusion of Being Deterministic -		[IBD] Fabini, J., "The Illusion of Being Deterministic -
	Application-Level Considerations on Delay in 3G HSPA		Application-Level Considerations on Delay in 3G HSPA
	Networks", Lecture Notes in Computer Science, Springer,		Networks", Lecture Notes in Computer Science, Springer,
	Volume 5550, 2009, pp 301-312 , May 2009.		Volume 5550, 2009, pp 301-312 , May 2009.
	[IRR] Fabini, J., "The Importance of Being Really Random:		[IRR] Fabini, J., "The Importance of Being Really Random:
	Methodological Aspects of IP-Layer 2G and 3G Network Delay		Methodological Aspects of IP-Layer 2G and 3G Network Delay
	Assessment", ICC'09 Proceedings of the 2009 IEEE		Assessment", ICC'09 Proceedings of the 2009 IEEE
	International Conference on Communications, doi: 10.1109/		International Conference on Communications, doi: 10.1109/
End of changes. 11 change blocks.
	21 lines changed or deleted		62 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/