brainstorms (Re: dns based loadbalancing/failover)

["E.B. Dreger" <eddy+public+spam () noc everquick net>]

> Date: Sun, 7 Oct 2001 02:14:27 +0200
> From: Stefan Arentz <stefan.arentz () soze com>

[ snip ]

> I'm not very interested in the discussion why this behaviour
> would be broken. It's for more interesting to talk about
> improving DNS so that there will be room for things like load
> balancing or dynamic DNS. In such a way that people will not
> start screaming when they see TTLs of 30 seconds or non-linear
> behaviour of load balancers.

Note: "Context-defined new terms" in double quotes

How probable would a different A RR be on the "next" query?
Perhaps we should look at BGP or other link state protocols as a
starting point... a failover-ready NS could negotiate "I tell you
when the A RR changes iff it happens within TTL[1]" behavior with
the far end -- useful for failover, but not load-balancing.  Of
course, because DNS traffic is multihop, endpoint authentication
is more of an issue than with BGP.

[1] Not necessarily the same TTL as current DNS uses

Of course, the drawback with this approach is deployment:  Look
at the reluctance of MCSE monkeys and |<0b4lt |<1dd13z^W^W^W^W^W
some net admins to patch critical bugs.  Do you think that
they'll upgrade things at the edge to support a non-critical cool
new feature?  Not likely.  The onus for correct operation is on
the hosting provider.

Are we talking about dynamic balancing within a single site, or
across multiple locations?  If the former, why not use gear a la
Extreme, thus 1) conserving IP space and 2) remaining transparent
to the outside world?

If distributing across multiple sites, one can use BGP to advert
the same subnet from different points... let routing protocols
route, and DNS give the same answer all the time.  (Damn those
filters!)  Ideally, the routing protocols could shunt "excess
traffic" from a "heavily loaded" site to a "lightly loaded" one.

Load balancing across multiple sites gets uglier.  Either we have
incredibly short TTLs (sorry, AOL users[2]) or we need something
else.  Perhaps storing multiple routes (woops, more route memory)
and use some sort of ECN?

[2] I personally find it tempting to say, 'screw anyone who uses
looong TTLs with flagrant disregard to the authoritative host's
wishes'... allowing bad behavior to become a de facto standard by
virtue of customer base is _not_ sound engineering.

All-pairs-shortest-paths gives nice info... until you look at
scalability, or the lack thereof.  O(N^4) cpu time[3] and a few
times as much RAM?  Ughh.

[3] IIRC, O(N^3 * log(N)) is do-able.  However, standard APSP
does not record paths... only path lengths.  Minus two points for
chewing up even more CPU.

I guess that the big questions would be:

1. How often do changes occur?
2. How sparse are "rapidly changing" values wrt the entire graph?
3. Distribution across multiple sites?
4. What do we leave up to DNS?
5. What do we leave up to routing?

If heavily enough distributed, congestion should be highly
localized... if present at all.  Let's assume that a "basic
server" can service 10 Mbps of traffic.  Install servers in
various points, a la Akamai... any traffic sinks here ever manage
to overload your Akamai boxen?  If so, how often compared to a
random traffic source.

Whatever we do, we must keep state as far from the core as
possible.  State in core baaad.

I've rambled enough.  CTRL+X with no further edits.


Eddy

---------------------------------------------------------------------------
Brotsman & Dreger, Inc. - EverQuick Internet Division
Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence
---------------------------------------------------------------------------

Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist () brics com>
To: blacklist () brics com
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.  Do NOT
send mail to <blacklist () brics com>, or you are likely to be blocked.