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

Re: Second shim

On 12-okt-2005, at 15:26, marcelo bagnulo braun wrote:

[...]
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 order to provide decent multihoming capabilities we need to solve scenario 2, but a mechanism where we intercept the API calls mentioned above and retry them with different addresses until there is success works regardless of whether the correspondent supports the shim, so it also covers scenario 1.
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.
Since this "second shim" sits between the application and the transport protocol, the breakage is very different from what happens below the transport: all transport-related functions work without trouble because the addresses the transport protocol sees are the ones on the wire. The only problem is that the application may think it's using a certain address while the communication is really using a different address.
In this case, what we need would be the upgraded RFC3484 which would allow to cycle through different source addresses.
RFC 3484 says _applications_ should cycle through all destination addresses. That's no good for two reasons:
1. as discussed in the interim meeting, cycling through just the destination addresses isn't enough to pass through ingress filtering and the like, you really need cycling through all possible address pairs (source as well as destination)
2. putting this burden on applications is bad because it means reinventing the wheel and if an application doesn't do the right thing multihoming won't work right (and cycling through all source/ dest pairs is hard to implement in applications) 

[quote from RFC 3484]
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
Yes, but we want this for the destination address too. But doing it for the source if left unspecified is better than nothing, I guess.
(we still need to understand what does "seems to be working means though..)
TCP and such: easy: the connection establishes. For UDP it's a bit harder but a packet coming back with the same source/dest addresses and port numbers but now reversed seems like a pretty good hint that things are working.
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 

Yes. Applications generally specify a source address for a reason.
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.
That may be useful for some shim aware applications, but we need to be concerned with unmodified applications.
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.
For these purposes, that's not important. Whether you connect to www1.cnn.com or www2.cnn.com (that both share the alias www.cnn.com) doesn't matter as they both provide the same service. Only once you have a session you don't want to jump to another host any longer.