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

Re: reachability also for non-shim protocols

On 29-jun-2006, at 12:33, marcelo bagnulo braun wrote:


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

You're going way too fast.  :-)
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 

Right.
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?
Yes, but I'm assuming by this point there is a big fat list of address pairs, where some address pairs may only be of interest to one client protocol but others may be used by more than one client protocol.
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... 

I don't think I understand...
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
Sure, but if a firewall filters ALL shim packets then you don't have a problem because you're simply not going to be using shim6. The problems start when you can negotiate shim6 but not send probes or some other combinations of parts that work and other parts that don't. 


i mean, you can use the probes as a return routability test.
The point here is that in order to be able to trust a return routability test, this must be something encapsulated in the client protocol. So maybe A1<->B1 works for proto=shim, but not for proto=mip.
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. 

Right!
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 

Well if you read on you'll see that I wrote:
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.
In other words: nice idea, shame about the firewalls that make in unusable in practice.
But essentially, every communciation where we send something and the other side sends something back where we can determine which addresses we used in our packet and that this wasn't too long ago, can serve as a probe. So if an address pair works for MIP, we know it's extremely likely it will work for shim as well so we only need to make sure by sending a probe in shim encapsulation. The other way around, if a shim probe for a certain address pair has timed out, it makes much more sense for mip to try other pairs first as it's unlikely that this pair will work for mip but not for shim.
So a good use of hints makes having a shared probing protocol mostly unnecessary.