reachability also for non-shim protocols

[Iljitsch van Beijnum <iljitsch@muada.com>]

I've been thinking a bit more about the issues with making the  
reachability detection protocol more general so it can be used for  
protocols other than shim6 as well. I'll be calling shim6 and other  
protocols that are interested in reachability "client protocols".

The whole process of rehoming to a new address pair can be broken up  
in several parts:

1. Make a list of individual addresses / address pair under  
consideration ordered by preference

2. Order available address pairs by likelihood of being reachable

3. Integrate 1 and 2 into a single ordered lists of address pairs  
(order of subsequent probing)

4. Schedule probes, considering exponential backoff

5. When packets are received, update 2

6. Choose an address pair and perform a return routability check

Step 1 must be done by the client protocol, and if it supports  
preferences, those will probably be per session rather than the same  
for all sessions.

For step 2 there is no client protocol specific information so it can  
be done host-wide. It's also very useful to include information from  
other sessions, contexts and client protocols, including upper layer  
feedback. For instance, if a host has two addresses and a dozen of  
sessions tied to each, and suddenly there are problems with stuff  
tied to address 1 but not address 2, it makes sense to avoid pairs  
with source address 1.

It doesn't matter too much how 3, 4  and 5 happen, although ideally,  
scheduling happens host-wide so synchronization and temporary  
congestion are avoided.

6 is again something that must happen in the client protocol. In  
theory, making sure the other side is who we think it is can be done  
for more than one client protocol at the same time (this is what I  
tried to accomplish in http://www.muada.com/drafts/draft-van-beijnum- 
shim6-reach-detect-00.txt which the secretariat still hasn't  
posted...) but in practice that is the firewall problem, which can  
make it such that a certain path is usable for one client protocol,  
but not for another, because the second one is filtered out by a  
firewall.

So the return routability check must be performed by each client  
protocol itself. Considering all the ways in which this can go wrong,  
performing the return routability checks involves most of the  
complexity of probing reachability in the first place, so we must  
invoke the end-to-end principle which I think applies in the  
following way: if all cient protocols must do all this work  
themselves anyway, having another instance of the same mechanism in  
the middle serves no purpose.

However, there is synergy to be had and congestion to be avoided by  
sharing the reachability detected by other protocols as hints. The  
trikcy part is figuring out how this should happen. I want to say  
"API" but how many APIs can we stand to have? And because all/most of  
this happens in the kernel, it should be possible for implementers to  
do the right thing without any guidance from us. Or maybe not. I  
don't know.

It would be worthwhile to separate the specification into a shim- 
specific and non-shim-specific part to promote code reuse, though.

Thoughts?