[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