Internet DRAFT - draft-wang-appsawg-end2end-overload-control
draft-wang-appsawg-end2end-overload-control
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]
