[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: reachability also for non-shim protocols
El 26/06/2006, a las 21:51, Iljitsch van Beijnum escribió:
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
yes, but preference information can be in may forms, considering local
policy, peer policy, temp vs public add, HoA vs CoAs and so on...
so i guess that all this needs to be integrated in a single list
2. Order available address pairs by likelihood of being reachable
again there are multiple sources for this information, local, remote,
e2e
same here, we need to integrate all this information in a single list
(which imho is simpler thant the previous case...)
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
this is funny, i would say that probes of step 4,5 could be used for
this...
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.
yes, but again, there are two aspects here.
on one hand we have the protocol specific preferences, like the locator
preferences options of shim6
then we have that each protocol may have different usage for different
type of addresses, like preffering temp over stabel addresses and so on
For step 2 there is no client protocol specific information so it can
be done host-wide.
well, different hosts may decide to include different locators sets in
the contexts, so the list will vary depending on the particular
context, and particular protocol, right?
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.
right, but maybe the sessions have different sets of addresses, so the
addresses available for one session are not available for the other
one. In this case, you need to probe with different addresses for
different sessions...
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.
but this is the case for all the probes imho
i mean, you can use the probes as a return routability test.
I guess that what you are proposing is to make the probing using a
general protocol and then perform a return routability check using the
client protocol specific encapsulation in order to verify if the
particular client protocol is filtered by the firewall.
The other option is to perform the probes using the client protocol
encpasulation and then you don't need to perform the additional return
routability. The trade off here is that you do a joint path exploration
for all protocols but you need an additional return routability check
per client protocol (and the added complexity of coordinating among
protocols...) i am not sure is worth it
regards, marcelo
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?