[secdir] [New-work] WG Review: SIP Overload Control (soc)

[IESG Secretary <[e-mail]>]

A new IETF working group has been proposed in the Real-time Applications
and Infrastructure Area.  The IESG has not made any determination as yet.
The following draft charter was submitted, and is provided for
informational purposes only. Please send your comments to the IESG mailing
list ([e-mail]) by Tuesday, May 4, 2010.   

SIP Overload Control (soc)
---------------------------
Current Status: Proposed Working Group

Last Modified: 2010-04-22

Chair(s)
TBD

Real-time Applications and Infrastructure Area Directors:
   Gonzalo Camarillo <[e-mail]>
   Robert Sparks <[e-mail]>

Real-time Applications and Infrastructure Area Advisor:
   Robert Sparks <[e-mail]>

Mailing Lists:
   General Discussion: [e-mail]
   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, the goodput (effective application throughput not 
counting the overhead of retransmission and redundant data) of a network 
of SIP servers can be significantly degraded.  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.  This is often called 
congestion collapse. 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.

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
_______________________________________________
New-work mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/new-work