draft-ietf-rmcat-sbd-06.txt		draft-ietf-rmcat-sbd-07.txt
	RTP Media Congestion Avoidance Techniques D. Hayes, Ed.		RTP Media Congestion Avoidance Techniques D. Hayes, Ed.
	Internet-Draft S. Ferlin		Internet-Draft S. Ferlin
	Intended status: Experimental Simula Research Laboratory		Intended status: Experimental Simula Research Laboratory
	Expires: August 19, 2017 M. Welzl		Expires: December 10, 2017 M. Welzl
	K. Hiorth		K. Hiorth
	University of Oslo		University of Oslo
	February 15, 2017		June 8, 2017
	Shared Bottleneck Detection for Coupled Congestion Control for RTP		Shared Bottleneck Detection for Coupled Congestion Control for RTP
	Media.		Media.
	draft-ietf-rmcat-sbd-06		draft-ietf-rmcat-sbd-07
	Abstract		Abstract
	This document describes a mechanism to detect whether end-to-end data		This document describes a mechanism to detect whether end-to-end data
	flows share a common bottleneck. It relies on summary statistics		flows share a common bottleneck. It relies on summary statistics
	that are calculated based on continuous measurements and used as		that are calculated based on continuous measurements and used as
	input to a grouping algorithm that runs wherever the knowledge is		input to a grouping algorithm that runs wherever the knowledge is
	needed. This mechanism complements the coupled congestion control		needed. This mechanism complements the coupled congestion control
	mechanism in draft-ietf-rmcat-coupled-cc.		mechanism in draft-ietf-rmcat-coupled-cc.
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 19, 2017.		This Internet-Draft will expire on December 10, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 27 ¶		skipping to change at page 2, line 27 ¶
	1.2.3. Path lag . . . . . . . . . . . . . . . . . . . . . . 4		1.2.3. Path lag . . . . . . . . . . . . . . . . . . . . . . 4
	2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Parameters and their effect . . . . . . . . . . . . . . . 7		2.1. Parameters and their effect . . . . . . . . . . . . . . . 7
	2.2. Recommended parameter values . . . . . . . . . . . . . . 8		2.2. Recommended parameter values . . . . . . . . . . . . . . 8
	3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 8		3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.1. SBD feedback requirements . . . . . . . . . . . . . . . . 9		3.1. SBD feedback requirements . . . . . . . . . . . . . . . . 9
	3.1.1. Feedback when all the logic is placed at the sender . 9		3.1.1. Feedback when all the logic is placed at the sender . 9
	3.1.2. Feedback when the statistics are calculated at the		3.1.2. Feedback when the statistics are calculated at the
	receiver and SBD performed at the sender . . . . . . 10		receiver and SBD performed at the sender . . . . . . 10
	3.1.3. Feedback when bottlenecks can be determined at both		3.1.3. Feedback when bottlenecks can be determined at both
	senders and receivers . . . . . . . . . . . . . . . . 10		senders and receivers . . . . . . . . . . . . . . . . 11
	3.2. Key metrics and their calculation . . . . . . . . . . . . 11		3.2. Key metrics and their calculation . . . . . . . . . . . . 11
	3.2.1. Mean delay . . . . . . . . . . . . . . . . . . . . . 11		3.2.1. Mean delay . . . . . . . . . . . . . . . . . . . . . 11
	3.2.2. Skewness estimate . . . . . . . . . . . . . . . . . . 11		3.2.2. Skewness estimate . . . . . . . . . . . . . . . . . . 11
	3.2.3. Variability estimate . . . . . . . . . . . . . . . . 12		3.2.3. Variability estimate . . . . . . . . . . . . . . . . 12
	3.2.4. Oscillation estimate . . . . . . . . . . . . . . . . 12		3.2.4. Oscillation estimate . . . . . . . . . . . . . . . . 12
	3.2.5. Packet loss . . . . . . . . . . . . . . . . . . . . . 13		3.2.5. Packet loss . . . . . . . . . . . . . . . . . . . . . 13
	3.3. Flow Grouping . . . . . . . . . . . . . . . . . . . . . . 13		3.3. Flow Grouping . . . . . . . . . . . . . . . . . . . . . . 13
	3.3.1. Flow grouping algorithm . . . . . . . . . . . . . . . 13		3.3.1. Flow grouping algorithm . . . . . . . . . . . . . . . 13
	3.3.2. Using the flow group signal . . . . . . . . . . . . . 15		3.3.2. Using the flow group signal . . . . . . . . . . . . . 16
	4. Enhancements to the basic SBD algorithm . . . . . . . . . . . 15		4. Enhancements to the basic SBD algorithm . . . . . . . . . . . 17
	4.1. Reducing lag and improving responsiveness . . . . . . . . 15		4.1. Reducing lag and improving responsiveness . . . . . . . . 17
	4.1.1. Improving the response of the skewness estimate . . . 16		4.1.1. Improving the response of the skewness estimate . . . 18
	4.1.2. Improving the response of the variability estimate . 18		4.1.2. Improving the response of the variability estimate . 20
	4.2. Removing oscillation noise . . . . . . . . . . . . . . . 18		4.2. Removing oscillation noise . . . . . . . . . . . . . . . 20
	5. Measuring OWD . . . . . . . . . . . . . . . . . . . . . . . . 19		5. Measuring OWD . . . . . . . . . . . . . . . . . . . . . . . . 21
	5.1. Time stamp resolution . . . . . . . . . . . . . . . . . . 19		5.1. Time stamp resolution . . . . . . . . . . . . . . . . . . 21
	5.2. Clock skew . . . . . . . . . . . . . . . . . . . . . . . 19		5.2. Clock skew . . . . . . . . . . . . . . . . . . . . . . . 21
	6. Expected feedback from experiments . . . . . . . . . . . . . 19		6. Expected feedback from experiments . . . . . . . . . . . . . 21
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 20		9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
	10. Change history . . . . . . . . . . . . . . . . . . . . . . . 20		10. Change history . . . . . . . . . . . . . . . . . . . . . . . 22
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
	11.1. Normative References . . . . . . . . . . . . . . . . . . 21		11.1. Normative References . . . . . . . . . . . . . . . . . . 23
	11.2. Informative References . . . . . . . . . . . . . . . . . 21		11.2. Informative References . . . . . . . . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
	1. Introduction		1. Introduction
	In the Internet, it is not normally known if flows (e.g., TCP		In the Internet, it is not normally known if flows (e.g., TCP
	connections or UDP data streams) traverse the same bottlenecks. Even		connections or UDP data streams) traverse the same bottlenecks. Even
	flows that have the same sender and receiver may take different paths		flows that have the same sender and receiver may take different paths
	and may or may not share a bottleneck. Flows that share a bottleneck		and may or may not share a bottleneck. Flows that share a bottleneck
	link usually compete with one another for their share of the		link usually compete with one another for their share of the
	capacity. This competition has the potential to increase packet loss		capacity. This competition has the potential to increase packet loss
	and delays. This is especially relevant for interactive applications		and delays. This is especially relevant for interactive applications
	skipping to change at page 9, line 27 ¶		skipping to change at page 9, line 27 ¶
	and H2, neither H1 nor H2 alone obtain enough knowledge to detect		and H2, neither H1 nor H2 alone obtain enough knowledge to detect
	this shared bottleneck; H3 can however determine it by combining		this shared bottleneck; H3 can however determine it by combining
	the summary statistics related to H1 and H2, respectively.		the summary statistics related to H1 and H2, respectively.
	3.1. SBD feedback requirements		3.1. SBD feedback requirements
	There are three possible scenarios each with different feedback		There are three possible scenarios each with different feedback
	requirements:		requirements:
	1. Both summary statistic calculations and SBD are performed at		1. Both summary statistic calculations and SBD are performed at
	senders only.		senders only. When sender-based congestion control is
			implemented, this method is RECOMMENDED.
	2. Summary statistics calculated on the receivers and SBD at the		2. Summary statistics calculated on the receivers and SBD at the
	senders.		senders.
	3. Summary statistic calculations on receivers, and SBD performed at		3. Summary statistic calculations on receivers, and SBD performed at
	both senders and receivers (beyond the current scope, but allows		both senders and receivers (beyond the current scope, but allows
	cooperative detection of bottlenecks).		cooperative detection of bottlenecks).
	Note that the mechanism bases its calculations on the interval T. It		All three possibilities are discussed for completeness in this
	does not require T to be the feedback interval, only that		document, however, it is expected that feedback will take the form
	calculations can be performed over measurements made in that		scenario 1 and operate in conjunction with sender-based congestion
	interval.		control mechanisms.
	3.1.1. Feedback when all the logic is placed at the sender		3.1.1. Feedback when all the logic is placed at the sender
	Having the sender calculate the summary statistics and determine the		Having the sender calculate the summary statistics and determine the
	shared bottlenecks based on them has the advantage of placing most of		shared bottlenecks based on them has the advantage of placing most of
	the functionality in one place -- the sender.		the functionality in one place -- the sender.
	The sender requires precise accurate OWD measurements for every		For every packet, the sender requires accurate OWD measurements of
	packet, along with an indication of lost packets (or the proportion		adequate precision, along with an indication of lost packets (or the
	of packets lost over the interval T). The mechanism performs its		proportion of packets lost over an interval). These can be provided
	calculations every T and requires measurements to be available for		by [I-D.dt-rmcat-feedback-message].
	this.
	It is expected that the draft-ietf-rmcat-feedback-message will		The mechanism performs its calculation whenever it has received
	provide the necessary feedback for both SBD and congestion		sufficient measurements in the feedback messages to cover the T base
	controllers.		time interval. The exact timing of these calculations will depend on
			the frequency of the feedback message.
	3.1.2. Feedback when the statistics are calculated at the receiver and		3.1.2. Feedback when the statistics are calculated at the receiver and
	SBD performed at the sender		SBD performed at the sender
	This scenario minimizes feedback, but requires receivers to send		This scenario minimizes feedback, but requires receivers to send
	selected summary statistics at an agreed regular interval. We		selected summary statistics at an agreed regular interval. We
	envisage the following exchange of information to initialize the		envisage the following exchange of information to initialize the
	system:		system:
	o An initialization message from the sender to the receiver will		o An initialization message from the sender to the receiver will
	skipping to change at page 10, line 44 ¶		skipping to change at page 10, line 45 ¶
	* The values of T, N, M, and the necessary resolution and		* The values of T, N, M, and the necessary resolution and
	precision of the relayed statistics.		precision of the relayed statistics.
	o A response message from the receiver acknowledges this message		o A response message from the receiver acknowledges this message
	with a list of key metrics it supports (subset of the senders		with a list of key metrics it supports (subset of the senders
	list) and is able to relay back to the sender.		list) and is able to relay back to the sender.
	This initialization exchange may be repeated to finalize the agreed		This initialization exchange may be repeated to finalize the agreed
	metrics should not all be supported by all receivers.		metrics should not all be supported by all receivers.
	After initialization the agreed summary statistics will be fed back		After initialization the agreed summary statistics SHOULD be fed back
	to the sender (nominally every T).		to the sender (nominally every T).
	3.1.3. Feedback when bottlenecks can be determined at both senders and		3.1.3. Feedback when bottlenecks can be determined at both senders and
	receivers		receivers
	This type of mechanism is currently beyond the scope of SBD in RMCAT.		This type of mechanism is currently beyond the scope of SBD in RMCAT.
	It is mentioned here to ensure more advanced sender/receiver		It is mentioned here to ensure more advanced sender/receiver
	cooperative shared bottleneck determination mechanisms remain		cooperative shared bottleneck determination mechanisms remain
	possible in the future.		possible in the future.
	skipping to change at page 14, line 39 ¶		skipping to change at page 14, line 41 ¶
	These flows, flows transiting a bottleneck, are then progressively		These flows, flows transiting a bottleneck, are then progressively
	divided into groups based on the freq_est, var_est, and skew_est		divided into groups based on the freq_est, var_est, and skew_est
	summary statistics. The process proceeds according to the following		summary statistics. The process proceeds according to the following
	steps:		steps:
	2. Group flows whose difference in sorted freq_est is less than a		2. Group flows whose difference in sorted freq_est is less than a
	threshold:		threshold:
	diff(freq_est) < p_f		diff(freq_est) < p_f
	3. Subdivide freq_est groups by grouping flows whose difference in		3. Subdivide the groups obtained in 2. by grouping flows whose
	sorted E_M(var_est) (highest to lowest) is less than a threshold:		difference in sorted E_M(var_est) (highest to lowest) is less
			than a threshold:
	diff(var_est) < (p_mad * var_est)		diff(var_est) < (p_mad * var_est)
	The threshold, (p_mad * var_est), is with respect to the highest		The threshold, (p_mad * var_est), is with respect to the highest
	value in the difference.		value in the difference.
	4. Subdivide var_est groups by grouping flows whose difference in		4. Subdivide the groups obtained in 3. by grouping flows whose
	sorted skew_est is less than a threshold:		difference in sorted skew_est is less than a threshold:
	diff(skew_est) < p_s		diff(skew_est) < p_s
	5. When packet loss is high enough to be reliable (pkt_loss > p_l),		5. When packet loss is high enough to be reliable (pkt_loss > p_l),
	Subdivide skew_est groups by grouping flows whose difference is		Subdivide the groups obtained in 4. by grouping flows whose
	less than a threshold		difference is less than a threshold
	diff(pkt_loss) < (p_d * pkt_loss)		diff(pkt_loss) < (p_d * pkt_loss)
	The threshold, (p_d * pkt_loss), is with respect to the highest		The threshold, (p_d * pkt_loss), is with respect to the highest
	value in the difference.		value in the difference.
	This procedure involves sorting estimates from highest to lowest. It		This procedure involves sorting estimates from highest to lowest. It
	is simple to implement, and efficient for small numbers of flows (up		is simple to implement, and efficient for small numbers of flows (up
	to 10-20).		to 10-20).Figure 2 illustrates this algorithm
			*********
			* Flows *
			***.**.**
			/ '
			/ '--.
			/ \
			.---v--. .----v---.
			1. Flows traversing | Cong | | UnCong |
			a bottleneck '-.--.-' '--------'
			/ \
			/ \
			/ \
			.--v--. v-----.
			2. Divide by | g_1 | ... | g_n |
			freq_est '---.-. '----..
			/ \ / \
			/ '--. v '------.
			/ \ \
			.----v-. .-v----. .---v--.
			3. Divide by | g_1a | ... | g_1z | ... | g_nz |
			var_est '---.-.' '-----.. '-.-.--'
			/ \ / \ / |
			/ '-----. v v v |
			/ \ |
			.-v-----. .-v-----. .---v---.
			4. Divide by | g_1ai | ... | g_1ax | ... | g_nzx |
			skew_est '----.-.' '------.. '-.-.---'
			/ \ / \ / |
			/ '--. v v v |
			/ \ |
			.-----v--. .-v------. .----v---.
			5. Divide by | g_1aiA | ... | g_1aiZ | ... | g_nzxZ |
			pkt_loss '--------' '--------' '--------'
			(when applicable)
			Simple grouping algorithm.
			Figure 2
	3.3.2. Using the flow group signal		3.3.2. Using the flow group signal
	Grouping decisions can be made every T from the second T, however		Grouping decisions can be made every T from the second T, however
	they will not attain their full design accuracy until after the		they will not attain their full design accuracy until after the
	2*N'th T interval. We recommend that grouping decisions are not made		2*N'th T interval. We recommend that grouping decisions are not made
	until 2*M T intervals.		until 2*M T intervals.
	Network conditions, and even the congestion controllers, can cause		Network conditions, and even the congestion controllers, can cause
	bottlenecks to fluctuate. A coupled congestion controller MAY decide		bottlenecks to fluctuate. A coupled congestion controller MAY decide
	skipping to change at page 19, line 27 ¶		skipping to change at page 21, line 27 ¶
	clock offsets should be approximately constant over the measurement		clock offsets should be approximately constant over the measurement
	periods, the offset is subtracted out in the calculation.		periods, the offset is subtracted out in the calculation.
	5.1. Time stamp resolution		5.1. Time stamp resolution
	The SBD mechanism requires timing information precise enough to be		The SBD mechanism requires timing information precise enough to be
	able to make comparisons. As a rule of thumb, the time resolution		able to make comparisons. As a rule of thumb, the time resolution
	should be less than one hundredth of a typical path's range of		should be less than one hundredth of a typical path's range of
	delays. In general, the coarser the time resolution, the more care		delays. In general, the coarser the time resolution, the more care
	that needs to be taken to ensure rounding errors do not bias the		that needs to be taken to ensure rounding errors do not bias the
	skewness calculation.		skewness calculation. Time stamp resolution such as that described
			by [I-D.dt-rmcat-feedback-message] should be sufficient.
	Typical RTP media flows use sub-millisecond timers, which should be
	adequate in most situations.
	5.2. Clock skew		5.2. Clock skew
	Generally sender and receiver clock skew will be too small to cause		Generally sender and receiver clock skew will be too small to cause
	significant errors in the estimators. Skew_est and freq_est are the		significant errors in the estimators. Skew_est and freq_est are the
	most sensitive to this type of noise due to their use of a mean OWD		most sensitive to this type of noise due to their use of a mean OWD
	calculated over a longer interval. In circumstances where clock skew		calculated over a longer interval. In circumstances where clock skew
	is high, basing skew_est only on the previous T's mean and ignoring		is high, basing skew_est only on the previous T's mean and ignoring
	freq_est provides a noisier but reliable signal.		freq_est provides a noisier but reliable signal.
	skipping to change at page 20, line 32 ¶		skipping to change at page 22, line 30 ¶
	Non-authenticated RTCP packets carrying OWD measurements, shared		Non-authenticated RTCP packets carrying OWD measurements, shared
	bottleneck indications, and/or summary statistics could allow		bottleneck indications, and/or summary statistics could allow
	attackers to alter the bottleneck sharing characteristics for private		attackers to alter the bottleneck sharing characteristics for private
	gain or disruption of other parties communication.		gain or disruption of other parties communication.
	10. Change history		10. Change history
	Changes made to this document:		Changes made to this document:
			WG-06->WG-07 : Updates addressing
			https://mailarchive.ietf.org/arch/msg/
			rmcat/80B6q4nI7carGcf_ddBwx7nKvOw. Mainly
			clarifications. Figure 2 to supplement grouping
			algorithm description.
	WG-05->WG-06 : Updates addressing WG reviews		WG-05->WG-06 : Updates addressing WG reviews
	https://mailarchive.ietf.org/arch/msg/rmcat/-		https://mailarchive.ietf.org/arch/msg/rmcat/-
	1JdrTMq1Y5T6ZNlOkrQJQ27TzE and		1JdrTMq1Y5T6ZNlOkrQJQ27TzE and
	https://mailarchive.ietf.org/arch/msg/rmcat/		https://mailarchive.ietf.org/arch/msg/rmcat/
	eI2Q1f8NL2SxbJgjFLR4_rEmJ_g. This has mainly		eI2Q1f8NL2SxbJgjFLR4_rEmJ_g. This has mainly
	involved minor clarifications, including the moving		involved minor clarifications, including the moving
	of 3.4.1 and 3.5 into the new Section 4, and 3.4.1		of 3.4.1 and 3.5 into the new Section 4, and 3.4.1
	into Section 5		into Section 5
	WG-04->WG-05 : Fix ToC formatting. Add section on expected		WG-04->WG-05 : Fix ToC formatting. Add section on expected
	skipping to change at page 22, line 13 ¶		skipping to change at page 24, line 13 ¶
	11.2. Informative References		11.2. Informative References
	[Hayes-LCN14]		[Hayes-LCN14]
	Hayes, D., Ferlin, S., and M. Welzl, "Practical Passive		Hayes, D., Ferlin, S., and M. Welzl, "Practical Passive
	Shared Bottleneck Detection using Shape Summary		Shared Bottleneck Detection using Shape Summary
	Statistics", Proc. the IEEE Local Computer Networks		Statistics", Proc. the IEEE Local Computer Networks
	(LCN) pp150-158, September 2014,		(LCN) pp150-158, September 2014,
	<http://heim.ifi.uio.no/davihay/		<http://heim.ifi.uio.no/davihay/
	hayes14__pract_passiv_shared_bottl_detec-abstract.html>.		hayes14__pract_passiv_shared_bottl_detec-abstract.html>.
			[I-D.dt-rmcat-feedback-message]
			Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP
			Control Protocol (RTCP) Feedback for Congestion Control",
			draft-dt-rmcat-feedback-message-02 (work in progress), May
			2017.
	[I-D.ietf-rmcat-coupled-cc]		[I-D.ietf-rmcat-coupled-cc]
	Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion		Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion
	control for RTP media", draft-ietf-rmcat-coupled-cc-00		control for RTP media", draft-ietf-rmcat-coupled-cc-06
	(work in progress), September 2015.		(work in progress), March 2017.
	[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.		[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
	Jacobson, "RTP: A Transport Protocol for Real-Time		Jacobson, "RTP: A Transport Protocol for Real-Time
	Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,		Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
	July 2003, <http://www.rfc-editor.org/info/rfc3550>.		July 2003, <http://www.rfc-editor.org/info/rfc3550>.
	[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,		[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
	"Extended RTP Profile for Real-time Transport Control		"Extended RTP Profile for Real-time Transport Control
	Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,		Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
	DOI 10.17487/RFC4585, July 2006,		DOI 10.17487/RFC4585, July 2006,
End of changes. 19 change blocks.
	50 lines changed or deleted		100 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/