One Domain; Multiple IPs.

[Brad Knowles]

At 12:08 AM -0400 7/20/01, Kevin Darcy wrote:

>  Is the TTL issue really the *central* complaint you have against DNS-based
>  load-balancing, then?

	It is a significant part of my complaint, but I would not 
characterize it as the sole central complaint, no.

>  Well, this is what *load*-balancing means, isn't it? It's not the same
>  as latency minimization. One's overall transaction speed is impacted by
>  both how long the server takes to process the request and how long the
>  packets take to travel between client and server. Load-balancing,
>  _ipso_facto_, only addresses one of those factors. Network-aware
>  load-balancers try to do both. That's a lot iffier.

	However, if the essential driving factor behind the use of 
DNS-based load balancing is cost, then there's really no point.  A 
closed-source hardware implementation of a DNS-based load balancing 
device is no less expensive than an L4 load-balancing switch. 
Indeed, when you look at products like RadWARE WSD Pro and WSD Pro+ 
switches, they typically provide multiple different ways to solve the 
same problem, including DNS-based load balancing.  I think you'd 
probably be hard-pressed to find a solution on the market that 
implemented just DNS-based load balancing and nothing else.

>  Agreed. It would be stupid to *only* load-balance -- ignoring network
>  latency -- if one had servers or server farms in such disparate parts
>  of the Internet. But when all of your servers are at roughly equal
>  distance, topologically, from the major exchange points, the network
>  latency may be a wash, and the main performance factor may become
>  server load.

	Network latency could only be a wash if the underlying assumption 
was that there was no congestion, and that all of your clients are 
exclusively coming from only the major NAPs.  However, since there 
are almost always congestion issues, and since the major NAPs may be 
quite some distance away from remote customers across the world, I 
don't think it's possible for network latency to ever be a wash for 
this kind of situation.

>               In such a situation, load-balancing may be all you need.
>  On the other end of the scale, if you're a low-budget operation that
>  only has a *single* presence on the net (who needs redundancy?),
>  network latency differentials may be a moot point.

	Certainly, if you've only got one site, then network latency 
probably doesn't mean too much -- depending on where that site is 
located in the topology, how many other networks it is directly 
connected to, etc....

>  Hmmm... Yeah, let's blame DNS-based load-balancing instead of
>  pornography, spam and all of those streaming or P2P protocols....

	But DNS-based load-balancing runs underneath all those other 
issues.  If you're running a huge pornography site, you probably want 
to make use of load-balancing and distributed server facilities just 
like all the other big sites, and for the same reasons -- It doesn't 
matter that your content is different.

	However, DNS-based load-balancing can easily cause traffic 
congestion at busy sites to be significantly worse, if it doesn't 
also take into account network topology.  And the best way to take 
into account network topology is to make use of the low-level network 
routing protocols at the time the connection is set up, and not in a 
DNS query that may have occurred five minutes ago.

>  The monitoring can be done by a separate machine with a private backchannel
>  to the load-balancer.

	It doesn't matter.  The information that the central 
load-balancer would have would still be stale to a greater or lesser 
degree, because you can't monitor the load on each machine with each 
and every query.  So, you're balancing your incoming connections 
based on information of how loaded each server was one, five, ten, 
fifteen, or however many minutes ago.  As we know, loads on systems 
can change very rapidly, and having an inherent time delay built into 
each decision on distributing a connection can only make the 
situation worse.

>                                         If you want something really
>  fine-grained, then go to a more sophisticated technology.

	The thing is, by going to a different solution that is more 
fine-grained (where the load-balancing switch can track each and 
every connection going to each server), you can make better used of 
the back-end resources, and perhaps even spend less on the overall 
system.

>  The trouble with plain old round-robin is the stupid clients out there with
>  ridiculously long failover times.

	Yup, there are all sorts of stupid clients out there that do 
stupid things with the DNS responses they get.  That's one of the 
reasons I want to get away from using the DNS for this kind of thing.

>                                               Only caching servers care
>  about (a), but if DNS-based load-balancing can make a site a *little*
>  more available or perform a *little* faster for X clients, at the cost
>  of making Y caching nameservers work a little harder than they
>  otherwise would, then maybe this is a win overall, given that X is
>  likely to be several times larger than Y.

	You know, spammers say exactly the same thing:

		If it makes my life a little bit easier, it doesn't
		really matter if it makes like harder for the people
		on the other end, since the cost increment for each
		of them is a lot less than my cost increment.

	I note that Piranhas do the same -- each fish probably only gets 
one or two bites, but a school of 50,000 can strip the flesh from an 
elephant in just a few hours.

>  Now, I'm not going to try to defend the decision of various vendors to
>  implement DNS-based load-balancing products as combined hardware/software
>  solutions. Personally, I think that may have been a marketing/packaging
>  blunder. I'm only dealing with the *inherent* cost-effectiveness of the
>  approach, which I think is quite favorable.

	How is the cost of a RadWARE WSD Pro+ switch that does DNS-based 
load balancing any cheaper than the cost of a RadWARE WSD Pro+ switch 
that uses other techniques?  When comparing the low end of these 
hardware implementations, how is the hardware DNS-based load 
balancing device any cheaper than other low-end hardware 
load-balancing devices?

	I'm sorry, I've worked at a company where we've used these 
things, and I just don't see any kind of a cost advantage whatsoever.

-- 
Brad Knowles, <brad.knowles at skynet.be>

/*        efdtt.c  Author:  Charles M. Hannum <root at ihack.net>          */
/*       Represented as 1045 digit prime number by Phil Carmody         */
/*     Prime as DNS cname chain by Roy Arends and Walter Belgers        */
/*                                                                      */
/*     Usage is:  cat title-key scrambled.vob | efdtt >clear.vob        */
/*   where title-key = "153 2 8 105 225" or other similar 5-byte key    */

dig decss.friet.org|perl -ne'if(/^x/){s/[x.]//g;print pack(H124,$_)}'