draft-ietf-ippm-reporting-01.txt		draft-ietf-ippm-reporting-02.txt
	Network Working Group S. Shalunov		Network Working Group S. Shalunov
	Internet-Draft Internet2		Internet-Draft
	Expires: April 26, 2007 B. Lutzmann		Intended status: Standards Track M. Swany
	F. Pouzols		Expires: January 15, 2009 University of Delaware
	October 23, 2006		July 14, 2008
	Reporting IP Performance Metrics to Users		Reporting IP Performance Metrics to Users
	draft-ietf-ippm-reporting-01.txt		draft-ietf-ippm-reporting-02.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on April 26, 2007.		This Internet-Draft will expire on January 15, 2009.
	Copyright Notice
	Copyright (C) The Internet Society (2006).
	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 state to an end user. It is for this purpose		describing a network's state to an end user. It is for this purpose
	that the present set of metrics is defined.		that the present set of metrics is defined.
	Table of Contents		Table of Contents
	1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3		1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
	2. Goals and Motivation . . . . . . . . . . . . . . . . . . . . . 4		2. Goals and Motivation . . . . . . . . . . . . . . . . . . . . . 4
	3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Applicability for Long-Term Measurements . . . . . . . . . . . 6
	4. Reportable Metrics Set . . . . . . . . . . . . . . . . . . . . 7		4. Reportable Metrics Set . . . . . . . . . . . . . . . . . . . . 7
	4.1. Delay . . . . . . . . . . . . . . . . . . . . . . . . . . 7		4.1. Median Delay . . . . . . . . . . . . . . . . . . . . . . . 7
	4.2. Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		4.2. Loss Ratio . . . . . . . . . . . . . . . . . . . . . . . . 7
	4.3. Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . 7		4.3. Delay Spread . . . . . . . . . . . . . . . . . . . . . . . 7
	4.4. Duplication . . . . . . . . . . . . . . . . . . . . . . . 8		4.4. Duplication . . . . . . . . . . . . . . . . . . . . . . . 7
	4.5. Reordering . . . . . . . . . . . . . . . . . . . . . . . . 8		4.5. Reordering . . . . . . . . . . . . . . . . . . . . . . . . 8
	5. Sample Source . . . . . . . . . . . . . . . . . . . . . . . . 9		5. Sample Source . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.1. One-Way Active Measurement . . . . . . . . . . . . . . . . 9		5.1. One-Way Active Measurement . . . . . . . . . . . . . . . . 9
	5.2. Round-Trip Active Measurement . . . . . . . . . . . . . . 10		5.2. Round-Trip Active Measurement . . . . . . . . . . . . . . 10
	5.3. Passive Measurement . . . . . . . . . . . . . . . . . . . 10		5.3. Passive Measurement . . . . . . . . . . . . . . . . . . . 10
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 11		6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	9. Internationalization Considerations . . . . . . . . . . . . . 14		9. Internationalization Considerations . . . . . . . . . . . . . 14
	10. Normative References . . . . . . . . . . . . . . . . . . . . . 14		10. Normative References . . . . . . . . . . . . . . . . . . . . . 15
	Appendix A. Sample Source Code for Computing the Metrics . . . . 15		Appendix A. Sample Source Code for Computing the Metrics . . . . 16
	Appendix B. Example Report . . . . . . . . . . . . . . . . . . . 39		Appendix B. Example Report . . . . . . . . . . . . . . . . . . . 40
	Appendix C. TODO . . . . . . . . . . . . . . . . . . . . . . . . 40		Appendix C. TODO . . . . . . . . . . . . . . . . . . . . . . . . 41
	Appendix D. Revision History . . . . . . . . . . . . . . . . . . 41		Appendix D. Revision History . . . . . . . . . . . . . . . . . . 42
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
	Intellectual Property and Copyright Statements . . . . . . . . . . 43		Intellectual Property and Copyright Statements . . . . . . . . . . 44
	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].
	2. Goals and Motivation		2. Goals and Motivation
	The IPPM working group has defined many richly parameterized		The IPPM working group has defined many richly parameterized
	skipping to change at page 4, line 26		skipping to change at page 4, line 26
	be compared against each other.		be compared against each other.
	Existing tools already report statistic about the network. This is		Existing tools already report statistic about the network. This is
	done for varying reasons: network testing tools, such as the ping		done for varying reasons: network testing tools, such as the ping
	program available in UNIX-derived operating systems as well as in		program available in UNIX-derived operating systems as well as in
	Microsoft Windows, report statistics with no knowledge of why the		Microsoft Windows, report statistics with no knowledge of why the
	user is running the program; networked games might report statistics		user is running the program; networked games might report statistics
	of the network connection to the server so users can better		of the network connection to the server so users can better
	understand why they get the results they get (e.g., if something is		understand why they get the results they get (e.g., if something is
	slow, is this because of the network or the CPU?), so they can		slow, is this because of the network or the CPU?), so they can
	compare their statistics to those of others (``you're not lagged any		compare their statistics to those of others ("you're not lagged any
	more than I am'') or perhaps so that users can decide whether they		more than I am") or perhaps so that users can decide whether they
	need to upgrade the connection to their home; IP telephony hardware		need to upgrade the connection to their home; IP telephony hardware
	and software might report the statistics for similar reasons. While		and software might report the statistics for similar reasons. While
	existing tools report statistics all right, the particular set of		existing tools report statistics all right, the particular set of
	metrics they choose is ad hoc; some metrics are not statistically		metrics they choose is ad hoc; some metrics are not statistically
	robust, some are not relevant, and some are not easy to understand;		robust, some are not relevant, and some are not easy to understand;
	more important than specific shortcomings, however, is the		more important than specific shortcomings, however, is the
	incompatibility: even if the sets of metrics were perfect, they would		incompatibility: even if the sets of metrics were perfect, they would
	still be all different, and, therefore, metrics reported by different		still be all different, and, therefore, metrics reported by different
	tools would not be comparable.		tools would not be comparable.
	skipping to change at page 6, line 5		skipping to change at page 6, line 5
	Finally, while this set will most frequently be computed for small		Finally, while this set will most frequently be computed for small
	data sets, where efficiency is not a serious consideration, it must		data sets, where efficiency is not a serious consideration, it must
	be possible to compute for large data sets, too. In particular, it		be possible to compute for large data sets, too. In particular, it
	must be possible to compute the metrics in a single pass over the		must be possible to compute the metrics in a single pass over the
	data using a limited amount of memory (i.e., it must be possible to		data using a limited amount of memory (i.e., it must be possible to
	take a source of measurement data with a high data rate and compute		take a source of measurement data with a high data rate and compute
	the metrics on the fly, discarding each data point after it is		the metrics on the fly, discarding each data point after it is
	processed).		processed).
	3. Scope		3. Applicability for Long-Term Measurements
	The metrics in this document are applicable to short-term network		The metrics in this document are most applicable to short-term
	measurements (seconds or at most minutes) and are aimed at real-time		network measurements (seconds or at most minutes) and are targeted
	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.
	4. Reportable Metrics Set		4. Reportable Metrics Set
	The following metrics comprise the set:		The following metrics comprise the set:
	1. delay;		1. median delay;
	2. loss;		2. loss ratio;
	3. jitter;		3. delay spread;
	4. duplication;		4. duplication;
	5. reordering.		5. reordering.
	Each of the above is represented by a single numeric quantity,		Each of the above is represented by a single numeric quantity,
	computed as described below.		computed as described below.
	4.1. Delay		4.1. Median Delay
	The reported delay is the median of all delays in the sample. When a		The reported median delay is the median of all delays in the sample.
	packet is lost, its delay is to be considered +infinity for the		When a packet is lost, its delay is to be considered +infinity for
	purposes of this computation; therefore, if more than half of all		the purposes of this computation; therefore, if more than half of all
	packets are lost, the delay is +infinity.		packets are lost, the delay is +infinity.
	FIXME: References.		4.2. Loss Ratio
	4.2. Loss
	Loss is the fraction, expressed as a percentage, of packets that did
	not arrive intact within a given number of seconds (timeout value)
	after being sent. Since this set of metrics often has to be reported
	to a waiting human user, the default timeout value has to be small.
	By default, 2 seconds MUST be the timeout value.
	FIXME: References.
	4.3. Jitter		Loss Ratio is the fraction, expressed as a percentile, of packets
			that did not arrive intact within a given number of seconds (the
			timeout value) after being sent. Since this set of metrics often has
			to be reported to a waiting human user, the default timeout value
			should be small. By default, 2 seconds MUST be the timeout value.
			Use of a different timeout value MUST be reported.
	Jitter is the interquartile spread of delay. In other words, jitter		4.3. Delay Spread
	is equal to the difference of the 75th and 25th percentiles of delay.
	When both percentiles are +infinity, the value of jitter is
	undefined. Therefore, if less than 25% of packets are lost, jitter
	is defined and finite; if between 75% and 25% of packets are lost,
	jitter is +infinity; finally, if more than 75% of packets are lost,
	jitter is undefined.
	FIXME: References.		Delay spread is the interquartile spread of observed delays. This is
			a metric to represent what is commonly referred to as "jitter".
			Delay spread is reported as the difference of the 75th and 25th
			percentiles of delay. When both percentiles are +infinity, the value
			of delay spread is undefined. Therefore, if less than 25% of packets
			are lost, it is defined and finite; if between 75% and 25% of packets
			are lost, it is +infinity; finally, if more than 75% of packets are
			lost, it is undefined.
	4.4. Duplication		4.4. Duplication
	Duplication is the fraction of packets for which more than a single		Duplication is the fraction of transmitted packets for which more
	copy of the packet was received within the timeout period (same		than a single copy of the packet was received within the timeout
	timeout as in the definition of loss), expressed in percentage		period (ideally using the same timeout as in the definition of loss),
	points.		expressed in percentage points.
	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%.
	FIXME: References (tough one---IPPM hasn't defined duplication).
	4.5. Reordering		4.5. Reordering
	Reordering is the fraction of sent packets for which the sequence		Reordering is the fraction of sent packets for which the sequence
	number of the packet received immediately before the first copy of		number of the packet received immediately before the first copy of
	the given packet is not the decrement of the sequence number of the		the given packet is not the decrement of the sequence number of the
	given packet. For the purposes of determining the sequence number of		given packet. For the purposes of determining the sequence number of
	the preceding packet in this definition, assuming sequence numbers		the preceding packet in this definition, assuming sequence numbers
	starting with 1, an extra packet at the start of the stream of		starting with 1, an extra packet at the start of the stream of
	received packets, with a sequence number of 0, is considered to be		received packets, with a sequence number of 0, is considered to be
	present (this extra packet, of course, is not counted for the		present (this extra packet, of course, is not counted for the
	skipping to change at page 9, line 48		skipping to change at page 9, line 48
	(pseudo-)random deviates.		(pseudo-)random deviates.
	The default packet size is the minimum necessary for the measurement.		The default packet size is the minimum necessary for the measurement.
	Values other than the default ones MAY be used; if they are used,		Values other than the default ones MAY be used; if they are used,
	their use, and specific values used, MUST be reported.		their use, and specific values used, MUST be reported.
	A one-way active measurement is characterized by the source IP		A one-way active measurement is characterized by the source IP
	address, the destination IP address, the time when measurement was		address, the destination IP address, the time when measurement was
	taken, and the type of packets (e.g., UDP with given port numbers and		taken, and the type of packets (e.g., UDP with given port numbers and
	a given DSCP) used in the measurement. For the time, the middle of		a given DSCP) used in the measurement. For the time, the end of the
	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 measurement 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
	skipping to change at page 10, line 26		skipping to change at page 10, line 26
	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.
	The same default duration applies to passive measurement as to one-		The same default duration applies to passive measurement as to one-
	way active measurement (Section 5.1).		way active measurement (Section 5.1).
	When the passive measurement data is reported in real time, a sliding		When the passive measurement data is reported in real time, or based
	window SHOULD be used as a measurement period, so that recent data		on user demand, a sliding window SHOULD be used as a measurement
	become more quickly reflected.		period, so that recent data become more quickly reflected. For
			historical reporting purposes, a fixed interval may be preferable.
	6. Security Considerations		6. Security Considerations
	The reporting per se, not being a protocol, does not raise security		The reporting per se, not being a protocol, does not raise security
	considerations.		considerations.
	An aspect of reporting relevant to security is how the reported		An aspect of reporting relevant to security is how the reported
	metrics are used and how they are collected. If it is important that		metrics are used and how they are collected. If it is important that
	the metrics satisfy certain conditions (e.g., that the ISP whose		the metrics satisfy certain conditions (e.g., that the ISP whose
	network is being measured be unable to make the metrics appear better		network is being measured be unable to make the metrics appear better
	than they are), the collection mechanism MUST ensure that this is,		than they are), the collection mechanism MUST ensure that this is,
	indeed, so. The exact mechanisms to do so our outside of scope of		indeed, so. The exact mechanisms to do so are outside of scope of
	this document and belong with discussion of particular measurement		this document and belong with discussion of particular measurement
	data collection protocols.		data collection protocols.
	7. Acknowledgments		7. Acknowledgments
	We gratefully acknowledge discussion with, encouragement from, and		We gratefully acknowledge discussion with, encouragement from, and
	contributions of Lawrence D. Dunn, Reza Fardid, Ruediger Geib,		contributions of Lawrence D. Dunn, Reza Fardid, Ruediger Geib,
	Matt Mathis, Al Morton, Carsten Schmoll, Henk Uijterwaal, and		Matt Mathis, Al Morton, Carsten Schmoll, Henk Uijterwaal, and
	Matthew J. Zekauskas.		Matthew J. Zekauskas.
	skipping to change at page 42, line 8		skipping to change at page 43, line 8
	Revision 1.2 2006/04/04 21:39:20 shalunov		Revision 1.2 2006/04/04 21:39:20 shalunov
	Convert to xml2rfc 1.30 and RFC 3978 IPR statement.		Convert to xml2rfc 1.30 and RFC 3978 IPR statement.
	Revision 1.1.1.1 2006/04/02 17:07:36 shalunov		Revision 1.1.1.1 2006/04/02 17:07:36 shalunov
	Initial import into CVS.		Initial import into CVS.
	Authors' Addresses		Authors' Addresses
	Stanislav Shalunov		Stanislav Shalunov
	Internet2
	1000 Oakbrook Drive, Suite 300		Email: shalunov@shlang.com
	Ann Arbor, MI 48104		URI: http://shlang.com/
			Martin Swany
			University of Delaware
			Department of Computer and Information Sciences
			Newark, DE 19716
	US		US
	Email: shalunov@internet2.edu		Email: swany@cis.udel.edu
	URI: http://www.internet2.edu/~shalunov/		URI: http://www.cis.udel.edu/~swany/
	Bernhard Lutzmann		Full Copyright Statement
	Email: belu@users.sf.net		Copyright (C) The IETF Trust (2008).
	Federico Montesino Pouzols		This document is subject to the rights, licenses and restrictions
			contained in BCP 78, and except as set forth therein, the authors
			retain all their rights.
	Email: fedemp@altern.org		This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
			THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
			OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
			THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property Statement		Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	skipping to change at page 43, line 28		skipping to change at line 1569
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Disclaimer of Validity
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement
	Copyright (C) The Internet Society (2006). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.
	Acknowledgment
	Funding for the RFC Editor function is currently provided by the
	Internet Society.
End of changes. 31 change blocks.
	77 lines changed or deleted		81 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/