draft-ietf-ippm-reporting-05.txt		draft-ietf-ippm-reporting-06.txt
	Network Working Group S. Shalunov		Network Working Group S. Shalunov
	Internet-Draft		Internet-Draft
	Intended status: Standards Track M. Swany		Intended status: Standards Track M. Swany
	Expires: January 14, 2011 University of Delaware		Expires: September 15, 2011 University of Delaware
	July 13, 2010		March 14, 2011
	Reporting IP Performance Metrics to Users		Reporting IP Performance Metrics to Users
	draft-ietf-ippm-reporting-05.txt		draft-ietf-ippm-reporting-06.txt
	Abstract		Abstract
	The aim of this document is to define a small set of metrics that are		The aim of this document is to define a small set of metrics that are
	robust, easy to understand, orthogonal, relevant, and easy to		robust, easy to understand, orthogonal, relevant, and easy to
	compute. The IPPM WG has defined a large number of richly		compute. The IPPM WG has defined a large number of richly
	parameterized metrics because network measurement has many purposes.		parameterized metrics because network measurement has many purposes.
	Often, the ultimate purpose is to report a concise set of metrics		Often, the ultimate purpose is to report a concise set of metrics
	describing a network's current state to an end user. It is for this		describing a network's current state to an end user. It is for this
	purpose that the present set of metrics is defined, and the document		purpose that the present set of metrics is defined, and the document
	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 14, 2011.		This Internet-Draft will expire on September 15, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2011 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 24		skipping to change at page 3, line 24
	4.4. Duplication . . . . . . . . . . . . . . . . . . . . . . . 9		4.4. Duplication . . . . . . . . . . . . . . . . . . . . . . . 9
	4.5. Reordering . . . . . . . . . . . . . . . . . . . . . . . . 9		4.5. Reordering . . . . . . . . . . . . . . . . . . . . . . . . 9
	5. Sample Source . . . . . . . . . . . . . . . . . . . . . . . . 10		5. Sample Source . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.1. One-Way Active Measurement . . . . . . . . . . . . . . . . 10		5.1. One-Way Active Measurement . . . . . . . . . . . . . . . . 10
	5.2. Round-Trip Active Measurement . . . . . . . . . . . . . . 11		5.2. Round-Trip Active Measurement . . . . . . . . . . . . . . 11
	5.3. Passive Measurement . . . . . . . . . . . . . . . . . . . 11		5.3. Passive Measurement . . . . . . . . . . . . . . . . . . . 11
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 12		6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	9. Internationalization Considerations . . . . . . . . . . . . . 15		9. Internationalization Considerations . . . . . . . . . . . . . 15
	10. Normative References . . . . . . . . . . . . . . . . . . . . . 16		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
			10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
			10.2. Informative References . . . . . . . . . . . . . . . . . . 16
	Appendix A. Sample Source Code for Computing the Metrics . . . . 17		Appendix A. Sample Source Code for Computing the Metrics . . . . 17
	Appendix B. Example Report . . . . . . . . . . . . . . . . . . . 41		Appendix B. Example Report . . . . . . . . . . . . . . . . . . . 41
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
	1. Requirements Notation		1. Requirements Notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	skipping to change at page 5, line 41		skipping to change at page 5, line 41
	choose is ad hoc; some metrics are not statistically robust, some are		choose is ad hoc; some metrics are not statistically robust, some are
	not relevant, and some are not easy to understand; more important		not relevant, and some are not easy to understand; more important
	than specific shortcomings, however, is the incompatibility: even if		than specific shortcomings, however, is the incompatibility: even if
	the sets of metrics were perfect, they would still be all different,		the sets of metrics were perfect, they would still be all different,
	and, therefore, metrics reported by different tools would not be		and, therefore, metrics reported by different tools would not be
	comparable.		comparable.
	The set of metrics of this document is meant for human consumption.		The set of metrics of this document is meant for human consumption.
	It must therefore be small. A screen full of numbers is likely to be		It must therefore be small. A screen full of numbers is likely to be
	too confusing. Restricting output to a single number would likewise		too confusing. Restricting output to a single number would likewise
	not be descriptive enough. (Would you pick loss? delay? throughput?		not be descriptive enough. This document aims for a small set of
	something else?) In this document we aim for a "handful" of numbers.		easily understood numbers.
	Each of the metrics must be statistically robust. Intuitively, this		Each of the metrics must be statistically robust. Intuitively, this
	means that having a small number of bad data points and a small		means that having a small number of bad data points and a small
	amount of noise must not dramatically change the metric.		amount of noise must not dramatically change the metric.
	Each metric in the set must have, qualitatively, an immediate		Each metric in the set must have, qualitatively, an immediate
	intuitive meaning that has to be obvious for an advanced end user		intuitive meaning that has to be obvious for an advanced end user
	without consulting documentation (that is, it has to be clear what		without consulting documentation (that is, it has to be clear what
	rough meaning, intuitively, the larger values of a given metric		rough meaning, intuitively, the larger values of a given metric
	have).		have).
	skipping to change at page 8, line 5		skipping to change at page 7, line 18
	network measurements (seconds or at most minutes) and are targeted		network measurements (seconds or at most minutes) and are targeted
	for real-time display of such measurements.		for real-time display of such measurements.
	One consideration that would have to be addressed to make these		One consideration that would have to be addressed to make these
	metrics suitable for longer-term measurements (hours and days) is		metrics suitable for longer-term measurements (hours and days) is
	that of network availability: during such long periods of time the		that of network availability: during such long periods of time the
	network may be completely down for some time and it does not seem to		network may be completely down for some time and it does not seem to
	make sense to average out the reports in such a way that the network		make sense to average out the reports in such a way that the network
	being down for 1% of the time becomes 1% packet loss.		being down for 1% of the time becomes 1% packet loss.
			Long-term reporting considerations are now being developed within the
			IPPM working group. See the working group draft
			[I-D.ietf-ippm-reporting-metrics] (or future RFC) for details.
	4. Reportable Metrics Set		4. Reportable Metrics Set
	The following metrics comprise the set:		The following metrics comprise the set:
	1. median delay;		1. median delay;
	2. loss ratio;		2. loss ratio;
	3. delay spread;		3. delay spread;
	skipping to change at page 9, line 17		skipping to change at page 9, line 17
	For more information, refer to section 5.1 (Type-P-One-way-Delay-		For more information, refer to section 5.1 (Type-P-One-way-Delay-
	Percentile) of RFC 2679 [RFC2679] (A One-way Delay Metric for IPPM),		Percentile) of RFC 2679 [RFC2679] (A One-way Delay Metric for IPPM),
	and supporting text. The Delay Spread is the 75th Type-P-One-way-		and supporting text. The Delay Spread is the 75th Type-P-One-way-
	Delay-Percentile minus the 25th Type-P-One-way-Delay-Percentile.		Delay-Percentile minus the 25th Type-P-One-way-Delay-Percentile.
	4.4. Duplication		4.4. Duplication
	Duplication is the fraction of packets sent but not lost for which		Duplication is the fraction of packets sent but not lost for which
	more than a single copy of the packet was received within the timeout		more than a single copy of the packet was received within the timeout
	period (ideally using the same timeout as in the definition of loss),		period (ideally using the same timeout as in the definition of loss).
	expressed in percentage points.		It is expressed as a percentage.
	Note: while most received packets can be ones previously seen,		Note: while most received packets can be ones previously seen,
	duplication can never exceed 100%.		duplication can never exceed 100%.
	For more information, see section 5.2 (Type-P-one-way-replicated-		For more information, see section 5.2 (Type-P-one-way-replicated-
	packet-rate) of RFC 5560 [RFC5560] (A One-Way Packet Duplication		packet-rate) of RFC 5560 [RFC5560] (A One-Way Packet Duplication
	Metric). Duplication is Type-P-one-way-replicated-packet-rate		Metric). Duplication is Type-P-one-way-replicated-packet-rate
	expressed as a percentage.		expressed as a percentage.
	4.5. Reordering		4.5. Reordering
	skipping to change at page 11, line 12		skipping to change at page 11, line 12
	a given DSCP) used in the measurement. For the time, the end of the		a given DSCP) used in the measurement. For the time, the end of the
	measurement interval MUST be reported.		measurement interval MUST be reported.
	5.2. Round-Trip Active Measurement		5.2. Round-Trip Active Measurement
	The same default parameters and characterization apply to round-trip		The same default parameters and characterization apply to round-trip
	measurement as to one-way measurement (Section 5.1).		measurement as to one-way measurement (Section 5.1).
	5.3. Passive Measurement		5.3. Passive Measurement
	Passive measurement use whatever data it is natural to use. For		Passive measurements use whatever data it is natural to use. For
	example, an IP telephony application or a networked game would use		example, an IP telephony application or a networked game would use
	the data that it sends. An analysis of performance of a link might		the data that it sends. An analysis of performance of a link might
	use all the packets that traversed the link in the measurement		use all the packets that traversed the link in the measurement
	interval. An analysis of performance of an Internet service		interval. An analysis of performance of an Internet service
	provider's network might use all the packets that traversed the		provider's network might use all the packets that traversed the
	network in the measurement interval. An analysis of performance of a		network in the measurement interval. An analysis of performance of a
	specific service from the point of view of a given site might use an		specific service from the point of view of a given site might use an
	appropriate filter to select only the relevant packets. In any case,		appropriate filter to select only the relevant packets. In any case,
	the source needs to be reported.		the source needs to be reported.
	skipping to change at page 16, line 5		skipping to change at page 16, line 5
	This document requires no action from the IANA.		This document requires no action from the IANA.
	9. Internationalization Considerations		9. Internationalization Considerations
	The reported metrics, while they might occasionally be parsed by		The reported metrics, while they might occasionally be parsed by
	machine, are primarily meant for human consumption. As such, they		machine, are primarily meant for human consumption. As such, they
	MAY be reported in the language preferred by the user, using an		MAY be reported in the language preferred by the user, using an
	encoding suitable for the purpose, such as UTF-8.		encoding suitable for the purpose, such as UTF-8.
	10. Normative References		10. References
			10.1. Normative References
	[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.
	[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.
	[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.
	[RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric",		[RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric",
	RFC 5560, May 2009.		RFC 5560, May 2009.
			10.2. Informative References
			[I-D.ietf-ippm-reporting-metrics]
			Morton, A., Ramachandran, G., and G. Maguluri, "Reporting
			Metrics: Different Points of View",
			draft-ietf-ippm-reporting-metrics-04 (work in progress),
			October 2010.
	Appendix A. Sample Source Code for Computing the Metrics		Appendix A. Sample Source Code for Computing the Metrics
	This appendix only serves for illustrative purposes.		This appendix only serves for illustrative purposes.
	/*		/*
	* reporting.c -- performance metrics reporting as in Internet Draft		* reporting.c -- performance metrics reporting as in Internet Draft
	* draft-ietf-ippm-reporting.		* draft-ietf-ippm-reporting.
	*		*
	* Written by Stanislav Shalunov, http://www.internet2.edu/~shalunov/		* Written by Stanislav Shalunov, http://www.internet2.edu/~shalunov/
	* Bernhard Lutzmann, belu@users.sf.net		* Bernhard Lutzmann, belu@users.sf.net
End of changes. 11 change blocks.
	12 lines changed or deleted		28 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/