Subject: [dispatch] SIP Load balancing (SIPLB) Charter proposal

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 23 May 2011 20:34:24 +0530

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

---

From: <[email-masked]>
Date: Tue, 24 May 2011 19:29:51 +0200

Hi all,

1 comment and 1 question

Comment: In the list of considerations that must be taken into account I would add « Whether the load balancer is SIP-aware or not.

Question: Is the Charter intended to cover architectures with an in-path load balancer in front of a farm of SIP servers only or is it expected to cover as well other architectures where the load balancer is off-path or even architectures where load balancing just relies on frequent updates of the DNS?

Bruno

 

De : [email-masked] [mailto:[email-masked]] De la part de Parthasarathi R (partr)
Envoyé : lundi 23 mai 2011 17:04
À : [email-masked]
Objet : [dispatch] SIP Load balancing (SIPLB) Charter proposal

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-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-control-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. 

Thanks

Vijay/Partha

 
Load balancing across a farm of SIP servers can be done today, but without 
servers etc. The capabilities and processing capacity on hosts in the farm 
 
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).

In order to achieve such a load balancing scheme in practice, the following 
considerations must be taken in account:

 

a mechanism can become less effective or ineffective under some conditions, 
is to allow potential deployments to make the best use of these mechanism in 

The group will produce:

Goals and Milestones

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 25 May 2011 09:53:46 +0530

Hi Bruno,
 
Thanks for your interest in the charter. Please read inline.
 
Thanks
Partha

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, May 24, 2011 11:00 PM
To: Parthasarathi R (partr); [email-masked]
Subject: RE: [dispatch] SIP Load balancing (SIPLB) Charter proposal

Hi all,

1 comment and 1 question

<Partha>  Till now, we are discussing about SIP-aware load balancer only. In case the load balancer is SIP-unaware, is it something like load-balance by open-loop model wherein there is no feedback required from downstream servers or load balance in the transport layer instead of SIP layer ?. Could you please explain your consideration in detail. </Partha>

<Partha>  The charter's first consideration explains open-loop model. So, it might be possible to get the solution through open-loop model (off-path). ISTM, DNS update for load balancer also falls under open-loop model until otherwise DNS weight and priority varies so often based on system load but it is next to impossible to change DNS so frequently in the real-time. </Partha>

I guess that 1st consideration will 

Bruno

 

Hi all,

Thanks

Vijay/Partha

 

 

 

 
 
The group will produce:

Goals and Milestones