[dns-operations] Vista implements a bizarre DNS server selection algorithm from RFC3484?

[Joe Greco]

> > Yes.  However, because this is a decision made by the client side  
> > site,
> > and we're talking client logic, that's something that you can  
> > configure
> > around.
> >
> > From the server's side, it's spectacularly difficult to passively  
> > detect
> > this, but from the client's side, you can *know*.  I don't see this as
> > being even much of a speedbump.  You have to be able to have a way to
> > configure knowledge of IPv4 RIR assignments anyways.
> 
> The client can only know geography / latency, and latency can only be  
> known with work done at the time of connection.  Geography can be  
> known pre-connection - if you get lucky.

Trivially and demonstrably false.  The client can also know significant
things about past performance, including things that have transpired as
recently as "what was just transferred."

> The server, OTOH, can pre-calculate a lot of stuff.  (I guess  
> theoretically the client can too, but I don't think that's  
> reasonable.) 

But I'm saying that it potentially *is* reasonable.  It's not certain
that every situation is going to win if you do so.  However, would you
care to explain to me how your server can pre-calculate that the client
has noticed a trend of packet loss towards net 37.0.0.0/8?

The server is not the only endpoint with potentially useful and
interesting knowledge.

> The server also knows about its own resources, which the  
> client does not and cannot know. 

That's why I'm talking about a standard that allows clients and servers
to "specify, learn, and/or infer some useful information about topology
and performance that would allow programs to automatically make 
intelligent decisions" ...  certainly the server's knowledge of its own
resources would be construed as "performance" by most reasonable people.

> If a server hands out two IP  
> addresses, you have every reason to believe the server expects them to  
> be loaded evenly.

Except that it doesn't work that way.  There is no particular reason to
expect that a recurser will actually honor ordering or that a client will,
for that matter.

> Geography / latency is not a good way to guarantee  
> even loading.  Why would you intentionally work against the intentions  
> of the owner of the resource?

Well, if you are hosting your web site on a hacked server, then maybe that
is a concern, since the owner of the resource isn't the owner of the
server.  But you probably don't care about optimizing performance in that
case.  However, I've been discussing a standard that allows intelligent
decisions to be made automatically, so presumably the "owner of the
resource" would not aim the gun at his foot and pull the trigger and then
try to claim I'm trying to work against him.  So for the rest of the non-
law-breaking world, there's no way for your statement to be meaningful.

> >>> Of course, a GSLB system at the other end may be trying to do the  
> >>> same
> >>> thing, based on the IP address of the recurser in use, which we all
> >>> know
> >>> has some ins and outs.
> >>>
> >>> I guess the real question is why we have failed to design and
> >>> implement
> >>> a standard to allow both clients and servers to specify, learn,  
> >>> and/or
> >>> infer some useful information about topology and performance that
> >>> would
> >>> allow programs to automatically make intelligent decisions in an
> >>> automated
> >>> manner that would also allow configuration by administrators.
> >>
> >> Is that a good idea?
> >
> > Yes, it is, without any doubt.  At least, it's a better idea than  
> > anything
> > done today on a wide scale.
> 
> We disagree.

We certainly do.

> >> One of the issues with the idea of a client-side making a decision on
> >> which end point to reach is the assumption the server-side is not
> >> smart enough to figure out the best resource allocation of its own
> >> resources.
> >
> > By the time a client has connected to a server, Patrick, it's too  
> > late.
> > The decision has already been made.
> 
> Wow, I didn't think you were that confused.

Really?  You're just able to magically cause the endpoint of an existing
connection to move somewhere else? 

> Look at Google's GGC for just one pretty minor example of how wrong  
> your statement is.

I don't see it.

> > Solutions such as DNS based GSLB's may attempt to "solve" this by  
> > making
> > guesses about where to punt a client, but they're using the recurser  
> > IP
> > address, not the client's.  This can trivially fail in many cases.   
> > There
> > is no guarantee about the closeness of a recurser to the client.
> 
> Of course not.  Fortunately objective reality shows that it works high  
> 90s percent of the time.  And most of the time it is wrong, the  
> "wrongness" is still not horrifically wrong (e.g. nameserver in SJC,  
> host in IAD).

So, only from one coast to another.  "I see."

> I do not have numbers, but I would bet that this matching is much  
> higher than the RIR/geography matching.  (Sorry, we don't use RIR  
> geography to map things.)

And you don't have to, with what I'm talking about.  But a client could
use it as a first-level approximation of something reasonable to do,
absent any better clues being provided by the server.

> I do have hard numbers that the idea of doing a redirect or latency  
> test _at the time of connection_ is on average slower than this tiny  
> percentage of disoptimization for all but the largest files (e.g. 100s  
> of MBs or GBs), and even then only for the worst of misdirected clients.

Not all protocols allow a redirect.  I'd like to see something that acts
at an intermediate level.  Something *new*.

> Of course if you are in South Africa, South America, some South East  
> Asian countries, etc. (hrmm, I see a pattern forming here :), then  
> things change.  But the entire traffic to Africa is smaller than some  
> cities in the EU or North America.  Doing more work in the vast  
> majority of cases to optimize the corner cases is silly.  And even in  
> those corner cases, the server _can_ optimize without harming the rest  
> of the clients.  Look at most CDNs or Google's GGC for just two  
> examples.

That's a great excuse to not actually try to address the problem more
generally.  Not.

> IOW: Let the server do it.  The server has more information and can  
> make better decisions.  The client does not, and therefore cannot.

In many cases, the server isn't doing jack, though.  People just pass
out some IP addresses.  (See, again, the start of this discussion)  The
website implementor expects some particular behaviour and finds out that
the Internet is a very strange place, and it doesn't work as expected,
not because the server "has more information and can make better
decisions", but because the server *HASN'T* done that.  In such a case,
in particular, your statement rings completely false.  My copy of Firefox
already tracks things like download speeds from a given website.  There
is no reason that my PC couldn't have a general idea of overall network
performance to various areas of the network, just as one possible example.

> >> If you make that assumption, fine.  But even if you assume the  
> >> server-
> >> side has any intelligence at all, or even is just allocating things
> >> randomly, then doing anything other than blindly accepting the
> >> server's decision is counter-productive.
> >>
> >> And since we have no way to signal "this server knows what it is
> >> doing" vs. "this server is stupid", I think the safer assumption is
> >> the server is doing something intelligent, or at least random.
> >
> > But, Patrick, what did I just finish saying in my quoted message?
> 
> Yeah, Joe, I'm the one not listening to you.

Clearly.

> > I would like to see a system where *both* sides could participate in  
> > the
> > process, because that's the only way to really cover all the cases.
> 
> [snip]
> 
> I think you'll find that unless you are downloading DVDs from across a  
> continent or ocean (and sometimes not even then), the extra work done  
> to optimize things actually makes the whole experience worse than just  
> doing it the way we do it today.

I think I expect to see the Internet continuing to become more important,
more data flying around, and more desire to localize resources, for all
the reasons that have made Akamai successful.

> You know, because no one has  
> actually thought of this before or tested it or anything.  But I'm  
> happy to be wrong.

You *are* wrong.  Because nobody has implemented what I'm talking about,
at least not on a meaningful or wide scale.  Specialized clients like
GameSpy might actually be one of the closest things to what I'm talking
about.

> Anything that improves user experience is a Good  
> Thing, IMHO.
> 
> Good luck.  Let us know what you find.

You might do well to contemplate that I'm in an industry that actually 
*does* transfer gigabytes at a time and lacks a reasonable way to do
global load distribution reliably *and* transparently.  I've been
thinking about these issues since before Akamai existed.  The whole
world isn't HTTP.  I'm telling you what I've "found."  I've found that
DNS based load balancing has severe issues.  I've found that you're
screwed if you have a client in Australia connect to a server in IAD
when something half as far is available.  You cannot just magically
move TCP connections around without tradeoffs.  Web sites try to shim
in intelligence through things like redirects and DNS tries to shim in
intelligence through anycast, but a more comprehensive solution could
be had with a formalized standard that allowed both parties to a
transaction to contribute knowledge to arrive at an intelligent 
decision.  This is not something that currently exists or is currently
deployed, but could be created.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.