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

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 6 Jul 2011 23:40:32 +0530

Bruno,

Sorry for the delay reply. Please read inline.

Thanks
Partha 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Tuesday, June 14, 2011 2:43 PM
> To: [email-masked]; Parthasarathi R (partr); 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [dispatch] SIP Load balancing (SIPLB) Charter proposal
> 
> 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 
<Partha> In case DNS server & SIP entity are co-located, then it is just protocol choice and no architecture/performance impact </Partha>

or implemented as a 
> standalone off path node that uses e.g. SNMP to collect (or 
> be notified of) load information
<Partha> Here, the assumption is that load balancing report update delay is less but the algorithm efficiency will not while nearing overload scenario in some of the downstream entity. IMO, the best load balancer has to work well when some portion of the downstream entity is overloaded as well. The advantage with information in co-located solution is that the updation happens instantaneously. </Partha>

> 
> ii) The clients that make load balancing decisions based on 
> priority and weight fields found in DNS records
<Partha> I'm not DNS expert but this proposed mechanism may have other side-effect with DNS enhancement like DNS caching based on TTL. DNS caching is the most common behavior in DNS client implementation whereas here the caching should not be enabled. </Partha>

> 
> Bruno
> 
> > -----Message d'origine-----
> > De : DOLLY, MARTIN C (ATTSI) [mailto:[email-masked]] Envoyé 
> : vendredi 
> > 10 juin 2011 13:35 À : CHATRAS Bruno RD-CORE-ISS; [email-masked]; 
> > [email-masked]; [email-masked] Cc : 
> [email-masked] Objet : 
> > RE: [dispatch] SIP Load balancing (SIPLB) Charter proposal
> > 
> > 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:bruno.chatras@orange- 
> > ftgroup.com]
> > 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
> > 
> > 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
> > 
> > > -----Message d'origine-----
> > > De : Parthasarathi R (partr) [mailto:[email-masked]] 
> Envoyé : jeudi 
> > > 9 juin 2011 19:45 À : Richard Shockey; CHATRAS Bruno RD-CORE-ISS; 
> > > [email-masked]; [email-masked] Cc : [email-masked] 
> Objet : RE: 
> > > [dispatch] SIP Load balancing (SIPLB) Charter proposal
> > >
> > > 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]; vkg@bell-
> > labs.com
> > > 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,
> > > 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
> > >
> > >
> > > > -----Message d'origine-----
> > > > 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,
> > > >
> > > > 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,
> > > >
> > > > 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
> > > >
> > > > > -----Message d'origine-----
> > > > > 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
> > > > >
> > > > > On 06/07/2011 04:13 AM, 
> [email-masked] wrote:
> > > > > bruno> Comment: In the list of considerations that 
> must be taken 
> > > > > bruno> 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 
> > > > > partha> balancer
> > > > only.
> > > > > partha> In case the load balancer is SIP-unaware, is it 
> > > > > partha> 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 
> > > > > bruno> with 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 
> > > > > bruno> 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
> > > > > --
> > > > > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 
> 1960 Lucent 
> > > > > Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> > > > > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-
> > > lucent.com
> > > > > Web:   http://ect.bell-labs.com/who/vkg/
> > > > _______________________________________________
> > > > dispatch mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/dispatch
> > > _______________________________________________
> > > dispatch mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/dispatch
> > >
> > > _______________________________________________
> > > dispatch mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/dispatch
>