RE: shim-aware transports

[<john.loughney@nokia.com>]

Pekka,

>I have a feeling we have some sort of a communication problem 
>here but that we fundamentally agree; this message is an 
>attempt to clarify what I am trying to say.
>
>I am all for the initial goal of keeping the ULPs unchanged.  

To finese this a bit, I would hope our goal would be that shim6
would work if the ULPs are unchanged, but ULPs might benefit
from some extra richness that the shim would provide.  I guess
what I am wondering is, do we create some extra richness in 
socket options (for example) or whatever is the OS API for the
shim layer, what ULPs could take advantage of.

>That's the whole point.  However, when doing so I also think that we
>*probably* should adopt the conservative approach adopted by e.g.  
>SCTP, i.e., to have one preferred locator and to use the rest 
>as equal backups.  Two reasons: keep it simple, and less 
>surprises to the transport algorithms.

I agree in the basic shim protocol, that we should keep it simple.

>Now, AFAICT, the discussion below cornered around what to do 
>next, after the initial goal has been reached.  What I 
>remember from Paris we all seem to agree that we need some 
>kind of an interface between the shim layer and ULP.
>
>My two messages (URLs below) define a strawman for such an 
>interface, while trying to keep the system at the same time as 
>simple as possible.  I don't see that changing at all the way 
>the shim works with unmodified ULPs, or what state it maintains.
>
>On the other hand, what I find somewhat worrisome are 
>allusions that we should make the state at the shim layer more 
>complex as we add multi-addressing support to ULPs.  It looks 
>to me that some folks would like to do locator-policy 
>decisions at multi-addressing transports, and then push those 
>policies somehow to the shim, to be executed there.  I find 
>that unnecessarily complex.  Why can't the ULP just pick the 
>locators, if it knows about them; in that case the shim just 
>protects the transport from using locators that are no longer valid.

Isn't this an address selection problem?  A multi-interface host will
have a lot of IP addresses, esp. if there are additional tunnel
interfaces,
privacy addresses, transition mechanisms, etc.  The shim will somehow
need 
to have some simple rules for deciding which of these are actually
useful.
There probably will be some issues with address selection at the shim
layer and then identity selection at the ULP.

John