A new IETF working group has been formed in the Real-time Applications and Infrastructure Area. For additional information, please contact the Area Directors or the WG Chairs. SIP Overload Control (soc) --------------------------- Current Status: Active Working Group Last Modified: 2010-05-06 Chair(s) Volker Hilt <volker.hilt@alcatel-lucent.com> Salvatore Loreto <salvatore.loreto@ericsson.com> Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo <gonzalo.camarillo@ericsson.com> Robert Sparks <rjsparks@nostrum.com> 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. 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 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
