< draft-ietf-soc-overload-rate-control-04.txt		draft-ietf-soc-overload-rate-control-05.txt >
	SOC Working Group Eric Noel		SOC Working Group Eric Noel
	Internet-Draft AT&T Labs		Internet-Draft AT&T Labs
	Intended status: Standards Track Philip M Williams		Intended status: Standards Track Philip M Williams
	Expires: October 8, 2013 BT Innovate & Design		Expires: February 21, 2014 BT Innovate & Design
	April 8, 2013		August 21, 2013
	Session Initiation Protocol (SIP) Rate Control		Session Initiation Protocol (SIP) Rate Control
	draft-ietf-soc-overload-rate-control-04.txt		draft-ietf-soc-overload-rate-control-05.txt
	Abstract		Abstract
	The prevalent use of Session Initiation Protocol (SIP) [RFC3261] in		The prevalent use of Session Initiation Protocol (SIP) in Next
	Next Generation Networks necessitates that SIP networks provide		Generation Networks necessitates that SIP networks provide adequate
	adequate control mechanisms to maintain transaction throughput by		control mechanisms to maintain transaction throughput by preventing
	preventing congestion collapse during traffic overloads. Already		congestion collapse during traffic overloads. Already a loss-based
	[draft-ietf-soc-overload-control-12] proposes a loss-based solution		solution to remedy known vulnerabilities of the SIP 503 (service
	to remedy known vulnerabilities of the [RFC3261] SIP 503 (service		unavailable) overload control mechanism has been proposed. This
	unavailable) overload control mechanism. This document proposes a		document proposes a rate-based control scheme to complement the
	rate-based control solution to complement the loss-based control		loss-based control scheme, using the same signaling.
	defined in [draft-ietf-soc-overload-control-12].
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as		at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as "work in progress."		reference material or to cite them other than as "work in progress."
	This Internet-Draft will expire on October 8, 2013.		This Internet-Draft will expire on February 21, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 21 ¶		skipping to change at page 2, line 18 ¶
	document must include Simplified BSD License text as described in		document must include Simplified BSD License text as described in
	Section 4.e of the Trust Legal Provisions and are provided without		Section 4.e of the Trust Legal Provisions and are provided without
	warranty as described in the Simplified BSD License.		warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction...................................................2		1. Introduction...................................................2
	2. Terminology....................................................3		2. Terminology....................................................3
	3. Rate-based algorithm scheme....................................4		3. Rate-based algorithm scheme....................................4
	3.1. Overview..................................................4		3.1. Overview..................................................4
	3.2. Summary of via headers parameters for overload control....4		3.2. Via header field parameters for overload control..........4
	3.3. Client and server rate-control algorithm selection........5		3.3. Client and server rate-control algorithm selection........5
	3.4. Server operation..........................................5		3.4. Server operation..........................................5
	3.5. Client operation..........................................6		3.5. Client operation..........................................7
	3.5.1. Default algorithm....................................6		3.5.1. Default algorithm....................................7
	3.5.2. Optional enhancement: avoidance of resonance........10		3.5.2. Priority treatment..................................10
	4. Example.......................................................11		3.5.3. Optional enhancement: avoidance of resonance........11
	5. Syntax........................................................12		4. Example.......................................................13
	6. Security Considerations.......................................13		5. Syntax........................................................14
	7. IANA Considerations...........................................14		6. Security Considerations.......................................14
	8. References....................................................14		7. IANA Considerations...........................................15
	8.1. Normative References.....................................14		8. References....................................................16
	8.2. Informative References...................................14		8.1. Normative References.....................................16
	Appendix A. Contributors.........................................15		8.2. Informative References...................................16
	Appendix B. Acknowledgments......................................15		Appendix A. Contributors.........................................17
			Appendix B. Acknowledgments......................................17
	1. Introduction		1. Introduction
	The use of SIP in large scale Next Generation Networks requires that		The use of SIP in large scale Next Generation Networks requires that
	SIP based networks provide adequate control mechanisms for handling		SIP based networks provide adequate control mechanisms for handling
	traffic growth. In particular, SIP networks must be able to handle		traffic growth. In particular, SIP networks must be able to handle
	traffic overloads gracefully, maintaining transaction throughput by		traffic overloads gracefully, maintaining transaction throughput by
	preventing congestion collapse.		preventing congestion collapse.
	A promising SIP based overload control solution has been proposed in		A promising SIP based overload control solution has been proposed in
	[draft-ietf-soc-overload-control-12]. That solution provides a		[draft-ietf-soc-overload-control-13]. That solution provides a
	communication scheme for overload control algorithms. It also		communication scheme for overload control algorithms. It also
	includes a default loss-based overload control algorithm that makes		includes a default loss-based overload control algorithm that makes
	it possible for a set of clients to limit offered load towards an		it possible for a set of clients to limit offered load towards an
	overloaded server.		overloaded server.
	However, such loss control algorithm is sensitive to variations in		However, such loss control algorithm is sensitive to variations in
	load so that any increase in load would be directly reflected by the		load so that any increase in load would be directly reflected by the
	clients in the offered load presented to the overloaded servers.		clients in the offered load presented to the overloaded servers.
	More importantly, a loss-based control cannot guarantee clients to		More importantly, a loss-based control cannot guarantee clients to
	produce a bounded offered load from the clients towards an		produce a bounded offered load from the clients towards an
	overloaded server and requires frequent updates which may have		overloaded server and requires frequent updates which may have
	implications for stability.		implications for stability.
	This document proposes extensions to [draft-ietf-soc-overload-		This document proposes extensions to [draft-ietf-soc-overload-
	control-12] to support a rate-based control that guarantees an upper		control-13] to support a rate-based control that guarantees an upper
	bound on the rate, constant between server updates, of requests sent		bound on the rate, constant between server updates, of requests sent
	by clients towards an overloaded server.. The tradeoff is in terms		by clients towards an overloaded server. The tradeoff is in terms of
	of algorithmic complexity, since the overloaded server must estimate		algorithmic complexity, since the overloaded server is more likely
	a separate target for each client, rather than an overall loss		to use a different target (maximum rate) for each client, than the
	percentage, equally applicable to all clients.		loss approach.
	The proposed rate-based overload control algorithm mitigates		The proposed rate-based overload control algorithm mitigates
	congestion in SIP networks while adhering to the overload signaling		congestion in SIP networks while adhering to the overload signaling
	scheme in [draft-ietf-soc-overload-control-12] and presenting a rate		scheme in [draft-ietf-soc-overload-control-13] and presenting a rate
	based control as an optional alternative to the default loss-based		based control as an optional alternative to the default loss-based
	control in [draft-ietf-soc-overload-control-12].		control in [draft-ietf-soc-overload-control-13].
	2. Terminology		2. Terminology
	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 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	The normative statements in this specification as they apply to SIP		The normative statements in this specification as they apply to
	clients and SIP servers assume that both the SIP clients and SIP		clients and servers assume that both the clients and servers support
	servers support this specification. If, for instance, only a SIP		this specification. If, for instance, only a client supports this
	client supports this specification and not the SIP server, then		specification and not the server, then follows that the normative
	follows that the normative statements in this specification		statements in this specification pertinent to the behavior of a
	pertinent to the behavior of a SIP server do not apply to the server		server do not apply to the server that does not support this
	that does not support this specification.		specification.
	3. Rate-based algorithm scheme		3. Rate-based algorithm scheme
	3.1. Overview		3.1. Overview
	The server is what the overload control algorithm defined here		The server is the one protected by the overload control algorithm
	protects and the client is what throttles traffic towards the		defined here, and the client is the one that throttles traffic
	server.		towards the server.
	Following the procedures defined in [draft-ietf-soc-overload-		Following the procedures defined in [draft-ietf-soc-overload-
	control-12], the server and clients signal one another support for		control-13], the server and clients signal one another support for
	rate-based overload control.		rate-based overload control.
	Then periodically, the server relies on internal measurements (e.g.		Then periodically, the server relies on internal measurements (e.g.
	CPU utilization, queueing delay...) to evaluate its overload state		CPU utilization, queueing delay...) to evaluate its overload state
	and estimate a target SIP request rate (as opposed to target percent		and estimate a target SIP request rate in number of request per
	loss in the case of loss-based control).		second (as opposed to target percent loss in the case of loss-based
			control).
	When in overload, the server uses [draft-ietf-soc-overload-control-		When in overload, the server uses the Via header field oc parameters
	12] via header oc parameters of SIP responses to inform the clients		[draft-ietf-soc-overload-control-13] of SIP responses in order to
	of its overload state and of the target SIP request rate.		inform the clients of its overload state and of the target SIP
			request rate.
	Upon receiving the oc parameters with a target SIP request rate,		Upon receiving the oc parameters with a target SIP request rate,
	each client throttles new SIP requests towards the overloaded		each client throttles new SIP requests towards the overloaded
	server.		server.
	3.2. Summary of via headers parameters for overload control		3.2. Via header field parameters for overload control
	oc: Used by SIP clients to indicate draft-ietf-soc-overload-control-
	12 support and by SIP servers to indicate the load reduction amount.
	oc parameters defined in draft-ietf-soc-overload-control-12 are		oc parameters defined in [draft-ietf-soc-overload-control-13] are
	summarized below:		summarized below:
	oc-algo: Used by SIP clients to advertise supported overload control		oc: Used by clients in SIP requests to indicate [draft-ietf-soc-
	algorithms and by SIP servers to notify clients of algorithm in		overload-control-13] support and by servers to indicate the load
	effect. Support values: loss (default), rate (optional).		reduction amount.
	oc-validity: Used by SIP servers to indicate an interval of time		oc-algo: Used by clients in SIP requests to advertise supported
	(msec) that the load reduction should be in effect. A value of 0 is		overload control algorithms and by servers to notify clients of the
	reserved for server to stop overload control. A non-zero value is		algorithm in effect. Supported values: loss (default), rate
	required in conjunction with an "oc" parameter.		(optional).
			oc-validity: Used by servers in SIP responses to indicate an
			interval of time (msec) that the load reduction should be in effect.
			A value of 0 is reserved for server to stop overload control. A non-
			zero value is required in conjunction for all other cases.
	oc-seq: A sequence number associated with the "oc" parameter.		oc-seq: A sequence number associated with the "oc" parameter.
	The use of the via header oc parameter(s) inform of the desired		The use of the via header oc parameter(s) inform of the desired
	rate, but they don't explicitly ''inform clients of the overload		rate, but they don't explicitly "inform clients of the overload
	state''.		state".
	3.3. Client and server rate-control algorithm selection		3.3. Client and server rate-control algorithm selection
	Per [draft-ietf-soc-overload-control-12], new clients indicate		Per [draft-ietf-soc-overload-control-13], new clients indicate
	supported overload control algorithms to servers by inserting oc and		supported overload control algorithms to servers by inserting oc and
	oc-algo, with the names of the supported algorithms, in Via header		oc-algo, with the names of the supported algorithms, in Via header
	of SIP requests destined to servers. The inclusion by the client of		of SIP requests destined to servers. The inclusion by the client of
	the string ''rate'' indicates that the client supports a rate based		the string "rate" indicates that the client supports a rate based
	algorithm. Conversely, servers notify clients of selected overload		algorithm. Conversely, servers notify clients of the selected
	control algorithm through the oc-algo parameter in the Via header of		overload control algorithm through the oc-algo parameter in the Via
	SIP responses to clients. The inclusion by the server of the string		header of SIP responses to clients. The inclusion by the server of
	''rate'' indicates that the rate based algorithm has been selected by		the string "rate" in the oc-algo parameter indicates that the rate
	the server.		based algorithm has been selected by the server.
	Support of rate-based control MUST be indicated by clients setting		Support of rate-based control MUST be indicated by clients setting
	oc-algo to "rate". Selection of rate-based control MUST be indicated		oc-algo to "rate". Selection of rate-based control MUST be indicated
	by servers by setting oc-algo to ''rate''.		by servers by setting oc-algo to "rate".
	3.4. Server operation		3.4. Server operation
	The actual algorithm used by the server to determine its overload		The actual algorithm used by the server to determine its overload
	state and estimate a target SIP request rate is beyond the scope of		state and estimate a target SIP request rate is beyond the scope of
	this document.		this document.
	However, the server MUST be able to evaluate periodically its		However, the server MUST periodically evaluate its overload state
	overload state and estimate a target SIP request rate beyond which		and estimate a target SIP request rate beyond which it would become
	it would become overloaded. The server must allocate a portion of		overloaded. The server must allocate a portion of the target SIP
	the target SIP request rate to each of its client. The server may		request rate to each of its client. The server may set the same rate
	set the same rate for every client, or may set different rates for		for every client, or may set different rates for different clients.
	different clients.
	The max rate determined by the server for a client applies to the		The max rate determined by the server for a client applies to the
	entire stream of SIP requests, even though throttling may only		entire stream of SIP requests, even though throttling may only
	affect a particular subset of the requests, since as per [draft-		affect a particular subset of the requests, since as per [draft-
	ietf-soc-overload-control-12] and REQ 13 of RFC 5390, request		ietf-soc-overload-control-13] and REQ 13 of RFC 5390, request
	prioritization is the client responsibility. But when deriving this		prioritization is the client responsibility.
	rate the server may need to take into account characteristics of the
	requests, and the effect of the client prioritization on the load it
	receives, e.g. CPU utilization will depend upon the characteristics
	of the requests which would presumably allow the server to take in
	account prioritization.
	Note that the target SIP request rate is a max rate that may not be
	attained by the arrival rate at the client, and the server cannot
	assume that it will.
	Upon detection of overload, the server MUST follow the		When setting the maximum rate for a particular client, the server
	specifications in [draft-ietf-soc-overload-control-12] to notify its		may need take into account the workload (e.g. cpu load per request)
	clients of the allocated target SIP request rate.		of the distribution of message types from that client. Furthermore,
			because the client may prioritize the specific types of messages it
			sends while under overload restriction, this distribution of message
			types may be different from (e.g., either higher or lower cpu load)
			the message distribution for that client under non-overload
			conditions
	The server MUST use [draft-ietf-soc-overload-control-12] oc		Note that the oc parameter for the rate algorithm is an upper bound
			(in messages per second) on the traffic sent by the client to the
			server. The client may send traffic at a rate significantly lower
			than the upper bound, for a variety of reasons
			In other words, when multiple clients are being controlled by an
			overloaded server, at any given time some clients may receive
			requests at a rate below its target SIP request rate while others
			above that target rate. But the resulting request rate presented to
			the overloaded server will converge towards the target SIP request
			rate.
			Upon detection of overload, and the determination to invoke overload
			controls, the server MUST follow the specifications in [draft-ietf-
			soc-overload-control-13] to notify its clients of the allocated
			target SIP request rate.
			The server MUST use [draft-ietf-soc-overload-control-13] oc
	parameter to send a target SIP request rate to each of its clients.		parameter to send a target SIP request rate to each of its clients.
	3.5. Client operation		3.5. Client operation
	3.5.1. Default algorithm		3.5.1. Default algorithm
			In determining whether or not to transmit a specific message, the
			client may use any algorithm that limits the message rate to 1/T
			messages per second. It may be strictly deterministic, or it may be
			probabilistic. It may, or may not, have a tolerance factor, to allow
			for short bursts, as long as the long term rate remains below 1/T.
			The algorithm may have provisions for prioritizing traffic in
			accordance with REQ 13 of RFC5390.
			If the algorithm requires other parameters (in addition to "T",
			which is 1/oc), they may be set autonomously by the client, or they
			may be negotiated independently between client and server.
			In either case, the coordination is out of scope for this document.
			The default algorithms presented here (one without provisions for
			prioritizing traffic, one with) are only examples. Other algorithms
			that forward messages in conformance with the upper bound of 1/T
			messages per second may be used
	To throttle new SIP requests at the rate specified in the oc value		To throttle new SIP requests at the rate specified in the oc value
	sent by the server to its clients, the client MAY use the proposed		sent by the server to its clients, the client MAY use the proposed
	default algorithm for rate-based control or any other equivalent		default algorithm for rate-based control or any other equivalent
	algorithm.		algorithm.
	The default Leaky Bucket algorithm presented here is based on [ITU-T		The default Leaky Bucket algorithm presented here is based on [ITU-T
	Rec. I.371] Appendix A.2. The algorithm makes it possible for		Rec. I.371] Appendix A.2. The algorithm makes it possible for
	clients to deliver SIP requests at a rate specified in the oc value		clients to deliver SIP requests at a rate specified in the oc value
	with tolerance parameter TAU (preferably configurable).		with tolerance parameter TAU (preferably configurable).
	Conceptually, the Leaky Bucket algorithm can be viewed as a finite		Conceptually, the Leaky Bucket algorithm can be viewed as a finite
	capacity bucket whose real-valued content drains out at a continuous		capacity bucket whose real-valued content drains out at a continuous
	rate of 1 unit of content per time unit and whose content increases		rate of 1 unit of content per time unit and whose content increases
	by the increment T for each forwarded SIP request. T is computed as		by the increment T for each forwarded SIP request. T is computed as
	the inverse of the rate specified in the oc value, namely T = 1 /		the inverse of the rate specified in the oc value, namely T = 1 /
	oc-value.		oc-value.
	Note that when the oc-value is 0 with a non-zero oc-validity, then		Note that when the oc-value is 0 with a non-zero oc-validity, then
	the client should reject 100% of SIP requests destined to the		the client should reject 100% of SIP requests destined to the
	overload server. However, when both oc-value and oc-validity are 0,		overload server. However, when the oc-validity value is 0, the
	the client should immediately stop throttling.		client should immediately stop throttling.
	If at a new SIP request arrival the content of the bucket is less		If, at a new SIP request arrival, the content of the bucket is less
	than or equal to the limit value TAU, then the SIP request is		than or equal to the limit value TAU, then the SIP request is
	forwarded to the server; otherwise, the SIP request is rejected.		forwarded to the server; otherwise, the SIP request is rejected.
	Note that the capacity of the bucket (the upper bound of the		Note that the capacity of the bucket (the upper bound of the
	counter) is (T + TAU).		counter) is (T + TAU).
	The tolerance parameter TAU determines how close the long-term		The tolerance parameter TAU determines how close the long-term
	admitted rate is to an ideal control that would admit all SIP		admitted rate is to an ideal control that would admit all SIP
	requests for arrival rates less than 1/T and then admit SIP requests		requests for arrival rates less than 1/T and then admit SIP requests
	precisely rate at 1/T for arrival rates above 1/T. In particular at		precisely at the rate of 1/T for arrival rates above 1/T. In
	mean arrival rates close to 1/T, it determines the tolerance to		particular at mean arrival rates close to 1/T, it determines the
	deviation of the inter-arrival time from T (the larger TAU the more		tolerance to deviation of the inter-arrival time from T (the larger
	tolerance to deviations from the inter-departure interval T).		TAU the more tolerance to deviations from the inter-departure
			interval T).
	This deviation from the inter-departure interval influences the		This deviation from the inter-departure interval influences the
	admitted rate burstyness, or the number consecutive SIP requests		admitted rate burstyness, or the number of consecutive SIP requests
	forwarded to the SIP server (burst size proportional to TAU over the		forwarded to the server (burst size proportional to TAU over the
	difference between 1/T and the arrival rate).		difference between 1/T and the arrival rate).
	SIP servers with a very large number of clients, each with a		Servers with a very large number of clients, each with a relatively
	relatively small arrival rate, will generally benefit from a smaller		small arrival rate, will generally benefit from a smaller value for
	value for TAU in order to limit queuing (and hence response times)		TAU in order to limit queuing (and hence response times) at the
	at the server when subjected to a sudden surge of traffic from all		server when subjected to a sudden surge of traffic from all clients.
	clients. Conversely, a SIP server with a relatively small number of		Conversely, a server with a relatively small number of clients, each
	clients, each with proportionally larger arrival rate, will benefit		with proportionally larger arrival rate, will benefit from a larger
	from a larger value of TAU.		value of TAU.
	At the arrival time of the k-th new SIP request ta(k) after control		Once the control has been activated, at the arrival time of the k-th
	has been activated, the content of the bucket is provisionally		new SIP request, ta(k), the content of the bucket is provisionally
	updated to the value		updated to the value
	X' = X - ([ta(k) - LCT])		X' = X - (ta(k) - LCT)
	where X is the content of the bucket after arrival of the last		where X is the value of the leaky bucket counter after arrival of
	forwarded SIP request, and LCT is the time at which the last SIP		the last forwarded SIP request, and LCT is the time at which the
	request was forwarded.		last SIP request was forwarded.
	If X' is less than or equal to the limit value TAU, then the new SIP		If X' is less than or equal to the limit value TAU, then the new SIP
	request is forwarded and the bucket content X is set to X' (or to 0		request is forwarded and the leaky bucket counter X is set to X' (or
	if X' is negative) plus the increment T, and LCT is set to the		to 0 if X' is negative) plus the increment T, and LCT is set to the
	current time ta(k). If X' is greater than the limit value TAU, then		current time ta(k). If X' is greater than the limit value TAU, then
	the new SIP request is rejected and the values of X and LCT are		the new SIP request is rejected and the values of X and LCT are
	unchanged.		unchanged.
	When the first response from the server has been received indicating		When the first response from the server has been received indicating
	control activation (oc-validity>0), LCT is set to the time of		control activation (oc-validity>0), LCT is set to the time of
	activation, and the occupancy of the bucket is initialized to the		activation, and the leaky bucket counter is initialized to the
	parameter TAU0 (preferably configurable) which is 0 or larger but		parameter TAU0 (preferably configurable) which is 0 or larger but
	less than or equal to TAU.		less than or equal to TAU.
	Following [draft-ietf-soc-overload-control-12], the client is		TAU can assume any positive real number value and is not necessarily
			bounded by T.
			TAU=4*T is a reasonable compromise between burst size and throttled
			rate adaptation at low offered rate.
			Note that specification of a value for TAU, and any communication or
			coordination between servers, is beyond the scope of this document.
			A reference algorithm is shown below.
			No priority case:
			// T: inter-transmission interval, set to 1 / TargetRate
			// TAU: tolerance parameter
			// ta: arrival time of the most recent arrival
			// LCT: arrival time of last SIP request that was sent to the server
			// (initialized to the first arrival time)
			// X: current value of the leaky bucket counter (initialized to
			// TAU0)
			// After most recent arrival, calculate auxiliary variable Xp
			Xp = X - (ta - LCT);
			if (Xp <= TAU) {
			// Transmit SIP request
			// Update X and LCT
			X = max (0, Xp) + T;
			LCT = ta;
			} else {
			// Reject SIP request
			// Do not update X and LCT
			}
			3.5.2. Priority treatment
			Following [draft-ietf-soc-overload-control-13], the client is
	responsible for message priority and for maintaining two categories		responsible for message priority and for maintaining two categories
	of requests: Requests candidate for reduction, requests not subject		of requests: Requests candidate for reduction, requests not subject
	to reduction (except under extenuating circumstances when there		to reduction (except under extenuating circumstances when there
	aren't any messages in the first category that can be reduced).		aren't any messages in the first category that can be reduced).
	Accordingly, the proposed Leaky bucket implementation is modified to		Accordingly, the proposed Leaky bucket implementation is modified to
	support priority using two thresholds for SIP requests in the set of		support priority using two thresholds for SIP requests in the set of
	requests candidate for reduction. With two priorities, the proposed		requests candidate for reduction. With two priorities, the proposed
	Leaky bucket requires two thresholds TAU1 < TAU2:		Leaky bucket requires two thresholds TAU1 < TAU2:
	. All new requests would be admitted when the bucket fill is at		. All new requests would be admitted when the leaky bucket
	or below TAU1,		counter is at or below TAU1,
	. Only higher priority requests would be admitted when the bucket		. Only higher priority requests would be admitted when the leaky
	fill is between TAU1 and TAU2,		bucket counter is between TAU1 and TAU2,
	. All requests would be rejected when the bucket fill is above		. All requests would be rejected when the bucket counter is above
	TAU2.		TAU2.
	This can be generalized to n priorities using n thresholds for n>2		This can be generalized to n priorities using n thresholds for n>2
	in the obvious way.		in the obvious way.
	With a priority scheme that relies on two tolerance parameters (TAU2		With a priority scheme that relies on two tolerance parameters (TAU2
	influences the priority traffic, TAU1 influences the non-priority		influences the priority traffic, TAU1 influences the non-priority
	traffic), always set TAU1 <= TAU2 (TAU is replaced by TAU1 and		traffic), always set TAU1 <= TAU2 (TAU is replaced by TAU1 and
	TAU2). Setting both tolerance parameters to the same value is		TAU2). Setting both tolerance parameters to the same value is
	equivalent to having no priority. TAU1 influences the admitted rate		equivalent to having no priority. TAU1 influences the admitted rate
	the same way as TAU does when no priority are set. And the larger		the same way as TAU does when no priority is set. And the larger the
	the difference between TAU1 and TAU2, the closer to the control is		difference between TAU1 and TAU2, the closer the control is to
	to strict priority.		strict priority queueing.
	TAU (or TAU1 and TAU2) can assume any positive real number value and
	is not necessarily bounded by T.
	Note that specification of a value for TAU is beyond the scope of
	this document.
	A reference algorithm is shown below.
	No priority case:		TAU1 and TAU2 can assume any positive real number value and is not
			necessarily bounded by T.
	// T: emission interval, set to 1 / TargetRate		Reasonable values for TAU0, TAU1 & TAU2 are: TAU0 = 0, TAU1 = 1/2 *
	// TAU: tolerance parameter		TAU2 and TAU2 = 10 * T.
	// ta: arrival time of last arrival
	// LCT: arrival time of last conforming SIP request (initialized to
	// the first arrival time)
	// X: current value of leaky bucket counter (initialized to 0)
	// After first arrival, calculate auxiliary variable Xp		Note that specification of a value for TAU1 and TAU2, and any
	Xp = X - (ta - LCT);		communication or coordination between servers, is beyond the scope
			of this document.
	if (Xp <= TAU) {		A reference algorithm is shown below.
	// Accept SIP request
	// Update X and LCT
	X = max(0,Xp) + T;
	LCT = ta;
	} else {
	// Reject SIP request
	// Do not update X and LCT
	}
	Priority case:		Priority case:
	// T: emission interval, set to 1 / TargetRate		// T: inter-transmission interval, set to 1 / TargetRate
	// TAU1: tolerance parameter of no priority SIP requests		// TAU1: tolerance parameter of no priority SIP requests
	// TAU2: tolerance parameter of priority SIP requests		// TAU2: tolerance parameter of priority SIP requests
	// ta: arrival time of last arrival		// ta: arrival time of the most recent arrival
	// LCT: arrival time of last conforming SIP request (initialized to		// LCT: arrival time of last SIP request that was sent to the server
	// the first arrival time)		// (initialized to the first arrival time)
	// X: current value of leaky bucket counter (initialized to 0)		// X: current value of the leaky bucket counter (initialized to
			// TAU0)
	// After first arrival, calculate auxiliary variable Xp		// After most recent arrival, calculate auxiliary variable Xp
	Xp = X - (ta - LCT);		Xp = X - (ta - LCT);
	if (AnyRequestReceived && Xp <= TAU1 || PriorityRequestReceived &&
			if (AnyRequestReceived && Xp <= TAU1) || (PriorityRequestReceived &&
	Xp <= TAU2 && Xp > TAU1) {		Xp <= TAU2 && Xp > TAU1) {
	// Accept SIP request		// Transmit SIP request
	// Update X and LCT		// Update X and LCT
	X = max(0,Xp) + T;		X = max (0, Xp) + T;
	LCT = ta;		LCT = ta;
	} else {		} else {
	// Reject SIP request		// Reject SIP request
	// Do not update X and LCT		// Do not update X and LCT
	}		}
	3.5.2. Optional enhancement: avoidance of resonance		3.5.3. Optional enhancement: avoidance of resonance
	As the number of client sources of traffic increases and the		As the number of client sources of traffic increases and the
	throughput of the server decreases, the maximum rate admitted by		throughput of the server decreases, the maximum rate admitted by
	each client needs to decrease, and therefore the value of T becomes		each client needs to decrease, and therefore the value of T becomes
	larger. Under some circumstances, e.g. if the traffic arises very		larger. Under some circumstances, e.g. if the traffic arises very
	quickly simultaneously at many sources, the occupancies of each		quickly simultaneously at many sources, the occupancies of each
	bucket can become synchronized, resulting in the admissions from		bucket can become synchronized, resulting in the admissions from
	each source being close in time and batched or very 'peaky' arrivals		each source being close in time and batched or very 'peaky' arrivals
	at the server, which not only gives rise to control instability, but		at the server, which not only gives rise to control instability, but
	also very poor delays and even lost messages. An appropriate term		also very poor delays and even lost messages. An appropriate term
	for this is 'resonance' [Erramilli].		for this is 'resonance' [Erramilli].
	If the network topology is such that this can occur, then a simple		If the network topology is such that this can occur, then a simple
	way to avoid this is to randomize the bucket occupancy at two		way to avoid this is to randomize the bucket occupancy at two
	appropriate points: At the activation of control, and whenever the		appropriate points: At the activation of control, and whenever the
	bucket empties, as follows.		bucket empties, as follows.
	After updating the bucket occupancy to X', generate a value u as		After updating the value of the leaky bucket to X', generate a value
	follows:		u as follows:
	if X' > 0, then u=0		if X' > 0, then u=0
	else if X' <= 0 then uniformly distributed between -1/2 and +1/2		else if X' <= 0 then uniformly distributed between -1/2 and +1/2
	Then (only) if the arrival is admitted, increase the bucket by an		Then (only) if the arrival is admitted, increase the bucket by an
	amount T + uT, which will therefore be just T if the bucket hadn't		amount T + uT, which will therefore be just T if the bucket hadn't
	emptied, or lie between T/2 and 3T/2 if it had.		emptied, or lie between T/2 and 3T/2 if it had.
	This randomization should also be done when control is activated,		This randomization should also be done when control is activated,
	i.e. instead of simply initializing the bucket fill to TAU0,		i.e. instead of simply initializing the leaky bucket counter to
	initialize it to TAU0 + uT, where u is uniformly distributed as		TAU0, initialize it to TAU0 + uT, where u is uniformly distributed
	above. Since activation would have been a result of response to a		as above. Since activation would have been a result of response to a
	request sent by the client, the second term in this expression can		request sent by the client, the second term in this expression can
	be interpreted as being the bucket increment following that		be interpreted as being the bucket increment following that
	admission.		admission.
	This method has the following characteristics:		This method has the following characteristics:
	. If TAU0 is chosen to be equal to TAU and all sources were to		. If TAU0 is chosen to be equal to TAU and all sources were to
	activate control at the same time due to an extremely high		activate control at the same time due to an extremely high
	request rate, then the time until the first request admitted by		request rate, then the time until the first request admitted by
	each client would be uniformly distributed over [0,T];		each client would be uniformly distributed over [0,T];
	skipping to change at page 11, line 28 ¶		skipping to change at page 13, line 11 ¶
	minimum time between admissions is uniformly distributed over		minimum time between admissions is uniformly distributed over
	[T/2, 3T/2], and the mean time between admissions is the same,		[T/2, 3T/2], and the mean time between admissions is the same,
	i.e. T+1/R where R is the request arrival rate;		i.e. T+1/R where R is the request arrival rate;
	. At high load randomization rarely occurs, so there is no loss		. At high load randomization rarely occurs, so there is no loss
	of precision of the admitted rate, even though the randomized		of precision of the admitted rate, even though the randomized
	'phasing' of the buckets remains.		'phasing' of the buckets remains.
	4. Example		4. Example
	Adapting [draft-ietf-soc-overload-control-12] example in section 6.2		Adapting [draft-ietf-soc-overload-control-13] example in section 6.2
	where SIP client P1 sends requests to a downstream server P2:		where client P1 sends requests to a downstream server P2:
	INVITE sips:user@example.com SIP/2.0		INVITE sips:user@example.com SIP/2.0
	Via: SIP/2.0/TLS p1.example.net;		Via: SIP/2.0/TLS p1.example.net;
	branch=z9hG4bK2d4790.1;received=192.0.2.111;		branch=z9hG4bK2d4790.1;received=192.0.2.111;
	oc;oc-algo="loss,rate"		oc;oc-algo="loss,rate"
	...		...
	SIP/2.0 100 Trying		SIP/2.0 100 Trying
	Via: SIP/2.0/TLS p1.example.net;		Via: SIP/2.0/TLS p1.example.net;
	branch=z9hG4bK2d4790.1;received=192.0.2.111;		branch=z9hG4bK2d4790.1;received=192.0.2.111;
	oc-algo="rate";oc-validity=0;		oc=0;oc-algo="rate";oc-validity=0;
	oc-seq=1282321615.781		oc-seq=1282321615.781
	...		...
	In the messages above, the first line is sent by P1 to P2. This		In the messages above, the first line is sent by P1 to P2. This
	line is a SIP request; because P1 supports overload control, it		line is a SIP request; because P1 supports overload control, it
	inserts the "oc" parameter in the topmost Via header that it		inserts the "oc" parameter in the topmost Via header that it
	created. P1 supports two overload control algorithms: loss and rate.		created. P1 supports two overload control algorithms: loss and rate.
	The second line --- a SIP response --- shows the top most Via header		The second line --- a SIP response --- shows the top most Via header
	amended by P2 according to this specification and sent to P1.		amended by P2 according to this specification and sent to P1.
	Because P2 also supports overload control, it chooses the ''rate''		Because P2 also supports overload control, it chooses the "rate"
	based scheme and sends that back to P1 in the ''oc-algo'' parameter.		based scheme and sends that back to P1 in the "oc-algo" parameter.
	It uses oc-validity=0 to indicate no overload.		It uses oc-validity=0 to indicate no overload control.
	At some later time, P2 starts to experience overload. It sends the		At some later time, P2 starts to experience overload. It sends the
	following SIP message indicating P1 should send SIP requests at a		following SIP message indicating P1 should send SIP requests at a
	rate no greater than or equal to 150 SIP requests per seconds.		rate no greater than or equal to 150 SIP requests per seconds and
			for a duration of 1,000 msec.
	SIP/2.0 180 Ringing		SIP/2.0 180 Ringing
	Via: SIP/2.0/TLS p1.example.net;		Via: SIP/2.0/TLS p1.example.net;
	branch=z9hG4bK2d4790.1;received=192.0.2.111;		branch=z9hG4bK2d4790.1;received=192.0.2.111;
	oc=150;oc-algo="rate";oc-validity=1000;		oc=150;oc-algo="rate";oc-validity=1000;
	oc-seq=1282321615.782		oc-seq=1282321615.782
	...		...
	5. Syntax		5. Syntax
	This specification extends the existing definition of the Via header		This specification extends the existing definition of the Via header
	field parameters of [RFC3261] as follows:		field parameters of [RFC3261] as follows:
	oc = "oc" EQUAL oc-value		algo-list /= "rate"
	oc-value = "NaN" / oc-num
	oc-num = 1*DIGIT
	6. Security Considerations		6. Security Considerations
	For completeness, draft-ietf-soc-overload-control-12 Security		For completeness, [draft-ietf-soc-overload-control-13] Security
	Considerations section is repeated here.		Considerations section is repeated here.
	Overload control mechanisms can be used by an attacker to conduct a		Overload control mechanisms can be used by an attacker to conduct a
	denial-of-service attack on a SIP entity if the attacker can pretend		denial-of-service attack on a SIP entity if the attacker can pretend
	that the SIP entity is overloaded. When such a forged overload		that the SIP entity is overloaded. When such a forged overload
	indication is received by an upstream SIP client, it will stop		indication is received by an upstream client, it will stop sending
	sending traffic to the victim. Thus, the victim is subject to a		traffic to the victim. Thus, the victim is subject to a denial-of-
	denial-of-service attack.		service attack.
	An attacker can create forged overload feedback by inserting itself		An attacker can create forged overload feedback by inserting itself
	into the communication between the victim and its upstream		into the communication between the victim and its upstream
	neighbors. The attacker would need to add overload feedback		neighbors. The attacker would need to add overload feedback
	indicating a high load to the responses passed from the victim to		indicating a high load to the responses passed from the victim to
	its upstream neighbor. Proxies can prevent this attack by		its upstream neighbor. Proxies can prevent this attack by
	communicating via TLS. Since overload feedback has no meaning beyond		communicating via TLS. Since overload feedback has no meaning beyond
	the next hop, there is no need to secure the communication over		the next hop, there is no need to secure the communication over
	multiple hops.		multiple hops.
	skipping to change at page 14, line 7 ¶		skipping to change at page 15, line 32 ¶
	The solution to this problem depends on the overload control method.		The solution to this problem depends on the overload control method.
	For rate-based and window-based overload control, it is very easy		For rate-based and window-based overload control, it is very easy
	for a downstream entity to monitor if the upstream neighbor		for a downstream entity to monitor if the upstream neighbor
	throttles traffic forwarded as directed. For percentage throttling		throttles traffic forwarded as directed. For percentage throttling
	this is not always obvious since the load forwarded depends on the		this is not always obvious since the load forwarded depends on the
	load received by the upstream neighbor.		load received by the upstream neighbor.
	7. IANA Considerations		7. IANA Considerations
	None.		Header Field Parameter Name Predefined Values Reference
			_______________________________________________________
			Via oc-algo Yes RFCABCD RFCOPRQ
			RFCABCD RFCOPRQ [NOTE TO RFC-EDITOR: Please replace with final RFC
			number of draft-ietf-soc-overload-rate-control & draft-ietf-soc-
			overload-control]
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	June 2002.		June 2002.
	[RFC5390] Rosenberg, J., "Requirements for Management of Overload in		[RFC5390] Rosenberg, J., "Requirements for Management of Overload in
	the Session Initiation Protocol", RFC 5390, December 2008.		the Session Initiation Protocol", RFC 5390, December 2008.
	8.2. Informative References		8.2. Informative References
	[draft-ietf-soc-overload-control-12]		[draft-ietf-soc-overload-control-13]
	Gurbani, V., Hilt, V., Schulzrinne, H., "Session		Gurbani, V., Hilt, V., Schulzrinne, H., "Session
	Initiation Protocol (SIP) Overload Control", draft-ietf-		Initiation Protocol (SIP) Overload Control", draft-ietf-
	soc-overload-control-12.		soc-overload-control-13.
	[ITU-T Rec. I.371]		[ITU-T Rec. I.371]
	"Traffic control and congestion control in B-ISDN", ITU-T		"Traffic control and congestion control in B-ISDN", ITU-T
	Recommendation I.371.		Recommendation I.371.
	[Erramilli]		[Erramilli]
	A. Erramilli and L. J. Forys, "Traffic Synchronization		A. Erramilli and L. J. Forys, "Traffic Synchronization
	Effects In Teletraffic Systems", ITC-13, 1991.		Effects In Teletraffic Systems", ITC-13, 1991.
	Appendix A. Contributors		Appendix A. Contributors
	Significant contributions to this document were made by Janet Gunn.		Significant contributions to this document were made by Janet Gunn.
	Appendix B. Acknowledgments		Appendix B. Acknowledgments
	Many thanks for comments and feedback on this document to: Volker		Many thanks for comments and feedback on this document to: Keith
	Hilt.		Drage, Vijay Gurbany, Volker Hilt, Christer Holmberg, Winston Hong,
			James Yu.
	This document was prepared using 2-Word-v2.0.template.dot.		This document was prepared using 2-Word-v2.0.template.dot.
	Authors' Addresses		Authors' Addresses
	Eric Noel		Eric Noel
	AT&T Labs		AT&T Labs
	200s Laurel Avenue		200s Laurel Avenue
	Middletown, NJ, 07747		Middletown, NJ, 07747
	USA		USA
	Philip M Williams		Philip M Williams
	BT Innovate & Design		BT Innovate & Design
			Ipswich, IP5 3RE
	UK		UK
End of changes. 70 change blocks.
	193 lines changed or deleted		258 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/