Re: Distributed reachability information

[Erik Nordmark <Erik.Nordmark@eng.sun.com>]

> For yes/no reachability information: sure, why not. Either the information
> is correct, and I benefit, or the information is wrong and I'm no worse
> off then if I had picked the wrong address to try first myself.

If you can choose between addresses A and B and B is in fact unreachable
but somebody has entered information into the cache to the opposite
(i.e. that B is good and A is unreachable) then you end up trying B before
A, which seems worse than a random pick.

> Obvioulsy, when the cache says something is not reachable, we only take
> this to mean we should try other addresses first, not that we shouldn't
> try to contact the "unreachable" address at all. The address might have
> become reachable again in the mean time.
> 
> For the more detailed RTT, bandwidth and packet loss information this
> could be more of a problem: skillful manipulation of this information
> might do more damage. And I'm not sure I'm willing to trust all
> implementations to calculate these values correctly. So this part is
> problematic.

Some of those metrics might also become stale in about one RTT (packet loss
depending on congestion and congestion control per connection reacting in
one RTT approx.) so the utility of caching them might be limited.

> 
> > Would you trust one shared by all the customers of one of your ISPs?
> 
> If we make sure one single host can't flood the network with unlimited
> amounts of false messages, the number of "good" messages will outnumber
> the "bad" ones so there should still be some benefit.

And how could you make sure?


> I think even in relatively small networks the correlation between remote
> hosts accessed is large enough to be helpful.

Even for a single household? The household members are not very likely
to share interests i.e. communication patters.

I wish there was real data on IP address usage e.g. for households
so we'd have to data to talk about.

> Especially if the DNS is in
> on it, since in many situations prior to communication the local name
> server will have to contact a remote name server that is close to the
> destination host.

Often the host would communicate with a DNS resolver (a server which does
recursion) and not with the actual DNS servers for the target domain.
And then the DNS does private caching so the resolver (or host if there
is no resolver) might not talk to the authoritative server.
Finally, the location of the authoritative server might not have much to
do with the location of hosts in that domain. For instance, example.com
might run their own authoritative server at the site (with secondaries
at example.net), but www.example.com is outsourced to some completely
different entity and location.

Again it would be useful to have data indicating whether or not the DNS lookup
could provide useful hints to the communication following the lookup.

   Erik

I wonder about the correlation of DNS servers and