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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 7 Nov 2001 16:34:04 -0500

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:[email-masked]]
> Sent: Tuesday, November 06, 2001 12:45 PM
> To: Jonathan Rosenberg
> Cc: Steve Gardell; [email-masked]'
> Subject: Re: [Sipping] Server Load Balancer Integration?
> 
> > 
> > 1. SRV doesn't allow for more intelligent load balancing, 
> based on available
> > 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.

Even if the per-request-load is small on average, you still want this if the
variance in the load per request is large. Otherwise, you may not be serving
enough requests on a particular box for the strong law of large numbers to
drive the total load across all boxes to be the same. ALso, if there is any
correlation in processing of requests, purely randomized LB won't be good
enough either.

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

Trying all of the servers means you are continously rediscovering that one
has failed. That process takes time - 500ms for a UDP retransmit to generate
an ICMP error, perhaps, which is going to take too long.
> > 
> > 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).
> 
> 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

I suspect that these are used in conjunction with load balancing boxes, but
its just a guess.

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

Sure; the DNS dip could be just as much delay. Most LB boxes have failover
capabilities.

I still stand by my point that SRV is not sufficient for load
balancing/failover in many cases, particularly in cases where elements
within a provider network are load balancing across downstream elements
(ie., proxies LB across a set of gateways).

-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 Schulzrinne <[email-masked]>
Date: Wed, 07 Nov 2001 23:20:15 -0500

> correlation in processing of requests, purely randomized LB won't be good

Nobody seems to have done measurements on this; so either way, this
remains speculation.

> I suspect that these are used in conjunction with load balancing boxes, but

I doubt it.

Btw, there are others, like google, which only return one answer, but it
differs each time you ask:

Name:    www.google.com
Address:  216.239.33.100

host www.google.com
www.google.com. has address 216.239.35.100

> Sure; the DNS dip could be just as much delay. Most LB boxes have failover

Unless you're arguing that there should be no DNS at all, the
incremental cost for SRV is effectively zero.

Even with SRV, you can have failover, if what you mean by that is one
box can assume the other's identity. Indeed, adding the IP address of
the failed box as an interface on a "good" box is pretty easy "in
flight", at least for Unix-style boxes and Win2K. This addresses the
"UDP going to dead box" problem.

> (ie., proxies LB across a set of gateways).

For gateways I can see that, since the number of concurrent calls is
typically small and you want to run the gateways at close to capacity.
For the server part, it's probably wise to have more headroom, given the
small cost of additional CPU capacity vs. additional trunk capacity. I
think it would be fair to compare the total cost of a system, in terms
of software and hardware. If I can spend your LB money on "real"
servers, I think I'll come out ahead :-) In the end, it is a cost issue,
since if cost weren't an issue, you'd run each server at 1% utilization
and SRV load balancing would work just as well as any load balancer even
in the face of very bursty loads.

For other configurations, I don't see the need except in really special
cases.