draft-ietf-sipping-overload-design-00.txt   draft-ietf-sipping-overload-design-01.txt 
SIPPING Working Group V. Hilt (Ed.) SIPPING Working Group V. Hilt (Ed.)
Internet-Draft Bell Labs/Alcatel-Lucent Internet-Draft Bell Labs/Alcatel-Lucent
Intended status: Informational October 22, 2008 Intended status: Informational March 7, 2009
Expires: April 25, 2009 Expires: September 8, 2009
Design Considerations for Session Initiation Protocol (SIP) Overload Design Considerations for Session Initiation Protocol (SIP) Overload
Control Control
draft-ietf-sipping-overload-design-00 draft-ietf-sipping-overload-design-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 25, 2009. This Internet-Draft will expire on September 8, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
Overload occurs in Session Initiation Protocol (SIP) networks when Overload occurs in Session Initiation Protocol (SIP) networks when
SIP servers have insufficient resources to handle all SIP messages SIP servers have insufficient resources to handle all SIP messages
they receive. Even though the SIP protocol provides a limited they receive. Even though the SIP protocol provides a limited
overload control mechanism through its 503 (Service Unavailable) overload control mechanism through its 503 (Service Unavailable)
response code, SIP servers are still vulnerable to overload. This response code, SIP servers are still vulnerable to overload. This
document discusses models and design considerations for a SIP document discusses models and design considerations for a SIP
overload control mechanism. overload control mechanism.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SIP Overload Problem . . . . . . . . . . . . . . . . . . . . . 4 2. SIP Overload Problem . . . . . . . . . . . . . . . . . . . . . 4
3. Explicit vs. Implicit Overload Control . . . . . . . . . . . . 4 3. Explicit vs. Implicit Overload Control . . . . . . . . . . . . 5
4. System Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. System Model . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Degree of Cooperation . . . . . . . . . . . . . . . . . . . . 7 5. Degree of Cooperation . . . . . . . . . . . . . . . . . . . . 7
5.1. Hop-by-Hop . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Hop-by-Hop . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. End-to-End . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. End-to-End . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Local Overload Control . . . . . . . . . . . . . . . . . . 10 5.3. Local Overload Control . . . . . . . . . . . . . . . . . . 10
6. Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Explicit Overload Control Feedback . . . . . . . . . . . . . . 13 7. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Rate-based Overload Control . . . . . . . . . . . . . . . 13 8. Performance Metrics . . . . . . . . . . . . . . . . . . . . . 13
7.2. Loss-based Overload Control . . . . . . . . . . . . . . . 14 9. Explicit Overload Control Feedback . . . . . . . . . . . . . . 14
7.3. Window-based Overload Control . . . . . . . . . . . . . . 15 9.1. Rate-based Overload Control . . . . . . . . . . . . . . . 14
7.4. Overload Signal-based Overload Control . . . . . . . . . . 16 9.2. Loss-based Overload Control . . . . . . . . . . . . . . . 15
7.5. On-/Off Overload Control . . . . . . . . . . . . . . . . . 16 9.3. Window-based Overload Control . . . . . . . . . . . . . . 16
8. Implicit Overload Control . . . . . . . . . . . . . . . . . . 17 9.4. Overload Signal-based Overload Control . . . . . . . . . . 17
9. Overload Control Algorithms . . . . . . . . . . . . . . . . . 17 9.5. On-/Off Overload Control . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. Implicit Overload Control . . . . . . . . . . . . . . . . . . 18
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 11. Overload Control Algorithms . . . . . . . . . . . . . . . . . 19
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 18 12. Message Prioritization . . . . . . . . . . . . . . . . . . . . 19
12. Informative References . . . . . . . . . . . . . . . . . . . . 18 13. Security Considerations . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 19 15. Informative References . . . . . . . . . . . . . . . . . . . . 19
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
As with any network element, a Session Initiation Protocol (SIP) As with any network element, a Session Initiation Protocol (SIP)
[RFC3261] server can suffer from overload when the number of SIP [RFC3261] server can suffer from overload when the number of SIP
messages it receives exceeds the number of messages it can process. messages it receives exceeds the number of messages it can process.
Overload occurs if a SIP server does not have sufficient resources to Overload occurs if a SIP server does not have sufficient resources to
process all incoming SIP messages. These resources may include CPU, process all incoming SIP messages. These resources may include CPU,
memory, network bandwidth, input/output, or disk resources. memory, network bandwidth, input/output, or disk resources.
skipping to change at page 3, line 44 skipping to change at page 3, line 44
for them. for them.
The SIP protocol provides a limited mechanism for overload control The SIP protocol provides a limited mechanism for overload control
through its 503 (Service Unavailable) response code and the Retry- through its 503 (Service Unavailable) response code and the Retry-
After header. However, this mechanism cannot prevent overload of a After header. However, this mechanism cannot prevent overload of a
SIP server and it cannot prevent congestion collapse. In fact, it SIP server and it cannot prevent congestion collapse. In fact, it
may cause traffic to oscillate and to shift between SIP servers and may cause traffic to oscillate and to shift between SIP servers and
thereby worsen an overload condition. A detailed discussion of the thereby worsen an overload condition. A detailed discussion of the
SIP overload problem, the problems with the 503 (Service Unavailable) SIP overload problem, the problems with the 503 (Service Unavailable)
response code and the Retry-After header and the requirements for a response code and the Retry-After header and the requirements for a
SIP overload control mechanism can be found in SIP overload control mechanism can be found in [RFC5390].
[I-D.ietf-sipping-overload-reqs].
This document discusses the models, assumptions and design This document discusses the models, assumptions and design
considerations for a SIP overload control mechanism. The document is considerations for a SIP overload control mechanism. The document is
a product of the SIP overload control design team. a product of the SIP overload control design team.
2. SIP Overload Problem 2. SIP Overload Problem
A key contributor to the SIP congestion collapse A key contributor to the SIP congestion collapse [RFC5390] is the
[I-D.ietf-sipping-overload-reqs] is the regenerative behavior of regenerative behavior of overload in the SIP protocol. When SIP is
overload in the SIP protocol. When SIP is running over the UDP running over the UDP protocol, it will retransmit messages that were
protocol, it will retransmit messages that were dropped by a SIP dropped by a SIP server due to overload and thereby increase the
server due to overload and thereby increase the offered load for the offered load for the already overloaded server. This increase in
already overloaded server. This increase in load worsens the load worsens the severity of the overload condition and, in turn,
severity of the overload condition and, in turn, causes more messages causes more messages to be dropped. A congestion collapse can occur
to be dropped. A congestion collapse can occur. [Noel et al.], [Shen et al.] and [Hilt et al.].
While regenerative behavior under overload should ideally be avoided Regenerative behavior under overload should ideally be avoided by any
by any protocol and would lead to stable operation under overload, protocol as this would lead to stable operation under overload.
this is often difficult to achieve in practice. For example, However, this is often difficult to achieve in practice. For
changing the SIP retransmission timer mechanisms can reduce the example, changing the SIP retransmission timer mechanisms can reduce
degree of regeneration during overload, however, these changes will the degree of regeneration during overload but will impact the
impact the ability of SIP to recover from message losses. Without ability of SIP to recover from message losses. Without any
any retransmission each message that is dropped due to SIP server retransmission each message that is dropped due to SIP server
overload will eventually lead to a failed call. overload will eventually lead to a failed call.
For a SIP INVITE transaction to be successful a minimum of three For a SIP INVITE transaction to be successful a minimum of three
messages need to be forwarded by a SIP server, often five or more. messages need to be forwarded by a SIP server. Often an INVITE
If a SIP server under overload randomly discards messages without transaction consists of five or more SIP messages. If a SIP server
evaluating them, the chances that all messages belonging to a under overload randomly discards messages without evaluating them,
transaction are passed on will decrease as the load increases. Thus, the chances that all messages belonging to a transaction are
the number of successful transactions will decrease even if the successfully forwarded will decrease as the load increases. Thus,
message throughput of a server remains up and the overload behavior the number of transactions that complete successfully will decrease
would be fully non-regenerative. A SIP server might (partially) even if the message throughput of a server remains up and assuming
parse incoming messages to determine if it is a new request or a the overload behavior is fully non-regenerative. A SIP server might
message belonging to an existing transaction. However, after having (partially) parse incoming messages to determine if it is a new
spend resources on parsing a SIP message, discarding this message request or a message belonging to an existing transaction. However,
becomes expensive as the resources already spend are lost. The after having spend resources on parsing a SIP message, discarding
number of successful transactions will therefore decline with an this message is expensive as the resources already spend are lost.
The number of successful transactions will therefore decline with an
increase in load as less and less resources can be spent on increase in load as less and less resources can be spent on
forwarding messages. The slope of the decline depends on the amount forwarding messages and more and more resources are consumed by
of resources spent to evaluate each message. inspecting messages that will eventually be dropped. The slope of
the decline depends on the amount of resources spent to inspect each
message.
Another key challenge for SIP overload control is that the rate of Another key challenge for SIP overload control is that the rate of
the true traffic source usually cannot be controlled. Overload is the true traffic source usually cannot be controlled. Overload is
often caused by a large number of UAs each of which creates only a often caused by a large number of UAs each of which creates only a
single message. These UAs cannot be rate controlled as they only single message. These UAs cannot be rate controlled as they only
send one message. However, the sum of their traffic can overload a send one message. However, the sum of their traffic can overload a
SIP server. SIP server.
3. Explicit vs. Implicit Overload Control 3. Explicit vs. Implicit Overload Control
The main differences between explicit and implicit overload control The main differences between explicit and implicit overload control
is the way overload is signaled from a SIP server that is reaching is the way overload is signaled from a SIP server that is reaching
overload condition to its upstream neighbors. overload condition to its upstream neighbors.
In an explicit overload control mechanism, a SIP server uses an In an explicit overload control mechanism, a SIP server uses an
explicit overload signal to indicate that it is reaching its capacity explicit overload signal to indicate that it is reaching its capacity
limit. Upstream neighbors receiving this signal can adjust their limit. Upstream neighbors receiving this signal can adjust their
transmission rate as indicated in the overload signal to a level that transmission rate as indicated by the overload signal to a level that
is acceptable to the downstream server. The overload signal enables is acceptable to the downstream server. The overload signal enables
a SIP server to steer the load it is receiving to a rate at which it a SIP server to steer the load it is receiving to a rate at which it
can perform at maximum capacity. can perform at maximum capacity.
Implicit overload control uses the absence of responses and packet Implicit overload control uses the absence of responses and packet
loss as an indication of overload. A SIP server that is sensing such loss as an indication of overload. A SIP server that is sensing such
a condition reduces the load it is forwarding a downstream neighbor. a condition reduces the load it is forwarding a downstream neighbor.
Since there is no explicit overload signal, this mechanism is robust Since there is no explicit overload signal, this mechanism is robust
as it does not depend on actions taken by the SIP server running into as it does not depend on actions taken by the SIP server running into
overload. overload.
skipping to change at page 5, line 45 skipping to change at page 6, line 4
Monitor: The Monitor measures the current load of the SIP processor Monitor: The Monitor measures the current load of the SIP processor
on the receiving entity. It implements the mechanisms needed to on the receiving entity. It implements the mechanisms needed to
determine the current usage of resources relevant for the SIP determine the current usage of resources relevant for the SIP
processor and reports load samples (S) to the Control Function. processor and reports load samples (S) to the Control Function.
Control Function: The Control Function implements the overload Control Function: The Control Function implements the overload
control algorithm. The control function uses the load samples (S) control algorithm. The control function uses the load samples (S)
and determines if overload has occurred and a throttle (T) needs and determines if overload has occurred and a throttle (T) needs
to be set to adjust the load sent to the SIP processor on the to be set to adjust the load sent to the SIP processor on the
receiving entity. The control function on the receiving entity receiving entity. The control function on the receiving entity
sends load feedback (F) to the sending entity. sends load feedback (F) to the sending entity.
Actuator: The Actuator implements the algorithms needed to act on Actuator: The Actuator implements the algorithms needed to act on
the throttles (T) and ensures that the amount of traffic forwarded the throttles (T) and ensures that the amount of traffic forwarded
to the receiving entity meets the criteria of the throttle. For to the receiving entity meets the criteria of the throttle. For
example, a throttle may instruct the Actuator to not forward more example, a throttle may instruct the Actuator to not forward more
than 100 INVITE messages per second. The Actuator implements the than 100 INVITE messages per second. The Actuator implements the
algorithms to achieve this objective, e.g., using message gapping. algorithms to achieve this objective, e.g., using message gapping.
It also implements algorithms to select the messages that will be It also implements algorithms to select the messages that will be
affected and determine whether they are rejected or redirected. affected and determine whether they are rejected or redirected.
The type of feedback (F) conveyed from the receiving to the sending The type of feedback (F) conveyed from the receiving to the sending
entity depends on the overload control method used (i.e., loss-based, entity depends on the overload control method used (i.e., loss-based,
rate-based or window-based overload control; see Section 7), the rate-based, window-based or signal-based overload control; see
overload control algorithm (see Section 9) as well as other design Section 9), the overload control algorithm (see Section 11) as well
parameters. In any case, the feedback (F) enables the sending entity as other design parameters. The feedback (F) enables the sending
to adjust the amount of traffic forwarded to the receiving entity to entity to adjust the amount of traffic forwarded to the receiving
a level that is acceptable to the receiving entity without causing entity to a level that is acceptable to the receiving entity without
overload. causing overload.
Figure 1 depicts a general system model for overload control. In Figure 1 depicts a general system model for overload control. In
this diagram, one instance of the control function is on the sending this diagram, one instance of the control function is on the sending
entity (i.e., associated with the actuator) and one is on the entity (i.e., associated with the actuator) and one is on the
receiving entity (i.e., associated with the monitor). However, a receiving entity (i.e., associated with the monitor). However, a
specific mechanism may not require both elements. In this case, one specific mechanism may not require both elements. In this case, one
of two control function elements can be empty and simply passes along of two control function elements can be empty and simply passes along
feedback. E.g., if (F) is defined as a loss-rate (e.g., reduce feedback. E.g., if (F) is defined as a loss-rate (e.g., reduce
traffic by 10%) there is no need for a control function on the traffic by 10%) there is no need for a control function on the
sending entity as the content of (F) can be copied directly into (T). sending entity as the content of (F) can be copied directly into (T).
The model in Figure 1 shows a scenario with one sending and one The model in Figure 1 shows a scenario with one sending and one
receiving entity. In a more realistic scenario a receiving entity receiving entity. In a more realistic scenario a receiving entity
will receive traffic from multiple sending entities and vice versa will receive traffic from multiple sending entities and vice versa
(see Section 6). The feedback generated by a Monitor will therefore (see Section 6). The feedback generated by a Monitor will therefore
often be distributed across multiple Actuators. An Actuator needs to often be distributed across multiple Actuators. A Monitor needs to
be able to split the load it can process across multiple sending
entities and generate feedback that correctly adjusts the load each
sending entity is allowed to send. Similarly, an Actuator needs to
be prepared to receive different levels of feedback from different be prepared to receive different levels of feedback from different
receiving entities and throttle traffic to these entities receiving entities and throttle traffic to these entities
accordingly. accordingly.
Sending Receiving Sending Receiving
Entity Entity Entity Entity
+----------------+ +----------------+ +----------------+ +----------------+
| Server A | | Server B | | Server A | | Server B |
| +----------+ | | +----------+ | -+ | +----------+ | | +----------+ | -+
| | Control | | F | | Control | | | | | Control | | F | | Control | | |
skipping to change at page 7, line 30 skipping to change at page 7, line 30
| +----------+ | | +----------+ | | | +----------+ | | +----------+ | |
<-+--| SIP | | | | SIP | | | SIP <-+--| SIP | | | | SIP | | | SIP
--+->|Processor |--+------+->|Processor |--+-> | System --+->|Processor |--+------+->|Processor |--+-> | System
| +----------+ | | +----------+ | | | +----------+ | | +----------+ | |
+----------------+ +----------------+ -+ +----------------+ +----------------+ -+
Figure 1: System Model for Explicit Overload Control Figure 1: System Model for Explicit Overload Control
5. Degree of Cooperation 5. Degree of Cooperation
A SIP request is often processed by more than one SIP server on its A SIP request is usually processed by more than one SIP server on its
path to the destination. Thus, a design choice for an explicit path to the destination. Thus, a design choice for an explicit
overload control mechanism is where to place the components of overload control mechanism is where to place the components of
overload control along the path of a request and, in particular, overload control along the path of a request and, in particular,
where to place the Monitor and Actuator. This design choice where to place the Monitor and Actuator. This design choice
determines the degree of cooperation between the SIP servers on the determines the degree of cooperation between the SIP servers on the
path. Overload control can be implemented hop-by-hop with the path. Overload control can be implemented hop-by-hop with the
Monitor on one server and the Actuator on its direct upstream Monitor on one server and the Actuator on its direct upstream
neighbor. Overload control can be implemented end-to-end with neighbor. Overload control can be implemented end-to-end with
Monitors on all SIP servers along the path of a request and an Monitors on all SIP servers along the path of a request and an
Actuator on the sender. In this case, the Control Functions Actuator on the sender. In this case, the Control Functions
skipping to change at page 8, line 47 skipping to change at page 8, line 47
Figure 2: Degree of Cooperation between Servers Figure 2: Degree of Cooperation between Servers
5.1. Hop-by-Hop 5.1. Hop-by-Hop
The idea of hop-by-hop overload control is to instantiate a separate The idea of hop-by-hop overload control is to instantiate a separate
control loop between all neighboring SIP servers that directly control loop between all neighboring SIP servers that directly
exchange traffic. I.e., the Actuator is located on the SIP server exchange traffic. I.e., the Actuator is located on the SIP server
that is the direct upstream neighbor of the SIP server that has the that is the direct upstream neighbor of the SIP server that has the
corresponding Monitor. Each control loop between two servers is corresponding Monitor. Each control loop between two servers is
completely independent of the control loop between other servers completely independent of the control loop between other servers
further up- or downstream. In the example in Figure 2(b), three further up- or downstream. In the example in Figure 2(a), three
independent overload control loops are instantiated: A - B, B - C and independent overload control loops are instantiated: A - B, B - C and
B - D. Each loop only controls a single hop. Overload feedback B - D. Each loop only controls a single hop. Overload feedback
received from a downstream neighbor is not forwarded further received from a downstream neighbor is not forwarded further
upstream. Instead, a SIP server acts on this feedback, for example, upstream. Instead, a SIP server acts on this feedback, for example,
by re-routing or rejecting traffic if needed. If the upstream by rejecting SIP messages if needed. If the upstream neighbor of a
neighbor of a server also becomes overloaded, it will report this server also becomes overloaded, it will report this problem to its
problem to its upstream neighbors, which again take action based on upstream neighbors, which again take action based on the reported
the reported feedback. Thus, in hop-by-hop overload control, feedback. Thus, in hop-by-hop overload control, overload is always
overload is always resolved by the direct upstream neighbors of the resolved by the direct upstream neighbors of the overloaded server
overloaded server without the need to involve entities that are without the need to involve entities that are located multiple SIP
located multiple SIP hops away. hops away.
Hop-by-hop overload control reduces the impact of overload on a SIP Hop-by-hop overload control reduces the impact of overload on a SIP
network and can avoid congestion collapse. It is simple and scales network and can avoid congestion collapse. It is simple and scales
well to networks with many SIP entities. A key advantage is that it well to networks with many SIP entities. An advantage is that it
does not require feedback to be transmitted across multiple-hops, does not require feedback to be transmitted across multiple-hops,
possibly crossing multiple trust domains. Feedback is sent to the possibly crossing multiple trust domains. Feedback is sent to the
next hop only. Furthermore, it does not require a SIP entity to next hop only. Furthermore, it does not require a SIP entity to
aggregate a large number of overload status values or keep track of aggregate a large number of overload status values or keep track of
the overload status of SIP servers it is not communicating with. the overload status of SIP servers it is not communicating with.
5.2. End-to-End 5.2. End-to-End
End-to-end overload control implements an overload control loop along 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 the entire path of a SIP request, from UAC to UAS. An end-to-end
overload control mechanism consolidates overload information from all overload control mechanism consolidates overload information from all
SIP servers on the way (including all proxies and the UAS) and uses SIP servers on the way (including all proxies and the UAS) and uses
this information to throttle traffic as far upstream as possible. An this information to throttle traffic as far upstream as possible. An
end-to-end overload control mechanism has to be able to frequently end-to-end overload control mechanism has to be able to frequently
collect the overload status of all servers on the potential path(s) collect the overload status of all servers on the potential path(s)
to a destination and combine this data into meaningful overload to a destination and combine this data into meaningful overload
feedback. feedback.
A UA or SIP server only needs to throttle requests if it knows that A UA or SIP server only throttles requests if it knows that these
these requests will eventually be forwarded to an overloaded server. requests will eventually be forwarded to an overloaded server. For
For example, if D is overloaded in Figure 2(c), A should only example, if D is overloaded in Figure 2(b), A should only throttle
throttle requests it forwards to B when it knows that they will be requests it forwards to B when it knows that they will be forwarded
forwarded to D. It should not throttle requests that will eventually to D. It should not throttle requests that will eventually be
be forwarded to C, since server C is not overloaded. In many cases, forwarded to C, since server C is not overloaded. In many cases, it
it is difficult for A to determine which requests will be routed to C is difficult for A to determine which requests will be routed to C
and D since this depends on the local routing decision made by B. and D since this depends on the local routing decision made by B.
These routing decisions can be highly variable and, for example, These routing decisions can be highly variable and, for example,
depend on call routing policies configured by the user, services depend on call routing policies configured by the user, services
invoked on a call, load balancing policies, etc. The fact that a invoked on a call, load balancing policies, etc. The fact that a
previous call to a target has been routed through an overload server previous message to a target has been routed through an overload
does not necessarily mean the next call to this target will also be server does not necessarily mean the next message to this target will
routed through the same server. also be routed through the same server.
Overall, the main problem of end-to-end path overload control is its The main problem of end-to-end overload control is its inherent
inherent complexity since UAC or SIP servers need to monitor all complexity since UAC or SIP servers need to monitor all potential
potential paths to a destination in order to determine which requests paths to a destination in order to determine which requests should be
should be throttled and which requests may be sent. Even if this throttled and which requests may be sent. Even if this information
information is available, it is not clear which path a specific is available, it is not clear which path a specific request will
request will take. Therefore, end-to-end overload control is likely take.
to only work well in simple, well-known topologies (e.g., a server
that is known to only have one downstream neighbor). A variant of end-to-end overload control is to implement a control
loop control between a set of well-known SIP servers along the path
of a SIP request. For example, an overload control loop can be
instantiated between a server that only has one downstream neighbor
or a set of closely coupled SIP servers. A control loop spanning
multiple hops can be used if the sending entity has full knowledge
about the SIP servers on the path of a SIP message.
A key difference to transport protocols using end-to-end congestion A key difference to transport protocols using end-to-end congestion
control such as TCP is that the traffic exchanged by SIP servers control such as TCP is that the traffic exchanged between SIP servers
consists of many individual SIP messages. Each of these SIP messages consists of many individual SIP messages. Each of these SIP messages
has its own source and destination. This is different from TCP which has its own source and destination. Even SIP messages containing
controls a stream of packets between a single source and a single identical SIP URIs (e.g., a SUBSCRIBE and a INVITE message to the
destination. same SIP URI) can be routed to different destinations. This is
different from TCP which controls a stream of packets between a
single source and a single destination.
5.3. Local Overload Control 5.3. Local Overload Control
The idea of local overload control is to run the Monitor and Actuator The idea of local overload control (see Figure 2(c)) is to run the
on the same server. This enables the server to monitor the current Monitor and Actuator on the same server. This enables the server to
resource usage and to reject messages that can't be processed without monitor the current resource usage and to reject messages that can't
overusing the local resources. The fundamental assumption behind be processed without overusing the local resources. The fundamental
local overload control is that it is less resource consuming for a assumption behind local overload control is that it is less resource
server to reject messages than to process them. A server can consuming for a server to reject messages than to process them. A
therefore reject the excess messages it cannot process, stopping all server can therefore reject the excess messages it cannot process to
retransmissions of these messages. stop all retransmissions of these messages.
Local overload control can be used in conjunction with an implicit or Local overload control can be used in conjunction with an other
explicit overload control mechanism and provides an additional layer overload control mechanisms and provides an additional layer of
of protection against overload. It is fully implemented on the local protection against overload. It is fully implemented on the local
server and does not require any cooperation from upstream neighbors. server and does not require any cooperation from upstream neighbors.
In general, servers should use implicit or explicit overload control In general, SIP servers should apply implicit or explicit overload
techniques before using local overload control as a mechanism of last control techniques to control load before a local overload control
resort. mechanism is activated as a mechanism of last resort.
6. Topologies 6. Topologies
The following topologies describe four generic SIP server The following topologies describe four generic SIP server
configurations. These topologies illustrate specific challenges for configurations. These topologies illustrate specific challenges for
an overload control mechanism. An actual SIP server topology is an overload control mechanism. An actual SIP server topology is
likely to consist of combinations of these generic scenarios. likely to consist of combinations of these generic scenarios.
In the "load balancer" configuration shown in Figure 3(a) a set of In the "load balancer" configuration shown in Figure 3(a) a set of
SIP servers (D, E and F) receives traffic from a single source A. A SIP servers (D, E and F) receives traffic from a single source A. A
skipping to change at page 11, line 11 skipping to change at page 11, line 19
load balancer) from sending too much traffic to any of its downstream load balancer) from sending too much traffic to any of its downstream
neighbors D, E and F. If one of the downstream neighbors becomes neighbors D, E and F. If one of the downstream neighbors becomes
overloaded, A can direct traffic to the servers that still have overloaded, A can direct traffic to the servers that still have
capacity. If one of the servers serves as a backup, it can be capacity. If one of the servers serves as a backup, it can be
activated once one of the primary servers reaches overload. activated once one of the primary servers reaches overload.
If A can reliably determine that D, E and F are its only downstream If A can reliably determine that D, E and F are its only downstream
neighbors and all of them are in overload, it may choose to report neighbors and all of them are in overload, it may choose to report
overload upstream on behalf of D, E and F. However, if the set of overload upstream on behalf of D, E and F. However, if the set of
downstream neighbors is not fixed or only some of them are in downstream neighbors is not fixed or only some of them are in
overload then A should not use overload control since A can still overload then A should not activate an overload control since A can
forward the requests destined to non-overloaded downstream neighbors. still forward the requests destined to non-overloaded downstream
These requests would be throttled as well if A would use overload neighbors. These requests would be throttled as well if A would use
control towards its upstream neighbors. overload control towards its upstream neighbors.
In the "multiple sources" configuration shown in Figure 3(b), a SIP In the "multiple sources" configuration shown in Figure 3(b), a SIP
server D receives traffic from multiple upstream sources A, B and C. server D receives traffic from multiple upstream sources A, B and C.
Each of these sources can contribute a different amount of traffic, Each of these sources can contribute a different amount of traffic,
which can vary over time. The set of active upstream neighbors of D which can vary over time. The set of active upstream neighbors of D
can change as servers may become inactive and previously inactive can change as servers may become inactive and previously inactive
servers may start contributing traffic to D. servers may start contributing traffic to D.
If D becomes overloaded, it needs to generate feedback to reduce the If D becomes overloaded, it needs to generate feedback to reduce the
amount of traffic it receives from its upstream neighbors. D needs amount of traffic it receives from its upstream neighbors. D needs
to decide by how much each upstream neighbor should reduce traffic. to decide by how much each upstream neighbor should reduce traffic.
This decision can require the consideration of the amount of traffic This decision can require the consideration of the amount of traffic
sent by each upstream neighbor and it may need to be re-adjusted as sent by each upstream neighbor and it may need to be re-adjusted as
the traffic contributed by each upstream neighbor varies over time. the traffic contributed by each upstream neighbor varies over time.
Server D can use a local fairness policy to determine much traffic it
accepts from each upstream neighbor.
In many configurations, SIP servers form a "mesh" as shown in In many configurations, SIP servers form a "mesh" as shown in
Figure 3(c). Here, multiple upstream servers A, B and C forward Figure 3(c). Here, multiple upstream servers A, B and C forward
traffic to multiple alternative servers D and E. This configuration traffic to multiple alternative servers D and E. This configuration
is a combination of the "load balancer" and "multiple sources" is a combination of the "load balancer" and "multiple sources"
scenario. scenario.
+---+ +---+ +---+ +---+
/->| D | | A |-\ /->| D | | A |-\
/ +---+ +---+ \ / +---+ +---+ \
skipping to change at page 13, line 12 skipping to change at page 13, line 12
The Retry-After header can be used in 503 (Service Unavailable) The Retry-After header can be used in 503 (Service Unavailable)
responses to ask UAs to wait a given number of seconds before trying responses to ask UAs to wait a given number of seconds before trying
the call again. Using 503 (Service Unavailable) towards individual the call again. Using 503 (Service Unavailable) towards individual
sources can, however, not prevent overload if a large number of users sources can, however, not prevent overload if a large number of users
places calls at the same time. places calls at the same time.
Note: The requirements of the "edge proxy" topology are different Note: The requirements of the "edge proxy" topology are different
than the ones of the other topologies, which may require a than the ones of the other topologies, which may require a
different method for overload control. different method for overload control.
7. Explicit Overload Control Feedback 7. Fairness
There are many different ways to define fairness if a SIP server has
multiple upstream neighbors. In the context of SIP server overload,
it is helpful to describe two categories of fairness criteria: basic
fairness and customized fairness. With basic fairness a SIP server
treats all end-users equally and ensures that each end-user has the
same chance in accessing the server resources. With customized
fairness the server allocate resources according to different
priorities. An example application of the basic fairness criteria is
the "Third caller receives free tickets" scenario, where each end-
user should have an equal success probability in making calls through
an overloaded SIP server, regardless of which service provider he/she
is subscribing to. An example of customized fairness would be a
server which gives different resource allocations to its upstream
neighbors (e.g., service providers) as defined in service level
agreements.
8. Performance Metrics
The performance of an overload control mechanism can be measured
using different metrics.
A key performance indicator is the goodput of a SIP server during
overload. Ideally, a SIP server is enabled to perform at its
capacity limit during periods of overload. E.g., if a SIP server has
a processing capacity of 140 INVITE transactions per second then an
overload control mechanism should enable it to handle 140 INVITEs per
second even if the offered load is much higher. The delay introduced
by a SIP server is another important indicator. An overload control
mechanism should ensure that the delay encountered by a SIP message
is not increased significantly during periods of overload.
Reactiveness and stability are other important performance
indicators. An overload control mechanism should quickly react to an
overload occurrence and ensure that a SIP server does not become
overloaded even during sudden peaks of load. Similarly, an overload
control mechanism should quickly remove all throttles if the overload
disappears. Stability is another important criteria as using an
overload control mechanism should not lead to the oscillation of load
on a SIP server. The performance of SIP overload control mechanisms
is discussed in [Noel et al.], [Shen et al.] and [Hilt et al.].
In addition to the above metrics, there are other indicators that are
relevant for the evaluation of an overload control mechanism:
Fairness: Which types of fairness does the overload control
mechanism implement?
Self-limiting: Is the overload control self-limiting if a SIP server
becomes unresponsive?
Changes in neighbor set: How does the mechanism adapt to a changing
set of sending entities?
Data points to monitor: Which data points does an overload control
mechanism need to monitor?
Tuning requirements: Does the algorithm work out of the box or is
parameter tweaking required?
TBD: a discussion of these metrics for the following overload
control mechanisms is needed.
9. Explicit Overload Control Feedback
Explicit overload control feedback enables a receiver to indicate how Explicit overload control feedback enables a receiver to indicate how
much traffic it wants to receive. Explicit overload control much traffic it wants to receive. Explicit overload control
mechanisms can be differentiated based on the type of information mechanisms can be differentiated based on the type of information
conveyed in the overload control feedback. conveyed in the overload control feedback. Another way to classify
explicit overload control mechanisms is whether the control function
is in the receiving or sending entity (receiver- vs. sender-based
overload control).
7.1. Rate-based Overload Control 9.1. Rate-based Overload Control
The key idea of rate-based overload control is to limit the request The key idea of rate-based overload control is to limit the request
rate at which an upstream element is allowed to forward to the rate at which an upstream element is allowed to forward traffic to
downstream neighbor. If overload occurs, a SIP server instructs each the downstream neighbor. If overload occurs, a SIP server instructs
upstream neighbor to send at most X requests per second. Each each upstream neighbor to send at most X requests per second. Each
upstream neighbor can be assigned a different rate cap. upstream neighbor can be assigned a different rate cap.
An example algorithm for the Actuator in a sending entity to An example algorithm for the Actuator in a sending entity to
implement a rate cap request gapping. After transmitting a request implement a rate cap is request gapping. After transmitting a
to a downstream neighbor, a server waits for 1/X seconds before it request to a downstream neighbor, a server waits for 1/X seconds
transmits the next request to the same neighbor. Requests that before it transmits the next request to the same neighbor. Requests
arrive during the waiting period are not forwarded and are either that arrive during the waiting period are not forwarded and are
redirected, rejected or buffered. either redirected, rejected or buffered.
The rate cap ensures that the number of requests received by a SIP The rate cap ensures that the number of requests received by a SIP
server never increases beyond the sum of all rate caps granted to server never increases beyond the sum of all rate caps granted to
upstream neighbors. Rate-based overload control protects a SIP upstream neighbors. Rate-based overload control protects a SIP
server against overload even during load spikes assuming there are no server against overload even during load spikes assuming there are no
new upstream neighbors that start sending traffic. New upstream new upstream neighbors that start sending traffic. New upstream
neighbors need to be considered in all rate caps currently assigned neighbors need to be considered in all rate caps currently assigned
to upstream neighbors. The current overall rate cap of a SIP server to upstream neighbors. The current overall rate cap of a SIP server
is determined by an overload control algorithm, e.g., based on system is determined by an overload control algorithm, e.g., based on system
load. load.
skipping to change at page 14, line 22 skipping to change at page 15, line 40
the server. the server.
An approach for estimating a rate cap for each upstream neighbor is An approach for estimating a rate cap for each upstream neighbor is
using a fixed proportion of a control variable, X, where X is using a fixed proportion of a control variable, X, where X is
initially equal to the capacity of the SIP server. The server then initially equal to the capacity of the SIP server. The server then
increases or decreases X until the workload arrival rate matches the increases or decreases X until the workload arrival rate matches the
actual server capacity. Usually, this will mean that the sum of the actual server capacity. Usually, this will mean that the sum of the
rate caps sent out by the server (=X) exceeds its actual capacity, rate caps sent out by the server (=X) exceeds its actual capacity,
but enables upstream neighbors who are not generating more than their but enables upstream neighbors who are not generating more than their
fair share of the work to be effectively unrestricted. In this fair share of the work to be effectively unrestricted. In this
approach, the server only has to measure the aggregate arrival rate, approach, the server only has to measure the aggregate arrival rate.
however, since the overall rate cap is usually higher than the actual However, since the overall rate cap is usually higher than the actual
capacity, brief periods of overload may occur. capacity, brief periods of overload may occur.
7.2. Loss-based Overload Control 9.2. Loss-based Overload Control
A loss percentage enables a SIP server to ask an upstream neighbor to A loss percentage enables a SIP server to ask an upstream neighbor to
reduce the number of requests it would normally forward to this reduce the number of requests it would normally forward to this
server by a percentage X. For example, a SIP server can ask an server by a percentage X. For example, a SIP server can ask an
upstream neighbor to reduce the number of requests this neighbor upstream neighbor to reduce the number of requests this neighbor
would normally send by 10%. The upstream neighbor then redirects or would normally send by 10%. The upstream neighbor then redirects or
rejects X percent of the traffic that is destined for this server. rejects X percent of the traffic that is destined for this server.
An algorithm for the sending entity to implement a loss percentage is An algorithm for the sending entity to implement a loss percentage is
to draw a random number between 1 and 100 for each request to be to draw a random number between 1 and 100 for each request to be
skipping to change at page 15, line 10 skipping to change at page 16, line 28
when forwarding traffic), the current system utilization and the when forwarding traffic), the current system utilization and the
desired system utilization. For example, if the server load desired system utilization. For example, if the server load
approaches 90% and the current loss percentage is set to a 50% approaches 90% and the current loss percentage is set to a 50%
traffic reduction, then the server can decide to increase the loss traffic reduction, then the server can decide to increase the loss
percentage to 55% in order to get to a system utilization of 80%. percentage to 55% in order to get to a system utilization of 80%.
Similarly, the server can lower the loss percentage if permitted by Similarly, the server can lower the loss percentage if permitted by
the system utilization. the system utilization.
Loss-based overload control requires that the throttle percentage is Loss-based overload control requires that the throttle percentage is
adjusted to the current overall number of requests received by the adjusted to the current overall number of requests received by the
server. This is in particular important if the number of requests server. This is particularly important if the number of requests
received fluctuates quickly. For example, if a SIP server sets a received fluctuates quickly. For example, if a SIP server sets a
throttle value of 10% at time t1 and the number of requests increases throttle value of 10% at time t1 and the number of requests increases
by 20% between time t1 and t2 (t1<t2), then the server will see an by 20% between time t1 and t2 (t1<t2), then the server will see an
increase in traffic by 10% between time t1 and t2. This is even increase in traffic by 10% between time t1 and t2. This is even
though all upstream neighbors have reduced traffic by 10% as told. though all upstream neighbors have reduced traffic by 10% as told.
Thus, percentage throttling requires an adjustment of the throttling Thus, percentage throttling requires an adjustment of the throttling
percentage in response to the traffic received and may not always be percentage in response to the traffic received and may not always be
able to prevent a server from encountering brief periods of overload able to prevent a server from encountering brief periods of overload
in extreme cases. in extreme cases.
7.3. Window-based Overload Control 9.3. Window-based Overload Control
The key idea of window-based overload control is to allow an entity 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 to transmit a certain number of messages before it needs to receive a
confirmation for the messages in transit. Each sender maintains an confirmation for the messages in transit. Each sender maintains an
overload window that limits the number of messages that can be in overload window that limits the number of messages that can be in
transit without being confirmed. transit without being confirmed.
Each sender maintains an unconfirmed message counter for each Each sender maintains an unconfirmed message counter for each
downstream neighbor it is communicating with. For each message sent downstream neighbor it is communicating with. For each message sent
to the downstream neighbor, the counter is increased by one. For to the downstream neighbor, the counter is increased. For each
each confirmation received, the counter is decreased by one. The confirmation received, the counter is decreased. The sender stops
sender stops transmitting messages to the downstream neighbor when transmitting messages to the downstream neighbor when the unconfirmed
the unconfirmed message counter has reached the current window size. message counter has reached the current window size.
A crucial parameter for the performance of window-based overload A crucial parameter for the performance of window-based overload
control is the window size. Each sender has an initial window size control is the window size. Each sender has an initial window size
it uses when first sending a request. This window size can be it uses when first sending a request. This window size can be
changed based on the feedback it receives from the receiver. changed based on the feedback it receives from the receiver.
The sender adjusts its window size as soon as it receives the The sender adjusts its window size as soon as it receives the
corresponding feedback from the receiver. If the new window size is corresponding feedback from the receiver. If the new window size is
smaller than the current unconfirmed message counter, the sender smaller than the current unconfirmed message counter, the sender
stops transmitting messages until more messages are confirmed and the stops transmitting messages until more messages are confirmed and the
skipping to change at page 16, line 18 skipping to change at page 17, line 35
problems. problems.
The behavior and issues of window-based overload control are similar The behavior and issues of window-based overload control are similar
to rate-based overload control, in that the total available receiver to rate-based overload control, in that the total available receiver
buffer space needs to be divided among all upstream neighbors. buffer space needs to be divided among all upstream neighbors.
However, unlike rate-based overload control, window-based overload However, unlike rate-based overload control, window-based overload
control can ensure that the receiver buffer does not overflow under control can ensure that the receiver buffer does not overflow under
normal conditions. The transmission of messages by senders is normal conditions. The transmission of messages by senders is
effectively clocked by message confirmations received from the effectively clocked by message confirmations received from the
receiver. A buffer overflow can occur if a large number of new receiver. A buffer overflow can occur if a large number of new
upstream neighbors arrives at the same time. upstream neighbors arrives at the same time. In window-based
overload control, the number of messages a sender is allowed to send
can be set to zero. In these cases, the sender needs to be informed
through an out-of-band mechanism that it is allowed to send again if
the window at the receiver has opened up.
7.4. Overload Signal-based Overload Control 9.4. Overload Signal-based Overload Control
The key idea of overload signal-based overload control is to use the The key idea of overload signal-based overload control is to use the
transmission of a 503 (Service Unavailable) response as a signal for transmission of a 503 (Service Unavailable) response as a signal for
overload in the downstream neighbor. After receiving a 503 (Service overload in the downstream neighbor. After receiving a 503 (Service
Unavailable) response, the sender reduces the load forwarded to the Unavailable) response, the sender reduces the load forwarded to the
downstream neighbor to avoid triggering more 503 (Service downstream neighbor to avoid triggering more 503 (Service
Unavailable) responses. The sender reduces the load further if more Unavailable) responses. The sender keeps reducing the load if 503
503 (Service Unavailable) responses are returned. This scheme is (Service Unavailable) responses are received. This scheme is based
based on the use of 503 (Service Unavailable) responses without on the use of 503 (Service Unavailable) responses without Retry-After
Retry-After header as the Retry-After header would require a sender header as the Retry-After header would require a sender to entirely
to stop forwarding requests. stop forwarding requests.
A sender which has not received 503 (Service Unavailable) responses A sender which has not received 503 (Service Unavailable) responses
for a while but is still throttling traffic can start to increase the for a while but is still throttling traffic can start to increase the
offered load. By slowly increasing load a sender can detect that offered load. By slowly increasing the traffic forwarded a sender
overload in the downstream neighbor has been resolved and more load can detect that overload in the downstream neighbor has been resolved
can be forwarded. The load is increased until the sender again and more load can be forwarded. The load is increased until the
receives another 503 (Service Unavailable) response or is forwarding sender again receives another 503 (Service Unavailable) response or
all requests it has. is forwarding all requests it has.
A possible algorithm for adjusting traffic is additive increase/ A possible algorithm for adjusting traffic is additive increase/
multiplicative decrease (AIMD). multiplicative decrease (AIMD).
7.5. On-/Off Overload Control Overload Signal-based Overload Control is a sender-based overload
control mechanism.
9.5. On-/Off Overload Control
On-/off overload control feedback enables a SIP server to turn the On-/off overload control feedback enables a SIP server to turn the
traffic it is receiving either on or off. The 503 (Service traffic it is receiving either on or off. The 503 (Service
Unavailable) response with Retry-After header implements on-/off Unavailable) response with Retry-After header implements on-/off
overload control. On-/off overload control is less effective in overload control. On-/off overload control is less effective in
controlling load than the fine grained control methods above. In controlling load than the fine grained control methods above. In
fact, the above methods can realize on/-off overload control, e.g., fact, all above methods can realize on/-off overload control, e.g.,
by setting the allowed rate to either zero or unlimited. by setting the allowed rate to either zero or unlimited.
8. Implicit Overload Control 10. Implicit Overload Control
Implicit overload control ensures that the transmission of a SIP Implicit overload control ensures that the transmission of a SIP
server is self-limiting. It slows down the transmission rate of a server is self-limiting. It slows down the transmission rate of a
sender when there is an indication that the receiving entity is sender when there is an indication that the receiving entity is
experiencing overload. Such an indication can be that the receiving experiencing overload. Such an indication can be that the receiving
entity is not responding within the expected timeframe or is not entity is not responding within the expected timeframe or is not
responding at all. The idea of implicit overload control is that responding at all. The idea of implicit overload control is that
senders should try to sense overload of a downstream neighbor even if senders should try to sense overload of a downstream neighbor even if
there is no explicit overload control feedback. It avoids that an there is no explicit overload control feedback. It avoids that an
overloaded server, which has become unable to generate overload overloaded server, which has become unable to generate overload
control feedback, will be overwhelmed with requests. control feedback, will be overwhelmed with requests.
Window-based overload control is inherently self-limiting since a Window-based overload control is inherently self-limiting since a
sender cannot continue without receiving confirmations. All other sender cannot continue without receiving confirmations. All other
explicit overload control schemes described above do not have this explicit overload control schemes described above do not have this
property and require additional implicit controls to limit property and require additional implicit controls to limit
transmissions in case an overloaded downstream neighbor does not transmissions in case an overloaded downstream neighbor does not
generate explicit feedback. generate explicit feedback.
9. Overload Control Algorithms 11. Overload Control Algorithms
An important aspect of the design of an overload control mechanism is An important aspect of the design of an overload control mechanism is
the overload control algorithm. The control algorithm determines the overload control algorithm. The control algorithm determines
when the amount of traffic to a SIP server needs to be decreased and when the amount of traffic to a SIP server needs to be decreased and
when it can be increased. In terms of the model described in when it can be increased. In terms of the model described in
Section 4 the control algorithm takes (S) as an input value and Section 4 the control algorithm takes (S) as an input value and
generates (T) as a result. generates (T) as a result.
Overload control algorithms have been studied to a large extent and Overload control algorithms have been studied to a large extent and
many different overload control algorithms exist. With many many different overload control algorithms exist. With many
different overload control algorithms available, it seems reasonable different overload control algorithms available, it seems reasonable
to define a baseline algorithm and allow the use of other algorithms to define a baseline algorithm and allow the use of other algorithms
if they don't violate the protocol semantics. This will also allow if they don't violate the protocol semantics. This will also allow
the development of future algorithms, which may lead to a better the development of future algorithms, which may lead to a better
performance. performance.
10. Security Considerations 12. Message Prioritization
[TBD.] Overload control can require a SIP server to prioritize messages and
select messages that need to be rejected or redirected. The
selection is largely a matter of local policy of the SIP server. As
a general rule, a SIP server should prioritize high-priority
requests, such as emergency service requests, and preserve them as
much as possible during times of overload. It should also prioritize
messages for ongoing sessions over messages that set up a new
session.
11. IANA Considerations 13. Security Considerations
This document does not require any IANA considerations. Overload control mechanisms, in general, have security implications.
If not designed carefully they can, for example, be used to launch a
denial of service attack. The specific security risks and their
remedies depend on the actual protocol mechanisms chosen for overload
control. They need to be addressed in a document that specifies such
a mechanism.
Appendix A. Contributors 14. IANA Considerations
Contributors to this document are: Ahmed Abdelal (Sonus Networks), This document does not require any IANA considerations.
Mary Barnes (Nortel), Carolyn Johnson (AT&T Labs), Daryl Malas
(CableLabs), Eric Noel (AT&T Labs), Tom Phelan (Sonus Networks),
Jonathan Rosenberg (Cisco), Henning Schulzrinne (Columbia
University), Charles Shen (Columbia University), Nick Stewart
(British Telecommunications plc), Rich Terpstra (Level 3), Fangzhe
Chang (Bell Labs/Alcatel-Lucent). Many thanks!
12. Informative References 15. Informative References
[I-D.ietf-sipping-overload-reqs] [Hilt et al.]
Rosenberg, J., "Requirements for Management of Overload in Hilt, V. and I. Widjaja, "Controlling Overload in Networks
the Session Initiation Protocol", of SIP Servers", IEEE International Conference on Network
draft-ietf-sipping-overload-reqs-05 (work in progress), Protocols (ICNP'08), Orlando, Florida, October 2008.
July 2008.
[Noel et al.]
Noel, E. and C. Johnson, "Initial Simulation Results That
Analyze SIP Based VoIP Networks Under Overload",
International Teletraffic Congress (ITC'07), Ottawa,
Canada, June 2007.
[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.
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)", Priority for the Session Initiation Protocol (SIP)",
RFC 4412, February 2006. RFC 4412, February 2006.
[RFC5390] Rosenberg, J., "Requirements for Management of Overload in
the Session Initiation Protocol", RFC 5390, December 2008.
[Shen et al.]
Shen, C., Schulzrinne, H., and E. Nahum, "Session
Initiation Protocol (SIP) Server Overload Control: Design
and Evaluation, Principles", Systems and Applications of
IP Telecommunications (IPTComm'08), Heidelberg, Germany,
July 2008.
Appendix A. Contributors
Contributors to this document are: Ahmed Abdelal (Sonus Networks),
Mary Barnes (Nortel), Carolyn Johnson (AT&T Labs), Daryl Malas
(CableLabs), Eric Noel (AT&T Labs), Tom Phelan (Sonus Networks),
Jonathan Rosenberg (Cisco), Henning Schulzrinne (Columbia
University), Charles Shen (Columbia University), Nick Stewart
(British Telecommunications plc), Rich Terpstra (Level 3), Fangzhe
Chang (Bell Labs/Alcatel-Lucent). Many thanks!
Author's Address Author's Address
Volker Hilt (Ed.) Volker Hilt (Ed.)
Bell Labs/Alcatel-Lucent Bell Labs/Alcatel-Lucent
791 Holmdel-Keyport Rd 791 Holmdel-Keyport Rd
Holmdel, NJ 07733 Holmdel, NJ 07733
USA USA
Email: volkerh@bell-labs.com Email: volkerh@bell-labs.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
 End of changes. 58 change blocks. 
167 lines changed or deleted 294 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/