SIPPING Working Group V. Hilt
Internet-Draft I. Widjaja
Expires: September 4, 2007 Bell Labs/Alcatel-Lucent
D. Malas
Level 3 Communications
H. Schulzrinne
Columbia University
March 3, 2007
Session Initiation Protocol (SIP) Overload Control
draft-hilt-sipping-overload-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 4, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Overload occurs in Session Initiation Protocol (SIP) networks when
SIP servers have insufficient resources to handle all SIP messages
they receive. Even though the SIP protocol provides a limited
overload control mechanism through its 503 response code, SIP servers
Hilt, et al. Expires September 4, 2007 [Page 1]
Internet-Draft Overload Control March 2007
are still vulnerable to overload. This document proposes several new
overload control mechanisms for the SIP protocol.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Design Considerations . . . . . . . . . . . . . . . . . . . . 4
3.1. System Model . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Hop-by-Hop vs. End-to-End . . . . . . . . . . . . . . . . 5
3.3. Topologies . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Overload Control Method . . . . . . . . . . . . . . . . . 9
3.4.1. Rate-based Overload Control . . . . . . . . . . . . . 9
3.4.2. Loss-based Overload Control . . . . . . . . . . . . . 10
3.4.3. Window-based Overload Control . . . . . . . . . . . . 10
3.5. Overload Control Algorithms . . . . . . . . . . . . . . . 11
3.5.1. Increase Algorithm . . . . . . . . . . . . . . . . . . 12
3.5.2. Decrease Algorithm . . . . . . . . . . . . . . . . . . 12
3.6. Load Status . . . . . . . . . . . . . . . . . . . . . . . 12
3.7. SIP Mechanism . . . . . . . . . . . . . . . . . . . . . . 13
3.8. Backwards Compatibility . . . . . . . . . . . . . . . . . 13
3.9. Interaction with Local Overload Control . . . . . . . . . 14
4. SIP Application Considerations . . . . . . . . . . . . . . . . 14
4.1. How to Calculate Load Levels . . . . . . . . . . . . . . . 14
4.2. Responding to an Overload Indication . . . . . . . . . . . 15
4.3. Emergency Services Requests . . . . . . . . . . . . . . . 15
4.4. Operations and Management . . . . . . . . . . . . . . . . 16
5. SIP Load Header Field . . . . . . . . . . . . . . . . . . . . 16
5.1. Generating the Load Header . . . . . . . . . . . . . . . . 16
5.2. Determining the Load Header Value . . . . . . . . . . . . 17
5.3. Determining the Throttle Parameter Value . . . . . . . . . 17
5.4. Processing the Load Header . . . . . . . . . . . . . . . . 18
5.5. Using the Load Header Value . . . . . . . . . . . . . . . 19
5.6. Using the Throttle Parameter Value . . . . . . . . . . . . 19
5.7. Rejecting Requests . . . . . . . . . . . . . . . . . . . . 20
6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 25
Hilt, et al. Expires September 4, 2007 [Page 2]
Internet-Draft Overload Control March 2007
1. Introduction
As with any network element, a Session Initiation Protocol (SIP) [2]
server can suffer from overload when the number of SIP messages it
receives exceeds the number of messages it can process. SIP server
overload can pose a serious problem. During periods of overload, the
throughput of a SIP network can be significantly degraded. In
particular, SIP server overload may lead to a situation in which the
throughput drops to a small fraction of the original capacity of the
network. This is often called congestion collapse.
The SIP protocol provides a limited mechanism for overload control
through its 503 response code. However, this mechanism cannot
prevent SIP server overload and it cannot prevent congestion collapse
in a network of SIP servers. In fact, the 503 response code
mechanism may cause traffic to move back and forth between SIP
servers and thereby worsen an overload condition. A detailed
discussion of the SIP overload problem, the 503 response code and the
requirements for a SIP overload control solution can be found in [5].
Overload is said to occur if a SIP server does not have sufficient
resources to process all incoming SIP messages. These resources may
include CPU processing capacity, memory, network bandwidth, input/
output, or disk resources. Generally speaking, overload occurs if a
SIP server can no longer process or respond to all incoming SIP
messages.
We only consider failure cases where SIP servers cannot process all
incoming SIP requests. There are other failure cases where the SIP
server can process, but not fulfill, requests. These are beyond the
scope of this document since SIP provides other response codes for
these cases and overload control MUST NOT be used to handle these
scenarios. For example, a PSTN gateway that runs out of trunk lines
but still has plenty of capacity to process SIP messages should
reject incoming INVITEs using a 488 (Not Acceptable Here) response
[4]. Similarly, a SIP registrar that has lost connectivity to its
registration database but is still capable of processing SIP messages
should reject REGISTER requests with a 500 (Server Error) response
[2].
This specification is structured as follows: Section 3 discusses
general design principles of an SIP overload control mechanism.
Section 4 discusses general considerations for applying SIP overload
control. Section 5 defines a SIP protocol extension for overload
control and Section 6 introduces the syntax of this extension.
Section 7 and Section 8 discuss security and IANA considerations
respectively.
Hilt, et al. Expires September 4, 2007 [Page 3]
Internet-Draft Overload Control March 2007
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [1] and indicate requirement levels for
compliant implementations.
3. Design Considerations
This section discusses key design considerations for a SIP overload
control mechanism. The goal for this mechanism is to prevent
upstream servers to send SIP messages to an overloaded downstream
server, rather than rejecting messages already sent at the overloaded
server.
3.1. System Model
The model shown in Figure 1 identifies fundamental components of an
SIP overload control system:
o SIP Processor: component that processes SIP messages. The SIP
processor is the component that is protected by overload control.
o Monitor: component that monitors the current load of the SIP
processor on the receiving entity. The monitor implements the
mechanisms needed to measure the current usage of resources
relevant for the SIP processor. It reports load samples (S) to
the Control Function.
o Control Function: component that implements the actual overload
control mechanism on the receiving and sending entity. The
control function uses the load samples (S) provided by the
monitor. It determines if overload has occurred and a throttle
(T) needs to be set to adjust the load sent to the SIP processor
on the receiving entity. The control function on the receiving
entity sends load feedback (F) to the control function sending
entity.
o Actuator: component that acts on the throttles (T) generated by
the control function and adjust the load forwarded to the
receiving entity accordingly. For example, a throttle may
instruct the actuator to reduce the load destined to the receiving
entity by 10%. The actuator decides how the load reduction is
achieved (e.g., by redirecting or rejecting requests).
The type of feedback (F) conveyed from the receiving to the sending
entity depends on the overload control method used (i.e., rate-based
vs. window-based overload control; see Section 3.4.3) as well as
other design parameters (e.g., whether load status information is
Hilt, et al. Expires September 4, 2007 [Page 4]
Internet-Draft Overload Control March 2007
included or not). In any case, the feedback (F) informs the sending
entity that overload has occurred and that the traffic forward to the
receiving entity needs to be reduced to a lower rate.
Sending Receiving
Entity Entity
+----------------+ +----------------+
| Server A | | Server B |
| +----------+ | | +----------+ | -+
| | Control | | F | | Control | | |
| | Function |<-+------+--| Function | | |
| +----------+ | | +----------+ | |
| T | | | ^ | | Overload
| v | | | S | | Control
| +----------+ | | +----------+ | |
| | Actuator | | | | Monitor | | |
| +----------+ | | +----------+ | |
| | | | ^ | -+
| v | | | | -+
| +----------+ | | +----------+ | |
<-+--| SIP | | | | SIP | | | SIP
--+->|Processor |--+------+->|Processor |--+-> | System
| +----------+ | | +----------+ | |
+----------------+ +----------------+ -+
Figure 1: System Model for Overload Control
3.2. Hop-by-Hop vs. End-to-End
A SIP request is often processed by more than one SIP server. Thus,
overload control can in theory be applied hop-by-hop, i.e.,
individually between each pair of servers, or end-to-end as a single
control loop that stretches across the entire path from UAC to UAS
(see Figure 2).
Hilt, et al. Expires September 4, 2007 [Page 5]
Internet-Draft Overload Control March 2007
+---------+ +-------+----------+
+------+ | | | ^ |
| | | +---+ | | +---+
v | v //=>| C | v | //=>| C |
+---+ +---+ // +---+ +---+ +---+ // +---+
| A |===>| B | | A |===>| B |
+---+ +---+ \\ +---+ +---+ +---+ \\ +---+
^ \\=>| D | ^ | \\=>| D |
| +---+ | | +---+
| | | v |
+---------+ +-------+----------+
(a) hop-by-hop loop (b) end-to-end loop
==> SIP request flow
<-- Load feedback loop
Figure 2: Hop-by-Hop vs. End-to-End
In the hop-by-hop model, a separate overload control loop is
instantiated between each pair of neighboring SIP servers on the path
of a SIP request. Each SIP server provides load feedback to its
upstream neighbors, which then adjust the amount of traffic they are
forwarding to the SIP server. However, the neighbors do not forward
the received feedback information further upstream. Instead, they
act on the feedback and resolve the overload condition if needed, for
example, by re-routing or rejecting traffic.
The upstream neighbor of a server can, and should, use a separate
overload control loop with its upstream neighbors. If the neighbor
becomes overloaded, it will report this problem to its upstream
neighbors, which again take action based on the reported feedback.
Thus, in hop-by-hop overload control, overload is resolved by the
direct upstream neighbors of the overloaded server without the need
to involve entities that are located multiple SIP hops away.
Hop-by-hop overload control can effectively reduce the impact of
overload on a SIP network and, in particular, can avoid congestion
collapse. In addition, hop-by-hop overload control is simple and
scales well to networks with many SIP entities. It does not require
a SIP entity to aggregate a large number of load status values or
keep track of the load status of SIP servers it is not communicating
with.
End-to-end overload control implements an overload control loop along
the entire path of a SIP request, from UAC to UAS. An end-to-end
overload control mechanism needs to consider load information from
Hilt, et al. Expires September 4, 2007 [Page 6]
Internet-Draft Overload Control March 2007
all SIP servers on the way (including all proxies and the UAS). It
has to be able to frequently collect the load status of all servers
on the potential path(s) to a destination and combine this data into
meaningful load feedback. A UA or SIP server should not throttle its
load unless it knows that all potential paths to the destination are
overloaded.
Overall, the main problem of end-to-end path overload control is its
inherent complexity since a UAC or SIP server would need to monitor
all potential paths to a destination in order to know when to
throttle. Therefore, end-to-end overload control is likely to only
work if a UA/server sends lots of requests to the exact same
destination.
3.3. Topologies
A simple topology for overload control is a SIP server that receives
traffic from a single source (as shown in Figure 3(a)). A load
balancer is a typical example for this configuration. In more
complex topology, a SIP server receives traffic from multiple
upstream sources. This is shown in Figure 3(b), where SIP servers A,
B and C forward traffic to server D. It is important to note that
each of these servers may contribute a different amount of load to
the overall load of D. This load mix may vary over time. If server D
becomes overloaded, it generates feedback to reduce the amount of
traffic it receives from its upstream neighbors (i.e., A or A, B and
C respectively).
If a SIP server (server D) becomes overloaded, it needs to decide how
overload control feedback is balanced across upstream neighbors.
This decision needs to account for the actual amount of traffic
received from an upstream neighbor. The decision may need to be re-
adjusted as the load contributed by each upstream neighbor varies
over time. A server may use a local policy to decide how much load
it wants to receive from each upstream neighbor. For example, a
server may throttle all upstream sources equally (e.g., all sources
need to reduce traffic forwarded by 10%) or to prefer some servers
over others. For example, it may want to throttle a less preferred
upstream neighbor earlier than a preferred neighbor or throttle the
neighbor first that sends the most traffic. Since this decision is
made by the receiving entity (i.e., server D), all senders for this
entity are governed by the same overload control algorithm.
In many network configurations, upstream servers (A, B and C) have
alternative servers (server E) to which they can redirect excess
messages if the primary target (server D) is overloaded (see
Figure 3(c)). Servers D and E may differ in their processing
capacity. When redirecting messages, the upstream servers need to
Hilt, et al. Expires September 4, 2007 [Page 7]
Internet-Draft Overload Control March 2007
ensure that these messages do not overload the alternate server. An
overload control mechanism should enables upstream servers to only
choose alternative servers that have enough capacity to handle the
redirected requests.
+---+ +---+
/->| D | | A |-\
/ +---+ +---+ \
/ \ +---+
+---+-/ +---+ +---+ \->| |
| A |------>| E | | B |------>| D |
+---+-\ +---+ +---+ /->| |
\ / +---+
\ +---+ +---+ /
\->| F | | C |-/
+---+ +---+
(a) load balancer w/ (b) multiple upstream
alternate servers neighbors
+---+
| A |---\ a--\
+---+=\ \---->+---+ \
\/----->| D | b--\ \--->+---+
+---+--/\ /-->+---+ \---->| |
| B | \/ c-------->| D |
+---+===\/\===>+---+ | |
/\====>| E | ... /--->+---+
+---+--/ /==>+---+ /
| C |=====/ z--/
+---+
(c) multiple upstream (d) very large number of
neighbors w/ alternate server upstream neighbors
Figure 3: Topologies
Overload control that is based on throttling the message rate is not
suited for servers that receive requests from a very large population
of senders, which only infrequently send requests as shown in
Figure 3(d). An edge proxy that is connected to many UAs is an
example for such a configuration. Since each UA typically only
contributes a single request to an overload condition, it can't
decrease its message rate to resolve the overload.
In such a configuration, a SIP server can gradually reduce its load
Hilt, et al. Expires September 4, 2007 [Page 8]
Internet-Draft Overload Control March 2007
by rejecting a percentage of the requests it receives with 503
responses. Since there are many upstream neighbors that contribute
to the overall load, sending 503 to a fraction of them gradually
reduces load without entirely stopping the incoming traffic and helps
to resolve the overload condition in this scenario.
3.4. Overload Control Method
The method used by an overload control mechanism to curb the amount
of traffic forwarded to an element is a key aspect of the design.
Three different types of overload control methods exist: rate-based,
loss-based and window-based overload control.
3.4.1. Rate-based Overload Control
The key idea of rate-based overload control is to indicate the
message rate that an upstream element is allowed to send to the
downstream neighbor. If overload occurs, a SIP server instructs each
upstream neighbor to send at most X messages per second. This rate
cap ensures that the offered load for a SIP server never increases
beyond the sum of the rate caps granted to all upstream neighbors and
can protect a SIP server from overload even during extreme load
spikes.
A common technique to implement a rate cap of a given number of
messages per second X is message gapping. After transmitting a
message to a downstream neighbor, a server waits for 1/X seconds
before it transmits the next message to the same neighbor. Messages
that arrive during the waiting period are not forwarded and are
either redirected, rejected or buffered.
The main drawback of this mechanism is that it requires a SIP server
to assign a certain rate cap to each of its upstream neighbors based
on its overall capacity. Effectively, a server assigns a share of
its capacity to each upstream neighbor. The server needs to ensure
that the sum of all rate caps assigned to upstream neighbors is not
(significantly) higher than its actual processing capacity. This
requires a SIP server to continuously evaluate the amount of load it
receives from an upstream neighbor and assign a rate cap that is
suitable for this neighbor. For example, in a non-overloaded
situation, it could assign a rate cap that is 10% higher than the
current rate from this neighbor. The rate cap needs to be adjusted
if the load offered by upstream neighbors changes and new upstream
neighbors appear or an existing neighbor stops transmitting. If the
cap assigned to an upstream neighbor is too high, the server may
still experience overload. However, if the cap is too low, the
upstream neighbors will reject messages even though they could be
processed by the server. Thus, rate-based overload control is likely
Hilt, et al. Expires September 4, 2007 [Page 9]
Internet-Draft Overload Control March 2007
to work well only if the number of upstream servers is small and
constant, e.g., as shown in the example in Figure 3(d).
3.4.2. Loss-based Overload Control
A loss percentage enables a SIP server to ask its upstream neighbor
to reduce the amount of traffic it would normally forward to this
server by a percentage X. For example, a SIP server can ask its
upstream neighbors to lower the traffic it would forward to it by
10%. The upstream neighbor then redirects or rejects X percent of
the traffic that is destined for this server.
A loss percentage can be implemented in the upstream entity, for
example, by drawing a random number between 1 and 100 for each
request to be forwarded. The request is not forwarded to the server
if the random number is less than or equal to X.
A server does not need to track the message rate it receives from
each upstream neighbor. To reduce load, a server can ask each
upstream neighbor to lower traffic by a certain percentage which can
be determined independent of the actual message rate contributed by
each server. The loss percentage depends on the loss percentage
currently used by the upstream servers and the current system load of
the server. For example, if the server load approaches 90% and the
current loss percentage is set to a 50% load reduction, then the
server may decide to increase the loss percentage to 55% in order to
get back to a system load of 80%. Similarly, the server can lower
the loss percentage if permitted by the system utilization. This
requires that system load can be accurately measured and that these
measurements are reasonably stable.
The main drawback of percentage throttling is that the throttle
percentage needs to be adjusted to the offered load, in particular,
if the load fluctuates quickly. For example, if a SIP server sets a
throttle value of 10% at time t1 and load increases by 20% between
time t1 and t2 (t1<t2), then the server will see a load increase by
10% between time t1 and t2. This is true even though all upstream
neighbors reduced traffic by 10% as told. Thus, percentage
throttling requires the quick adjustment of the throttling percentage
and may not always be able to prevent a server from encountering
brief periods of overload in extreme cases.
3.4.3. Window-based Overload Control
The key idea of window-based overload control is to allow an entity
to transmit a certain number of messages before it needs to receive a
confirmation for the messages in transit. Each sender maintains an
overload window that limits the number of messages that can be in
Hilt, et al. Expires September 4, 2007 [Page 10]
Internet-Draft Overload Control March 2007
transit without being confirmed.
Each sender maintains a unconfirmed message counter for each
downstream neighbor it is communicating with. For each message sent
to the downstream neighbor, the counter is increased by one. For
each confirmation received, the counter is decreased by one. The
sender stops transmitting messages to the downstream neighbor when
the unconfirmed message counter has reached the current window size.
A crucial parameter for the performance of window-based overload
control is the window size. The windows size together with the
round-trip time between sender and receiver determines the effective
message rate that can be achieved. Each sender has an initial window
size it uses when first sending a request. This window size can
change based on the feedback it receives from the receiver. The
receiver can require a decrease in window size to throttle the sender
or allow an increase to allow an increasing message rate.
The sender adjusts its window size as soon as it receives the
corresponding feedback from the receiver. If the new window size is
smaller than the current unconfirmed message counter, the sender MUST
stop transmitting messages until more messages are confirmed and the
current unconfirmed message counter is less than the window size.
A sender should not treat the reception of a 100 Trying response as
an implicit confirmation for a message. 100 Trying responses are
often created by a SIP server very early in the process and do not
indicate that a message has been successfully processed and cleared
from the input buffer. If the downstream neighbor is a stateless
proxy, it will not create 100 Trying responses at all and instead
pass through 100 Trying responses created by the next stateful
server. Also, 100 Trying response are typically only created for
INVITE requests. Explicit message confirmations in a load feedback
report do not have these problems.
The behavior and issues of window-based overload control are similar
to rate-based overload control, in that the total available receiver
buffer space needs to be divided among all upstream neighbors.
However, unlike rate-based overload control, it can ensure that the
receiver buffer never overflows. The transmission of messages by
senders is effectively clocked by message confirmations received from
the receiver.
3.5. Overload Control Algorithms
This section describes algorithms that govern the behavior of
entities that implement the overload control mechanism.
Hilt, et al. Expires September 4, 2007 [Page 11]
Internet-Draft Overload Control March 2007
OPEN ISSUE: the following overload control algorithms are strawman
proposals. They depend on the overload control methods.
3.5.1. Increase Algorithm
A SIP server that is starting to transmit messages to a downstream
neighbor should slowly increase the message rate until it reaches the
rate allowed by the receiver. In particular servers that are
restarted or added to the network should execute this algorithm. The
slow increase prevents a server from overloading its downstream
neighbor by suddenly and significantly increasing load. A server
should, however, not reject requests during this period. Instead, it
should redirect or buffer requests it cannot forward right away.
This avoids that calls are rejected in a empty network because of the
slow increase algorithm.
A slow increase should also be used when the receiver has recovered
from an overload condition and is increasing the allowed transmission
rate. In this case, the sender may reject messages during the slow
increase Slow increase after overload avoids that the receiver
becomes overloaded again when all senders suddenly increase the
message rate.
OPEN ISSUE: this algorithm seems to be useful for loss-based
overload control but may not be needed for other types of overload
control.
3.5.2. Decrease Algorithm
A sender MUST immediately reduce its transmission rate when it
receives an indication that the receiver has reached an overload
condition.
3.6. Load Status
It may be useful for a SIP server to frequently provide its current
load status to upstream neighbors. The load status indicates to
which degree the resources needed by a SIP server to process SIP
messages are utilized. SIP servers can use the load status to
balance load between alternative proxies and to find under-utilized
servers. It should be noted, however, that reporting load is not
intended to replace specialized load balancing mechanisms.
OPEN ISSUE: reporting load status seems related but somewhat
orthogonal to overload control. It might therefore be better to
handle overload control and load reporting/balancing in separate
mechanisms.
Hilt, et al. Expires September 4, 2007 [Page 12]
Internet-Draft Overload Control March 2007
3.7. SIP Mechanism
A SIP mechanism needs to convey load feedback from the receiving to
the sending SIP entity. A number of alternatives exist to realize
such a mechanism.
In principle, it would be possible to define a new SIP request that
can be used to convey load status reports from the receiving to the
sending entity. However, sending separate load status requests from
receiving to the sending entity would create additional messaging
overhead, which is undesirable during periods of overload. It would
also require each SIP server to keep track of all potential upstream
neighbors.
Similarly, it would be possible to define an event packages for
subscriptions to overload status. This package would enable a
sending entity to subscribe to the load status of its downstream
neighbor and receive status updates in NOTIFY messages. However, it
would require each sending entity to set up a subscription to all
entities it may forward traffic to and manage these subscriptions
over time for a varying set of downstream neighbors. Setting up
subscriptions and sending overload feedback in notifications creates
an undesirable messaging overhead.
Another approach is to define a new SIP header field for load
information that can be inserted into SIP responses. This approach
has the advantage that it automatically provides load feedback to all
upstream SIP entities that are currently forwarding traffic to a SIP
server with very little overhead.
Hop-by-hop overload control requires that the distribution of load
feedback is limited to the next upstream SIP server. This can be
achieved by adding the address of the next hop server, that is, the
destination of the load report, to the load header. Conveying load
feedback in a SIP response header requires that SIP traffic is
flowing between the sending and the receiving entity. This is
usually not a problem when regulating traffic between SIP servers.
Even in an overload situation that requires 100% throttling, an
upstream server can forward an occasional request or send an OPTIONS
request to probe the load status of the downstream neighbor.
3.8. Backwards Compatibility
An important requirement for an overload control mechanism is that it
can be gradually introduced into a network and that it functions
properly if only a fraction of the servers support it.
Hop-by-hop overload control does not require that all SIP entities in
Hilt, et al. Expires September 4, 2007 [Page 13]
Internet-Draft Overload Control March 2007
a network support it. It can be used effectively between two
adjacent SIP servers if both servers support this extension and does
not depend on the support from any other server or user agent. The
more SIP servers in a network support this mechanism, the more
effective it is since it includes more of the servers in the load
reporting and offloading process.
In topologies such as the ones depicted in Figure 3(b) and (c), a SIP
server has multiple neighbors from which only some may support
overload control. If a server would simply use this extension for
overload control, only those that support it would throttle their
load. Others would keep sending at the full rate and benefit from
the throttling by other servers supporting this extension. In other
words, upstream neighbors that do not support overload control would
be better off than those that do.
A SIP server should therefore use 5xx responses towards upstream
neighbors that do not support this specification. The server should
reject the same amount of requests with 5xx responses that would be
otherwise be rejected/redirected by the upstream neighbor if it would
support overload control. For example, if the server has throttled
the load by 10%, it should reject 10% of the requests with a 5xx
response for this neighbor.
3.9. Interaction with Local Overload Control
Servers may want to protect themselves against overload by rejecting
incoming messages with minimal effort when a server is overloaded.
We refer to such mechanisms as local overload control.
Local overload control can be used in conjunction with the mechanisms
defined in this specification and provides an additional layer of
protection against overload, for example, in cases where upstream
servers do not support overload control. In general, servers should
start to throttle upstream neighbors before using local overload
control mechanisms to reject messages, i.e., at a lower level of
load.
4. SIP Application Considerations
4.1. How to Calculate Load Levels
Calculating an element's load level is dependent on the limiting
resource for this element. There can be several contributing
factors, such as CPU, memory, queue depth, calls per second,
application threads. The element should consider to have reached a
load level of 100% at a point at which it cannot reliably process any
Hilt, et al. Expires September 4, 2007 [Page 14]
Internet-Draft Overload Control March 2007
more messages. If an element knows what its limiting resource is, it
can calculate its load level based on this resource or use a
combination of resources. The element should recognize percentages
of load prior to hitting 100% based on the limit at which the element
becomes 100% loaded.
4.2. Responding to an Overload Indication
An element may receive a load header indicating that it needs to
reduce the traffic it sends to its downstream neighbor. An element
can accomplish this task by sending some of the requests that would
have gone to the overloaded element to a different destination or by
altering its load-balancing algorithm to lower the number of calls it
will offer to the overloaded resource. It can also buffer requests
in the hope that the overload condition will resolve quickly and the
requests still can be forwarded in time. Finally, it can reject
these requests.
The algorithm to reduce load is open to element and vendor
implementation. (Note: the load reduction algorithm is not
specifying the quantity of SIP messages allowed by the SIP server, it
is simply specifying a treatment of new request based on a specified
load level.) However, the algorithm should provide for tunable
parameters to allow the network operator to optimize over time. The
settings for these parameters could be different for a carrier
network versus an enterprise or VSP network. The goal of the
algorithm is to alleviate load throughout the network. This means
avoidance of propagating load from one element to another. This also
means trying to keep the network as full as possible without reaching
100% on any given element, except when all elements approach 100%.
Balancing load across a network is the responsibility of the
operator, but the load header may help the operator to adjust the
balancing in a more dynamic fashion by allowing the load-balancing
algorithm to react to bursts or outages.
4.3. Emergency Services Requests
It is generally recommended proxy servers should attempt to balance
all SIP requests, and relative resources, to a maximum load of 80%.
In doing so, the servers are proactively tuned to allow an emergency
services request [7] attempt to be placed to any available upstream
or downstream SIP device for immediate processing and delivery to the
intended emergency services provider.
In some cases, the load will increase beyond this point and a server
will need to begin to lower the number of requests forwarded. When
the SIP server receives an emergency services request, it should not
be treated by alleviation methods and should be processed
Hilt, et al. Expires September 4, 2007 [Page 15]
Internet-Draft Overload Control March 2007
immediately. In some cases, a SIP server may receive more emergency
services requests than it is allowed to forward. This may happen,
for example, to a SIP server that is serving an emergency service
center. In these cases and after rejecting/redirecting all non-
emergency service requests, a SIP server should also include
emergency service requests in the alleviation treatment to avoid that
the downstream server becomes overloaded.
4.4. Operations and Management
The load header information can be captured within Call Detail
Records (CDRs) and SNMP traps for use in service reports. These
service reports could be used for future network optimization.
5. SIP Load Header Field
This section defines a new SIP header field for overload control, the
Load header. This header field follows the above design
considerations for an overload control mechanism.
Note: the Load header field is an initial proposal for a overload
feedback mechanism. The design of this header depends on many of
the design aspects discussed above (in particular the overload
control method as discussed in Section 3.4).
5.1. Generating the Load Header
A SIP server compliant to this specification SHOULD frequently
provide load feedback to its upstream neighbors in a timely manner.
It does so by inserting a Load header field into the SIP responses it
is forwarding or creating. The Load header is a new header field
defined in this specification. The Load header can be inserted into
all response types, including provisional, success and failure
response types. A SIP server SHOULD insert a Load header into all
responses.
A SIP server MAY choose to insert Load headers less frequently, for
example, once every x milliseconds. This may be useful for SIP
servers that receive a very high number of messages from the same
upstream neighbor or servers with a very low variability of the load
measure. In any case, a SIP server SHOULD insert a Load header into
a response well before the previous Load header sent to the same
upstream neighbor expires. Only SIP servers that frequently insert
Load header into responses are protected against overload.
The Load header is only defined in SIP responses and MUST NOT be used
in SIP requests. The SIP header is only useful to the upstream
Hilt, et al. Expires September 4, 2007 [Page 16]
Internet-Draft Overload Control March 2007
neighbor of a SIP server since this is the entity that can offload
traffic by redirecting/rejecting new requests. If requests are
forwarded in both directions between two SIP servers (i.e., the roles
of upstream/downstream neighbors change), there are also responses
flowing in both directions which allow the two SIP servers to
exchange load information. While Load headers in requests may
increase the frequency with which load information is exchanged in
these scenarios, this increase will rarely provide benefits and does
not seem to justify the added overhead and complexity needed.
A SIP server MUST insert the address of its upstream neighbor into
the "target" parameter of the Load header. It SHOULD use the address
of the upstream neighbor found in the topmost Via header of the
response for this purpose.
The "target" parameter enables the receiver of a Load header to
determine if it should process the Load header (since it was
generated by its downstream neighbor) or if the Load header needs to
be ignored (since it was passed along by an entity that does not
support this extension). Effectively, the "target" parameter
implements the hop-by-hop semantics and prevents the use of load
status information beyond the next hop.
OPEN ISSUE: instead of using the address in the Via header it
might make sense to use an application identifier similar to the
one defined for SigComp [6].
A SIP server SHOULD add a "validity" parameter to the Load header.
The "validity" parameter defines the time in milliseconds during
which the Load header should be considered valid. The default value
of the "validity" parameter is 500. A SIP server SHOULD use a
shorter "validity" time if its load status varies quickly and MAY use
a longer "validity" time if the current load level is more stable.
5.2. Determining the Load Header Value
The value of the Load header contains the current load status of the
SIP server generating this header. Load header values range from 0
(idle) to 100 (overloaded) and MUST reflect the current level in the
usage of SIP message processing resources. For example, a SIP server
that is processing SIP messages at a rate that corresponds to 50% of
its maximum capacity must set the Load header value to 50.
5.3. Determining the Throttle Parameter Value
The value of the "throttle" parameter specifies the percentage by
which the load forwarded to this SIP server should be reduced.
Possible values range from 0 (the load forwarded is reduced by 0%,
Hilt, et al. Expires September 4, 2007 [Page 17]
Internet-Draft Overload Control March 2007
i.e., all traffic is forwarded) to 100 (the load forwarded is reduced
by 100%, i.e., no traffic forwarded). The default value of the
"throttle" parameter is 0. The "throttle" parameter value is
determined by the control function of the SIP server generating the
Load header.
OPEN ISSUE: this parameter depends on the overload control method
used (e.g., whether rate-based or window-based overload control is
used).
5.4. Processing the Load Header
A SIP entity compliant to this specification MUST remove all Load
headers from the SIP messages it receives before forwarding the
message. A SIP entity may, of course, insert its own Load header
into a SIP message.
A SIP entity MUST ignore all Load headers that were not addressed to
it. It MUST compare its own addresses with the address in the
"target" parameter of the Load header. If none of its addresses
match, it MUST ignore the Load header. This ensures that a SIP
entity only processes Load headers that were generated by its direct
neighbors.
A SIP server MUST store the information received in Load headers from
a downstream neighbor in a server load table. Each time a SIP server
receives a response with a Load header from a downstream neighbor, it
MUST overwrites the current value it has stored for this neighbor
with the one received. Each entry in the server load table has the
following elements:
o Address of the server from which the Load header was received.
o Time when the header was received.
o Load header value.
o Throttle parameter value (default value if not present).
o Validity parameter value (default value if not present).
A SIP entity SHOULD slowly fade out the contents of Load headers that
have exceeded their expiration time by additively decreasing the Load
header and throttle parameter values until they reach zero. This is
achieved by using the following equation to access stored Load header
and "throttle" parameter values. Note that this equation is only
used to access Load header and "throttle" parameter values and the
result is not written back into the table.
result = value - ((cur_t - rec_t) DIV validity) * 20
If the result is negative, zero is used instead. Value is the stored
Hilt, et al. Expires September 4, 2007 [Page 18]
Internet-Draft Overload Control March 2007
value of the Load header/the "throttle" parameter. Cur_t is the
current time in milliseconds, rec_t is the time the Load header was
received. Validity is the "validity" parameter value. DIV is a
function that returns the integer portion of a division.
The idea behind this equation is to subtract 20 from the value for
each validity period that has passed since the header was received.
A value of 100, for example, will be reduced to 80 after the first
validity period and it will be completely removed after 5 * validity
milliseconds.
A stored Load header is removed from the table when the above
equation returns zero for both the load header and throttle parameter
value.
5.5. Using the Load Header Value
A SIP entity MAY use the Load header value to balance load or to find
an underutilized SIP server.
5.6. Using the Throttle Parameter Value
A SIP entity compliant to this specific MUST honor "throttle"
parameter values when forwarding SIP messages to a downstream SIP
server.
A SIP entity applies the usual SIP procedures to determine the next
hop SIP server as, e.g., described in [2] and [3]. After selecting
the next hop server, the SIP entity MUST determine if it has a stored
Load header from this server has not yet fully expired. If it has a
Load header and the header contained a throttle parameter that is
non-zero, the SIP server MUST determine if it can or cannot forward
the current request within the current throttle conditions.
The SIP MAY use the following algorithm to determine if it can
forward the request. The SIP entity draws a random number between 1
and 100 for the current request. If the random number is less than
or equal to the throttle value, the request is not forwarded.
Otherwise, the request if forwarded as usual. Another algorithm for
SIP entities that processes a large number of requests is to reject/
redirect the first X of every 100 requests processed. Other
algorithms that lead to the same result may be used as well.
The treatment of SIP requests that cannot be forwarded to the
selected SIP Server is a matter of local policy. A SIP entity MAY
try to find an alternative target or it MAY reject the request (see
Section 5.7).
Hilt, et al. Expires September 4, 2007 [Page 19]
Internet-Draft Overload Control March 2007
5.7. Rejecting Requests
A SIP server that rejects a request because of overload MUST reject
this request with a 520 response code. 520 is a new SIP response code
defined in this specification. This response code is used for
requests that are rejected because the SIP server has received an
indication that its downstream neighbor is overloaded or because the
SIP server itself is under overload.
OPEN ISSUE: does it make sense to use a new response code or
should 500 be used? Is 520 a reasonable code to use?
A SIP server may determine that an upstream neighbor does not support
this extension. If a SIP server is under overload, it SHOULD use 520
responses to reject a fraction of requests from upstream neighbors
that do not support this extension. This fraction SHOULD be
equivalent to the fraction of requests the upstream server would
reject/redirect if it did support this extension. This is to ensure
that SIP entities, which do not support this extension, don't receive
an unfair advantage over those that do.
A SIP server that has reached overload (i.e., a load close to 100)
SHOULD start using 520 responses in addition to the throttle
parameter in the Load header for all upstream neighbors. If the
proxy has reached a load close to 100, it needs to protect itself
against overload. Also, it is likely that upstream proxies have
ignored the increasing load status reports and thus do not support
this extension.
6. Syntax
This section defines the syntax of a new SIP response header, the
Load header. The Load header field is used to advertise the current
load status information of a SIP entity to its upstream neighbor.
The value of the Load header is an integer between 0 and 100 with the
value of 0 indicating that the proxy is least overloaded and the
value of 100 indicating that the proxy is most overloaded.
The "target" parameter is mandatory and contains the URI of the next
hop SIP entity for the response. I.e., the SIP entity the response
is forwarded to. This is the entity that will process the Load
header.
The "throttle" parameter is optional and contains a number between 0
and 100. It describes the percentage by which the load forwarded by
"target" SIP entity to the SIP server generating this header should
Hilt, et al. Expires September 4, 2007 [Page 20]
Internet-Draft Overload Control March 2007
be reduced.
The "validity" parameter is optional and contains an indication of
how long the reporting proxy is likely to remain in the given load
status.
The syntax of the Load header field is:
Load = "Load" HCOLON loadStatus
loadStatus = 0-100 SEMI serverID *( SEMI loadParam )
loadParam = throttleRate | validMS | generic-param
serverID = "target" EQUAL SIP-URI | SIPS-URI
throttleRate = "throttle" EQUAL 0-100
validMS = "validity" EQUAL delta-ms
delta-ms = 1*DIGIT
The BNF for SIP-URI, SIPS-URI and generic-param is defined in [2].
Table 1 is an extension of Tables 2 and 3 in [2].
Header field where proxy ACK BYE CAN INV OPT REG
________________________________________________________
Load r ar - o o o o o
Table 1: Load Header Field
Example:
Load: 80;throttle=20;validity=500;target=p1.example.com
7. Security Considerations
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
that the SIP entity is overloaded. When such a forged overload
indication is received by an upstream SIP entity, it will stop
sending traffic to the victim. Thus, the victim is subject to a
denial-of-service attack.
An attacker can create forged load status reports by inserting itself
into the communication between the victim and its upstream neighbors.
The attacker would need to add status reports indicating a high load
to the responses passed from the victim to its upstream neighbor.
Proxies can prevent this attack by communicating via TLS. Since load
status reports have no meaning beyond the next hop, there is no need
to secure the communication over multiple hops.
Another way to conduct an attack is to send a message containing a
Hilt, et al. Expires September 4, 2007 [Page 21]
Internet-Draft Overload Control March 2007
high load status value through a proxy that does not support this
extension. Since this proxy does not remove the load status
information, it will reach the next upstream proxy. If the attacker
can make the recipient believe that the load status was created by
its direct downstream neighbor (and not by the attacker further
downstream) the recipient stops sending traffic to the victim. A
precondition for this attack is that the victim proxy does not
support this extension since it would not pass through load status
information otherwise. The attack also does not work if there is a
stateful proxy between the attacker and the victim and only 100
(Trying) responses are used to convey the Load header.
A malicious SIP entity could gain an advantage by pretending to
support this specification but never reducing the load it forwards to
the downstream neighbor. If its downstream neighbor receives traffic
from multiple sources which correctly implement overload control, the
malicious SIP entity would benefit since all other sources to its
downstream neighbor would reduce load.
OPEN ISSUE: the solution to this problem depends on the overload
control algorithm. For a fixed message rate and window-based
overload control, it is very easy for a downstream entity to
monitor if the upstream neighbor throttles load as directed. For
percentage throttling this is not always obvious since the load
forwarded depends on the load received by the upstream neighbor.
8. IANA Considerations
[TBD.]
Appendix A. Acknowledgements
Many thanks to Rich Terpstra and Jonathan Rosenberg for their
contributions to this specification.
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
Hilt, et al. Expires September 4, 2007 [Page 22]
Internet-Draft Overload Control March 2007
[3] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[4] Schulzrinne, H. and J. Polk, "Communications Resource Priority
for the Session Initiation Protocol (SIP)", RFC 4412,
February 2006.
9.2. Informative References
[5] Rosenberg, J., "Requirements for Management of Overload in the
Session Initiation Protocol",
draft-rosenberg-sipping-overload-reqs-02 (work in progress),
October 2006.
[6] Liu, Z., "Applying Signaling Compression (SigComp) to the
Session Initiation Protocol (SIP)",
draft-ietf-rohc-sigcomp-sip-04 (work in progress),
November 2006.
[7] Rosen, B., "Framework for Emergency Calling in Internet
Multimedia", draft-ietf-ecrit-framework-00 (work in progress),
October 2006.
Authors' Addresses
Volker Hilt
Bell Labs/Alcatel-Lucent
101 Crawfords Corner Rd
Holmdel, NJ 07733
USA
Email: volkerh@bell-labs.com
Indra Widjaja
Bell Labs/Alcatel-Lucent
600-700 Mountain Avenue
Murray Hill, NJ 07974
USA
Email: iwidjaja@alcatel-lucent.com
Hilt, et al. Expires September 4, 2007 [Page 23]
Internet-Draft Overload Control March 2007
Daryl Malas
Level 3 Communications
1025 Eldorado Blvd.
Broomfield, CO
USA
Email: daryl.malas@level3.com
Henning Schulzrinne
Columbia University/Department of Computer Science
450 Computer Science Building
New York, NY 10027
USA
Phone: +1 212 939 7004
Email: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Hilt, et al. Expires September 4, 2007 [Page 24]
Internet-Draft Overload Control March 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Hilt, et al. Expires September 4, 2007 [Page 25]