Subject: [dispatch] SIP Load balancing Problem statement

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 9 May 2011 22:21:23 +0530

Hi all,
 
In IETF 80, there was a Side-meeting on SIP load balancing and attendees
were Dale Worley, Hadriel Kaplan, Keith Drage, Paul Kyzivat, Victor
Pascual, Vijay Gurbani,  Volker Hilt, Parthasarathi R. As we concluded
in Side Meeting, Vijay and myself had written the initial draft for SIP
Load balancing problem statement, shared with all attendees and Dale
reviewed it. 
 
Could you please review SIP load balancing problem statement and provide
your valuable comments which helps to move this work to the next level
in IETF.
 
The initial problem statement is as follows:
 
Load balancing across a farm of SIP servers can be done today, but
without 
generally agreed upon principles on how to best do accomplish this.
Confounding the problem is that a SIP farm may consist of hosts with 
varying capabilities, example, a SIP proxy, a back-to-back user agent 
(B2BUA), a public-switched telephone system (PSTN) gateway, SIP Media 
servers etc. The capabilities and processing capacity on hosts in the 
farm may be different, sometimes vastly, from each other.  Furthermore, 
the duration of time that a SIP host requires to process a SIP request
may 
vary. SIP proxies, operating at the transaction layer, may be more 
efficient at processing transactions than a B2BUA would be, which may 
need to maintain a long-lived dialogue state in addition to the 
transaction state.  PSTN gateways may have other limitations such 
as media resources that may be depleted even though the gateway may 
have enough processing power (i.e., CPU) to handle incoming requests.
 
In face of such diversity, simple load balancing schemes based on 
round-robin selection tend to work only when many assumptions are met.
First, the relative capacity and processing resources of all SIP servers

in the farm should be nearly equal.  Furthermore, because a round-
robin scheme presents a load of (1/n)*N to each server, where n = number

of servers and N = arrival rate in requests per second, it assumes that 
the service time at each server is such that the utilization of each 
server is not negatively impacted (i.e., utilization ratio of the  
arrival rate over the mean service rate is less than 1.0).  And finally,

the round-robin load balancing does not have a backward feedback
mechanism 
whereby the load-balanced server can inform the load balancer of its 
current utilization (i.e., round-robin load balancing acts as 
an open-loop controller).
 
The problem statement for load balancing is, therefore, how to arrive 
at a load balancing scheme that distributes SIP requests to a collection

of servers to effectively utilize the resources at those servers. 
These resources can include CPU, memory, network bandwidth, 
input/output, DSP, DS0 or disk resources. 
 
In order to achieve such a load balancing scheme in practice, the
following 
considerations must be taken in account:
 
1) Should the load balancing scheme have a closed-loop model, i.e., 
should it report utilization to the load balancer to allow the load 
balancer to distribute requests proportionally?
 
    Note: The discussion that occurred before the Prague IETF seem to
    concur that some sort of an adaptive closed-loop model is
    effective.  Reporting a number that signifies a dynamically
    calculated "weight" [1], or the number that signifies an estimate
    of additional sessions that a SIP host can accept [2] seems to be
    of use.
 
2) What diversity of SIP hosts in a farm should be accommodated?  Is it 
reasonable to assume that the same load balancing scheme should be 
applicable to a pair of SIP servers, one of which can handle an order 
of magnitude more requests per unit time that the other?
 
3) What information must be provisioned into the load balancer and 
the servers?
 
4) As SIP request resource consumption in SIP signaling only 
server varies drastically from SIP media servers [3], should the 
solution be split such that load balancing of a pure signaling server 
is different than that of a SIP server that handles signaling as 
well as media?
 
The last consideration above is especially important since a solution
to load balancing a media farm will require a model where the SIP 
load balancer is closely coupled with the downstream SIP servers.
In such a model, the SIP load balancer knows the resources available
at each of the downstream SIP servers and is able to inspect an
incoming request to determine its media-related requirements and thus
dispatch it to the downstream SIP server that has the highest
probability of servicing that request.  In some architectures, such
a coupling reduces post-dial delay.  
 
Keeping the SIP load balancer and the downstream SIP servers 
loosely coupled suffices for load balancing to a farm of SIP
servers that only handle signaling.  A loosely coupled model
operates purely on the feedback received from the downstream
SIP servers and does not require the SIP load balancer to inspect
an incoming request.
 
Any solution, or work towards a solution (a working group) needs to 
clearly specify its scope.  A solution also needs to clearly state 
any limitations, in performance or otherwise, the specified load 
balancing mechanism may have.  In particular, the a solution 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 these considerations is to allow 
potential deployers to make the best use of these mechanism in 
their particular networks.
 
[1]
http://tools.ietf.org/html/draft-bessis-dispatch-adaptive-load-balancing
-00
[2] http://tools.ietf.org/html/draft-jones-sip-overload-sce-00
[3]
http://tools.ietf.org/html/draft-partha-dispatch-sip-media-overload-cont
rol-00
 
Thanks
Vijay/Partha