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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 6 Nov 2001 01:19:35 -0500

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:[email-masked]]
> Sent: Monday, November 05, 2001 7:05 PM
> To: Steve Gardell
> Cc: [email-masked]'
> Subject: Re: [Sipping] Server Load Balancer Integration?
> 
> > 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.
> > 
> 
> 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.)

Load balancing is just one feature of these elements. SRV can do that just
fine also. However, there are drawbacks to SRV as the "only" solution:

1. SRV doesn't allow for more intelligent load balancing, based on available
capacity or other dynamic metrics of the next hop elements,
2. If an element fails, there is no way in SRV to know when it has come back
alive in order to start using it again
3. When you add a new element to the load balanced set, you need to wait for
DNS ttl's to expire to pick it up. This could be a LONG time. You could set
the ttl's low, but you really want to avoid cache misses on DNS to reduce
call setup times. In fact, I am aware of numerous service providers that
don't want ANY DNS in their networks. I'm sure some of that is religion, but
there certainly are issues.

Arguably, if DNS were always good enough, there would be no need for web
load balancers, since multiple A records does a similar job to SRV. But,
these web load balancers have evolved for many reasons, not the only one of
which is persisting server selection decisions for a particular session
(something not needed in sip, mostly because of record-routing). 

Anyway, there are commercial products that provide SIP load balancing akin
to web load balancers. People can contact me privately if they would like
more information.

There is also the rserpool effort, which seems to be aimed at solving some
of these problems. However, I haven't really been following it, so I can't
say.

THanks,
Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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: Tue, 06 Nov 2001 12:44:38 -0500

Jonathan Rosenberg wrote:

Just some additional points, not disagreements.

> capacity or other dynamic metrics of the next hop elements,

As long as the work-per-request is small, tracking load is probably
wasted effort. Random assignment, with weighting according to capacity,
will be close enough.

> alive in order to start using it again

This also doesn't matter if the user population is very large since new
arrivals will simply try all the servers. This only matters if the
number of different clients is very small. In that case, some fairly
rapid forgetting of bad server information is probably the best choice.

> there certainly are issues.

Obviously, if you don't want DNS, SRV can't help. Compared to typical
provisioning cycles, the day-long expiration time is not that big a
deal. Also, again, with a large user population, the DNS ttl just
doesn't matter since there a plenty of new customers that haven't seen
the old value.

If people don't want DNS, they either must have a small network so that
they can track addresses by hand, will rarely want to renumber hosts or
servers or have some magic server that has better failover than DNS. 

> (something not needed in sip, mostly because of record-routing).

DNS-based load balancing is widely used. See Akamai. 

I think this is primarily done for state-maintenance reasons.
Large-volume web site like yahoo look like this:

host www.yahoo.com
www.yahoo.com. is an alias for www.yahoo.akadns.net.
www.yahoo.akadns.net. has address 64.58.76.178
www.yahoo.akadns.net. has address 64.58.76.223
www.yahoo.akadns.net. has address 64.58.76.222
www.yahoo.akadns.net. has address 64.58.76.176
www.yahoo.akadns.net. has address 64.58.76.229
www.yahoo.akadns.net. has address 64.58.76.177
www.yahoo.akadns.net. has address 64.58.76.179
www.yahoo.akadns.net. has address 64.58.76.228
www.yahoo.akadns.net. has address 64.58.76.227
www.yahoo.akadns.net. has address 64.58.76.224
www.yahoo.akadns.net. has address 64.58.76.226
www.yahoo.akadns.net. has address 64.58.76.225

or that

host www.cnn.com
www.cnn.com. is an alias for cnn.com.
cnn.com. has address 207.25.71.25
cnn.com. has address 207.25.71.27
cnn.com. has address 207.25.71.29
cnn.com. has address 64.12.50.249
cnn.com. has address 64.12.48.217
cnn.com. has address 207.25.71.5

Another reason that A records are not equivalent is that they have no
notion of fallback. As far as I know, the browser tries the first
address returned. If that fails, too bad. (This is my semi-educated
guess.) Thus, A records are useless for redundancy and fail-over.

One should also note that any load balancer box has costs beyond the
expense for the box, in terms of delay and possible single point of
failure.

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

---

From: "Cullen Jennings" <[email-masked]>
Date: Mon, 26 Nov 2001 08:49:31 -0800

Random assignment with weighting according to capacity sounds fine in
theory but it is very difficult to explain to the field how to correctly
deploy this. The issue is knowing capacity. It's not like all the proxy
vendors are publishing SipStone numbers for tons of hardware
configurations so it makes it hard for a technician to get the correct
weighting. Not to motion what happens when some computer gets upgraded and
so on. Automatic discovery of capacity is very desirable to reduce
provisioning difficulties and once we start down this path we end up with
these weird protocols that estimate load based on response time and so on.

Cullen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Henning G. Schulzrinne
Sent: Tuesday, November 06, 2001 9:45 AM
To: Jonathan Rosenberg
Cc: Steve Gardell; [email-masked]'
Subject: Re: [Sipping] Server Load Balancer Integration?

Jonathan Rosenberg wrote: