draft-ietf-ippm-delay-var-as-00.txt		draft-ietf-ippm-delay-var-as-01.txt
	Network Working Group A. Morton		Network Working Group A. Morton
	Internet-Draft AT&T Labs		Internet-Draft AT&T Labs
	Intended status: Informational B. Claise		Intended status: Informational B. Claise
	Expires: August 20, 2008 Cisco Systems, Inc.		Expires: January 14, 2009 Cisco Systems, Inc.
	February 17, 2008		July 13, 2008
	Packet Delay Variation Applicability Statement		Packet Delay Variation Applicability Statement
	draft-ietf-ippm-delay-var-as-00		draft-ietf-ippm-delay-var-as-01
	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 August 20, 2008.		This Internet-Draft will expire on January 14, 2009.
	Copyright Notice
	Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	Packet delay variation metrics appear in many different standards		Packet delay variation metrics appear in many different standards
	documents. The metric definition in RFC 3393 has considerable		documents. The metric definition in RFC 3393 has considerable
	flexibility, and it allows multiple formulations of delay variation		flexibility, and it allows multiple formulations of delay variation
	through the specification of different packet selection functions.		through the specification of different packet selection functions.
	Although flexibility provides wide coverage and room for new ideas,		Although flexibility provides wide coverage and room for new ideas,
	it can make comparisons of independent implementations more		it can make comparisons of independent implementations more
	skipping to change at page 2, line 24		skipping to change at page 2, line 20
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Background Literature in IPPM and Elsewhere . . . . . . . 5		1.1. Background Literature in IPPM and Elsewhere . . . . . . . 5
	1.2. Organization of the Memo . . . . . . . . . . . . . . . . . 6		1.2. Organization of the Memo . . . . . . . . . . . . . . . . . 6
	2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 6		2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 6
	3. Brief Descriptions of Delay Variation Uses . . . . . . . . . . 7		3. Brief Descriptions of Delay Variation Uses . . . . . . . . . . 7
	3.1. Inferring Queue Occupation on a Path . . . . . . . . . . . 7		3.1. Inferring Queue Occupation on a Path . . . . . . . . . . . 7
	3.2. Determining De-jitter Buffer Size . . . . . . . . . . . . 7		3.2. Determining De-jitter Buffer Size . . . . . . . . . . . . 8
	3.3. Spatial Composition . . . . . . . . . . . . . . . . . . . 9		3.3. Spatial Composition . . . . . . . . . . . . . . . . . . . 9
	3.4. Service Level Comparison . . . . . . . . . . . . . . . . . 9		3.4. Service Level Comparison . . . . . . . . . . . . . . . . . 9
	3.5. <your favorite here> . . . . . . . . . . . . . . . . . . . 10		3.5. Application-Layer FEC Design . . . . . . . . . . . . . . . 10
	4. Formulations of IPDV and PDV . . . . . . . . . . . . . . . . . 10		4. Formulations of IPDV and PDV . . . . . . . . . . . . . . . . . 10
	4.1. IPDV: Inter-Packet Delay Variation . . . . . . . . . . . . 10		4.1. IPDV: Inter-Packet Delay Variation . . . . . . . . . . . . 10
	4.2. PDV: Packet Delay Variation . . . . . . . . . . . . . . . 11		4.2. PDV: Packet Delay Variation . . . . . . . . . . . . . . . 11
	4.3. A "Point" about Measurement Points . . . . . . . . . . . . 11		4.3. A "Point" about Measurement Points . . . . . . . . . . . . 11
	4.4. Examples and Initial Comparisons . . . . . . . . . . . . . 11		4.4. Examples and Initial Comparisons . . . . . . . . . . . . . 12
	5. Survey of Earlier Comparisons . . . . . . . . . . . . . . . . 12		5. Survey of Earlier Comparisons . . . . . . . . . . . . . . . . 13
	5.1. Demichelis' Comparison . . . . . . . . . . . . . . . . . . 13		5.1. Demichelis' Comparison . . . . . . . . . . . . . . . . . . 13
	5.2. Ciavattone et al. . . . . . . . . . . . . . . . . . . . . 14		5.2. Ciavattone et al. . . . . . . . . . . . . . . . . . . . . 14
	5.3. IPPM List Discussion from 2000 . . . . . . . . . . . . . . 15		5.3. IPPM List Discussion from 2000 . . . . . . . . . . . . . . 15
	5.4. Y.1540 Appendix II . . . . . . . . . . . . . . . . . . . . 17		5.4. Y.1540 Appendix II . . . . . . . . . . . . . . . . . . . . 17
	5.5. Clark's ITU-T SG 12 Contribution . . . . . . . . . . . . . 17		5.5. Clark's ITU-T SG 12 Contribution . . . . . . . . . . . . . 17
	6. Additional Properties and Comparisons . . . . . . . . . . . . 17		6. Additional Properties and Comparisons . . . . . . . . . . . . 17
	6.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 17		6.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 17
	6.2. Path Changes . . . . . . . . . . . . . . . . . . . . . . . 18		6.2. Path Changes . . . . . . . . . . . . . . . . . . . . . . . 18
	6.2.1. Lossless Path Change . . . . . . . . . . . . . . . . . 19		6.2.1. Lossless Path Change . . . . . . . . . . . . . . . . . 19
	6.2.2. Path Change with Loss . . . . . . . . . . . . . . . . 20		6.2.2. Path Change with Loss . . . . . . . . . . . . . . . . 20
	6.3. Clock Stability and Error . . . . . . . . . . . . . . . . 21		6.3. Clock Stability and Error . . . . . . . . . . . . . . . . 21
	6.4. Spatial Composition . . . . . . . . . . . . . . . . . . . 23		6.4. Spatial Composition . . . . . . . . . . . . . . . . . . . 23
	6.5. Reporting a Single Number (SLA) . . . . . . . . . . . . . 23		6.5. Reporting a Single Number (SLA) . . . . . . . . . . . . . 23
	6.6. Jitter in RTCP Reports . . . . . . . . . . . . . . . . . . 24		6.6. Jitter in RTCP Reports . . . . . . . . . . . . . . . . . . 24
	6.7. MAPDV2 . . . . . . . . . . . . . . . . . . . . . . . . . . 24		6.7. MAPDV2 . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	6.8. Load Balancing . . . . . . . . . . . . . . . . . . . . . . 25		6.8. Load Balancing . . . . . . . . . . . . . . . . . . . . . . 25
	7. Applicability of the Delay Variation Forms and		7. Applicability of the Delay Variation Forms and
	Recommendations . . . . . . . . . . . . . . . . . . . . . . . 26		Recommendations . . . . . . . . . . . . . . . . . . . . . . . 26
	7.1. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . . 26		7.1. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	7.1.1. Inferring Queue Occupancy . . . . . . . . . . . . . . 26		7.1.1. Inferring Queue Occupancy . . . . . . . . . . . . . . 26
	7.1.2. Determining De-jitter Buffer Size . . . . . . . . . . 26		7.1.2. Determining De-jitter Buffer Size (and FEC Design) . . 26
	7.1.3. Spatial Composition . . . . . . . . . . . . . . . . . 27		7.1.3. Spatial Composition . . . . . . . . . . . . . . . . . 27
	7.1.4. Service Level Specification: Reporting a Single		7.1.4. Service Level Specification: Reporting a Single
	Number . . . . . . . . . . . . . . . . . . . . . . . . 27		Number . . . . . . . . . . . . . . . . . . . . . . . . 27
	7.2. Challenging Circumstances . . . . . . . . . . . . . . . . 27		7.2. Challenging Circumstances . . . . . . . . . . . . . . . . 27
	7.2.1. Clock and Storage Issues . . . . . . . . . . . . . . . 27		7.2.1. Clock and Storage Issues . . . . . . . . . . . . . . . 27
	7.2.2. Frequent Path Changes . . . . . . . . . . . . . . . . 27		7.2.2. Frequent Path Changes . . . . . . . . . . . . . . . . 28
	7.2.3. Frequent Loss . . . . . . . . . . . . . . . . . . . . 28		7.2.3. Frequent Loss . . . . . . . . . . . . . . . . . . . . 28
	7.2.4. Load Balancing . . . . . . . . . . . . . . . . . . . . 28		7.2.4. Load Balancing . . . . . . . . . . . . . . . . . . . . 28
	7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 28		7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 28
	8. Measurement Considerations . . . . . . . . . . . . . . . . . . 29		8. Measurement Considerations . . . . . . . . . . . . . . . . . . 29
	8.1. Measurement Stream Characteristics . . . . . . . . . . . . 29		8.1. Measurement Stream Characteristics . . . . . . . . . . . . 30
	8.2. Measurement Devices . . . . . . . . . . . . . . . . . . . 31		8.2. Measurement Devices . . . . . . . . . . . . . . . . . . . 31
	8.3. Units of Measurement . . . . . . . . . . . . . . . . . . . 31		8.3. Units of Measurement . . . . . . . . . . . . . . . . . . . 31
	8.4. Test Duration . . . . . . . . . . . . . . . . . . . . . . 31		8.4. Test Duration . . . . . . . . . . . . . . . . . . . . . . 32
	8.5. Clock Sync Options . . . . . . . . . . . . . . . . . . . . 32		8.5. Clock Sync Options . . . . . . . . . . . . . . . . . . . . 32
	8.6. Distinguishing Long Delay from Loss . . . . . . . . . . . 32		8.6. Distinguishing Long Delay from Loss . . . . . . . . . . . 32
	8.7. Accounting for Packet Reordering . . . . . . . . . . . . . 32		8.7. Accounting for Packet Reordering . . . . . . . . . . . . . 33
	8.8. Results Representation and Reporting . . . . . . . . . . . 33		8.8. Results Representation and Reporting . . . . . . . . . . . 33
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 33		10. Security Considerations . . . . . . . . . . . . . . . . . . . 34
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
	12. Appendix on Reducing Delay Variation in Networks . . . . . . . 34		12. Appendix on Calculating the D(min) in PDV . . . . . . . . . . 34
	13. Appendix on Calculating the D(min) in PDV . . . . . . . . . . 34		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35		13.1. Normative References . . . . . . . . . . . . . . . . . . . 35
	14.1. Normative References . . . . . . . . . . . . . . . . . . . 35		13.2. Informative References . . . . . . . . . . . . . . . . . . 36
	14.2. Informative References . . . . . . . . . . . . . . . . . . 36
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
	Intellectual Property and Copyright Statements . . . . . . . . . . 39		Intellectual Property and Copyright Statements . . . . . . . . . . 39
	1. Introduction		1. Introduction
	There are many ways to formulate packet delay variation metrics for		There are many ways to formulate packet delay variation metrics for
	the Internet and other packet-based networks. The IETF itself has		the Internet and other packet-based networks. The IETF itself has
	several specifications for delay variation [RFC3393], sometimes		several specifications for delay variation [RFC3393], sometimes
	called jitter [RFC3550] or even inter-arrival jitter [RFC3550], and		called jitter [RFC3550] or even inter-arrival jitter [RFC3550], and
	these have achieved wide adoption. The International		these have achieved wide adoption. The International
	skipping to change at page 6, line 35		skipping to change at page 6, line 35
	1.2. Organization of the Memo		1.2. Organization of the Memo
	The Purpose and Scope follows in Section 2. We then give a summary		The Purpose and Scope follows in Section 2. We then give a summary
	of the main tasks for delay variation metrics in section 3. Section		of the main tasks for delay variation metrics in section 3. Section
	4 defines the two primary forms of delay variation, and section 5		4 defines the two primary forms of delay variation, and section 5
	presents summaries of four earlier comparisons. Section 6 adds new		presents summaries of four earlier comparisons. Section 6 adds new
	comparisons to the analysis, and section 7 reviews the applicability		comparisons to the analysis, and section 7 reviews the applicability
	and recommendations for each form of delay variation. Section 8 then		and recommendations for each form of delay variation. Section 8 then
	looks at many important delay variation measurement considerations.		looks at many important delay variation measurement considerations.
	Following the IANA and Security Considerations, there are two		Following the IANA and Security Considerations, there is an Appendix
	Appendices. One presents guidance on reducing delay variation in		on the calculation of the minimum delay for the PDV form.
	networks, and the other calculation of the minimum delay for the PDV
	form.
	2. Purpose and Scope		2. Purpose and Scope
	The IPDV and PDV formulations have certain features that make them		The IPDV and PDV formulations have certain features that make them
	more suitable for one circumstance and less so for another. The		more suitable for one circumstance and less so for another. The
	purpose of this memo is to compare two forms of delay variation, so		purpose of this memo is to compare two forms of delay variation, so
	that it will be evident which of the two is better suited for each of		that it will be evident which of the two is better suited for each of
	many possible uses and their related circumstances.		many possible uses and their related circumstances.
	The scope of this memo is limited to the two forms of delay variation		The scope of this memo is limited to the two forms of delay variation
	skipping to change at page 7, line 46		skipping to change at page 7, line 44
	queues. Some types of the delay sources along the path are constant,		queues. Some types of the delay sources along the path are constant,
	such as links between two locations. But the latency encountered in		such as links between two locations. But the latency encountered in
	each queue varies, depending on the number of packets in the queue		each queue varies, depending on the number of packets in the queue
	when a particular packet arrives. If one assumes that at least one		when a particular packet arrives. If one assumes that at least one
	of the packets in a test stream encounters virtually empty queues all		of the packets in a test stream encounters virtually empty queues all
	along the path (and the path is stable), then the additional delay		along the path (and the path is stable), then the additional delay
	observed on other packets can be attributed to the time spent in one		observed on other packets can be attributed to the time spent in one
	or more queues. Otherwise, the delay variation observed is the		or more queues. Otherwise, the delay variation observed is the
	variation in queue time experienced by the test stream.		variation in queue time experienced by the test stream.
			It is worth noting that delay variation can occur beyond IP router
			queues, in other communication components. Examples include media
			contention: DOCSIS, IEEE 802.11 and some mobile radio technologies.
			However, delay variation from all sources at the IP layer and below
			will be quantified using the two formulations discussed here.
	3.2. Determining De-jitter Buffer Size		3.2. Determining De-jitter Buffer Size
	Note - while this memo and other IPPM literature prefer the term		Note - while this memo and other IPPM literature prefer the term
	delay variation, the terms "jitter buffer" and the more accurate "de-		delay variation, the terms "jitter buffer" and the more accurate "de-
	jitter buffer" are widely adopted names for a component of packet		jitter buffer" are widely adopted names for a component of packet
	communication systems, and they will be used here to designate that		communication systems, and they will be used here to designate that
	system component.		system component.
	Most Isochronous applications (a.k.a. real-time applications) employ		Most Isochronous applications (a.k.a. real-time applications) employ
	a buffer to smooth out delay variation encountered on the path from		a buffer to smooth out delay variation encountered on the path from
	skipping to change at page 10, line 9		skipping to change at page 10, line 13
	customers. The measurement results must compare favorably with the		customers. The measurement results must compare favorably with the
	performance levels specified in the agreement.		performance levels specified in the agreement.
	Packet delay variation is usually one of the metrics specified in		Packet delay variation is usually one of the metrics specified in
	these agreements. In principle, any formulation could be specified		these agreements. In principle, any formulation could be specified
	in the Service Level Agreement (SLA). However, the SLA is most		in the Service Level Agreement (SLA). However, the SLA is most
	useful when the measured quantities can be related to ways in which		useful when the measured quantities can be related to ways in which
	the communication service will be utilized by the customer, and this		the communication service will be utilized by the customer, and this
	can usually be derived from one of the tasks described above.		can usually be derived from one of the tasks described above.
	3.5. <your favorite here>		3.5. Application-Layer FEC Design
	Note: At the IETF-68 IPPM session, Alan Clark suggested another		The design of application-layer Forward Error Correction (FEC)
	possible task for DV measurements, that of detecting and somehow		components is closely related to the design of a de-jitter buffer in
	removing the delay variation associated with a smoothing buffer used		several ways. The FEC designer must choose a protection interval
	with a video codec. Further work is needed to define the problem and		(time to send/receive a block of packets in a constant packet rate
	to investigate the applicability of IPDV and PDV.		system) consistent with the packet loss characteristics, but also
			mindful of the extent of delay variation expected. Further, the
			system designer must decide how long to wait for "late" packets to
			arrive. Again, the range of delay variation is the relevant
			expression delay variation for these tasks.
	4. Formulations of IPDV and PDV		4. Formulations of IPDV and PDV
	This section presents the formulations of IPDV and PDV, and provides		This section presents the formulations of IPDV and PDV, and provides
	some illustrative examples. We use the basic singleton definition in		some illustrative examples. We use the basic singleton definition in
	[RFC3393] (which itself is based on [RFC2679]):		[RFC3393] (which itself is based on [RFC2679]):
	"Type-P-One-way-ipdv is defined for two packets from Src to Dst		"Type-P-One-way-ipdv is defined for two packets from Src to Dst
	selected by the selection function F, as the difference between the		selected by the selection function F, as the difference between the
	value of the Type-P-One-way-delay from Src to Dst at T2 and the value		value of the Type-P-One-way-delay from Src to Dst at T2 and the value
	skipping to change at page 20, line 36		skipping to change at page 20, line 36
	change could be kept separated, presenting two different		change could be kept separated, presenting two different
	distributions. This avoids the difficult task of determining the		distributions. This avoids the difficult task of determining the
	different modes of a multi-modal distribution.		different modes of a multi-modal distribution.
	6.2.2. Path Change with Loss		6.2.2. Path Change with Loss
	If the path change is accompanied by loss, such that the are no		If the path change is accompanied by loss, such that the are no
	consecutive packet pairs that span the change, then no IPDV		consecutive packet pairs that span the change, then no IPDV
	singletons will reflect the change. This may or may not be		singletons will reflect the change. This may or may not be
	desirable, depending on the ultimate use of the delay variation		desirable, depending on the ultimate use of the delay variation
	measurement. The Figure 6, in which L means Lost and U means		measurement. Figure 6, in which L means Lost and U means undefined,
	undefined, illustrates this case.		illustrates this case.
	Packet # 1 2 3 4 5 6 7 8 9		Packet # 1 2 3 4 5 6 7 8 9
	Lost L L		Lost L L
	------------------------------------		------------------------------------
	Delay, ms 3 4 3 3 U U 8 9 8		Delay, ms 3 4 3 3 U U 8 9 8
	IPDV U 1 -1 0 U U U 1 -1		IPDV U 1 -1 0 U U U 1 -1
	PDV 0 1 0 0 U U 5 6 5		PDV 0 1 0 0 U U 5 6 5
	Figure 6: Path Change with Loss		Figure 6: Path Change with Loss
	PDV will again produce a bimodal distribution. But here, the		PDV will again produce a bimodal distribution. But here, the
	decision process to define sub-intervals associated with each path is		decision process to define sub-intervals associated with each path is
	further assisted by the presence of loss, in addition to TTL,		further assisted by the presence of loss, in addition to TTL,
	reordering information, and use of short measurement intervals		reordering information, and use of short measurement intervals
	consistent with the duration of user sessions. It is reasonable to		consistent with the duration of user sessions. It is reasonable to
	assume that at least loss and delay will be measured simultaneously		assume that at least loss and delay will be measured simultaneously
	with PDV and/or IPDV.		with PDV and/or IPDV.
			IPDV does not help to detect path changes when accompanied by loss,
			and this is a disadvantage for those who rely solely on IPDV
			measurements.
	6.3. Clock Stability and Error		6.3. Clock Stability and Error
	Low cost or low complexity measurement systems may be embedded in		Low cost or low complexity measurement systems may be embedded in
	communication devices that do not have access to high stability		communication devices that do not have access to high stability
	clocks, and time errors will almost certainly be present. However,		clocks, and time errors will almost certainly be present. However,
	larger time-related errors (~1ms) may offer an acceptable trade-off		larger time-related errors (~1ms) may offer an acceptable trade-off
	for monitoring performance over a large population (the accuracy		for monitoring performance over a large population (the accuracy
	needed to detect problems may be much less than required for a		needed to detect problems may be much less than required for a
	scientific study, ~0.01ms for example).		scientific study, ~0.01ms for example).
	skipping to change at page 22, line 38		skipping to change at page 22, line 42
	0.05ms.		0.05ms.
	o If PDV measurements are made on the same packets over a 60 second		o If PDV measurements are made on the same packets over a 60 second
	measurement interval, then the delay variation due to the max		measurement interval, then the delay variation due to the max
	free-running clock error will be 60 x 5 x 10-5 seconds, or 3ms		free-running clock error will be 60 x 5 x 10-5 seconds, or 3ms
	delay variation error from the first packet to the last.		delay variation error from the first packet to the last.
	Therefore, the additional accuracy required for equivalent PDV error		Therefore, the additional accuracy required for equivalent PDV error
	under these conditions is a factor of 60 more than for IPDV. This is		under these conditions is a factor of 60 more than for IPDV. This is
	a rather extreme scenario, because time-of-day error of 1 second		a rather extreme scenario, because time-of-day error of 1 second
	would accumulate in ~5.5 hours, potentially causing the measurment		would accumulate in ~5.5 hours, potentially causing the measurement
	interval alignment issue described above.		interval alignment issue described above.
	If skew is present in a sample of one-way-delays, its symptom is		If skew is present in a sample of one-way-delays, its symptom is
	typically a nearly linear growth or decline over all the one-way-		typically a nearly linear growth or decline over all the one-way-
	delay values. As a practical matter, if the same slope appears		delay values. As a practical matter, if the same slope appears
	consistently in the measurements, then it may be possible to fit the		consistently in the measurements, then it may be possible to fit the
	slope and compensate for the skew in the one-way-delay measurements,		slope and compensate for the skew in the one-way-delay measurements,
	thereby avoiding the issue in the PDV calculations that follow. See		thereby avoiding the issue in the PDV calculations that follow. See
	[RFC3393] for additional information on compensating for skew.		[RFC3393] for additional information on compensating for skew.
	skipping to change at page 23, line 24		skipping to change at page 23, line 28
	6.4. Spatial Composition		6.4. Spatial Composition
	ITU-T Recommendation [Y.1541] gives a provisional method to compose a		ITU-T Recommendation [Y.1541] gives a provisional method to compose a
	PDV metric using PDV measurement results from two or more sub-paths.		PDV metric using PDV measurement results from two or more sub-paths.
	Additional methods are considered in		Additional methods are considered in
	[I-D.ietf-ippm-spatial-composition].		[I-D.ietf-ippm-spatial-composition].
	PDV has a clear advantage at this time, since there is no validated		PDV has a clear advantage at this time, since there is no validated
	method to compose an IPDV metric. In addition, IPDV results depend		method to compose an IPDV metric. In addition, IPDV results depend
	greatly on the exact sequence of packets and may not lend themselves		greatly on the exact sequence of packets and may not lend themselves
	easily to the composition problem.		easily to the composition problem, where segments must be assumed to
			have independent delay distributions.
	6.5. Reporting a Single Number (SLA)		6.5. Reporting a Single Number (SLA)
	Despite the risk of over-summarization, measurements must often be		Despite the risk of over-summarization, measurements must often be
	displayed for easy consumption. If the right summary report is		displayed for easy consumption. If the right summary report is
	prepared, then the "dashboard" view correctly indicates whether there		prepared, then the "dashboard" view correctly indicates whether there
	is something different and worth investigating further, or that the		is something different and worth investigating further, or that the
	status has not changed. The dashboard model restricts every		status has not changed. The dashboard model restricts every
	instrument display to a single number. The packet network dashboard		instrument display to a single number. The packet network dashboard
	could have different instruments for loss, delay, delay variation,		could have different instruments for loss, delay, delay variation,
	skipping to change at page 24, line 8		skipping to change at page 24, line 13
	was avoided for several reasons, including stability of the maximum		was avoided for several reasons, including stability of the maximum
	delay. The 99.9%-ile of PDV is helpful to performance planners		delay. The 99.9%-ile of PDV is helpful to performance planners
	(seeking to meet some user-to-user objective for delay) and in design		(seeking to meet some user-to-user objective for delay) and in design
	of de-jitter buffer sizes, even those with adaptive capabilities.		of de-jitter buffer sizes, even those with adaptive capabilities.
	IPDV does not lend itself to summarization so easily. The mean IPDV		IPDV does not lend itself to summarization so easily. The mean IPDV
	is typically zero. As the IPDV distribution will have two tails		is typically zero. As the IPDV distribution will have two tails
	(positive and negative) the range or pseudo-range would not match the		(positive and negative) the range or pseudo-range would not match the
	needed de-jitter buffer size. Additional complexity may be		needed de-jitter buffer size. Additional complexity may be
	introduced when the variation exceeds the inter-packet sending		introduced when the variation exceeds the inter-packet sending
	interval, as discussed above. Should the Inter-Quartile Range be		interval, as discussed above (in sections 5.2 and 6.2.1). Should the
	used? Should the singletons beyond some threshold be counted (e.g.,		Inter-Quartile Range be used? Should the singletons beyond some
	mean +/- 50ms)? A strong rationale for one of these summary		threshold be counted (e.g., mean +/- 50ms)? A strong rationale for
	statistics has yet to emerge.		one of these summary statistics has yet to emerge.
	When summarizing IPDV, some prefer the simplicity of the single-sided		When summarizing IPDV, some prefer the simplicity of the single-sided
	distribution created by taking the absolute value of each singleton		distribution created by taking the absolute value of each singleton
	result, abs(D(i)-D(i-1)). This approach sacrifices the two-sided		result, abs(D(i)-D(i-1)). This approach sacrifices the two-sided
	inter-arrival spread information in the distribution. It also makes		inter-arrival spread information in the distribution. It also makes
	the evaluation using percentiles more confusing, because a single		the evaluation using percentiles more confusing, because a single
	late packet that exceeds the variation threshold will cause two		late packet that exceeds the variation threshold will cause two pairs
	singleton measurement pairs to fail the criteria (one positive, the		of singletons to fail the criteria (one positive, the other negative
	other negative converted to positive). The single-sided PDV		converted to positive). The single-sided PDV distribution is an
	distribution is an advantage in this category.		advantage in this category.
	6.6. Jitter in RTCP Reports		6.6. Jitter in RTCP Reports
	[RFC3550] gives the calculation of the inter-arrival Jitter field for		[RFC3550] gives the calculation of the inter-arrival Jitter field for
	the RTCP report, with a sample implementation in an Appendix.		the RTCP report, with a sample implementation in an Appendix.
	The RTCP Jitter value can be calculated using IPDV singletons. If		The RTCP Jitter value can be calculated using IPDV singletons. If
	there is packet reordering, as defined in [RFC4737], then estimates		there is packet reordering, as defined in [RFC4737], then estimates
	of Jitter based on IPDV may vary slightly, because [RFC3550]		of Jitter based on IPDV may vary slightly, because [RFC3550]
	specifies the use of receive packet order.		specifies the use of receive packet order.
	skipping to change at page 26, line 30		skipping to change at page 26, line 34
	stream. If the minimum delay is not the true minimum, then the PDV		stream. If the minimum delay is not the true minimum, then the PDV
	distribution captures the variation in queuing time and some		distribution captures the variation in queuing time and some
	additional amount of queuing time is experienced, but unknown. One		additional amount of queuing time is experienced, but unknown. One
	can summarize the PDV distribution with the mean, median, and other		can summarize the PDV distribution with the mean, median, and other
	statistics.		statistics.
	IPDV can capture the difference in queuing time from one packet to		IPDV can capture the difference in queuing time from one packet to
	the next, but this is a different distribution from the queue		the next, but this is a different distribution from the queue
	occupancy revealed by PDV.		occupancy revealed by PDV.
	7.1.2. Determining De-jitter Buffer Size		7.1.2. Determining De-jitter Buffer Size (and FEC Design)
	This task is complimentary to the problem of inferring queue		This task is complimentary to the problem of inferring queue
	occupancy through measurement. Again, use of the sample minimum as		occupancy through measurement. Again, use of the sample minimum as
	the reference delay for PDV yields a distribution that is very		the reference delay for PDV yields a distribution that is very
	relevant to de-jitter buffer size. This is because the minimum delay		relevant to de-jitter buffer size. This is because the minimum delay
	is an alignment point for the smoothing operation of de-jitter		is an alignment point for the smoothing operation of de-jitter
	buffers. A de-jitter buffer that is ideally aligned with the delay		buffers. A de-jitter buffer that is ideally aligned with the delay
	variation adds zero buffer time to packets with the longest		variation adds zero buffer time to packets with the longest
	accommodated network delay (any packets with longer delays are		accommodated network delay (any packets with longer delays are
	discarded). Thus, a packet experiencing minimum network delay should		discarded). Thus, a packet experiencing minimum network delay should
	be aligned to wait the maximum length of the de-jitter buffer. With		be aligned to wait the maximum length of the de-jitter buffer. With
	this alignment, the stream is smoothed with no unnecessary delay		this alignment, the stream is smoothed with no unnecessary delay
	added. [G.1020] illustrates the ideal relationship between network		added. [G.1020] illustrates the ideal relationship between network
	delay variation and buffer time.		delay variation and buffer time.
	The PDV distribution is also useful for this task, but different		The PDV distribution is also useful for this task, but different
	statistics are preferred. The range (max-min) or the 99.9%-ile of		statistics are preferred. The range (max-min) or the 99.9%-ile of
	PDV (pseudo-range) are closely related to the buffer size needed to		PDV (pseudo-range) are closely related to the buffer size needed to
	accommodate the observed network delay variation.		accommodate the observed network delay variation.
			The PDV distribution directly addresses the FEC waiting time
			question. When the PDV distribution has a 99th percentile of 10ms,
			then waiting 10ms longer than the FEC protection interval will allow
			99% of late packets to arrive and be used in the FEC block.
	In some cases, the positive excursions (or series of positive		In some cases, the positive excursions (or series of positive
	excursions) of IPDV may help to approximate the de-jitter buffer		excursions) of IPDV may help to approximate the de-jitter buffer
	size, but there is no guarantee that a good buffer estimate will		size, but there is no guarantee that a good buffer estimate will
	emerge, especially when the delay varies as a positive trend over		emerge, especially when the delay varies as a positive trend over
	several test packets.		several test packets.
	7.1.3. Spatial Composition		7.1.3. Spatial Composition
	PDV has a clear advantage at this time, since there is no validated		PDV has a clear advantage at this time, since there is no validated
	method to compose an IPDV metric.		method to compose an IPDV metric.
	skipping to change at page 28, line 33		skipping to change at page 29, line 4
	7.2.4. Load Balancing		7.2.4. Load Balancing
	PDV distributions offer the most straightforward way to identify that		PDV distributions offer the most straightforward way to identify that
	a sample of packets have traversed multiple paths. The tasks of de-		a sample of packets have traversed multiple paths. The tasks of de-
	jitter buffer sizing or assessing queue occupation with PDV should be		jitter buffer sizing or assessing queue occupation with PDV should be
	use a sample with a single flow because flows will experience only		use a sample with a single flow because flows will experience only
	one mode on a stable path, and it simplifies the analysis.		one mode on a stable path, and it simplifies the analysis.
	7.3. Summary		7.3. Summary
			+---------------+----------------------+----------------------------+
	+---------------+-----------------------+---------------------------+
	| Comparison | PDV | IPDV |		| Comparison | PDV | IPDV |
	| Area | | |		| Area | | |
	+---------------+-----------------------+---------------------------+		+---------------+----------------------+----------------------------+
	| Challenging | Less sensitive to | Preferred when path |		| Challenging | Less sensitive to | Preferred when path |
	| Circumstances | packet loss, and | changes are frequent or |		| Circumstances | packet loss, and | changes are frequent or |
	| | simplifies analysis | when measurement clocks |		| | simplifies analysis | when measurement clocks |
	| | when Load balancing | exhibit some skew |		| | when load balancing | exhibit some skew |
	| | or multiple paths are | |		| | or multiple paths | |
	| | present | |		| | are present | |
	| Spatial | All validated methods | Has sensitivity to |		| Spatial | All validated | Has sensitivity to |
	| Composition | use this form | sequence and spacing |		| Composition | methods use this | sequence and spacing |
	| of DV metric | | changes, which tend to |		| of DV metric | form | changes, which tends to |
	| | | break the segment IID |		| | | break the requirement for |
	| | | requirement |		| | | independent distributions |
			| | | between path segments |
	| Determine | "Pseudo-range" | No reliable relationship, |		| Determine | "Pseudo-range" | No reliable relationship, |
	| De-Jitter | reveals this property | but some heuristics |		| De-Jitter | reveals this | but some heuristics |
	| Buffer Size | by anchoring the | |		| Buffer Size | property by | |
	| Required | distribution at the | |		| Required | anchoring the | |
			| | distribution at the | |
	| | minimum delay | |		| | minimum delay | |
	| Estimate of | Distribution has | No reliable relationship |		| Estimate of | Distribution has | No reliable relationship |
	| Queuing Time | one-to-one | |		| Queuing Time | one-to-one | |
	| and Variation | relationship on a | |		| and Variation | relationship on a | |
	| | stable path, | |		| | stable path, | |
	| | especially when | |		| | especially when | |
	| | sample min = true min | |		| | sample min = true | |
	| Specification | One constraint needed | Distribution is |		| | min | |
	| Simplicity: | for single-sided | two-sided, usually has |		| Specification | One constraint | Distribution is two-sided, |
	| Single Number | distribution, and | zero mean, and no |		| Simplicity: | needed for | usually has zero mean, and |
	| SLS | easily related to | universal summary |		| Single Number | single-sided | no universal summary |
	| | quantities above | statistic that relates to |		| SLS | distribution, and | statistic that relates to |
	| | | a physical quantity |		| | easily related to | a physical quantity |
	+---------------+-----------------------+---------------------------+		| | quantities above | |
			+---------------+----------------------+----------------------------+
	Summary of Comparisons		Summary of Comparisons
	8. Measurement Considerations		8. Measurement Considerations
	TO DO: Add info comparing methodological approximations for each		This section discusses the practical aspects of delay variation
	form, including on-the-fly statistics, memory requirements,		measurement, with special attention to the two formulations compared
	implications on the reference value (D(min)), quantiles not available		in this memo.
	as a running measure, (possibly in a new subsection)
	8.1. Measurement Stream Characteristics		8.1. Measurement Stream Characteristics
	As stated in the background section, there is a strong dependency		As stated in the background section, there is a strong dependency
	between the active measurement stream characteristics and the		between the active measurement stream characteristics and the
	results. The IPPM literature includes two primary methods for		results. The IPPM literature includes two primary methods for
	collecting samples: Poisson sampling described in [RFC2330], and		collecting samples: Poisson sampling described in [RFC2330], and
	Periodic sampling in[RFC3432]. The Poisson method was intended to		Periodic sampling in[RFC3432]. The Poisson method was intended to
	collect an unbiased sample of performance, while the Periodic method		collect an unbiased sample of performance, while the Periodic method
	addresses a "known bias of interest". Periodic streams are required		addresses a "known bias of interest". Periodic streams are required
	skipping to change at page 31, line 8		skipping to change at page 31, line 25
	times, avoid synchronization with periodic events that are present in		times, avoid synchronization with periodic events that are present in
	networks, and avoid inducing synchronization with congestion-aware		networks, and avoid inducing synchronization with congestion-aware
	senders. When a Poisson stream is used with IPDV, the distribution		senders. When a Poisson stream is used with IPDV, the distribution
	will reflect inter-packet delay variation on many different time		will reflect inter-packet delay variation on many different time
	scales (or packet spacings). The unbiased Poisson sampling brings a		scales (or packet spacings). The unbiased Poisson sampling brings a
	new layer of complexity in the analysis of IPDV distributions.		new layer of complexity in the analysis of IPDV distributions.
	8.2. Measurement Devices		8.2. Measurement Devices
	One key aspect of measurement devices is their ability to store		One key aspect of measurement devices is their ability to store
	singleton measurements. This feature usually is closely related to		singletons (or individual measurements). This feature usually is
	local calculation capabilities. For example, an embedded measurement		closely related to local calculation capabilities. For example, an
	device with limited storage will like provide only a few statistics		embedded measurement device with limited storage will like provide
	on the delay variation distribution, while dedicated measurement		only a few statistics on the delay variation distribution, while
	systems store all the singletons and allow detailed analysis (later		dedicated measurement systems store all the singletons and allow
	calculation of either form of delay variation is possible with the		detailed analysis (later calculation of either form of delay
	original singletons).		variation is possible with the original singletons).
	Therefore, systems with limited storage must choose their metrics and		Therefore, systems with limited storage must choose their metrics and
	summary statistics in advance. If both IPDV and PDV statistics are		summary statistics in advance. If both IPDV and PDV statistics are
	desired, the supporting information must be collected as packets		desired, the supporting information must be collected as packets
	arrive. For example, the PDV range and high percentiles can be		arrive. For example, the PDV range and high percentiles can be
	determined later if the minimum and several of the largest delays are		determined later if the minimum and several of the largest delays are
	stored while the measurement is in-progress.		stored while the measurement is in-progress.
	8.3. Units of Measurement		8.3. Units of Measurement
	skipping to change at page 32, line 22		skipping to change at page 32, line 40
	1. Global Positioning System receivers		1. Global Positioning System receivers
	2. In some parts of the world, Cellular Code Division Multiple		2. In some parts of the world, Cellular Code Division Multiple
	Access (CDMA) systems distribute timing signals that are derived		Access (CDMA) systems distribute timing signals that are derived
	from GPS and traceable to UTC.		from GPS and traceable to UTC.
	3. Network Time Protocol [RFC1305] is a convenient choice in many		3. Network Time Protocol [RFC1305] is a convenient choice in many
	cases, but usually offers lower accuracy than the options above.		cases, but usually offers lower accuracy than the options above.
			When clock synchronization is inconvenient or subject to appreciable
			errors, then round-trip measurements may give a cumulative indication
			of the delay variation present on both directions of the path.
			However, delay distributions are rarely symmetrical, so it is
			difficult to infer much about the one-way delay variation from round-
			trip measurements. Also, measurements on asymmetrical paths add
			complications for the one-way delay metric.
	8.6. Distinguishing Long Delay from Loss		8.6. Distinguishing Long Delay from Loss
	Lost and delayed packets are separated by a waiting time threshold.		Lost and delayed packets are separated by a waiting time threshold.
	Packets that arrive at the measurement destination within their		Packets that arrive at the measurement destination within their
	waiting time have finite delay and are not lost. Otherwise, packets		waiting time have finite delay and are not lost. Otherwise, packets
	are designated lost and their delay is undefined. Guidance on		are designated lost and their delay is undefined. Guidance on
	setting the waiting time threshold may be found in [RFC2680] and		setting the waiting time threshold may be found in [RFC2680] and
	[I-D.morton-ippm-reporting-metrics].		[I-D.morton-ippm-reporting-metrics].
	In essence, [I-D.morton-ippm-reporting-metrics] suggests to use a		In essence, [I-D.morton-ippm-reporting-metrics] suggests to use a
	skipping to change at page 33, line 8		skipping to change at page 33, line 30
	variation.		variation.
	IPDV results will change if reordering is present because they are		IPDV results will change if reordering is present because they are
	sensitive to the sequence of delays of arriving packets. The main		sensitive to the sequence of delays of arriving packets. The main
	example of this sensitivity is in the truncation of the negative tail		example of this sensitivity is in the truncation of the negative tail
	of the distribution.		of the distribution.
	o When there is no reordering, the negative tail is limited by the		o When there is no reordering, the negative tail is limited by the
	sending time spacing between packets.		sending time spacing between packets.
	o If reordering occurs, the negative tail can take on any value (in		o If reordering occurs (and the reordered packets are not
			discarded), the negative tail can take on any value (in
	principal).		principal).
	In general, measurement systems should have the capability to detect		In general, measurement systems should have the capability to detect
	when sequence has changed. If IPDV measurements are made without		when sequence has changed. If IPDV measurements are made without
	regard to packet arrival order, the IPDV will be under-reported when		regard to packet arrival order, the IPDV will be under-reported when
	reordering occurs.		reordering occurs.
	8.8. Results Representation and Reporting		8.8. Results Representation and Reporting
	All of the references that discuss or define delay variation suggest		All of the references that discuss or define delay variation suggest
	skipping to change at page 33, line 45		skipping to change at page 34, line 22
	10. Security Considerations		10. Security Considerations
	The security considerations that apply to any active measurement of		The security considerations that apply to any active measurement of
	live networks are relevant here as well. See [RFC4656]		live networks are relevant here as well. See [RFC4656]
	11. Acknowledgements		11. Acknowledgements
	The authors would like to thank Phil Chimento for his suggestion to		The authors would like to thank Phil Chimento for his suggestion to
	employ the convention of conditional distributions for Delay to deal		employ the convention of conditional distributions for Delay to deal
	with packet loss, and his encouragement to "write the memo" after		with packet loss, and his encouragement to "write the memo" after
	hearing the talk on this topic at IETF-65. We also acknowledge		hearing "the talk" on this topic at IETF-65. We also acknowledge
	constructive comments from Alan Clark, Loki Jorgenson, Carsten		constructive comments from Alan Clark, Loki Jorgenson, Carsten
	Schmoll, and Robert Holley.		Schmoll, and Robert Holley.
	12. Appendix on Reducing Delay Variation in Networks		12. Appendix on Calculating the D(min) in PDV
	>>> The Authors plan to Delete this section, unless someone raises a
	strong rationale to keep it.
	This text is both preliminary and generic but we want to explain the
	basic troubleshooting.
	If there is a DV problem, it may be because:
	1. there is congestion. Find where the bottleneck is, and increase
	the buffer Alternatively, increase the bandwidth Alternatively,
	remove some applications from that class of service
	2. there is a variability of the traffic Discover that traffic, then
	change/apply QoS (for example, rate-limiting)
	13. Appendix on Calculating the D(min) in PDV
	Practitioners have raised questions several questions that this		Practitioners have raised questions several questions that this
	section intends to answer:		section intends to answer:
	- how is this D_min calculated? Is it DV(99%) as mentioned in		- how is this D_min calculated? Is it DV(99%) as mentioned in
	[Krzanowski]?		[Krzanowski]?
	- do we need to keep all the values from the interval, then take the		- do we need to keep all the values from the interval, then take the
	minimum? Or do we keep the minimum from previous intervals?		minimum? Or do we keep the minimum from previous intervals?
	skipping to change at page 35, line 13		skipping to change at page 35, line 18
	soon after collection.		soon after collection.
	It is not necessary to store all delay values in a sample when		It is not necessary to store all delay values in a sample when
	storage is a major concern. D_min can be found by comparing each new		storage is a major concern. D_min can be found by comparing each new
	singleton value with the current value and replacing it when		singleton value with the current value and replacing it when
	required. In a sample with 5000 packets, evaluation of the 99.9%-ile		required. In a sample with 5000 packets, evaluation of the 99.9%-ile
	can also be achieved with limited storage. One method calls for		can also be achieved with limited storage. One method calls for
	storing the top 50 delay singletons and revising the top value list		storing the top 50 delay singletons and revising the top value list
	each time 50 more packets arrive.		each time 50 more packets arrive.
	14. References		13. References
	14.1. Normative References		13.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.
	[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.
	[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.
	skipping to change at page 35, line 38		skipping to change at page 35, line 43
	Packet Loss Metric for IPPM", RFC 2680, September 1999.		Packet Loss Metric for IPPM", RFC 2680, September 1999.
	[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation		[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
	Metric for IP Performance Metrics (IPPM)", RFC 3393,		Metric for IP Performance Metrics (IPPM)", RFC 3393,
	November 2002.		November 2002.
	[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.
	[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
	Jacobson, "RTP: A Transport Protocol for Real-Time
	Applications", STD 64, RFC 3550, July 2003.
	[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute		[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
	Extensions to RSVP-TE for LSP Tunnels", RFC 4090,		Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
	May 2005.		May 2005.
	[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.		[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
	Zekauskas, "A One-way Active Measurement Protocol		Zekauskas, "A One-way Active Measurement Protocol
	(OWAMP)", RFC 4656, September 2006.		(OWAMP)", RFC 4656, September 2006.
	[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.
	14.2. Informative References		13.2. Informative References
	[COM12.D98]		[COM12.D98]
	Clark, Alan., "ITU-T Delayed Contribution COM 12 - D98,		Clark, Alan., "ITU-T Delayed Contribution COM 12 - D98,
	"Analysis, measurement and modelling of Jitter"",		"Analysis, measurement and modelling of Jitter"",
	January 2003.		January 2003.
	[Casner] "A Fine-Grained View of High Performance Networking, NANOG		[Casner] "A Fine-Grained View of High Performance Networking, NANOG
	22 Conf.; http://www.nanog.org/mtg-0105/agenda.html", May		22 Conf.; http://www.nanog.org/mtg-0105/agenda.html", May
	20-22 2001.		20-22 2001.
	skipping to change at page 36, line 40		skipping to change at page 36, line 43
	evaluating multimedia transmission performance over		evaluating multimedia transmission performance over
	Internet Protocol"", November 2005.		Internet Protocol"", November 2005.
	[I-D.ietf-ippm-framework-compagg]		[I-D.ietf-ippm-framework-compagg]
	Morton, A., "Framework for Metric Composition",		Morton, A., "Framework for Metric Composition",
	draft-ietf-ippm-framework-compagg-06 (work in progress),		draft-ietf-ippm-framework-compagg-06 (work in progress),
	February 2008.		February 2008.
	[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-05 (work in		Metrics", draft-ietf-ippm-spatial-composition-06 (work in
	progress), November 2007.		progress), February 2008.
	[I-D.morton-ippm-reporting-metrics]		[I-D.morton-ippm-reporting-metrics]
	Morton, A., Ramachandran, G., and G. Maguluri, "Reporting		Morton, A., Ramachandran, G., and G. Maguluri, "Reporting
	Metrics: Different Points of View",		Metrics: Different Points of View",
	draft-morton-ippm-reporting-metrics-04 (work in progress),		draft-morton-ippm-reporting-metrics-05 (work in progress),
	November 2007.		May 2008.
	[Krzanowski]		[Krzanowski]
	Presentation at IPPM, IETF-64, "Jitter Definitions: What		Presentation at IPPM, IETF-64, "Jitter Definitions: What
	is What?", November 2005.		is What?", November 2005.
	[Li.Mills]		[Li.Mills]
	Li, Quong. and David. Mills, ""The Implications of Short-		Li, Quong. and David. Mills, ""The Implications of Short-
	Range Dependency on Delay Variation Measurement", Second		Range Dependency on Delay Variation Measurement", Second
	IEEE Symposium on Network Computing and Applications",		IEEE Symposium on Network Computing and Applications",
	2003.		2003.
	skipping to change at page 37, line 22		skipping to change at page 37, line 24
	Morton, A., ""A Brief Jitter Metrics Comparison, and not		Morton, A., ""A Brief Jitter Metrics Comparison, and not
	the last word, by any means...", Slide Presentation at		the last word, by any means...", Slide Presentation at
	IETF-65, IPPM Session,", March 2006.		IETF-65, IPPM Session,", March 2006.
	[RFC1305] Mills, D., "Network Time Protocol (Version 3)		[RFC1305] Mills, D., "Network Time Protocol (Version 3)
	Specification, Implementation", RFC 1305, March 1992.		Specification, Implementation", RFC 1305, March 1992.
	[RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample		[RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample
	Metrics", RFC 3357, August 2002.		Metrics", RFC 3357, August 2002.
			[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
			Jacobson, "RTP: A Transport Protocol for Real-Time
			Applications", STD 64, RFC 3550, July 2003.
	[Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data		[Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data
	communication service - IP packet transfer and		communication service - IP packet transfer and
	availability performance parameters", December 2002.		availability performance parameters", December 2002.
	[Y.1541] ITU-T Recommendation Y.1540, "Network Performance		[Y.1541] ITU-T Recommendation Y.1540, "Network Performance
	Objectives for IP-Based Services", February 2006.		Objectives for IP-Based Services", February 2006.
	[Zhang.Duff]		[Zhang.Duff]
	Zhang, Yin., Duffield, Nick., Paxson, Vern., and Scott.		Zhang, Yin., Duffield, Nick., Paxson, Vern., and Scott.
	Shenker, ""On the Constancy of Internet Path Properties",		Shenker, ""On the Constancy of Internet Path Properties",
	skipping to change at page 39, line 44		skipping to change at line 1745
	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.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 43 change blocks.
	112 lines changed or deleted		118 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/