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
