draft-ietf-sipping-overload-design-01.txt   draft-ietf-sipping-overload-design-02.txt 
SIPPING Working Group V. Hilt (Ed.) SIPPING Working Group V. Hilt
Internet-Draft Bell Labs/Alcatel-Lucent Internet-Draft Bell Labs/Alcatel-Lucent
Intended status: Informational March 7, 2009 Intended status: Informational E. Noel
Expires: September 8, 2009 Expires: January 12, 2010 AT&T Labs
C. Shen
Columbia University
A. Abdelal
Sonus Networks
July 11, 2009
Design Considerations for Session Initiation Protocol (SIP) Overload Design Considerations for Session Initiation Protocol (SIP) Overload
Control Control
draft-ietf-sipping-overload-design-01 draft-ietf-sipping-overload-design-02
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), 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.
skipping to change at page 1, line 33 skipping to change at page 1, line 38
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 September 8, 2009. This Internet-Draft will expire on January 12, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 30 skipping to change at page 2, line 35
6. Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Performance Metrics . . . . . . . . . . . . . . . . . . . . . 13 8. Performance Metrics . . . . . . . . . . . . . . . . . . . . . 13
9. Explicit Overload Control Feedback . . . . . . . . . . . . . . 14 9. Explicit Overload Control Feedback . . . . . . . . . . . . . . 14
9.1. Rate-based Overload Control . . . . . . . . . . . . . . . 14 9.1. Rate-based Overload Control . . . . . . . . . . . . . . . 14
9.2. Loss-based Overload Control . . . . . . . . . . . . . . . 15 9.2. Loss-based Overload Control . . . . . . . . . . . . . . . 15
9.3. Window-based Overload Control . . . . . . . . . . . . . . 16 9.3. Window-based Overload Control . . . . . . . . . . . . . . 16
9.4. Overload Signal-based Overload Control . . . . . . . . . . 17 9.4. Overload Signal-based Overload Control . . . . . . . . . . 17
9.5. On-/Off Overload Control . . . . . . . . . . . . . . . . . 18 9.5. On-/Off Overload Control . . . . . . . . . . . . . . . . . 18
10. Implicit Overload Control . . . . . . . . . . . . . . . . . . 18 10. Implicit Overload Control . . . . . . . . . . . . . . . . . . 18
11. Overload Control Algorithms . . . . . . . . . . . . . . . . . 19 11. Overload Control Algorithms . . . . . . . . . . . . . . . . . 18
12. Message Prioritization . . . . . . . . . . . . . . . . . . . . 19 12. Message Prioritization . . . . . . . . . . . . . . . . . . . . 19
13. Security Considerations . . . . . . . . . . . . . . . . . . . 19 13. Security Considerations . . . . . . . . . . . . . . . . . . . 19
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
15. Informative References . . . . . . . . . . . . . . . . . . . . 19 15. Informative References . . . . . . . . . . . . . . . . . . . . 19
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 20 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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 4, line 45 skipping to change at page 4, line 45
request or a message belonging to an existing transaction. However, request or a message belonging to an existing transaction. However,
after having spend resources on parsing a SIP message, discarding after having spend resources on parsing a SIP message, discarding
this message is expensive as the resources already spend are lost. this message is expensive as the resources already spend are lost.
The number of successful transactions will therefore decline with an 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 and more and more resources are consumed by forwarding messages and more and more resources are consumed by
inspecting messages that will eventually be dropped. The slope of inspecting messages that will eventually be dropped. The slope of
the decline depends on the amount of resources spent to inspect each the decline depends on the amount of resources spent to inspect each
message. message.
Another key challenge for SIP overload control is that the rate of Another challenge for SIP overload control is that the rate of the
the true traffic source usually cannot be controlled. Overload is true traffic source usually cannot be controlled. Overload is often
often caused by a large number of UAs each of which creates only a caused by a large number of UAs each of which creates only a single
single message. These UAs cannot be rate controlled as they only message. These UAs cannot be rate controlled as they only send one
send one message. However, the sum of their traffic can overload a message. However, the sum of their traffic can overload a SIP
SIP server. 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
skipping to change at page 9, line 46 skipping to change at page 9, line 46
requests will eventually be forwarded to an overloaded server. For requests will eventually be forwarded to an overloaded server. For
example, if D is overloaded in Figure 2(b), A should only throttle example, if D is overloaded in Figure 2(b), A should only throttle
requests it forwards to B when it knows that they will be forwarded requests it forwards to B when it knows that they will be forwarded
to D. It should not throttle requests that will eventually be to D. It should not throttle requests that will eventually be
forwarded to C, since server C is not overloaded. In many cases, it forwarded to C, since server C is not overloaded. In many cases, 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 message to a target has been routed through an overload previous message to a target has been routed through an overloaded
server does not necessarily mean the next message to this target will server does not necessarily mean the next message to this target will
also be routed through the same server. also be routed through the same server.
The main problem of end-to-end overload control is its inherent The main problem of end-to-end overload control is its inherent
complexity since UAC or SIP servers need to monitor all potential complexity since UAC or SIP servers need to monitor all potential
paths to a destination in order to determine which requests should be paths to a destination in order to determine which requests should be
throttled and which requests may be sent. Even if this information throttled and which requests may be sent. Even if this information
is available, it is not clear which path a specific request will is available, it is not clear which path a specific request will
take. take.
A variant of end-to-end overload control is to implement a control 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 loop between a set of well-known SIP servers along the path of a SIP
of a SIP request. For example, an overload control loop can be request. For example, an overload control loop can be instantiated
instantiated between a server that only has one downstream neighbor between a server that only has one downstream neighbor or a set of
or a set of closely coupled SIP servers. A control loop spanning closely coupled SIP servers. A control loop spanning multiple hops
multiple hops can be used if the sending entity has full knowledge can be used if the sending entity has full knowledge about the SIP
about the SIP servers on the path of a SIP message. 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 between 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. Even SIP messages containing has its own source and destination. Even SIP messages containing
identical SIP URIs (e.g., a SUBSCRIBE and a INVITE message to the identical SIP URIs (e.g., a SUBSCRIBE and a INVITE message to the
same SIP URI) can be routed to different destinations. This is same SIP URI) can be routed to different destinations. This is
different from TCP which controls a stream of packets between a different from TCP which controls a stream of packets between a
single source and a single destination. single source and a single destination.
skipping to change at page 10, line 39 skipping to change at page 10, line 39
Monitor and Actuator on the same server. This enables the server to Monitor and Actuator on the same server. This enables the server to
monitor the current resource usage and to reject messages that can't monitor the current resource usage and to reject messages that can't
be processed without overusing the local resources. The fundamental be processed without overusing the local resources. The fundamental
assumption behind local overload control is that it is less resource assumption behind local overload control is that it is less resource
consuming for a server to reject messages than to process them. A consuming for a server to reject messages than to process them. A
server can therefore reject the excess messages it cannot process to server can therefore reject the excess messages it cannot process to
stop all retransmissions of these messages. stop all retransmissions of these messages.
Local overload control can be used in conjunction with an other Local overload control can be used in conjunction with an other
overload control mechanisms and provides an additional layer of overload control mechanisms and provides an additional layer of
protection against overload. It is fully implemented on the local protection against overload. It is fully implemented within a SIP
server and does not require any cooperation from upstream neighbors. server and does not require cooperation between servers. In general,
In general, SIP servers should apply implicit or explicit overload SIP servers should apply other overload control techniques to control
control techniques to control load before a local overload control load before a local overload control mechanism is activated as a
mechanism is activated as a mechanism of last resort. 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 13, line 14 skipping to change at page 13, line 14
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. Fairness 7. Fairness
There are many different ways to define fairness if a SIP server has There are many different ways to define fairness between multiple
multiple upstream neighbors. In the context of SIP server overload, upstream neighbors of a SIP server. In the context of SIP server
it is helpful to describe two categories of fairness criteria: basic overload, it is helpful to describe two categories of fairness: basic
fairness and customized fairness. With basic fairness a SIP server fairness and customized fairness. With basic fairness a SIP server
treats all end-users equally and ensures that each end-user has the treats all end users equally and ensures that each end user has the
same chance in accessing the server resources. With customized same chance of reaching the destination server. With customized
fairness the server allocate resources according to different fairness, the server allocates resources according to different
priorities. An example application of the basic fairness criteria is priorities. An example application of the basic fairness criteria is
the "Third caller receives free tickets" scenario, where each end- the "Third caller receives free tickets" scenario, where each end
user should have an equal success probability in making calls through user should have an equal success probability in making calls through
an overloaded SIP server, regardless of which service provider he/she an overloaded SIP server, regardless of which service provider he/she
is subscribing to. An example of customized fairness would be a is subscribed to. An example of customized fairness would be a
server which gives different resource allocations to its upstream server which assigns different resource allocations to its upstream
neighbors (e.g., service providers) as defined in service level neighbors (e.g., service providers) as defined in a service level
agreements. agreement (SLA).
8. Performance Metrics 8. Performance Metrics
The performance of an overload control mechanism can be measured The performance of an overload control mechanism can be measured
using different metrics. using different metrics.
A key performance indicator is the goodput of a SIP server during A key performance indicator is the goodput of a SIP server under
overload. Ideally, a SIP server is enabled to perform at its overload. Ideally, a SIP server will be enabled to perform at its
capacity limit during periods of overload. E.g., if a SIP server has capacity limit during periods of overload. E.g., if a SIP server has
a processing capacity of 140 INVITE transactions per second then an a processing capacity of 140 INVITE transactions per second then an
overload control mechanism should enable it to handle 140 INVITEs per overload control mechanism should enable it to process 140 INVITEs
second even if the offered load is much higher. The delay introduced per second even if the offered load is much higher. The delay
by a SIP server is another important indicator. An overload control introduced by a SIP server is another important indicator. An
mechanism should ensure that the delay encountered by a SIP message overload control mechanism should ensure that the delay encountered
is not increased significantly during periods of overload. by a SIP message is not increased significantly during periods of
overload.
Reactiveness and stability are other important performance Reactiveness and stability are other important performance
indicators. An overload control mechanism should quickly react to an indicators. An overload control mechanism should quickly react to an
overload occurrence and ensure that a SIP server does not become overload occurrence and ensure that a SIP server does not become
overloaded even during sudden peaks of load. Similarly, an overload overloaded even during sudden peaks of load. Similarly, an overload
control mechanism should quickly remove all throttles if the overload control mechanism should quickly remove all throttles if the overload
disappears. Stability is another important criteria as using an disappears. Stability is another important criteria. An overload
overload control mechanism should not lead to the oscillation of load control mechanism should not cause significant oscillations of load
on a SIP server. The performance of SIP overload control mechanisms on a SIP server. The performance of SIP overload control mechanisms
is discussed in [Noel et al.], [Shen et al.] and [Hilt et al.]. 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 In addition to the above metrics, there are other indicators that are
relevant for the evaluation of an overload control mechanism: relevant for the evaluation of an overload control mechanism:
Fairness: Which types of fairness does the overload control Fairness: Which types of fairness does the overload control
mechanism implement? mechanism implement?
Self-limiting: Is the overload control self-limiting if a SIP server Self-limiting: Is the overload control self-limiting if a SIP server
becomes unresponsive? becomes unresponsive?
Changes in neighbor set: How does the mechanism adapt to a changing Changes in neighbor set: How does the mechanism adapt to a changing
set of sending entities? set of sending entities?
Data points to monitor: Which data points does an overload control Data points to monitor: Which and how many data points does an
mechanism need to monitor? 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 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. Another way to classify conveyed in the overload control feedback and whether the control
explicit overload control mechanisms is whether the control function function is in the receiving or sending entity (receiver- vs. sender-
is in the receiving or sending entity (receiver- vs. sender-based based overload control).
overload control).
9.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 traffic to rate at which an upstream element is allowed to forward traffic to
the downstream neighbor. If overload occurs, a SIP server instructs the downstream neighbor. If overload occurs, a SIP server instructs
each 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 an Actuator in the sending entity is request
implement a rate cap is request gapping. After transmitting a gapping. After transmitting a request to a downstream neighbor, a
request to a downstream neighbor, a server waits for 1/X seconds server waits for 1/X seconds before it transmits the next request to
before it transmits the next request to the same neighbor. Requests the same neighbor. Requests that arrive during the waiting period
that arrive during the waiting period are not forwarded and are are not forwarded and are either 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 assigned to upstream
to upstream neighbors. The current overall rate cap of a SIP server neighbors. The overall rate cap of a SIP server is determined by an
is determined by an overload control algorithm, e.g., based on system overload control algorithm, e.g., based on system load.
load.
Rate-based overload control requires a SIP server to assign a rate Rate-based overload control requires a SIP server to assign a rate
cap to each of its upstream neighbors while it is activated. cap to each of its upstream neighbors while it is activated.
Effectively, a server needs to assign a share of its overall capacity Effectively, a server needs to assign a share of its overall capacity
to each upstream neighbor. A server needs to ensure that the sum of to each upstream neighbor. A server needs to ensure that the sum of
all rate caps assigned to upstream neighbors is not (significantly) all rate caps assigned to upstream neighbors is not higher than its
higher than its actual processing capacity. This requires a SIP actual processing capacity. This requires a SIP server to keep track
server to keep track of the set of upstream neighbors and to adjust of the set of upstream neighbors and to adjust the rate cap if a new
the rate cap if a new upstream neighbor appears or an existing upstream neighbor appears or an existing neighbor stops transmitting.
neighbor stops transmitting. For example, if the capacity of the For example, if the capacity of the server is X and this server is
server is X and this server is receiving traffic from two upstream receiving traffic from two upstream neighbors, it can assign a rate
neighbors, it can assign a rate of X/2 to each of them. If a third of X/2 to each of them. If a third sender appears, the rate for each
sender appears, the rate for each sender is lowered to X/3. If the sender is lowered to X/3. If the overall rate cap is too high, a
rate cap assigned to upstream neighbors is too high, a server may server may experience overload. If the cap is too low, the upstream
still experience overload. If the cap is too low, the upstream
neighbors will reject requests even though they could be processed by neighbors will reject requests even though they could be processed by
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
skipping to change at page 17, line 16 skipping to change at page 17, line 8
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
current unconfirmed message counter is less than the window size. current unconfirmed message counter is less than the window size.
A sender should not treat the reception of a 100 Trying response as Note that the reception of a 100 Trying response does not provide a
an implicit confirmation for a message. 100 Trying responses are confirmation for the reception of a message. 100 Trying responses are
often created by a SIP server very early in processing and do not often created by a SIP server very early in processing and do not
indicate that a message has been successfully processed and cleared indicate that a message has been successfully processed and cleared
from the input buffer. If the downstream neighbor is a stateless from the input buffer. If the downstream neighbor is a stateless
proxy, it will not create 100 Trying responses at all and instead proxy, it will not create 100 Trying responses at all and instead
pass through 100 Trying responses created by the next stateful pass through 100 Trying responses created by the next stateful
server. Also, 100 Trying responses are typically only created for server. Also, 100 Trying responses are typically only created for
INVITE requests. Explicit message confirmations do not have these INVITE requests. Explicit message confirmations do not have these
problems. problems.
The behavior and issues of window-based overload control are similar Window-based overload control is similar to rate-based overload
to rate-based overload control, in that the total available receiver control in that the total available receiver buffer space needs to be
buffer space needs to be divided among all upstream neighbors. divided among all upstream neighbors. However, unlike rate-based
However, unlike rate-based overload control, window-based overload overload control, window-based overload control is self-limiting and
control can ensure that the receiver buffer does not overflow under can ensure that the receiver buffer does not overflow under normal
normal conditions. The transmission of messages by senders is conditions. The transmission of messages by senders is clocked by
effectively clocked by message confirmations received from the message confirmations received from the receiver. A buffer overflow
receiver. A buffer overflow can occur if a large number of new can occur if a large number of new upstream neighbors arrives at the
upstream neighbors arrives at the same time. In window-based same time. However, senders will eventually stop transmitting new
overload control, the number of messages a sender is allowed to send requests once their initial sending window is closed.
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 In window-based overload control, the number of messages a sender is
the window at the receiver has opened up. allowed to send can frequently be set to zero. In this state, the
sender needs to be informed when it is allowed to send again and the
receiver window has opened up. However, since the sender is not
allowed to transmit messages, the receiver cannot convey the new
window size by piggybacking it in a response to another message.
Instead, it needs to inform the sender through another mechanism,
e.g., by sending a message that contains the new window size.
9.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 keeps reducing the load if 503 Unavailable) responses. The sender keeps reducing the load if more
(Service Unavailable) responses are received. This scheme is based 503 (Service Unavailable) responses are received. Note that this
on the use of 503 (Service Unavailable) responses without Retry-After scheme is based on the use of 503 (Service Unavailable) responses
header as the Retry-After header would require a sender to entirely without Retry-After header as the Retry-After header would require a
stop forwarding requests. sender to entirely 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 the traffic forwarded a sender offered load. By slowly increasing the traffic forwarded a sender
can detect that overload in the downstream neighbor has been resolved can detect that overload in the downstream neighbor has been resolved
and more load can be forwarded. The load is increased until the and more load can be forwarded. The load is increased until the
sender again receives another 503 (Service Unavailable) response or sender again receives another 503 (Service Unavailable) response or
is forwarding all requests it has. is forwarding all requests it has. A possible algorithm for
adjusting traffic is additive increase/multiplicative decrease
A possible algorithm for adjusting traffic is additive increase/ (AIMD).
multiplicative decrease (AIMD).
Overload Signal-based Overload Control is a sender-based overload Overload Signal-based Overload Control is a sender-based overload
control mechanism. control mechanism.
9.5. On-/Off Overload Control 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
skipping to change at page 19, line 17 skipping to change at page 19, line 13
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 suggest a baseline algorithm in a specification for a SIP overload
if they don't violate the protocol semantics. This will also allow control mechanism and allow the use of other algorithms if they
the development of future algorithms, which may lead to a better provide the same protocol semantics. This will also allow the
development of future algorithms, which may lead to a better
performance. performance.
12. Message Prioritization 12. Message Prioritization
Overload control can require a SIP server to prioritize messages and Overload control can require a SIP server to prioritize messages and
select messages that need to be rejected or redirected. The select messages that need to be rejected or redirected. The
selection is largely a matter of local policy of the SIP server. As selection is largely a matter of local policy of the SIP server. As
a general rule, a SIP server should prioritize high-priority a general rule, a SIP server should preserve high-priority requests
requests, such as emergency service requests, and preserve them as such as emergency service requests as much as possible during times
much as possible during times of overload. It should also prioritize of overload. It should also prioritize messages for ongoing sessions
messages for ongoing sessions over messages that set up a new over messages that set up a new session.
session.
13. Security Considerations 13. Security Considerations
Overload control mechanisms, in general, have security implications. Overload control mechanisms, in general, have security implications.
If not designed carefully they can, for example, be used to launch a If not designed carefully they can, for example, be used to launch a
denial of service attack. The specific security risks and their denial of service attack. The specific security risks and their
remedies depend on the actual protocol mechanisms chosen for overload remedies depend on the actual protocol mechanisms chosen for overload
control. They need to be addressed in a document that specifies such control. They need to be addressed in a document that specifies such
a mechanism. a mechanism.
skipping to change at page 20, line 35 skipping to change at page 20, line 32
[Shen et al.] [Shen et al.]
Shen, C., Schulzrinne, H., and E. Nahum, "Session Shen, C., Schulzrinne, H., and E. Nahum, "Session
Initiation Protocol (SIP) Server Overload Control: Design Initiation Protocol (SIP) Server Overload Control: Design
and Evaluation, Principles", Systems and Applications of and Evaluation, Principles", Systems and Applications of
IP Telecommunications (IPTComm'08), Heidelberg, Germany, IP Telecommunications (IPTComm'08), Heidelberg, Germany,
July 2008. July 2008.
Appendix A. Contributors Appendix A. Contributors
Contributors to this document are: Ahmed Abdelal (Sonus Networks), Contributors to this document are: Mary Barnes (Nortel), Carolyn
Mary Barnes (Nortel), Carolyn Johnson (AT&T Labs), Daryl Malas Johnson (AT&T Labs), Daryl Malas (CableLabs), Tom Phelan (Sonus
(CableLabs), Eric Noel (AT&T Labs), Tom Phelan (Sonus Networks), Networks), Jonathan Rosenberg (Cisco), Henning Schulzrinne (Columbia
Jonathan Rosenberg (Cisco), Henning Schulzrinne (Columbia University), Nick Stewart (British Telecommunications plc), Rich
University), Charles Shen (Columbia University), Nick Stewart Terpstra (Level 3), Fangzhe Chang (Bell Labs/Alcatel-Lucent). Many
(British Telecommunications plc), Rich Terpstra (Level 3), Fangzhe thanks!
Chang (Bell Labs/Alcatel-Lucent). Many thanks!
Author's Address Authors' Addresses
Volker Hilt (Ed.) Volker Hilt
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
Eric Noel
AT&T Labs
Email: eric.noel@att.com
Charles Shen
Columbia University
Email: charles@cs.columbia.edu
Ahmed Abdelal
Sonus Networks
Email: aabdelal@sonusnet.com
 End of changes. 32 change blocks. 
117 lines changed or deleted 118 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/