appsawg J. Wang Internet-Draft Q. Yu Intended status: Informational L. Deng China Mobile Oct 18, 2013 End-to-end Session Initiation Protocol (SIP) overload control draft-wang-appsawg-end2end-overload-control-00 Abstract This draft proposes end-to-end Session Initiation Protocol (SIP) overload control, in which the edge servers of the SIP network throttle the arriving calls in order to control overload for the SIP network. Compared to the local and hop-by-hop SIP overload control, the end-to-end SIP overload control can achieve best performance. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Wang, et al. Expires April 18, 2014 [Page 1] Internet-Draft end2end SIP overload control Oct 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. End-to-end overload control scheme . . . . . . . . . . . . . 3 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. End-to-end overload control design . . . . . . . . . . . 3 2.3. End-to-end overload control algorithm . . . . . . . . . . 4 2.3.1. End-to-end overload control algorithm metrics . . . . 4 2.3.2. Default End-to-end overload control algorithm . . . . 5 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 5.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction Session Initiation Protocol (SIP) serves as a foundation for many of today's session-oriented applications, such as Voice over IP (VoIP), multimedia distributions, video conferencing, instant messaging and presence service. The widespread popularity and rapidly growing deployments of SIP require that SIP servers provide adequate control mechanisms to handle overload. Overload of a SIP server occurs if the message arrival rate to the server exceeds its message processing capacity. Under overload, the throughput of a SIP server can drop significantly and can even reach zero. Besides, the call setup delay becomes unacceptable for a real-time media call. In this case, the server enters into a congestion collapse. [RFC6357] has classified the SIP overload control approaches into local, hop-by-hop and end-to-end overload control. In local overload control, the SIP server monitors its load and starts to reject requests locally by using 503 (Service Unavailable) responses when it detects overload. In hop-by-hop overload control, the overloaded SIP server can provide feedback to its direct upstream neighbors, which then adjust the amount of traffic forwarded to this SIP server to eliminate overload. In end-to-end overload control, the edge servers, which are considered as the closest servers to the sources of traffic in a SIP network, are responsible for adjusting the amount of traffic forwarded to the overloaded server to eliminate overload. In the deployment scenarios (such as IMS) where the SIP call traverses through multiple SIP servers in a SIP network, local and hop-by-hop overload control are inefficient since overload is resolved near the overloaded sever. In this case, the SIP servers located between the edge server and the overloaded server waste their processing resources on processing a request that will finally be Wang, et al. Expires April 18, 2014 [Page 2] Internet-Draft end2end SIP overload control Oct 2013 rejected. On the other hand, in end-to-end overload control minimum resources of SIP networks are wasted on processing a request that will finally be rejected since the edge servers are responsible for rejecting requests. The research in [Hilt] indicates that the end-to-end overload control achieves the best performance (highest throughput) although it is the most complex among all types of overload control approaches. Based on them, this document proposes an end-to-end overload control mechanism for networks of SIP servers. 2. End-to-end overload control scheme 2.1. Overview The SIP network consists of edge servers and core servers. Each UA is connected to the network via an edge server located closest to it. When a SIP call between two UAs goes through the network, the first server the call arrives at is denoted as the ingress server, and the last server the call arrives at is denoted as the target server. It is clear that both ingress server and target server are edge servers. The design of end-to-end overload control should follow the principles as below: o Overload MUST be controlled at ingress servers. That is, arriving calls from UAs are throttled at ingress servers. Overload control works best if applied at the servers closest to the source of traffic because in this way minimum resources of SIP networks are wasted on processing a request that will finally be rejected. o Overload SHOULD be controlled on a per-target basis. That is, each ingress server throttles the arriving call from UAs based on its target server. Without the per-target basis, an ingress server should identify which server is overloaded and throttle arriving calls that will be routed through the overloaded server. On the other hand, with the per-target basis, an ingress server only needs to identify which target server the call passing through the overloaded server is related to, and throttle arriving calls that will be forwarded to this target server. Thus per- target basis makes it much easier for ingress servers to control overload for the SIP network 2.2. End-to-end overload control design In end-to-end overload control, the core servers SHOULD only implement local overload control that rejects requests by using 503 responses. When receiving a 503 response from a downstream neighbor, the server SHOULD forward this response to the upstream neighbor, Wang, et al. Expires April 18, 2014 [Page 3] Internet-Draft end2end SIP overload control Oct 2013 from which the INVITE request related to this response has been received. In this way, the 503 response will finally be forwarded to the edge server. The edge servers SHOULD calculate and follow the restrictions on the traffic admitted to the SIP network based on the received 503 responses. In end-to-end overload control, a set of control-units is deployed at each ingress server to control overload for the SIP network. At an ingress server, each control-unit is related to a specific target server and controls the arriving calls from UAs that take this ingress server as first-hop and the target server as last-hop in the network. Thus, the load of the network is controlled by control- units at all ingress servers. Note that this approach is completely distributed: there is no centralized entity to control control-units and each control-unit is functionally identical and operates independently. Besides, there is no communication between control- units. Finally, this approach can be deployed incrementally, by installing control-units on ingress servers, with no need to alter other servers in the SIP network. Therefore, this approach is easy to implement. 2.3. End-to-end overload control algorithm The main function of the control-unit is to decide the call admission rate, which is calculated by using the end-to-end overload control algorithm. 2.3.1. End-to-end overload control algorithm metrics Aggressiveness: The network is underutilized when the call admission rate is below the capacity of the network. In this case, control- unit needs to increase the call admission rate as fast as possible in order to make full use of network resources and avoid unnecessary call rejections. Aggressiveness measures how fast a control-unit makes use of network resources as they are available. The aggressiveness is defined as the inverse of the time needed for the control-unit to achieve the increment of a certain amount of call admission rate, in response to: (1) a step increase of available network resources or (2) a step increase of call arrival rate when there are available resources in the network. Obviously, high aggressiveness, implying potentially high utilization, is desirable. Responsiveness: The network is overloaded when the call admission rate exceeds the capacity of the network. In this case, control-unit needs to decrease the call admission rate as fast as possible in order to eliminate overload. Responsiveness measures how fast a control-unit decreases the call admission rate in response to overload. We define responsiveness as the inverse of the time needed Wang, et al. Expires April 18, 2014 [Page 4] Internet-Draft end2end SIP overload control Oct 2013 for the control-unit to achieve the decrement of a certain amount of call admission rate, in response to a step increase of network overload. Obviously, high responsiveness, which allows control-unit to decrease the call admission rate quickly when overload occurs, is desirable. Throughput: The network is fully utilized when the call admission rate is close to the capacity of the network. In this case, the throughput is determined by the overload control algorithm. Obviously, high throughput is desirable 2.3.2. Default End-to-end overload control algorithm The default end-to-end overload control algorithm presented here is only an example. Other algorithms that can achieve high aggressiveness, high responsiveness and high throughput may be used. The default end-to-end overload control algorithm consists of an increasing rule and a decreasing rule. When there is no overload feedback, the algorithm increases call admission rate according to the increasing rule. When receiving the overload feedback, the algorithm decreases call admission rate according to the decreasing rule. The control-unit periodically executes the overload control algorithm (with interval T) and takes the number of received 503 responses during each T as the overload feedback to the algorithm. The increasing rule and decreasing rule are shown as follows: increasing: r(t+1)=r(t)+a, a>0 decreasing: r(t+1)=r(t)-b*r(t), 1>b>0 where r(t) is the call admission rate at time t. a and b are constant factors. That is, if no call rejection is received, the call admission rate is increased additively. Otherwise, it is decreased multiplicatively. 3. Security Considerations TBA 4. IANA Considerations None. 5. References 5.1. Normative References Wang, et al. Expires April 18, 2014 [Page 5] Internet-Draft end2end SIP overload control Oct 2013 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 5.2. Informative References [Hilt] Hilt, V. and I. Widjaja, "Controlling Overload in Networks of SIP Servers", October 2008. [Liao] Liao, J., Wang, J., Li, T., Wang, J., Wang, J., and X. Zhu, "A Distributed End-to-end Overload Control Mechanism for Networks of SIP Servers", COMPUTER NETWORKS , 2012. [RFC6357] Hilt, V., Noel, E., Shen, C., and A. Abdelal, "RFC 6357: Design Considerations for Session Initiation Protocol (SIP) Overload Control", August 2011. Authors' Addresses Jinzhu Wang China Mobile Email: wangjinzhu@chinamobile.com Qing Yu China Mobile Email: yuqing@chinamobile.com Lingli Deng China Mobile Email: denglingli@chinamobile.com Wang, et al. Expires April 18, 2014 [Page 6]