Hi all,
 
Charter proposal for SIP load balancing (SIPLB) is written in this mail
to create a new WG related to SIP based load balancing.
 
There are lot of interest in SIP load balancing work during the time of
IETF-80 and the side meeting leads to the creation of this charter.
There are lot of draft submitted in Dispatch related to this work and
the list is as follows:
 
[1]http://tools.ietf.org/html/draft-bessis-dispatch-adaptive-load-balanc
ing-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-c
ontrol-00
 
To make the progress in the work, the charter currently focus on two
types of SIP based load balancing namely signaling only SIP load
balancing and Media-related SIP based load balancing. 
 
Please provide your value inputs and comments in the below charter.
 
Thanks
Vijay/Partha
 
SIP Load balancing (SIPLB) Charter
----------------------------------
 
Session Load balancing (SIPLB) working group is chartered to define a 
SIP-based protocol for load balancing SIP sessions.
 
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 SIP load balancing working group is, therefore, chartered 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.  The load balancing
scheme must prevent excessive oscillation in the collection of
servers.
 
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?
 
2) What should the diversity of the SIP hosts in a farm be?  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, 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 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 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 deployments to make the best use of these
mechanism in 
their particular networks.
 
SIPLB Working Group will thoroughly identify use cases, provide example 
design & system architectures and deployment scenarios, and 
define requirements.
 
The group will produce:
 
1) Use case and requirement document.
2) A document surveying SIP load balancing strategies in use today.
3) An architecture document showing sample SIP topologies.
4) Specification for SIP based overload scheme applicable to a 
   signaling-only SIP server.
5) Specification for SIP based overload scheme applicable to a
   media-based SIP server.
 
Goals and Milestones
Mar 2012  Survey document for SIP load balancing strategies to IESG
          as an Informational document.
Jun 2012  Use cases and requirement document to IESG as an Informational
          document.
Aug 2012  Design & Architecture to IESG as Informational RFC
Feb 2013  Submit signaling based SIP overload solution to IESG as 
          Proposed Standard RFC 
Feb 2013  Submit signaling and media based SIP overload solution to 
          IESG as Proposed Standard RFC