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

From: <[email-masked]>
Date: Tue, 7 Jun 2011 11:13:45 +0200

De : Parthasarathi R (partr) [mailto:[email-masked]] 
Envoyé : mercredi 25 mai 2011 06:24
À : CHATRAS Bruno RD-CORE-ISS; [email-masked]
Objet : RE: [dispatch] SIP Load balancing (SIPLB) Charter proposal

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

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

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

[BC] I was referring to a load balancer at the transport layer with feedback from downstream servers.

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? 

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

[BC] I was indeed referring to solutions where the DNS is frequently updated (weight and priority) using RFC 2136. Note that there are architectures where the DNS is not directly updated by the SIP servers but by an intermediate entity (see e.g. the LDF in http://www.3gpp.org/ftp/Specs/archive/23_series/23.812/23812-115.zip)

I guess that 1st consideration will 

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. 

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, 7 Jun 2011 11:18:43 +0200

Items 4 and 5 are referring to an overload scheme rather than a load balancing scheme. Any reason for that? Typo?

Same comment applies to the last two milestones

Bruno

 

Hi all,

Thanks

Vijay/Partha

 

 

 

 
 
The group will produce:

Goals and Milestones

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 07 Jun 2011 09:15:28 -0500

Bruno: Thank you for your feedback.  More inline.

On 06/07/2011 04:18 AM, [email-masked] wrote:
> Items 4 and 5 are referring to an overload scheme rather than a load
> balancing scheme. Any reason for that? Typo?

Item 4 ("As SIP request ... as well as media?") refers to load
balancing.  I cannot find item 5 (if you are referring to
the list of considerations, there are four items there. If
you are referring to something else, please let me know what
it is).

> Same comment applies to the last two milestones

Ooops, this is embarrassing; sorry.  Indeed, the last two milestones
relate to load balancing and should say the following:

Feb 2013  Submit signaling based SIP load balancing solution to IESG as
           Proposed Standard RFC
Feb 2013  Submit signaling and media based SIP load balancing solution
           to IESG as Proposed Standard RFC

Thank you.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: <[email-masked]>
Date: Tue, 7 Jun 2011 16:17:41 +0200

Vijay,

I'm referring to 

> -----Message d'origine-----
> De : Vijay K. Gurbani [mailto:[email-masked]]
> Envoyé : mardi 7 juin 2011 16:15
> À : CHATRAS Bruno RD-CORE-ISS
> Cc : [email-masked]; [email-masked]
> Objet : Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal -
> overload
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 07 Jun 2011 09:20:51 -0500

> 5) Specification for SIP based overload scheme applicable to a

Dear Bruno: OK, in that case, the 4,5 will be changed in the next
revisions of the charter to:

Feb 2013  Submit signaling based SIP load balancing solution to IESG as
             Proposed Standard.
Feb 2013  Submit signaling and media based SIP load balancing solution
            to IESG as Proposed Standard.

Thanks for catching this!

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 07 Jun 2011 10:01:12 -0500

On 06/07/2011 04:13 AM, [email-masked] wrote:
bruno> Comment: In the list of considerations that must be taken into 
account I
bruno> would add « Whether the load balancer is SIP-aware or not.
bruno>
partha> Till now, we are discussing about SIP-aware load balancer only.
partha> In case the load balancer is SIP-unaware, is it something like
partha> load-balance by open-loop model wherein there is no feedback 
required
partha> from downstream servers or load balance in the transport layer 
instead
partha> of SIP layer ?. Could you please explain your consideration in 
detail.
partha>
bruno> I was referring to a load balancer at the transport layer with
bruno> feedback from downstream servers./*

Dear Bruno: I envision a SIP-aware load balancer with feedback
mechanism, where the feedback is carried in SIP signaling.

More inline.

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

My understanding is that service providers are loath to update DNS.
As such, a solution that does not depend on DNS is preferable.  This,
then, means that an in-path solution that does not require DNS would
be the most preferred.

I note that the LDF function you mention from [1] is a backward
feedback solution with the LDF updating the DNS periodically.

I think that it would be good to have substantive input from the
service provider community as well as the working group to
determine whether a solution that does not depend on DNS being
updated is preferred or not.

Thoughts?

[1] http://www.3gpp.org/ftp/Specs/archive/23_series/23.812/23812-115.zip

Thanks,

- vijay

---

From: <[email-masked]>
Date: Tue, 7 Jun 2011 17:48:51 +0200

OK that's clear now. 

By the way, I think that interactions between load balancing and overload detection should be added to the list of considerations to be taken into account.

Bruno

> Envoyé : mardi 7 juin 2011 16:21

---

From: <[email-masked]>
Date: Tue, 7 Jun 2011 17:54:13 +0200

Vijay,

Speaking as a representative of a Service Provider, I can tell you that we are interested in DNS-based solutions. I believe that the WG should address both types of solutions.

Bruno

> Envoyé : mardi 7 juin 2011 17:01
> Objet : Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 07 Jun 2011 12:04:24 -0500

On 06/07/2011 10:48 AM, [email-masked] wrote:
> OK that's clear now.
>
> By the way, I think that interactions between load balancing and
> overload detection should be added to the list of considerations to
> be taken into account.

Bruno: Yes, I agree.  I think we should do more than list it in the
consideration section --- I think that the use case and requirements
document should have a section on the interaction between load balancing
and overload control.

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 07 Jun 2011 12:06:04 -0500

On 06/07/2011 10:54 AM, [email-masked] wrote:
> Vijay,
>
> Speaking as a representative of a Service Provider, I can tell you
> that we are interested in DNS-based solutions. I believe that the WG
> should address both types of solutions.

Bruno: OK.  This is good feedback to consider.  Thanks much!

Anyone else ...

Thanks,

- vijay

---

From: "DOLLY, MARTIN C (ATTSI)" <[email-masked]>
Date: Wed, 8 Jun 2011 16:39:04 -0400

Bruno,

Do we really want to impact the DNS with a load balancing capability linked to overload control?

Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, June 07, 2011 11:54 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal

Vijay,

Bruno

> [1] http://www.3gpp.org/ftp/Specs/archive/23_series/23.812/23812-
_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: <[email-masked]>
Date: Thu, 9 Jun 2011 15:28:24 +0200

Hi Martin,
The load balancing capability can be implemented on dedicated DNS servers only. This does not put the service provider's DNS infrastructure at risk.
Bruno

> De : DOLLY, MARTIN C (ATTSI) [mailto:[email-masked]]
> Envoyé : mercredi 8 juin 2011 22:39
> À : CHATRAS Bruno RD-CORE-ISS; [email-masked]
> Cc : [email-masked]
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Speaking as a representative of a Service Provider, I can tell you that
> we are interested in DNS-based solutions. I believe that the WG should
> address both types of solutions.
> 
> Bruno
>

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 9 Jun 2011 11:08:18 -0400

Humm .. an application specific use of DNS technology in a closed controlled
environment.  I heard of these kind of things before.  Sounds like a
interesting idea. :-) 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Thursday, June 09, 2011 9:28 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal

Hi Martin,
The load balancing capability can be implemented on dedicated DNS servers
only. This does not put the service provider's DNS infrastructure at risk.
Bruno

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 9 Jun 2011 23:14:41 +0530

Bruno,

Thanks for your information about DNS based SIP load balancing in 3GPP spec (in different mail thread). 

IMO, There are two parts in feedback based SIP load balancing

1) Feedback value
2) Feedback protocol choice (SIP, DNS, SNMP) 

The current mail thread is about feedback protocol which has to be used. I agree with you that it is possible for other protocols for SIP load balancing. We will add the consideration and discuss in detail about protocol choice to sort out the discussion.

I really didn't see the usage of DNS based load balancing mechanism in Enterprise deployment. But initially, I have explored to use SNMP to pass feedback value as a trap and I got the comments that SIP based feedback mechanism will reduce the dependency on another protocol stack in the system. I guess that the comment will apply for DNS as well and also FQDN in SIP URI is not mandatory in SIP.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: Thursday, June 09, 2011 8:38 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal

Humm .. an application specific use of DNS technology in a closed controlled environment.  I heard of these kind of things before.  Sounds like a interesting idea. :-) 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, June 09, 2011 9:28 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal

Hi Martin,

> De : DOLLY, MARTIN C (ATTSI) [mailto:[email-masked]] Envoyé : mercredi 
> 8 juin 2011 22:39 À : CHATRAS Bruno RD-CORE-ISS; [email-masked] Cc 
> : [email-masked] Objet : RE: [dispatch] SIP Load balancing (SIPLB) 
> Charter proposal
> 
> Bruno,
> 
> > De : Vijay K. Gurbani [mailto:[email-masked]] Envoyé : mardi 7 
> > juin 2011 17:01 À : CHATRAS Bruno RD-CORE-ISS Cc : [email-masked]; 
> > [email-masked] Objet : Re: [dispatch] SIP Load balancing (SIPLB) 
> > Charter proposal
> >
> > bruno> Comment: In the list of considerations that must be taken 
> > bruno> into
> > account I
> > bruno> I was referring to a load balancer at the transport layer 
> > bruno> with feedback from downstream servers./*
> >
> > As such, a solution that does not depend on DNS is preferable.  
> > This, then, means that an in-path solution that does not require DNS 
> > would be the most preferred.
> >
> > service provider community as well as the working group to determine 
> > whether a solution that does not depend on DNS being updated is 
> > preferred or not.
> >
> > Thoughts?
> >
> > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent 
> > Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)

---

From: <[email-masked]>
Date: Fri, 10 Jun 2011 09:02:50 +0200

I think it's more than just a protocol issue. There are architectural aspects here as well (in-path vs. out-path load balancer). I think both approaches should be covered. 

In-path: All SIP traffic goes through the load balancer, which is itself a SIP entity 

Out-Path: SIP entities balance the load themselves, based on information received from a load balancer (DNS, 3GPP LDF or something else)

Bruno
 
> Envoyé : jeudi 9 juin 2011 19:45
> À : Richard Shockey; CHATRAS Bruno RD-CORE-ISS; [email-masked];
> [email-masked]
> Cc : [email-masked]
> The current mail thread is about feedback protocol which has to be used.
> I agree with you that it is possible for other protocols for SIP load
> balancing. We will add the consideration and discuss in detail about
> protocol choice to sort out the discussion.
> 
> 
> I really didn't see the usage of DNS based load balancing mechanism in
> Enterprise deployment. But initially, I have explored to use SNMP to
> pass feedback value as a trap and I got the comments that SIP based
> feedback mechanism will reduce the dependency on another protocol stack
> in the system. I guess that the comment will apply for DNS as well and
> also FQDN in SIP URI is not mandatory in SIP.
> 
> Thanks
> Partha
> 
> Behalf Of Richard Shockey
> Humm .. an application specific use of DNS technology in a closed
> controlled environment.  I heard of these kind of things before.
> Sounds like a interesting idea. :-)
> 
> The load balancing capability can be implemented on dedicated DNS
> servers only. This does not put the service provider's DNS
> infrastructure at risk.
> Bruno
> 
> 
> > > bruno> Question: Is the Charter intended to cover architectures
> with
> > an
> > > in-path
> determine

---

From: "DOLLY, MARTIN C (ATTSI)" <[email-masked]>
Date: Fri, 10 Jun 2011 07:34:33 -0400

AT&T supports the approach in the current draft, and would view the "DNS approach" as an option.
Let DNS do what it does well, and donot over complicate it.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, June 10, 2011 3:03 AM
To: [email-masked]; [email-masked]; DOLLY, MARTIN C (ATTSI); [email-masked]
Cc: [email-masked]
Subject: RE: [dispatch] SIP Load balancing (SIPLB) Charter proposal

Bruno

---

From: <[email-masked]>
Date: Tue, 14 Jun 2011 11:13:13 +0200

I agree it should be an option not THE only solution. I just want to make sure that this option is not ruled out of the scope of the WG.

Actually the "DNS approach" does not over complicate the DNS. It just makes use of DNS UPDATE (RFC2136). The "complexity", if any, is not on the DNS itself but rather on 

i) The logical entity that collects load information from the servers and updates the DNS using RFC2136. This logical entity can be co-located with the servers or implemented as a standalone off path node that uses e.g. SNMP to collect (or be notified of) load information

ii) The clients that make load balancing decisions based on priority and weight fields found in DNS records

Bruno

> Envoyé : vendredi 10 juin 2011 13:35
> À : CHATRAS Bruno RD-CORE-ISS; [email-masked]; [email-masked];
> [email-masked]
> Cc : [email-masked]
> I think it's more than just a protocol issue. There are architectural
> aspects here as well (in-path vs. out-path load balancer). I think both
> approaches should be covered.
> 
> Out-Path: SIP entities balance the load themselves, based on
> information received from a load balancer (DNS, 3GPP LDF or something
> else)
> 
> Bruno
> 
> > Thanks for your information about DNS based SIP load balancing in
> 3GPP
> > spec (in different mail thread).
> >
> > > Do we really want to impact the DNS with a load balancing
> capability
> > > linked to overload control?
> > >
> > > Martin
> > >
> > > > partha> of SIP layer ?. Could you please explain your
> consideration
> > > in
> > > > detail.
> > > > partha>
> > > > bruno> to cover as well other architectures where the load
> balancer
> > > is
> > > > off-path