[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Distributed reachability information




> This could be accomplished by using some kind of reachability cache,
> storing information about whether an address or prefix is reachable (or
> even how well, using RTT, bandwidth and packet loss statistics). As the
> session is initiated, the possible addresses for the remote host are
> checked against the reachability cache and the "best" address is selected.
> Obviously the choice is limited when just one address is available: then
> the system should try to connect to this address, whatever the cached
> status.
> 
> The data for the cache can come from ICMP unreachables and protocols or
> even applications that gather their own statistics. Sharing this
> information with other hosts and routers (as Peter Tattam and myself
> discussed earlier this week) makes a lot of sense. If one host discovers
> an address is unreachable, other local hosts can benefit from this and
> immediately contact one of the other addresses for this destination host
> if they want to connect to it shortly after that.
> 
> The question is: how do we implement this?

Before you go there I have a more basic question:
What is the trust model associated with the notion of a reachability cache?

Would you trust one shared in the IETF terminal room or any other
public or semi-public 802.11 infrastructure?

Would you trust one shared by all the customers of one of your ISPs?

If you can't trust "random" hosts in a fairly large network
(larger or a lot larger than a single home or personal area network) to
contribute unverified information to the cache then the idea doesn't seem
to be that useful since the probability of finding recent information
in the cache about a particular destination is likely to be rather small.

And if you take the path to verify the information I suspect (but it makes
sense to verify this) that many aspects of the solution space start looking
more like trusted route servers in the domain (that perhaps somehow interact
with the site border routers).

   Erik