2.5.15 SIP Overload Control (soc)

NOTE: This charter is a snapshot of the 78th IETF Meeting in Maastricht, Netherlands. It may now be out-of-date.

Last Modified: 2010-05-11

Chair(s):

Volker Hilt <volker.hilt@alcatel-lucent.com>
Salvatore Loreto <Salvatore.Loreto@ericsson.com>

Real-time Applications and Infrastructure Area Director(s):

Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Robert Sparks <rjsparks@nostrum.com>

* The Real-time Applications and Infrastructure Area Directors were seated during the IETF 65.

Real-time Applications and Infrastructure Area Advisor:

Robert Sparks <rjsparks@nostrum.com>

Mailing Lists:

General Discussion: sip-overload@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/sip-overload
Archive: http://www.ietf.org/mail-archive/web/sip-overload/

Description of Working Group:

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:

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

Internet-Drafts:

  • draft-ietf-soc-overload-design-01.txt

    No Request For Comments

    Meeting Minutes


    Slides

    Agenda Intro
    soc-overload-design
    SIP Overload Control
    SIP Load Control Event Package
    SoC based on Resource Availability
    Session Capacity Estimate (SCE)