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

Re: Second shim

What would be the difference between the "second
shim" and the actions of the "updated RFC 3484" that
we talked about in Amsterdam? Does the latter
impact applications? I thought not, but I may be
mistaken.

--Jari

Iljitsch van Beijnum wrote:
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.
Finding additional addresses is a challenge of its own, but a good start would be o look up the destination address supplied by the application in the DNS, and then look up all AAAA records for the resulting name. Whether these addresses are all present on the same host or they are for different hosts implementing the same service is of no importance at this point.
There is the slight caveat that hosts will now connect to a different address than they thought they were connecting to. A weak version of the second shim would leave the destination address untouched but only cycle through the available source addresses if the application specifies IN6ADDR_ANY (yes, yes, I know, this doesn't exist as such). In practice we'll probably want some management hooks that allow the administrator to specify whcih application/protocols get which treatment. 

Thoughts?