< draft-leith-tcp-htcp-05.txt		draft-leith-tcp-htcp-06.txt >
	draft-leith-tcp-htcp-05 D. Leith		draft-leith-tcp-htcp-06 D. Leith
	Internet-Draft R. Shorten		Internet-Draft Hamilton Institute
	Intended status: Experimental Hamilton Institute		Intended status: Experimental April 7, 2008
	Expires: August 4, 2008 Feb 2008		Expires: October 9, 2008
	H-TCP: TCP Congestion Control for High Bandwidth-Delay Product Paths		H-TCP: TCP Congestion Control for High Bandwidth-Delay Product Paths
	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.
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	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 4, 2008.		This Internet-Draft will expire on October 9, 2008.
	Copyright Notice
	Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	Our objective in this document is to renew discussion on how the TCP		This document describes a number of changes to the TCP congestion
	congestion control algorithm might best be modified to improve		control algorithm to to improve performance in high bandwidth-delay
	performance in high bandwidth-delay product paths. We focus on		product paths. We focus on changes to the congestion avoidance mode,
	changes to the additive increase element of the TCP AIMD algorithm.		rather than slow-start.
	Table of Contents		Table of Contents
	1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Additive Increase for High Bandwidth-Delay Product Paths . . . 6		3. Additive Increase for High Bandwidth-Delay Product Paths . . . 6
	4. Choice of Increase Function . . . . . . . . . . . . . . . . . 8		4. Impact of Changes on Performance . . . . . . . . . . . . . . . 8
	4.1. RTT unfairness . . . . . . . . . . . . . . . . . . . . . . 8		4.1. RTT unfairness . . . . . . . . . . . . . . . . . . . . . . 8
	4.2. Friendliness . . . . . . . . . . . . . . . . . . . . . . . 8		4.2. Friendliness . . . . . . . . . . . . . . . . . . . . . . . 8
	4.3. Responsiveness . . . . . . . . . . . . . . . . . . . . . . 9		4.3. Responsiveness . . . . . . . . . . . . . . . . . . . . . . 8
	4.4. Efficiency . . . . . . . . . . . . . . . . . . . . . . . . 9		4.4. Efficiency . . . . . . . . . . . . . . . . . . . . . . . . 8
	5. RTT Scaling . . . . . . . . . . . . . . . . . . . . . . . . . 10		5. Optional RTT Scaling . . . . . . . . . . . . . . . . . . . . . 10
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 11		6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
	8. Informative References . . . . . . . . . . . . . . . . . . . . 13		8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14		9. Informative References . . . . . . . . . . . . . . . . . . . . 14
	Intellectual Property and Copyright Statements . . . . . . . . . . 15		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
			Intellectual Property and Copyright Statements . . . . . . . . . . 16
	1. Conventions		1. Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119.		document are to be interpreted as described in RFC 2119.
	2. Introduction		2. Introduction
			This document describes a number of changes to the TCP congestion
			control algorithm to to improve performance in high bandwidth-delay
			product paths.
	The current TCP congestion control algorithm is known to perform		The current TCP congestion control algorithm is known to perform
	poorly on paths where the TCP congestion window becomes very large.		poorly on paths where the TCP congestion window becomes large.
	[Kelly02, Flo03, FAST04]. Following congestion, the congestion		[Kelly02, Flo03, FAST04]. Following congestion, the congestion
	window is halved and only increases at a rate of 1 packet per RTT.		window is halved and only increases at a rate of 1 packet per RTT.
	As a result flows can take an unacceptably long time to recover their		As a result flows can take an unacceptably long time to recover their
	window size after a congestion event.		window size after a congestion event.
	A direct solution is to make the time between congestion events		A direct solution is to make the time between congestion events
	smaller. This can be achieved by, for example, adjusting the AIMD		smaller. This can be achieved by, for example, adjusting the AIMD
	additive increase rate to be greater for flows with larger congestion		additive increase rate to be greater for flows with larger congestion
	window. Backward compatibility with legacy TCP can be ensured		window. Backward compatibility with legacy TCP can be ensured
	through the inclusion of a separate mode of operation that behaves as		through the inclusion of a separate mode of operation that behaves as
	skipping to change at page 4, line 38 ¶		skipping to change at page 4, line 42 ¶
	High-Speed TCP [Flo03] proposal. In addition to adjusting the AIMD		High-Speed TCP [Flo03] proposal. In addition to adjusting the AIMD
	increase parameter alpha as a function of congestion window, this		increase parameter alpha as a function of congestion window, this
	proposal also increases the multiplicative decrease factor beta to		proposal also increases the multiplicative decrease factor beta to
	further increase the aggressiveness of a flow. (Note. On		further increase the aggressiveness of a flow. (Note. On
	multiplicative decrease, the congestion window cwnd is updated to		multiplicative decrease, the congestion window cwnd is updated to
	beta x cwnd. We use this definition of the backoff factor beta		beta x cwnd. We use this definition of the backoff factor beta
	throughout this document).		throughout this document).
	While such modifications might appear straightforward, it has been		While such modifications might appear straightforward, it has been
	shown [Sho04, Yi05] that they often negatively impact the behaviour		shown [Sho04, Yi05] that they often negatively impact the behaviour
	of networks of TCP flows. High-speed TCP[Flo03] and BIC-TCP [BIC04]		of networks of TCP flows. High-speed TCP[Flo03], BIC-TCP [BIC04] and
	can exhibit extremely slow convergence following network disturbances		Cubic can exhibit slow convergence following network disturbances
	such as the start-up of new flows; Scalable-TCP [Kelly02] is a		such as the start-up of new flows; Scalable-TCP [Kelly02] is a
	multiplicative-increase multiplicative-decrease strategy and as such		multiplicative-increase multiplicative-decrease strategy and as such
	it is known that it may fail to converge to fairness in drop-tail		it is known that it may fail to converge to fairness in drop-tail
	networks [Jain89].		networks [Jain89].
	Our objective in this document is to therefore to renew discussion on
	how the TCP congestion control algorithm might best be modified to
	improve performance when the congestion window is large. Large
	congestion windows are associated with high bandwidth-delay product
	(BDP) paths and with the ongoing increase in network speeds, high BDP
	paths are becoming increasingly prevalent. In this document we focus
	on changes to the additive increase element of the TCP AIMD algorithm
	(we leave discussion of modifications to the backoff factor to a
	later date). In particular, we present proposed changes to the
	additive increase algorithm that we argue are promising enough (based
	on the outcome of experimental tests carried out by a number of
	groups [Hegde04, Yi05, Cot05]) to warrant further discussion within
	the wider networking community.
	Scope		Scope
	-----		-----
	Our focus in this document is on the behaviour of long-lived flows		Our focus in this document is on the behaviour of long-lived flows
	and so we do not consider changes to slow-start. We also seek to		and so we do not consider changes to slow-start. We also seek to
	make the smallest possible changes to the existing TCP congestion		make the smallest possible changes to the existing TCP congestion
	control algorithm, and so confine consideration to the AIMD packet-		control algorithm, and so confine consideration to the AIMD packet-
	loss based paradigm. Use of jumbo packets is viewed as complementary		loss based paradigm. Use of jumbo packets is viewed as complementary
	to the changes proposed here. We confine consideration to drop-tail		to the changes proposed here.
	queues as this is the prevalent queueing discipline in the current
	Internet and leave discussion of active queueing to a later date.
	3. Additive Increase for High Bandwidth-Delay Product Paths		3. Additive Increase for High Bandwidth-Delay Product Paths
	The AIMD algorithm used in TCP has two key features that underpin its		It is known that modifying the AIMD backoff factor can have a
	convergence behaviour. Firstly, flows with the same RTT increase		significant impact on network responsiveness, and this is discussed
	their congestion windows at the same rate. Secondly, the backoff		in more detail elsewhere [Sho04, Sho05]. In this document we confine
	mechanism is multiplicative. Hence, following congestion, flows with		attention to modifications to the AIMD increase rate with the aim of
	a larger congestion window will reduce their congestion window by		improving performance in high bandwidth-delay product paths. We
	more, in absolute terms, than flows with a smaller congestion window.		begin with the observation that making the AIMD increase rate an
	Thus larger flows yield more bandwidth than smaller flows. Since		increasing function of flow cwnd (as is done in the HS-TCP, BIC,
	flows increase congestion window at the same rate, flows with smaller		Cubic etc algorithms) means that flows with smaller cwnd are placed
	congestion window thereby gain a certain advantage over flows with		at a disadvantage to flows with larger cwnd when competing for
	larger congestion window, and it is this that enables flows with		bandwidth. This is a primary source of unfairness and slow
	small congestion window to seize bandwidth from flows with large		convergence. We therefore take an alternative approach. Noting that
	congestion window until balance is reached in the network.		it is the increase in congestion epoch duration with bandwidth-delay
			product that is the source of many issues, we make the AIMD increase
	It follows from this observation that modifying the AIMD backoff		rate purely a function of the elapsed time since the last congestion
	factor can have a very significant impact on network responsiveness,		event. This allows us to increase the aggressiveness of the AIMD
	and this is discussed in more detail elsewhere [Sho04, Sho05]. In		increase as the congestion epoch duration increases (so improving
	this document we do not consider changes to the backoff factor.		performance in high bandwidth-delay product paths) while avoiding
	Instead, we confine attention to modifications to the AIMD increase		placing flows with small cwnd at a consistent disadvantage.
	rate with the aim of improving performance in high bandwidth-delay
	product paths. Provided we retain appropriate symmetry between the
	increase rates of competing flows, modifying the increase rate
	affects the interval between congestion events but otherwise does not
	affect the responsiveness of TCP.
	We therefore propose generalising the AIMD algorithm by allowing the		RFC2591 specifies that during congestion avoidance, cwnd is
	increase parameter alpha to vary as a function of the elapsed time		incremented by 1 full-sized segment per round-trip time (RTT). We
	since the last congestion event. Specifically, if we let Delta		modify this behaviour to increase cwnd by alpha segments per RTT,
	denote the time in seconds that has elapsed since the last congestion		where alpha is calculated as follows.
	event experienced by a flow, we adjust the AIMD increase parameter
	according to some function which we denote f_alpha(Delta). To
	provide backward compatibility with legacy TCP flows we consider
	adjusting the increase parameter as follows
	if Delta <= Delta_L		if Delta <= Delta_L
	alpha = 1		alpha = 1
	else		else
	alpha = f_alpha(Delta)		alpha = f_alpha(Delta)
	where Delta_L is the threshold for switching from standard/legacy		where Delta is the time in seconds that has elapsed since the last
	operation to the new increase function. The choice of function		congestion event experienced by a flow and Delta_L is the threshold
	f_alpha is governed by the rate at which bandwidth should be		for switching from standard/legacy operation to the new increase
	acquired.		function. Delta_L MUST be at least 1 second, although larger values
			MAY be used. The increase function f_alpha is selected such that the
	We can immediately make the observation that, because the adjustment		duration of the congestion epochs remains reasonably small as the
	is based on time since the last backoff, a degree of symmetry is		bandwidth-delay product on a path increases. Below, we discuss a
	maintained between competing network flows and in particular flows		choice of increase function that yields convergence times that seem
	already in high speed mode are not awarded a long-term advantage over		reasonable. However, the precise responsiveness requirement in
	newer flows. Specifically, when packet drops are synchronised Delta		future networks is currently not well defined and so the specific
	is necessarily the same for all flows. Hence all flows share		choice of increase function may change.
	identical increase profiles and symmetry is maintained [Sho04]. When
	drops are not synchronised, Delta is the same *on average* for all
	flows provided flows share the same probability of backing off on
	congestion. Hence, symmetry is still maintained, albeit in an
	average sense.
	We select the increase function f_alpha such that the duration of the
	congestion epochs remains reasonably small as the bandwidth-delay
	product on a path increases. Below, we discuss one choice of
	increase function that yields convergence times that seem reasonable.
	However, the precise responsiveness requirement in future networks is
	currently not well defined and so we leave this, and the associated
	specific choice of increase function, as a question for further
	debate.
	4. Choice of Increase Function
	We consider, as an illustrative example, use of the increase function		Use of the following increase function is RECOMMENDED:
	f_alpha(Delta) = 1 + 10(Delta-Delta_L)+0.5(Delta-Delta_L)^2 (1)		f_alpha(Delta) = 1 + 10(Delta-Delta_L)+0.5(Delta-Delta_L)^2 (1)
	and Delta_L=1 second. This choice yields the congestion epoch		This choice yields the congestion epoch duration for a single flow,
	duration for a single flow, as a function of congestion window size,		as a function of congestion window size, shown in Table 1.
	shown in Table 1.
	-------------------------------------		-------------------------------------
	Congestion Congestion		Congestion Congestion
	window epoch		window epoch
	(packets) duration (s)		(packets) duration (s)
	-------------------------------------		-------------------------------------
	100 1.1		100 1.1
	1000 3.1		1000 3.1
	2000 4.3		2000 4.3
	5000 6.6		5000 6.6
	10000 9.2		10000 9.2
	20000 12.8		20000 12.8
	50000 19.4		50000 19.4
	-------------------------------------		-------------------------------------
	Table 1 - Congestion epoch duration vs congestion window		Table 1 - Congestion epoch duration vs congestion window
	size for an RTT of 100ms		size for an RTT of 100ms
			4. Impact of Changes on Performance
	4.1. RTT unfairness		4.1. RTT unfairness
	It follows from the introductory discussion that (when RTT scaling is		The level of unfairness between flows with different RTT's is similar
	not used) the level of unfairness between flows with different RTT's		to that with the standard TCP algorithm. This behaviour is confirmed
	is similar to that with the current AIMD algorithm. This behaviour		in experimental and simulation tests [HTCP04, Yi05].
	is confirmed in experimental and simulation tests [HTCP04, Yi05].
	4.2. Friendliness		4.2. Friendliness
	The mean AIMD increase parameter is shown in Table 2 for a range of		The mean AIMD increase parameter is shown in Table 2 for a range of
	bandwidth-delay products. This an indication of the number of		bandwidth-delay products. This an indication of the number of
	standard TCP flows (neglecting statistical multiplexing of backoffs)		standard TCP flows (neglecting statistical multiplexing of backoffs)
	whose aggregate would be equivalent to a flow using increase function		whose aggregate would be equivalent to a flow using increase function
	(1). That is, an indication of friendliness and also of the packet		(1). That is, an indication of friendliness and also of the packet
	drop overhead associated with the AIMD probing action.		drop overhead associated with the AIMD probing action.
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 5 ¶
	4.4. Efficiency		4.4. Efficiency
	Link utilisation depends on queue provisioning in a similar manner to		Link utilisation depends on queue provisioning in a similar manner to
	the current TCP congestion control algorithm. That is, for a single		the current TCP congestion control algorithm. That is, for a single
	flow (or multiple synchronised flows) 100% link utilisation requires		flow (or multiple synchronised flows) 100% link utilisation requires
	that the queue be sized as the bandwidth-delay product. Simulation		that the queue be sized as the bandwidth-delay product. Simulation
	and experimental tests indicate that statistical multiplexing between		and experimental tests indicate that statistical multiplexing between
	unsynchronised flows yields similar efficiency gains to standard TCP.		unsynchronised flows yields similar efficiency gains to standard TCP.
	5. RTT Scaling		5. Optional RTT Scaling
	We note that the parameter alpha determines the AIMD increase rate in		We note that the parameter alpha determines the AIMD increase rate in
	packets per RTT. Hence, flows with the same RTT have the same		packets per RTT. Hence, flows with the same RTT have the same
	increase rate in packets per second, but flows with different RTTs		increase rate in packets per second, but flows with different RTTs
	have different increase rate in packets per second. It is this that		have different increase rate in packets per second. It is this that
	primarily leads to unfairness between flows with different RTTs.		primarily leads to unfairness between flows with different RTTs.
	Removing RTT unfairness is not one of our objectives here. However,		Removing RTT unfairness is not one of our objectives here. However,
	we note that an AIMD flow generates roughly alpha packet drops per		we note that an AIMD flow generates roughly alpha packet drops per
	RTT as a result of its probing action. Hence, flows with short RTT		RTT as a result of its probing action. Hence, flows with short RTT
	are more aggressive than flows with long RTT in the sense that they		are more aggressive than flows with long RTT in the sense that they
	skipping to change at page 10, line 27 ¶		skipping to change at page 10, line 27 ¶
	seconds. We can reduce the aggressiveness of short RTT flows by		seconds. We can reduce the aggressiveness of short RTT flows by
	scaling the increase parameter alpha with RTT. This need not		scaling the increase parameter alpha with RTT. This need not
	compromise the responsiveness of TCP flows. As noted in [Sh04, Sh05,		compromise the responsiveness of TCP flows. As noted in [Sh04, Sh05,
	HTCP04], the convergence time of TCP flows using an AIMD backoff		HTCP04], the convergence time of TCP flows using an AIMD backoff
	factor of 0.5 is approximately 4 congestion epochs. Scaling alpha by		factor of 0.5 is approximately 4 congestion epochs. Scaling alpha by
	RTT leads to scaling of the congestion epoch duration to become		RTT leads to scaling of the congestion epoch duration to become
	effectively the same for both short and long RTT flows. The		effectively the same for both short and long RTT flows. The
	convergence time is therefore also scaled to be effectively the same		convergence time is therefore also scaled to be effectively the same
	for both short and long RTT flows.		for both short and long RTT flows.
	Such RTT scaling can be readily implemented by modifying the increase		Such RTT scaling MAY be implemented by modifying the increase rule to
	rule to
	if Delta <= Delta_L		if Delta <= Delta_L
	alpha = 1		alpha = 1
	else		else
	alpha = K x f_alpha(Delta)		alpha = K x f_alpha(Delta)
	where K = RTT/RTT_ref. Note that RTT scaling is not applied in low-		where K = RTT/RTT_ref. Note that RTT scaling is not applied in low-
	speed conditions in order to maintain backward compatibility with		speed conditions in order to maintain backward compatibility with
	legacy TCP flows (ensuring adequate backward compatibility presented		legacy TCP flows (ensuring adequate backward compatibility presented
	a major difficulty in previous studies on the use of RTT scaling).		a major difficulty in previous studies on the use of RTT scaling).
	Note also that the scaling is proportional to RTT rather than RTT^2,		Note also that the scaling is proportional to RTT rather than RTT^2,
	as we do not seek to achieve throughput fairness here. RTT_ref is		as we do not seek to achieve throughput fairness here. RTT_ref is
	the reference RTT for which f_alpha is designed to ensure acceptable		the reference RTT for which f_alpha is designed to ensure acceptable
	congestion epoch durations.		congestion epoch durations, with the recommended value being 100ms.
	6. Security Considerations		6. Security Considerations
	Security implications are not discussed in this document.		Security implications are not discussed in this document.
	7. Acknowledgements		7. Acknowledgements
	This work was supported by Science Foundation Ireland grants 00/PI.1/		This work was supported by Science Foundation Ireland grants 00/PI.1/
	C067 and 04/IN3/I460.		C067 and 04/IN3/I460.
	8. Informative References		8. Changelog
			April 2008: Updated to use RFC2119 terminology. Discussion
			streamlined.
			9. Informative References
	[Jain89] D.M. Chiu, R. Jain, Analysis of the increase and decrease		[Jain89] D.M. Chiu, R. Jain, Analysis of the increase and decrease
	algorithms for congestion avoidance in computer networks. Computer		algorithms for congestion avoidance in computer networks. Computer
	Networks and ISDN Systems, 1989.		Networks and ISDN Systems, 1989.
	[Flo03] S.Floyd, HighSpeed TCP for Large Congestion Windows . Sally		[Flo03] S.Floyd, HighSpeed TCP for Large Congestion Windows . Sally
	Floyd. IETF RFC 3649, Experimental, Dec 2003.		Floyd. IETF RFC 3649, Experimental, Dec 2003.
	[FAST04] C. Jin, D.X. Wei, S,H. Low, FAST TCP: motivation,		[FAST04] C. Jin, D.X. Wei, S,H. Low, FAST TCP: motivation,
	architecture, algorithms, performance. Proc IEEE INFOCOM 2004.		architecture, algorithms, performance. Proc IEEE INFOCOM 2004.
	skipping to change at page 14, line 5 ¶		skipping to change at page 15, line 5 ¶
	[Cot05] R.L. Cottrell, S. Ansari, P. Khandpur, R. Gupta, R. Hughes-		[Cot05] R.L. Cottrell, S. Ansari, P. Khandpur, R. Gupta, R. Hughes-
	Jones, M. Chen, L. MacIntosh, F. Leers, Characterization and		Jones, M. Chen, L. MacIntosh, F. Leers, Characterization and
	Evaluation of TCP and UDP-Based Transport On Real Networks. . Proc.		Evaluation of TCP and UDP-Based Transport On Real Networks. . Proc.
	3rd Workshop on Protocols for Fast Long-distance Networks, Lyon,		3rd Workshop on Protocols for Fast Long-distance Networks, Lyon,
	France, 2005.		France, 2005.
	[Hegde04] S. Hegde, D. Lapsley, B. Wydrowski, J. Lindheim, D.Wei, C.		[Hegde04] S. Hegde, D. Lapsley, B. Wydrowski, J. Lindheim, D.Wei, C.
	Jin, S. Low, H. Newman, FAST TCP in High Speed Networks: An		Jin, S. Low, H. Newman, FAST TCP in High Speed Networks: An
	Experimental Study. Proc. GridNets, San Jose, 2004.		Experimental Study. Proc. GridNets, San Jose, 2004.
	Authors' Addresses		Author's Address
	Doug Leith		Doug Leith
	Hamilton Institute		Hamilton Institute
	NUI Maynooth		NUI Maynooth
	Maynooth, Co. Kildare		Maynooth, Co. Kildare
	Ireland		Ireland
	Email: doug.leith@nuim.ie		Email: doug.leith@nuim.ie
	Robert Shorten
	Hamilton Institute
	NUI Maynooth
	Maynooth, Co. KIldare
	Ireland
	Email: robert.shorten@nuim.ie
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	skipping to change at page 15, line 44 ¶		skipping to change at line 382 ¶
	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. 25 change blocks.
	120 lines changed or deleted		76 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/