datatracker.ietf.org
Sign in
Version 5.6.2.p5, 2014-08-04
Report a bug

SIP Overload Control
charter-ietf-soc-01

Versions: 01
Charter for "SIP Overload Control" (soc) WG
WG State: Active
Charter State:
Responsible AD: none

Send notices to: none
Last updated: 2010-05-11

Other versions: plain text

Charter charter-ietf-soc-01

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.