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

Re: host-centric draft

On 25-feb-04, at 18:06, Erik Nordmark wrote:

So the question is: can we detect the actual reachability using probes
fast enough that we don't feel we also need to look in the routing
tables?


That's on the benefit side, but also have too look at the cost side
in terms of scaling.
If all hosts perform e2e probing of all the local/peer locator pairs
this might add up to a lot of packets;

I'm afraind looking at the routing table first has very little impact on the number of reachability probes that are sent. After all, any given prefix is present in BGP 99% or more of the time, but we still don't know whether a certain address within that prefix is reachable. So only in the 1% of all cases where the routing table tells us the prefix is unavailable we save something.

might be more than the amount of
data packets that are exchanged in some cases (imagine hosts being sensors
which only send a data packet every 30 seconds and now you add probing 4 or
so local/peer locator pairs!).

That's why I think we should only perform reachability checks when we already know or at least have a strong suspicion that something is wrong.

One possible exception is session establishment: it might be useful to try several setup attempts in parallel, as the one that completes the fastest is probably also the one that offers best peformance during the session.

If we care about *site* (and not *host*) multihoming one could try to
have hosts share the information they learn from probing with their
neighboring hosts. But that leads more or less to reinventing
a routing protocol.

I think this would be useful (how many routing protocols are there? still room for one more) but we have other things on our plate right now.