draft-ietf-ippm-multimetrics-09.txt		draft-ietf-ippm-multimetrics-10.txt
	Network Working Group E. Stephan		Network Working Group E. Stephan
	Internet-Draft France Telecom		Internet-Draft France Telecom
	Intended status: Standards Track L. Liang		Intended status: Standards Track L. Liang
	Expires: April 18, 2009 University of Surrey		Expires: October 24, 2009 University of Surrey
	A. Morton		A. Morton
	AT&T Labs		AT&T Labs
	October 15, 2008		April 22, 2009
	IP Performance Metrics (IPPM) for spatial and multicast		IP Performance Metrics (IPPM) for spatial and multicast
	draft-ietf-ippm-multimetrics-09		draft-ietf-ippm-multimetrics-10
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with the
	applicable patent or other IPR claims of which he or she is aware		provisions of BCP 78 and BCP 79.
	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.
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	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."
	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 18, 2009.		This Internet-Draft will expire on October 24, 2009.
			Copyright Notice
			Copyright (c) 2009 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents in effect on the date of
			publication of this document (http://trustee.ietf.org/license-info).
			Please review these documents carefully, as they describe your rights
			and restrictions with respect to this document.
	Abstract		Abstract
	The IETF has standardized IP Performance Metrics (IPPM) for measuring		The IETF has standardized IP Performance Metrics (IPPM) for measuring
	end-to-end performance between two points. This memo defines two new		end-to-end performance between two points. This memo defines two new
	categories of metrics that extend the coverage to multiple		categories of metrics that extend the coverage to multiple
	measurement points. It defines spatial metrics for measuring the		measurement points. It defines spatial metrics for measuring the
	performance of segments of a source to destination path, and metrics		performance of segments of a source to destination path, and metrics
	for measuring the performance between a source and many destinations		for measuring the performance between a source and many destinations
	in multiparty communications (e.g., a multicast tree).		in multiparty communications (e.g., a multicast tree).
	skipping to change at page 2, line 30		skipping to change at page 3, line 4
	8. One-to-group Sample Statistics . . . . . . . . . . . . . . . . 26		8. One-to-group Sample Statistics . . . . . . . . . . . . . . . . 26
	9. Measurement Methods: Scalability and Reporting . . . . . . . . 36		9. Measurement Methods: Scalability and Reporting . . . . . . . . 36
	10. Manageability Considerations . . . . . . . . . . . . . . . . . 39		10. Manageability Considerations . . . . . . . . . . . . . . . . . 39
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 44		11. Security Considerations . . . . . . . . . . . . . . . . . . . 44
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
	13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45		13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49		14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49
	14.1. Normative References . . . . . . . . . . . . . . . . . . 49		14.1. Normative References . . . . . . . . . . . . . . . . . . 49
	14.2. Informative References . . . . . . . . . . . . . . . . . 50		14.2. Informative References . . . . . . . . . . . . . . . . . 50
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
	Intellectual Property and Copyright Statements . . . . . . . . . . 51
	1. Introduction and Scope		1. Introduction and Scope
	IETF has standardized IP Performance Metrics (IPPM) for measuring		IETF has standardized IP Performance Metrics (IPPM) for measuring
	end-to-end performance between two points. This memo defines two new		end-to-end performance between two points. This memo defines two new
	categories of metrics that extend the coverage to multiple		categories of metrics that extend the coverage to multiple
	measurement points. It defines spatial metrics for measuring the		measurement points. It defines spatial metrics for measuring the
	performance of segments of a source to destination path, and metrics		performance of segments of a source to destination path, and metrics
	for measuring the performance between a source and many destinations		for measuring the performance between a source and many destinations
	in multiparty communications (e.g., a multicast tree).		in multiparty communications (e.g., a multicast tree).
	skipping to change at page 3, line 27		skipping to change at page 3, line 27
	Spatial metrics measure the performance of each segment along a path.		Spatial metrics measure the performance of each segment along a path.
	One-to-group metrics measure the performance for a group of users.		One-to-group metrics measure the performance for a group of users.
	These metrics are derived from one-way end-to-end metrics, all of		These metrics are derived from one-way end-to-end metrics, all of
	which follow the IPPM framework [RFC2330].		which follow the IPPM framework [RFC2330].
	This memo is organized as follows: Section 2 introduces new terms		This memo is organized as follows: Section 2 introduces new terms
	that extend the original IPPM framework [RFC2330]. Section 3		that extend the original IPPM framework [RFC2330]. Section 3
	motivates each metric category and briefly introduces the new		motivates each metric category and briefly introduces the new
	metrics. Sections 4 through 7 develop each category of metrics with		metrics. Sections 4 through 7 develop each category of metrics with
	definitions and statistics. Then the memo discusses the impact of		definitions and statistics. Then the memo discusses the impact of
	the measurement methods on the scaleability and proposes an		the measurement methods on the scalability and proposes an
	information model for reporting the measurements. Finally, the memo		information model for reporting the measurements. Finally, the memo
	discusses security aspects related to measurement and registers the		discusses security aspects related to measurement and registers the
	metrics in the IANA IP Performance Metrics Registry [RFC4148].		metrics in the IANA IP Performance Metrics Registry [RFC4148].
	The scope of this memo is limited to metrics using a single source		The scope of this memo is limited to metrics using a single source
	packet or stream, and observations of corresponding packets along the		packet or stream, and observations of corresponding packets along the
	path (spatial), at one or more destinations (one-to-group), or both.		path (spatial), at one or more destinations (one-to-group), or both.
	Note that all the metrics defined herein are based on observations of		Note that all the metrics defined herein are based on observations of
	packets dedicated to testing, a process which is called active		packets dedicated to testing, a process which is called active
	measurement. Passive measurement (for example, a spatial metric		measurement. Passive measurement (for example, a spatial metric
	skipping to change at page 27, line 13		skipping to change at page 27, line 13
	The one-to-group metrics defined above are directly achieved by		The one-to-group metrics defined above are directly achieved by
	collecting relevant unicast one-way metrics measurements results and		collecting relevant unicast one-way metrics measurements results and
	by gathering them per group of receivers. They produce network		by gathering them per group of receivers. They produce network
	performance information which guides engineers toward potential		performance information which guides engineers toward potential
	problems which may have happened on any branch of a multicast routing		problems which may have happened on any branch of a multicast routing
	tree.		tree.
	The results of these metrics are not directly usable to present the		The results of these metrics are not directly usable to present the
	performance of a group because each result is made of a huge number		performance of a group because each result is made of a huge number
	of singletons which are difficult to read and analyze. As an		of singletons which are difficult to read and analyze. As an
	example, delay are not comparable because the distance between		example, delays are not comparable because the distance between
	receiver and sender differs. Furthermore they don't capture relative		receiver and sender differs. Furthermore they don't capture relative
	performance situation a multiparty communication.		performance situation a multiparty communication.
	From the performance point of view, the multiparty communication		From the performance point of view, the multiparty communication
	services not only require the support of absolute performance		services not only require the support of absolute performance
	information but also information on "relative performance". The		information but also information on "relative performance". The
	relative performance means the difference between absolute		relative performance means the difference between absolute
	performance of all users. Directly using the one-way metrics cannot		performance of all users. Directly using the one-way metrics cannot
	present the relative performance situation. However, if we use the		present the relative performance situation. However, if we use the
	variations of all users one-way parameters, we can have new metrics		variations of all users one-way parameters, we can have new metrics
	to measure the difference of the absolute performance and hence		to measure the difference of the absolute performance and hence
	provide the threshold value of relative performance that a multiparty		provide the threshold value of relative performance that a multiparty
	service might demand. A very good example of the high relative		service might demand. A very good example of the high relative
	performance requirement is the online gaming. A very light		performance requirement is online gaming. A very small difference in
	difference in delay might result in failure in the game. We have to		delay might result in failure in the game. We have to use multicast
	use multicast specific statistic metrics to define the relative delay		specific statistic metrics to define the relative delay required by
	required by online gaming. There are many other services, e.g.		online gaming. There are many other services, e.g. online biding,
	online biding, online stock market, etc., that require multicast		online stock market, etc., that require multicast metrics in order to
	metrics in order to evaluate the network against their requirements.		evaluate the network against their requirements. Therefore, we can
	Therefore, we can see the importance of new, multicast specific,		see the importance of new, multicast specific, statistic metrics to
	statistic metrics to feed this need.		feed this need.
	We might also use some one-to-group statistic conceptions to present		We might also use some one-to-group statistic conceptions to present
	and report the group performance and relative performance to save the		and report the group performance and relative performance to save the
	report transmission bandwidth. Statistics have been defined for One-		report transmission bandwidth. Statistics have been defined for One-
	way metrics in corresponding RFCs. They provide the foundation of		way metrics in corresponding RFCs. They provide the foundation of
	definition for performance statistics. For instance, there are		definition for performance statistics. For instance, there are
	definitions for minimum and maximum One-way delay in [RFC2679].		definitions for minimum and maximum One-way delay in [RFC2679].
	However, there is a dramatic difference between the statistics for		However, there is a dramatic difference between the statistics for
	one-to-one communications and for one-to-many communications. The		one-to-one communications and for one-to-many communications. The
	former one only has statistics over the time dimension while the		former one only has statistics over the time dimension while the
	skipping to change at page 29, line 4		skipping to change at page 29, line 4
	rather than sending every one-way singleton it observed. As long as		rather than sending every one-way singleton it observed. As long as
	an appropriate time interval is decided, appropriate statistics can		an appropriate time interval is decided, appropriate statistics can
	represent the performance in a certain accurate scale. How to decide		represent the performance in a certain accurate scale. How to decide
	the time interval and how to bootstrap all points of interest and the		the time interval and how to bootstrap all points of interest and the
	reference point depend on applications. For instance, applications		reference point depend on applications. For instance, applications
	with lower transmission rate can have the time interval longer and		with lower transmission rate can have the time interval longer and
	ones with higher transmission rate can have the time interval		ones with higher transmission rate can have the time interval
	shorter. However, this is out of the scope of this memo.		shorter. However, this is out of the scope of this memo.
	Moreover, after knowing the statistics over the time dimension, one		Moreover, after knowing the statistics over the time dimension, one
	might want to know how this statistics distributed over the space		might want to know how these statistics are distributed over the
	dimension. For instance, a TV broadcast service provider had the		space dimension. For instance, a TV broadcast service provider had
	performance Matrix M and calculated the One-way delay mean over the		the performance Matrix M and calculated the One-way delay mean over
	time dimension to obtain a delay Vector as {V1,V2,..., VN}. He then		the time dimension to obtain a delay Vector as {V1,V2,..., VN}. He
	calculated the mean of all the elements in the Vector to see what		then calculated the mean of all the elements in the Vector to see
	level of delay he has served to all N users. This new delay mean		what level of delay he has served to all N users. This new delay
	gives information on how good the service has been delivered to a		mean gives information on how good the service has been delivered to
	group of users during a sampling interval in terms of delay. It		a group of users during a sampling interval in terms of delay. It
	needs twice calculation to have this statistic over both time and		requires twice as much calculation to have this statistic over both
	space dimensions. We name this kind of statistics 2-level statistics		time and space dimensions. This kind of statistics is referred to as
	to distinct with those 1-level statistics calculated over either		2-level statistics to distinguish them from 1-level statistics
	space or time dimension. It can be easily proven that no matter over		calculated over either space or time dimension. It can be easily
	which dimension a 2-level statistic is calculated first, the results		proven that no matter over which dimension a 2-level statistic is
	are the same. I.e. one can calculate the 2-level delay mean using		calculated first, the results are the same. I.e. one can calculate
	the Matrix M by having the 1-level delay mean over the time dimension		the 2-level delay mean using the Matrix M by having the 1-level delay
	first and then calculate the mean of the obtained vector to find out		mean over the time dimension first and then calculate the mean of the
	the 2-level delay mean. Or, he can do the 1-level statistic		obtained vector to find out the 2-level delay mean. Or, he can do
	calculation over the space dimension first and then have the 2-level		the 1-level statistic calculation over the space dimension first and
	delay mean. Both two results will be exactly the same. Therefore,		then have the 2-level delay mean. Both two results will be exactly
	when defining a 2-level statistic there is no need to specify the		the same. Therefore, when defining a 2-level statistic there is no
	order in which the calculation is executed.		need to specify the order in which the calculation is executed.
	Many statistics can be defined for the proposed one-to-group metrics		Many statistics can be defined for the proposed one-to-group metrics
	over either the space dimension or the time dimension or both. This		over either the space dimension or the time dimension or both. This
	memo treats the case where a stream of packets from the Source		memo treats the case where a stream of packets from the Source
	results in a sample at each of the Receivers in the Group, and these		results in a sample at each of the Receivers in the Group, and these
	samples are each summarized with the usual statistics employed in		samples are each summarized with the usual statistics employed in
	one-to-one communication. New statistic definitions are presented,		one-to-one communication. New statistic definitions are presented,
	which summarize the one-to-one statistics over all the Receivers in		which summarize the one-to-one statistics over all the Receivers in
	the Group.		the Group.
	8.1. Discussion on the Impact of packet loss on statistics		8.1. Discussion on the Impact of packet loss on statistics
	The packet loss does have effects on one-way metrics and their		The packet loss does have effects on one-way metrics and their
	statistics. For example, the lost packet can result in an infinite		statistics. For example, a lost packet can result in an infinite
	one-way delay. It is easy to handle the problem by simply ignoring		one-way delay. It is easy to handle the problem by simply ignoring
	the infinite value in the metrics and in the calculation of the		the infinite value in the metrics and in the calculation of the
	corresponding statistics. However, the packet loss has so strong		corresponding statistics. However, the packet loss has such a strong
	impact on the statistics calculation for the one-to-group metrics		impact on the statistics calculation for the one-to-group metrics
	that it can not be solved by the same method used for one-way		that it can not be solved by the same method used for one-way
	metrics. This is due to the complexity of building a matrix, which		metrics. This is due to the complexity of building a matrix, which
	is needed for calculation of the statistics proposed in this memo.		is needed for calculation of the statistics proposed in this memo.
	The situation is that measurement results obtained by different end		The situation is that measurement results obtained by different end
	users might have different packet loss pattern. For example, for		users might have different packet loss pattern. For example, for
	User1, packet A was observed lost. And for User2, packet A was		User1, packet A was observed lost. And for User2, packet A was
	successfully received but packet B was lost. If the method to		successfully received but packet B was lost. If the method to
	overcome the packet loss for one-way metrics is applied, the two		overcome the packet loss for one-way metrics is applied, the two
	singleton sets reported by User1 and User2 will be different in terms		singleton sets reported by User1 and User2 will be different in terms
	of the transmitted packets. Moreover, if User1 and User2 have		of the transmitted packets. Moreover, if User1 and User2 have
	different number of lost packets, the size of the results will be		different number of lost packets, the size of the results will be
	different. Therefore, for the centralized calculation, the reference		different. Therefore, for the centralized calculation, the reference
	point will not be able to use these two results to build up the group		point will not be able to use these two results to build up the group
	Matrix and can not calculate the statistics. In an extreme		Matrix and can not calculate the statistics. The extreme situation
	situation, no single packet arrives all users in the measurement and		being the case when no packets arrive at any user. One of the
	the Matrix will be empty. One of the possible solutions is to		possible solutions is to replace the infinite/undefined delay value
	replace the infinite/undefined delay value by the average of the two		by the average of the two adjacent values. For example, if the
	adjacent values. For example, if the result reported by user1 is {		result reported by user1 is { R1dT1 R1dT2 R1dT3 ... R1dTK-1 UNDEF
	R1dT1 R1dT2 R1dT3 ... R1dTK-1 UNDEF R1dTK+1... R1DM } where "UNDEF"		R1dTK+1... R1DM } where "UNDEF" is an undefined value, the reference
	is an undefined value, the reference point can replace it by R1dTK =		point can replace it by R1dTK = {(R1dTK-1)+( R1dTK+1)}/2. Therefore,
	{(R1dTK-1)+( R1dTK+1)}/2. Therefore, this result can be used to		this result can be used to build up the group Matrix with an
	build up the group Matrix with an estimated value R1dTK. There are		estimated value R1dTK. There are other possible solutions such as
	other possible solutions such as using the overall mean of the whole		using the overall mean of the whole result to replace the infinite/
	result to replace the infinite/undefined value, and so on. However		undefined value, and so on. However this is out of the scope of this
	this is out of the scope of this memo.		memo.
	For the distributed calculation, the reported statistics might have		For the distributed calculation, the reported statistics might have
	different "weight" to present the group performance, which is		different "weight" to present the group performance, which is
	especially true for delay and ipdv relevant metrics. For example,		especially true for delay and ipdv relevant metrics. For example,
	User1 calculates the Type-P-Finite-One-way-Delay-Mean R1DM as shown		User1 calculates the Type-P-Finite-One-way-Delay-Mean R1DM as shown
	in Figure. 8 without any packet loss and User2 calculates the R2DM		in Figure. 8 without any packet loss and User2 calculates the R2DM
	with N-2 packet loss. The R1DM and R2DM should not be treated with		with N-2 packet loss. The R1DM and R2DM should not be treated with
	equal weight because R2DM was calculated only based on 2 delay values		equal weight because R2DM was calculated only based on 2 delay values
	in the whole sample interval. One possible solution is to use a		in the whole sample interval. One possible solution is to use a
	weight factor to mark every statistic value sent by users and use		weight factor to mark every statistic value sent by users and use
	skipping to change at page 37, line 30		skipping to change at page 37, line 30
	distributed statistic calculation method. The sample should include		distributed statistic calculation method. The sample should include
	all metrics parameters, the values and the corresponding sequence		all metrics parameters, the values and the corresponding sequence
	numbers. The transmission of the whole sample can cost much more		numbers. The transmission of the whole sample can cost much more
	bandwidth than the transmission of the statistics that should include		bandwidth than the transmission of the statistics that should include
	all statistic parameters specified by policies and the additional		all statistic parameters specified by policies and the additional
	information about the whole sample, such as the size of the sample,		information about the whole sample, such as the size of the sample,
	the group address, the address of the point of interest, the ID of		the group address, the address of the point of interest, the ID of
	the sample session, and so on. Apparently, the centralized		the sample session, and so on. Apparently, the centralized
	calculation method can require much more bandwidth than the		calculation method can require much more bandwidth than the
	distributed calculation method when the sample size is big. This is		distributed calculation method when the sample size is big. This is
	especially true when the measurement has huge number of the points of		especially true when the measurement has a very large number of the
	interest. It can lead to a scalability issue at the reference point		points of interest. It can lead to a scalability issue at the
	by over load the network resources. The distributed calculation		reference point by overloading the network resources.
	method can save much more bandwidth and release the pressure of the
	scalability issue at the reference point side. However, it can		The distributed calculation method can save much more bandwidth and
	result in the lack of information because not all measured singletons		mitigate issues arising from scalability at the reference point side.
	are obtained for building up the group matrix. The performance over
	time can be hidden from the analysis. For example, the loss pattern		However, it may result in a lost of information. As all measured
	can be missed by simply accepting the loss ratio as well as the delay		singletons are not available for building up the group matrix, the
	pattern. This tradeoff between the bandwidth consuming and the		real performance over time can be hidden from the result. For
	information acquiring has to be taken into account when design the		example, the loss pattern can be missed by simply accepting the loss
	measurement campaign to optimize the measurement results delivery.		ratio. This tradeoff between bandwidth consumption and information
	The possible solution could be to transit the statistic parameters to		acquisition has to be taken into account when designing the
			measurement approach.
			One possible solution could be to transit the statistic parameters to
	the reference point first to obtain the general information of the		the reference point first to obtain the general information of the
	group performance. If the detail results are required, the reference		group performance. If detailed results are required, the reference
	point should send the requests to the points of interest, which could		point should send the requests to the points of interest, which could
	be particular ones or the whole group. This procedure can happen in		be particular ones or the whole group. This procedure can happen in
	the off peak time and can be well scheduled to avoid delivery of too		the off peak time and can be well scheduled to avoid delivery of too
	many points of interest at the same time. Compression techniques can		many points of interest at the same time. Compression techniques can
	also be used to minimize the bandwidth required by the transmission.		also be used to minimize the bandwidth required by the transmission.
	This could be a measurement protocol to report the measurement		This could be a measurement protocol to report the measurement
	results. However, this is out of the scope of this memo.		results. However, this is out of the scope of this memo.
	9.2. Measurement		9.2. Measurement
	To prevent any bias in the result, the configuration of a one-to-many		To prevent any bias in the result, the configuration of a one-to-many
	measure must take in consideration that implicitly more packets will		measure must take in consideration that intrically more packets will
	to be routed than send and selects a test packets rate that will not		to be routed than sent (copies of a packet sent are expected to
	impact the network performance.		arrive at many destination points) and selects a test packets rate
			that will not impact the network performance.
	9.3. Effect of Time and Space Aggregation Order on Stats		9.3. Effect of Time and Space Aggregation Order on Stats
	This section presents the impact of the aggregation order on the		This section presents the impact of the aggregation order on the
	scalability of the reporting and of the computation. It makes the		scalability of the reporting and of the computation. It makes the
	hypothesis that receivers are not co-located and that results are		hypothesis that receivers are not co-located and that results are
	gathered in a point of reference for further usages.		gathered in a point of reference for further usages.
	Multimetrics samples are represented in a matrix as illustrated below		Multimetrics samples are represented in a matrix as illustrated below
	skipping to change at page 38, line 41		skipping to change at page 38, line 45
	n RnS1 RnS2 RnS3 ... RnSk /		n RnS1 RnS2 RnS3 ... RnSk /
	S1M S2M S3M ... SnM Stats over space		S1M S2M S3M ... SnM Stats over space
	\------------- ------------/		\------------- ------------/
	\/		\/
	Stat over space and time		Stat over space and time
	Figure 13: Impact of space aggregation on multimetrics Stat		Figure 13: Impact of space aggregation on multimetrics Stat
	2 methods are available to compute statistics on a matrix:		Two methods are available to compute statistics on a matrix:
	o Method 1: The statistic metric is computed over time and then over		o Method 1: The statistic metric is computed over time and then over
	space;		space;
	o Method 2: The statistic metric is computed over space and then		o Method 2: The statistic metric is computed over space and then
	over time.		over time.
	These 2 methods differ only by the order of the aggregation. The		These 2 methods differ only by the order of the aggregation. The
	order does not impact the computation resources required. It does		order does not impact the computation resources required. It does
	not change the value of the result. However, it impacts severely the		not change the value of the result. However, it impacts severely the
	minimal volume of data to report:		minimal volume of data to report:
	o Method 1: Each point of interest computes periodically statistics		o Method 1: Each point of interest computes periodically statistics
	over time to lower the volume of data to report. They are		over time to lower the volume of data to report. They are
	reported to the reference point for computing the stat over space.		reported to the reference point for for subsequent computations
	This volume no longer depends on the number of samples. It is		over the spatial dimension. This volume no longer depends on the
	only proportional to the computation period;		number of samples. It is only proportional to the computation
			period;
	o Method 2: The volume of data to report is proportional to the		o Method 2: The volume of data to report is proportional to the
	number of samples. Each sample, RiSi, must be reported to the		number of samples. Each sample, RiSi, must be reported to the
	reference point for computing statistic over space and statistic		reference point for computing statistic over space and statistic
	over time. The volume increases with the number of samples. It		over time. The volume increases with the number of samples. It
	is proportional to the number of test packets;		is proportional to the number of test packets;
	Method 2 has severe drawbacks in terms of security and dimensioning:		Method 2 has severe drawbacks in terms of security and dimensioning:
	o Increasing the rate of the test packets may result in a Denial of		o Increasing the rate of the test packets may result in a Denial of
	Service toward the points of reference;		Service toward the points of reference;
	o The dimensioning of a measurement system is quite impossible to		o The dimensioning of a measurement system is quite impossible to
	validate because any increase of the rate of the test packets will		validate because any increase of the rate of the test packets will
	increase the bandwidth requested to collect the raw results.		increase the bandwidth requested to collect the raw results.
	The computation period over time period (commonly named aggregation		The computation period over time period (commonly named aggregation
	period) provides the reporting side with a control of various		period) provides the reporting side with a control of various
	collecting aspects such as bandwidth, computation and storage		collecting aspects such as bandwidth, computation and storage
	capacities. So this draft defines metrics based on method 1.		capacities. So this draft defines metrics based on method 1.
	9.3.1. Impact on spatial statistics		9.3.1. Impact on spatial statistics
	2 methods are available to compute spatial statistics:		Two methods are available to compute spatial statistics:
	o Method 1: spatial segment metrics and statistics are preferably		o Method 1: spatial segment metrics and statistics are preferably
	computed over time by each points of interest;		computed over time for each points of interest;
	o Method 2: Vectors metrics are intrinsically instantaneous space		o Method 2: Vectors metrics are intrinsically instantaneous space
	metrics which must be reported using method2 whenever		metrics which must be reported using Method2 whenever
	instantaneous metrics information is needed.		instantaneous metrics information is needed.
	9.3.2. Impact on one-to-group statistics		9.3.2. Impact on one-to-group statistics
	2 methods are available to compute group statistics:		Two methods are available to compute group statistics:
	o Method1: Figure 5 and Figure 8 illustrate the method chosen: the		o Method1: Figure 5 and Figure 8 illustrate the method chosen: the
	one-to-one statistic is computed per interval of time before the		one-to-one statistic is computed per interval of time before the
	computation of the mean over the group of receivers;		computation of the mean over the group of receivers;
	o Method2: Figure 13 presents the second one, metric is computed		o Method2: Figure 13 presents the second one, metric is computed
	over space and then over time.		over space and then over time.
	10. Manageability Considerations		10. Manageability Considerations
	Usually IPPM WG documents defines each metric reporting within its		Usually IPPM WG documents defines each metric reporting within its
	definition. This document defines the reporting of all the metrics		definition. This document defines the reporting of all the metrics
	skipping to change at page 41, line 20		skipping to change at page 41, line 21
	10.2. Reporting One-to-group metric		10.2. Reporting One-to-group metric
	All reporting rules described in [RFC2679] and [RFC2680] apply to the		All reporting rules described in [RFC2679] and [RFC2680] apply to the
	corresponding One-to-group metrics. Following are specific		corresponding One-to-group metrics. Following are specific
	parameters that should be reported.		parameters that should be reported.
	10.2.1. Path		10.2.1. Path
	As suggested by the [RFC2679] and [RFC2680] , the path traversed by		As suggested by the [RFC2679] and [RFC2680] , the path traversed by
	the packet SHOULD be reported, if possible. For One-to-group		the packet SHOULD be reported, if possible. For One-to-group
	metrics, there is a path tree SHOULD be reported rather than A path.		metrics, the path tree between the source and the destinations or the
	This is even more impractical. If, by anyway, partial information is		set of paths between the source and each destination SHOULD be
	available to report, it might not be as valuable as it is in the one-		reported.
	to-one case because the incomplete path might be difficult to
	identify its position in the path tree. For example, how many points		Path tree might not be as valuable as individual paths because an
	of interest are reached by the packet travelled through this		incomplete path might be difficult to identify in the path tree. For
	incomplete path?		example, how many points of interest are reached by a packet
			travelling along an incomplete path?
	10.2.2. Group size		10.2.2. Group size
	The group size should be reported as one of the critical management		The group size should be reported as one of the critical management
	parameters. Unlike the spatial metrics, there is no need of order of		parameters. One-to-group metrics, unlike spatial metrics, don't
	points of interests.		require the ordering of the points of interests because group members
			receive the packets in parallel.
	10.2.3. Timestamping bias		10.2.3. Timestamping bias
	It is the same as described in section 10.1.3.		It is the same as described in section 10.1.3.
	10.2.4. Reporting One-to-group One-way Delay		10.2.4. Reporting One-to-group One-way Delay
	It is the same as described in section 10.1.4.		It is the same as described in section 10.1.4.
	10.2.5. Measurement method		10.2.5. Measurement method
	skipping to change at page 42, line 12		skipping to change at page 42, line 17
	IANA assigns each metric defined by the IPPM WG with a unique		IANA assigns each metric defined by the IPPM WG with a unique
	identifier as per [RFC4148] in the IANA-IPPM-METRICS-REGISTRY-MIB.		identifier as per [RFC4148] in the IANA-IPPM-METRICS-REGISTRY-MIB.
	10.4. Information model		10.4. Information model
	This section presents the elements of information and the usage of		This section presents the elements of information and the usage of
	the information reported for network performance analysis. It is out		the information reported for network performance analysis. It is out
	of the scope of this section to define how the information is		of the scope of this section to define how the information is
	reported.		reported.
	The information model is build with pieces of information introduced		The information model is built with pieces of information introduced
	and explained in one-way delay definitions [RFC2679], in packet loss		and explained in one-way delay definitions [RFC2679], in packet loss
	definitions [RFC2680] and in IPDV definitions of [RFC3393] and		definitions [RFC2680] and in IPDV definitions of [RFC3393] and
	[RFC3432]. It includes not only information given by "Reporting the		[RFC3432]. It includes not only information given by "Reporting the
	metric" sections but by sections "Methodology" and "Errors and		metric" sections but by sections "Methodology" and "Errors and
	Uncertainties" sections.		Uncertainties".
	Following are the elements of information taken from end-to-end		Following are the elements of information taken from end-to-end
	definitions referred in this memo and from spatial and multicast		metrics definitions referred in this memo and from spatial and
	metrics it defines:		multicast metrics it defines:
	o Packet_type, The Type-P of test packets (Type-P);		o Packet_type, The Type-P of test packets (Type-P);
	o Packet_length, a packet length in bits (L);		o Packet_length, a packet length in bits (L);
	o Src_host, the IP address of the sender;		o Src_host, the IP address of the sender;
	o Dst_host, the IP address of the receiver;		o Dst_host, the IP address of the receiver;
	o Hosts_serie: <H1, H2,..., Hn>, a list of points of interest;		o Hosts_serie: <H1, H2,..., Hn>, a list of points of interest;
	o Loss_threshold: The threshold of infinite delay;		o Loss_threshold: The threshold of infinite delay;
	o Systematic_error: constant delay between wire time and		o Systematic_error: constant delay between wire time and
	timestamping;		timestamping;
	o Calibration_error: maximal uncertainty;		o Calibration_error: maximal uncertainty;
	skipping to change at page 44, line 36		skipping to change at page 44, line 36
	function used to detect the packets may lead to a DoS attack toward		function used to detect the packets may lead to a DoS attack toward
	the point of reference.		the point of reference.
	11.2. One-to-group metrics		11.2. One-to-group metrics
	Reporting of measurement results from a huge number of probes may		Reporting of measurement results from a huge number of probes may
	overload reference point resources (network, network interfaces,		overload reference point resources (network, network interfaces,
	computation capacities ...).		computation capacities ...).
	The configuration of a measurement must take in consideration that		The configuration of a measurement must take in consideration that
	implicitly more packets will to be routed than send and selects a		implicitly more packets will be routed than sent and selects a test
	test packets rate accordingly. Collecting statistics from a huge		packets rate accordingly. Collecting statistics from a huge number
	number of probes may overload any combination of the network where		of probes may overload any combination of the network where the
	the measurement controller is attached to, measurement controller		measurement controller is attached to, measurement controller network
	network interfaces and measurement controller computation capacities.		interfaces and measurement controller computation capacities.
	One-to-group metrics measurement should consider using source		One-to-group metrics measurement should consider using source
	authentication protocols, standardized in the MSEC group, to avoid		authentication protocols, standardized in the MSEC group, to avoid
	fraud packet in the sampling interval. The test packet rate could be		fraud packet in the sampling interval. The test packet rate could be
	negotiated before any measurement session to avoid deny of service		negotiated before any measurement session to avoid deny of service
	attacks.		attacks.
	12. Acknowledgments		12. Acknowledgments
	Lei would like to acknowledge Prof. Zhili Sun from CCSR, University		Lei would like to acknowledge Prof. Zhili Sun from CCSR, University
	skipping to change at page 50, line 9		skipping to change at page 50, line 9
	Metric for IP Performance Metrics (IPPM)", RFC 3393,		Metric for IP Performance Metrics (IPPM)", RFC 3393,
	November 2002.		November 2002.
	[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics		[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics
	Registry", BCP 108, RFC 4148, August 2005.		Registry", BCP 108, RFC 4148, August 2005.
	14.2. Informative References		14.2. Informative References
	[I-D.ietf-ippm-spatial-composition]		[I-D.ietf-ippm-spatial-composition]
	Morton, A. and E. Stephan, "Spatial Composition of		Morton, A. and E. Stephan, "Spatial Composition of
	Metrics", draft-ietf-ippm-spatial-composition-07 (work in		Metrics", draft-ietf-ippm-spatial-composition-08 (work in
	progress), July 2008.		progress), March 2009.
	[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,		"Framework for IP Performance Metrics", RFC 2330,
	May 1998.		May 1998.
	[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.		November 2002.
	Authors' Addresses		Authors' Addresses
	skipping to change at page 51, line 4		skipping to change at line 2308
	Fax: +44 1483 683641		Fax: +44 1483 683641
	Email: L.Liang@surrey.ac.uk		Email: L.Liang@surrey.ac.uk
	Al Morton		Al Morton
	200 Laurel Ave. South		200 Laurel Ave. South
	Middletown, NJ 07748		Middletown, NJ 07748
	USA		USA
	Phone: +1 732 420 1571		Phone: +1 732 420 1571
	Email: acmorton@att.com		Email: acmorton@att.com
	Full Copyright Statement
	Copyright (C) The IETF Trust (2008).
	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.
	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
	The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in
	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
	made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.
End of changes. 32 change blocks.
	100 lines changed or deleted		115 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/