Subject: Distributed reachability information

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 8 Sep 2001 20:15:08 +0200 (CEST)

Thinking about a good way to turn my MILAR proposal into a draft, it
occurred to me that the following should probably be something separate.

In a multi-address multihoming environment, it helps a lot to have good
reachability information for the different addresses of a remote host.
Sending traffic immediately to the "best" address has many advantages over
choosing one more or less randomly and detect failures later.

Being able to pick a working address out of a set of addresses prior to
session establishment can even be considered a very basic form of
multihoming support.

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?

One way would be to create a protocol from scratch.

Another would be to abuse RIP for this. I haven't really looked in to
this, but RIP does a lot of the same things in a somewhat different
manner, so it could be a good starting point.

Then there is the most dangerous way: integrate some or all of this into
the DNS. Name servers already gather a lot of statistics that could be
useful. Also, hosts continuously query the DNS, adding reachability
information to the answers seems like a logical extension. Or the DNS
could even hold back addresses it thinks are unreachable when replying to
queries.

Tell me what you think.

It would probably help to get some input from a DNS guru. That is, if they
didn't all faint upon reading this.

Iljitsch van Beijnum

---

From: Michel Py <[email-masked]>
Date: Sun, 9 Sep 2001 17:06:38 -0700 (PDT)

Ilsitch -

>> Another would be to abuse RIP for this. I haven't
>> really looked in to this, but RIP does a lot of
>> the same things in a somewhat different manner,
>> so it could be a good starting point.

[view in courier font]

This is what RIP is about.

                   _____  _____
                  <     `/     |
                   >          (
                  |   _     _  |
                  |  |_) | |_) |
                  |  | \ | |   |
                  |            |
   ______.______%_|            |__________  _____
 _/                                       \|     |
|           Ilsitch's multihomed setup           <
|_____.-._________              ____/|___________|
                  |            |
                  |            |
                  |            |
                  |            |
                  |   _        <
                  |__/         |
                   / `--.      |
                 %|            |%
                  |/.%%|          -< @%%%
             `\%`@|     v      |@@%@%%    - mfj
           .%%%@@@|%    |    % @@@%%@%%%%
      _.%%%%%%@@@@@@%%_/%\_%@@%%@@@@@@@%%%%%%

Michel.

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 12 Sep 2001 17:03:50 +0200 (CEST)

> 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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 12 Sep 2001 18:19:13 +0200 (CEST)

> public or semi-public 802.11 infrastructure?

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.
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.

> 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.

> in the cache about a particular destination is likely to be rather small.

I think even in relatively small networks the correlation between remote
hosts accessed is large enough to be helpful. 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.

Iljitsch

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 12 Sep 2001 18:36:36 +0200 (CEST)

> 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.

> implementations to calculate these values correctly. So this part is

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.

> the "bad" ones so there should still be some benefit.

And how could you make sure?

> 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

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