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

Re: Second shim

El 12/10/2005, a las 11:55, Iljitsch van Beijnum escribió:
I had a conversation with Tony Hain and Daniel Karrenberg yesterday, where we discussed the issues with the shim and very short-lived sessions such as single packet UDP request/reply interactions. 
This ties in with the "failure of the initially chosen locators" issue 
that we talked about. I think it was Daniel who brought up the need 
for a "second shim" that sits between the application and the 
transport protocol that could handle this need.

I think that makes a lot of sense. The current shim is all about 
keeping ULP sessions flowing within the constraint of keeping the 
ULIDs stable. But in a single packet interaction there is no need to 
keep ULIDs "stable": you can just try different source/dest addresses 
and retry the transaction until it works.

I think the current presumption is that the application itself would 
do this. However, for what the shim as it is now _does_ do, the idea 
is that the shim's activities are completely hidden from applications 
and ULPs. So it makes sense to consider the possibilities of allowing 
current applications using current APIs to survive initial failures.

I'm not talking about single packet UDP stuff anymore: for our 
purposes, a TCP connection establishment is pretty much also an 
exchange of a handful of packets. It's only after the session 
establishes and the application starts sending/receiving data that TCP 
and the like are constrained by the requirement that the addresses 
remain stable. However, at this point the shim as currently intended 
can take over so that's not a problem.

It would work as follows. The "second shim" intercepts session 
establishement requests (bind(), connect() and the like) along with 
the sending of UDP packets (sendto(), sendmsg()). The second shim then 
first tries the requested action using the addresses supplied by the 
application and/or RFC 3484 address selection mechanisms. When this 
action times out, the second shim looks up additional addresses (see 
below) and tries all source/dest combinations until something works. 
At that point the whole thing is handed back to the calling 
application and the second shim gets out of the way.

First of all, i think it is important to exactly identify the scenario 
that we are considering. I can see two scenarios here:
- Scenario 1: the host that is initiating the communication supports 
some multihoming specific mechanisms but the peer is just a legacy IPv6 
host (no special multihoming support)
- Scenario 2: both hosts involved in the communication support 
multihoming specific mechanisms (like the second shim that you are 
talking about)

In scenario 1, the ULID and the locator used for the communication need 
to be the same since the peer does not support the translation, so, 
using a different ULID that the locator used would break things.
In this case, what we need would be the upgraded RFC3484 which would 
allow to cycle through different source addresses.

However, i would like to note some part of RFC3484:

   The application might also specify a source address
   with bind(), but often the source address is left unspecified.
   Therefore the network layer does often choose a source address from
   several alternatives.
...
   Separately, the IPv6 network layer will use the source address
   selection algorithm when an application or upper-layer has not
   specified a source address.


So this basically says that in very common scenarios, is actually the 
IP layer that selects the source address. In this case, then it would 
be possible to build additional mechanisms within the IP layer that 
when a packet with unspecified source address is received, it tries 
different source addresses and uses the one that seems to be working 
(we still need to understand what does "seems to be working means 
though..)

I mean, that updated RFC3484 could provide enhanced mechanisms to 
perform source address selection when the application leaves the source 
address unspecified, that would allow to try multiple source addresses
Perhaps this mechanisms would also work for legacy hosts (hosts that 
don't support the updated RFC3484) sicne it will only require support 
from the initiating host, that should try multiple source addresses

This behavior would be transparent for ulp as long as they don't 
specify the source address. If the source address is specified, then 
the app should cycle through different source and destination 
addresses. This seems to be coherent with the fact that the app is 
specifying the source address

In the second scenario, is what i understood that we called API on 
steroids in the interim meeting, where the app asks to connect with a 
given ulid and the shim will ask the resolver for the additional 
addresses that the resolver obtained for that particular query, and 
tries to connect using different locators, but keeping the same ULID.
This would cope with some failures but we need to keep in mind that 
different addresses associated with a given FQDN may belong to 
different hosts. this means that the shim needs to ask if the 
alternative locator used belongs to the same host that the used ULID
Actually, this is not good as it may seem, because maybe, it is 
possible that there are no working locators for that particular ULID, 
but that other addresses that are asociated with the same FQDN but that 
belong to a different host (hence cannot be used as locatros for the 
selected ULID) are working
In this case, it would be the application that needs to retry with a 
different ULID; but in this case, the shim could inform about which 
ulid to try first since it already knows which ones are working.

So, as we talked in the interim meeting, i guess that what is needed is:


- Updated RFC3484 to deal with legacy hosts and to cope with apps that 
left the source address unspecified

- API on steroids, to deal with apps that want to keep  the ulid fixed

- signaling from the shim to the ulp so that when the ulid selected is 
not working, information about which combinatiosn are working is passed

regards, marcelo