Subject: RE: [Sipping] Server Load Balancer Integration?

From: Steve Gardell <[email-masked]>
Date: Mon, 5 Nov 2001 14:21:02 -0500

Thanks Henning! 

I take this as an analysis of why this SLB
sort of technology sometimes isn't always necessary. 
I'd love to convince myself that this is generally 
true since the solution you propose is ever so
much easier and cheaper. We need to consider SIP 
entities that aren't quite as "easy" 
as a stateless proxy. For example, an array of 
media servers or 3'rd party call control entities 
in the fashion of draft-rosenberg-sip-3pcc-02.txt.

Let me test whether I understand what you propose: Implement
two stateless proxies (for redundancy). Access to these
is via DNS/SRV. Each stateless proxy directs calls 
"intelligently" to the stateful entities (UAS, B2BUA, etc.)
This seems to work fine for load balancing (which was
of course the thread title...) Hmmm, do we really need
the stateless proxies for this? - I guess that depends on
whether the simple DNS mechanisms are deemed adequate.

SLB's in general also provide Failover/Redundancy support, which
I must admit, is at least as big a concern to me. I  
believe that this DNS/SRV approach doesn't support mid-call
failures since I can't expect SIP UAC's or proxies to
re-try DNS during a call (can I?). I believe that the
SLB approach would support mid-call failures if state is 
replicated across end-points.
 
> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Monday, November 05, 2001 8:58 AM
> To: Steve Gardell
> Subject: Re: [Sipping] Server Load Balancer Integration?
> 
> 
> Shouldn't be needed with SIP. SRV or a stateless proxy are much better
> approaches than bending TCP pipes into funny shapes.
> 
> Steve Gardell wrote:
> > 
> > Is there any experience or analysis of the integration of a
> > "Server Load Balancer" such as the Cisco CSS or the Alteon
> > Websystems box with SIP? These devices typically front
> > Web-server farms to provide load balancing and redundancy
> > but they are also used to support other protocols such as FTP
> > and POP3. Obviously, this is more straight-forward with
> > SIP entities such as a stateless proxy...
> > 
> > Steven Gardell
> > Principal Engineer, Iperia Inc.
> > 781-993-3544
> > 
> > _______________________________________________
> > Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Mon, 05 Nov 2001 19:04:54 -0500

> replicated across end-points.

This only matters if proxies are call (not just transaction) stateful.
Since things in the network that keep state are a source of complexity
and failures, SIP tried hard not to introduce such entities. Except
possibly for firewall controllers, I have a hard time seeing the need
for proxies that need to be around "in person" to keep up a call.
Generally, why would you need mid-call signaling to keep a call up? This
isn't SS7... (If you're willing to replicate state across a set of
servers, it doesn't matter which server is visited mid-call, so even
there, SRV-style solutions work.)

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs