< draft-morton-ippm-2330-stdform-typep-00.txt		draft-morton-ippm-2330-stdform-typep-01.txt >
	Network Working Group A. Morton		Network Working Group A. Morton
	Internet-Draft AT&T Labs		Internet-Draft AT&T Labs
	Updates: 2330 (if approved) J. Fabini		Updates: 2330 (if approved) J. Fabini
	Intended status: Informational TU Wien		Intended status: Informational TU Wien
	Expires: February 7, 2016 N. Elkins		Expires: April 3, 2016 N. Elkins
	Inside Products, Inc.		Inside Products, Inc.
	M. Ackermann		M. Ackermann
	Blue Cross Blue Shield of Michigan		Blue Cross Blue Shield of Michigan
	V. Hegde		V. Hegde
	August 6, 2015		Consultant
			October 1, 2015
	Updates for IPPM's Active Metric Framework: Packets of Type-P and		Updates for IPPM's Active Metric Framework: Packets of Type-P and
	Standard-Formed Packets		Standard-Formed Packets
	draft-morton-ippm-2330-stdform-typep-00		draft-morton-ippm-2330-stdform-typep-01
	Abstract		Abstract
	This memo updates the IP Performance Metrics (IPPM) Framework RFC		This memo updates the IP Performance Metrics (IPPM) Framework RFC
	2330 with new considerations for measurement methodology and testing.		2330 with new considerations for measurement methodology and testing.
	The memo updates the definition of standard-formed packets in RFC		The memo updates the definition of standard-formed packets in RFC
	2330 to include IPv6 packets. It also augments distinguishing		2330 to include IPv6 packets. It also augments distinguishing
	aspects of packets, referred to as Type-P for test packets in RFC		aspects of packets, referred to as Type-P for test packets in RFC
	2330.		2330.
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 7 ¶
	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 February 7, 2016.		This Internet-Draft will expire on April 3, 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 29 ¶		skipping to change at page 2, line 29 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Packets of Type-P . . . . . . . . . . . . . . . . . . . . . . 3		3. Packets of Type-P . . . . . . . . . . . . . . . . . . . . . . 3
	4. Standard-Formed Packets . . . . . . . . . . . . . . . . . . . 4		4. Standard-Formed Packets . . . . . . . . . . . . . . . . . . . 5
	5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7		5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 7		6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	9.1. Normative References . . . . . . . . . . . . . . . . . . 7		9.1. Normative References . . . . . . . . . . . . . . . . . . 8
	9.2. Informative References . . . . . . . . . . . . . . . . . 9		9.2. Informative References . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		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. It has been updated in the area of metric composition		metrics. It has been updated in the area of metric composition
	[RFC5835], and in several areas related to active stream measurement		[RFC5835], and in several areas related to active stream measurement
	of modern networks with reactive properties [RFC7312].		of modern networks with reactive properties [RFC7312].
	skipping to change at page 4, line 29 ¶		skipping to change at page 4, line 29 ¶
	occur according to the conditions encountered in transit (such as		occur according to the conditions encountered in transit (such as
	congestion notification) or due to the requirements of segments of		congestion notification) or due to the requirements of segments of
	the Source to Destination path. For example, the packet length will		the Source to Destination path. For example, the packet length will
	change if IP headers are converted to the alternate version/address		change if IP headers are converted to the alternate version/address
	family, or if optional Extension Headers are added or removed. Local		family, or if optional Extension Headers are added or removed. Local
	policies in intermediate nodes based on examination of IPv6 Extension		policies in intermediate nodes based on examination of IPv6 Extension
	Headers may affect measurement repeatability. If intermediate nodes		Headers may affect measurement repeatability. If intermediate nodes
	follow the recommendations of [RFC7045], repeatability may be		follow the recommendations of [RFC7045], repeatability may be
	improved to some degree.		improved to some degree.
			A Network Address Translator (NAT) on the path can have unpredictable
			impact on latency measurement (in terms of the amount of additional
			time added), and possibly other types of measurements. It is not
			usually possible to control this impact (as testers may not have any
			control of the underlying network or middleboxes). There is a
			possibility that stateful NAT will lead to unstable performance for a
			flow with specific Type-P, since state needs to be created for the
			first packet of a flow, and state may be lost later if the NAT runs
			out of resources. However, this scenario does not invalidate the
			Type-P for testing. The presence of NAT may mean that the measured
			performance of Type-P will change between the source and the
			destination. This can cause an issue when attempting to correlate
			measurements conducted on segments of the path that include or
			exclude the NAT. Thus, it is a factor to be aware of when conducting
			measurements.
	A closely related note: it would be very useful to know if a given		A closely related note: it would be very useful to know if a given
	Internet component treats equally a class C of different types of		Internet component (like host, link, or path) treats equally a class
	packets. If so, then any one of those types of packets can be used		C of different types of packets. If so, then any one of those types
	for subsequent measurement of the component. This suggests we devise		of packets can be used for subsequent measurement of the component.
	a metric or suite of metrics that attempt to determine C.		This suggests we devise a metric or suite of metrics that attempt to
			determine C.
	4. Standard-Formed Packets		4. Standard-Formed Packets
	Unless otherwise stated, all metric definitions that concern IP		Unless otherwise stated, all metric definitions that concern IP
	packets include an implicit assumption that the packet is *standard-		packets include an implicit assumption that the packet is *standard-
	formed*. A packet is standard-formed if it meets all of the following		formed*. A packet is standard-formed if it meets all of the following
	criteria:		criteria:
	+ It includes a valid IP header: see below for version-specific		+ It includes a valid IP header: see below for version-specific
	criteria.		criteria.
	skipping to change at page 7, line 25 ¶		skipping to change at page 7, line 44 ¶
	The security considerations that apply to any active measurement of		The security considerations that apply to any active measurement of
	live paths are relevant here as well. See [RFC4656] and [RFC5357].		live paths are relevant here as well. See [RFC4656] and [RFC5357].
	When considering privacy of those involved in measurement or those		When considering privacy of those involved in measurement or those
	whose traffic is measured, the sensitive information available to		whose traffic is measured, the sensitive information available to
	potential observers is greatly reduced when using active techniques		potential observers is greatly reduced when using active techniques
	which are within this scope of work. Passive observations of user		which are within this scope of work. Passive observations of user
	traffic for measurement purposes raise many privacy issues. We refer		traffic for measurement purposes raise many privacy issues. We refer
	the reader to the privacy considerations described in the Large Scale		the reader to the privacy considerations described in the Large Scale
	Measurement of Broadband Performance (LMAP) Framework		Measurement of Broadband Performance (LMAP) Framework [RFC7594],
	[I-D.ietf-lmap-framework], which covers active and passive		which covers active and passive techniques.
	techniques.
	7. IANA Considerations		7. IANA Considerations
	This memo makes no requests of IANA.		This memo makes no requests of IANA.
	8. Acknowledgements		8. Acknowledgements
	The authors thank Brian Carpenter for identifying the lack of IPv6		The authors thank Brian Carpenter for identifying the lack of IPv6
	coverage in IPPM's Framework, and for listing additional		coverage in IPPM's Framework, and for listing additional
	distinguishing factors for packets of Type-P. Both Brian and Fred		distinguishing factors for packets of Type-P. Both Brian and Fred
	skipping to change at page 9, line 36 ¶		skipping to change at page 10, line 7 ¶
	DOI 10.17487/RFC7045, December 2013,		DOI 10.17487/RFC7045, December 2013,
	<http://www.rfc-editor.org/info/rfc7045>.		<http://www.rfc-editor.org/info/rfc7045>.
	[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.ietf-lmap-framework]		[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
	Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,		Aitken, P., and A. Akhter, "A Framework for Large-Scale
	Aitken, P., and A. Akhter, "A framework for Large-Scale		Measurement of Broadband Performance (LMAP)", RFC 7594,
	Measurement of Broadband Performance (LMAP)", draft-ietf-		DOI 10.17487/RFC7594, September 2015,
	lmap-framework-14 (work in progress), April 2015.		<http://www.rfc-editor.org/info/rfc7594>.
	Authors' Addresses		Authors' Addresses
	Al Morton		Al Morton
	AT&T Labs		AT&T Labs
	200 Laurel Avenue South		200 Laurel Avenue South
	Middletown, NJ 07748		Middletown, NJ 07748
	USA		USA
	Phone: +1 732 420 1571		Phone: +1 732 420 1571
	Fax: +1 732 368 1192		Fax: +1 732 368 1192
	Email: acmorton@att.com		Email: acmorton@att.com
	URI: http://home.comcast.net/~acmacm/		URI: http://home.comcast.net/~acmacm/
	skipping to change at page 10, line 37 ¶		skipping to change at page 11, line 4 ¶
	Inside Products, Inc.		Inside Products, Inc.
	Carmel Valley, CA 93924		Carmel Valley, CA 93924
	USA		USA
	Email: nalini.elkins@insidethestack.com		Email: nalini.elkins@insidethestack.com
	Michael S. Ackermann		Michael S. Ackermann
	Blue Cross Blue Shield of Michigan		Blue Cross Blue Shield of Michigan
	Email: mackermann@bcbsmi.com		Email: mackermann@bcbsmi.com
	Vinayak Hegde		Vinayak Hegde
			Consultant
			Brahma Sun City, Wadgaon-Sheri
			Pune, Maharashtra 411014
			INDIA
			Phone: +91 9449834401
	Email: vinayakh@gmail.com		Email: vinayakh@gmail.com
			URI: http://www.vinayakhegde.com
End of changes. 15 change blocks.
	23 lines changed or deleted		45 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/