IETF 80 Proceedings

Introduction  |  Area, Working Goup & BoF Reports  |  Plenaries  |  Training  |  Internet Research Task Force

SIP Overload Control (soc) (WG)

Minutes  | Audio Archives  |  Jabber Logs  |  Mailing List Archives

Additional information is available at tools.ietf.org/wg/soc

Chair(s): Volker Hilt Salvatore Loreto Real-time Applications and Infrastructure Area Director(s): Gonzalo Camarillo Robert Sparks * The Real-time Applications and Infrastructure Area Directors were seated during the IETF 65. Real-time Applications and Infrastructure Area Advisor: Robert Sparks

Meeting Slides

• Intro
• draft-ietf-soc-overload-control
• overload control event pck
• avalanche restart

Internet-Drafts:

• Design Considerations for Session Initiation Protocol (SIP) Overload Control (61850 bytes)
• Session Initiation Protocol (SIP) Overload Control (65090 bytes)
• A Session Initiation Protocol (SIP) Load Control Event Package (75555 bytes)

No Request For Comments

Charter (as of 2010-12-08)

As with any network element, a Session Initiation Protocol (SIP) server
can suffer from overload when the number of SIP messages it receives
exceeds the number of messages it can process. Overload is said to occur
when a SIP server does not have sufficient resources to complete the
processing of all incoming SIP messages within the required time.
These resources can include CPU, memory, network bandwidth, input/
output, or disk resources.

Overload can pose a serious problem for a network of SIP servers.
During periods of overload, a network of SIP servers can be
significantly degraded with regard to "goodput" (effective
application throughput, not counting the overhead of retransmission
and redundant data). In fact, overload may lead to a situation in
which the goodput drops down to zero or a small fraction of the
original processing capacity. The objective of a SIP overload control
mechanism is to enable SIP servers to operate close to their capacity
limit during times of overload.

The SIP protocol provides a limited mechanism for overload control
through its 503 (Service Unavailable) response code and the Retry-After
header. However, this mechanism cannot fully prevent overload of a SIP
server and it cannot prevent congestion collapse. In fact, its on/off
behavior may cause traffic to oscillate and shift between SIP servers
and thereby worsen an overload condition. A detailed discussion of the
SIP overload problem, the problems with the 503 (Service Unavailable)
response code and the Retry-After header and the requirements for a SIP
overload control mechanism can be found in RFC5390.

The objective of the working group is to develop mechanisms for SIP
overload control. The problem domain of SIP overload control can be
split into overload control between a user agent and a SIP server and
overload control between SIP servers.

Any specification developed by the working group needs to clearly
specify its scope. A specification also needs to clearly state any
limitations, in performance or otherwise, the specified overload control
mechanism may have. In particular, the working group shall carefully
define the deployment considerations for the effective operation of the
specified mechanisms and discuss, for example, when a mechanism requires
coordinated deployment and operation (if all servers need to deploy the
same mechanism, certain configuration values need to be identical on all
servers, etc), when a mechanism can become less effective or ineffective
under some conditions, or especially if there are cases when a mechanism
can reduce goodput compared to no overload protection. The intent of
these considerations is to allow potential deployers to make the best
use of these mechanism in their particular networks.

The working group will consider two complementary approaches for
handling overload situations:
- The first mechanism aims at preventing overload in SIP servers by
adjusting the incoming load to a level that is acceptable for this
server. This mechanism uses implicit and/or explicit feedback to
determine when an overload condition occurs in a SIP server and a
reduction in load is required.
- The second mechanism aims at preventing overload in SIP servers by
distributing load control filters to SIP servers that throttle calls
based on their source or destination domain, telephone number prefix or
for a specific user. Such filters can be used, for example, to throttle
calls to a hotline during a ticket-giveaway event.

The working group will develop the following deliverables:

1. A document describing key design considerations for a SIP overload
control mechanism.
2. A specification for an SIP overload control mechanism based on
implicit/explicit feedback.
3. A specification for a SIP load filtering mechanism.

Goals and Milestones:

Dec 2010		Design Considerations to IESG for publication as Informational
May 2011		Specification for a SIP overload control mechanism based on implicit/explicit feedback to IESG for publication as Proposed Standard
Aug 2011		Specification for a SIP load filtering mechaism to IESG for publication as Proposed Standard