| Dispatch Working Group | T.B. Bessis |
| Internet-Draft | V.K.G. Gurbani |
| Intended status: Standards Track | Alcatel-Lucent |
| Expires: September 08, 2011 | March 07, 2011 |
Adaptive load balancing in the Session Initiation Protocol (SIP)
DOCNAME
A Session Initiation Protocol (SIP) proxy, distributing traffic to a cluster of multiple downstream servers, can use the DNS SRV mechanism to perform load balancing. However, the "weight" field in the DNS SRV mechanism is intended for static server selection. Over time, the traffic arriving at the downstream SIP servers may cause them to enter an overload condition, adversely impacting the throughput of the SIP cluster. This document proposes to impart the dynamic load of each SIP server to the load distributing SIP proxy, thereby allowing it to load balance the traffic so as to reduce --- or even prevent --- an overload condition.
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."
This Internet-Draft will expire on September 08, 2011.
Copyright (c) 2011 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.
In SIP [RFC3261] networks, resolution of a target URI may result in a set of more than one SIP server to which the request can be sent. This set defines a logical cluster of servers, one of which can serve as the next hop server. The standard manner to choose one one of the downstream SIP servers from the set is specified in RFC 3263 [RFC3263], which in turn, employs RFC 2782 [RFC2782] to perform load balancing. RFC 2782 [RFC2782] proposes a simple and effective algorithm to distribute the traffic using the "weight" field. RRs with larger "weight" value have a higher probability of being selected.
This mechanism works well, however, since the load arriving at a cluster changes over time, the "weight" field is unable to reflect this change dynamically. The result is that when the offered load increases, the SIP proxy will proportionally send a higher fraction of the load to the downstream SIP server with a higher "weight", thereby causing congestion collapse at that SIP server.
It would be beneficial if the real-time load information from the cluster is made available to the SIP proxy so it can adjust its distribution accordingly. This document proposes such a mechanism.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
One way to impart dynamic server load information to the SIP proxy is to assign short TTLs to SRV RRs, thereby causing the resolver at the SIP proxy to expire its cache frequently. However, the disadvantage to such a solution is two-fold: one, the operational overhead to change the RRs frequently is often understood to be a sizable barrier, and two, frequently changing RRs will increase overall network load.
It is necessary to provide load feedback at an interval that will allow the SIP servers in the cluster to rapidly rebalance the load in the cluster. If the rebalancing is not done promptly and continuously, the most loaded of the servers (the one with a higher "weight" field value) will enter overload state and start shedding requests, even though the cluster itself has resources to process the load currently being shed.
Furthermore, the DNS SRV RR "weight" field, as envisioned by the authors of RFC 2782, is intended to express a static context through which to interpret the meaning. For instance, a server with a higher value --- say 3 --- in the "weight" field imparts that it is 3 times as efficient as a server that has a "weight" value of 1 (for some definition of efficiency that is understood by the DNS zone owner. For example, a server with a "weight" of 3 may be three times as fast --- more memory, more CPU cores, gigabit interfaces, etc. --- as the one with a "weight" of 1).
Thus, it appears that the "weight" value as used in RFC 2782 is not well suited to provide dynamic load status at a server processing SIP requests. Many operational SIP service providers are loathe to frequently change the value of the "weight" field for load balancing.
The proposal in this document is simple, and in fact, a default implementation of the load balance algorithm can be entirely based on the server selection algorithm specified in RFC 2782 [RFC2782], albeit with the load balance weights being updated continuously as described next.
Each SIP server in a cluster sends load information in the form of a weight continuously to the SIP proxy by piggybacking on the normal signaling messages being exchanged between the SIP proxy and the SIP server in the cluster (to this extent, a "Via" header parameter to transport load information is attractive). Load information is imparted as an integral value with a range between 0-65535 (this mirrors the range of the "weight" field in RFC 2782). This is a 16-bit unsigned integer in network-byte order form. Larger weights are given higher probability of being selected to receive a request. When a request is to be sent downstream, the SIP proxy recomputes the probability of sending a request downstream based on the latest load balance information that was returned to it by the SIP servers in the cluster.
As a SIP server in the cluster starts to process traffic, it will reduce the load control information going to its upstream SIP proxy. If the cluster has capacity, other load control weights will be higher, and will thus get a proportionate share of the traffic. As all SIP servers in the cluster reach capacity, the load distribution algorithm arranges for a uniform load distribution to all of the SIP servers until either the offered load subsides or the SIP servers enter into overload mode and start shedding traffic using the mechanism defined in the overload control draft [I-D.ietf-soc-overload-control].
Such a mechanism has the following benefits:
The usage and range of the load control parameter here mimics the usage and range of the "weight" parameter in RFC 2782. However, because the weights in RFC 2782 are static, a SIP proxy can use these weights as initialization vectors when the cluster is put into service. As the offered load increases (or decreases), the load control algorithm updates the weights in real time at the SIP proxy.
There is a natural inclination to conflate load balancing with overload control. While one can reduce overload control at a certain SIP server in the cluster by load balancing the traffic, overload control (as being defined by the SOC working group) by itself operates independent of load balancing.
Essentially, overload control is the ability of a SIP server in the cluster to recognize that it is under overload and ask its upstream neighbour to quench traffic arriving to the overloaded SIP server by some percentage [I-D.ietf-soc-overload-control]. As all SIP servers in the cluster reach capacity, the load distribution algorithm arranges for a uniform load distribution to all of the SIP servers until either the offered load subsides or the SIP servers enter into overload mode and start shedding traffic using the mechanism defined in the overload control draft [I-D.ietf-soc-overload-control].
An attacker that has access to the communication channel can mount a man-in-the-middle attack by unduly changing the value of the load balancing parameter to affect the downstream SIP server.
A SIP operator can ostensibly leak private information to an attacker that is observing the signaling messages. It becomes relatively easy to know which SIP server in a cluster is more capable than others by observing messages over a long period. However, this seeming leak of privacy is no different than what the same attacker can observe by querying DNS SRV RRs for a domain directly.
A SIP operator can prevent both of the above security issues by requiring TLS to be used between a SIP proxy and the individual SIP servers in a cluster. Furthermore, since load balancing feedback has no meaning beyond the next hop, there is no need to secure the communication over multiple hops.
TBD.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC3261] | Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. |
| [RFC3263] | Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. |
| [RFC2782] | Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. |
| [I-D.ietf-soc-overload-control] | Gurbani, V, Hilt, V and H Schulzrinne, "Session Initiation Protocol (SIP) Overload Control", Internet-Draft draft-ietf-soc-overload-control-05, October 2011. |
The authors thank Keith Drage and Volker Hilt for discussions related to load balancing that resulted in this draft.