[Brad Knowles]

At 12:32 PM +0100 7/19/01, Marc.Thach at radianz.com wrote:

>  But my view of the forest is this:
>  A server owner wants the fastest and cheapest service to the clients.
>  He/she therefore wishes to minimise global bandwidth costs and latency
>  (amongst other things).
>  He/she doesn't know or care one iota about Internet standards.
>  He/she most definitely wishes to minimise design and operational costs.
>  DD (which is the instance of the technique that I'm familiar with) is
>  relatively cheap.

	Penny wise and pound foolish.  In my experience, telecom costs 
are typically 90% of the entire operational budget of an ISP or ASP. 
For the cost of a single E-1 (about 2Mbps) for a year, my previous 
employer could have afforded to buy 250 MCC Smart cars, one for each 
and every employer.  This is for a company which has had over 100Mbps 
of intranational and international bandwidth, including a T-3 to 
London, and now have added a 100Mbps uplink to Level3.

>  It's well established therefore it's what his/her management team has heard
>  of, "nearest available server? that's DD isn't it, we'll get the DNS guys
>  onto it".

	Ahh, but DD requires that the packets all come into a central 
location (thousands of DNS packets per second will quickly add up to 
a significant amount of bandwidth, which is extremely bloody 
expensive compared to the hardware it's talking to), and then the 
connections get routed to the server that was the least loaded five 
minutes ago -- regardless of where that server is located 
topologically with respect to the client, and therefore most 
certainly *not* coming anywhere close to actually minimizing network 
traffic.

>  It's vendor-supported (not all decisions are based on logic)
>  It is physically localised in the network, at it's simplest only a single
>  extra box is required.

	Anycasting is done in the routers and on the machine which 
handles the virtual IP address, and should be supportable on most any 
box you can buy.

	I don't see this part of the equation being any worse for my 
proposal, if anything it would actually be better (since more is done 
down at the network level, as opposed to within a custom hack to the 
application).

>>  The more I think about it, the more I believe that this technique
>>  is probably actually a key player in the kinds of network routing and
>>  congestion problems that have plagued the 'net within the last few
>>  years.
>
>  I' love to see your reasoned justification for that one.

	Because connections are distributed to the server that is the 
least loaded, without respect to the topographical location of the 
server relative to the client.  And because there are apparently a 
boatload of people that employ this kind of "solution".

-- 
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,$_)}'