RE: shim-aware transports

[<john.loughney@nokia.com>]

Erik & Geoff,

>> Placing the potential functionality in the hands of the session layer

>> also infers that the shim state may not necessarily be 
>> endpoint-to-endpoint, but may operate at a finer level of selection 
>> (the 'equivalence" topic I referred to at the WG meeting). It also 
>> infers that an individual session may want to trigger a locator
change 
>> that appears to be an isolated request - in which case there appears 
>> to be a logical need for dynamic shim state forking in some form
(i.e. 
>> a shim state may state in a general host-to-host state, but
individual 
>> sessions may 'fork' out of this general state by requesting
individual 
>> locator change trigger settings, for example.)
>
>Geoff,
>
>This notion of forking makes sense, but it isn't clear to me 
>whether it is a local notion at the sending side, with the ULP 
>at each end being able to make independent decisions (perhaps 
>using some ULP signaling), or whether it is a shim-coordinated 
>decision.
>
>I think we can define it to be a local thing at the sending 
>side, where a ULP can signal that a given class of packets 
>between a ULP pair (or even at the granularity of each packet) 
>use a different locator pair than the default. The receiver 
>will happily accept such packets, because the locator pair is 
>in the negotiated set of locators for the ULP pair context.
>
>Do you think we'd loose something important if there isn't 
>shim signaling to have the two ends agree to switch the 
>locator pair for both directions?

I might be missing something here, but if a ULP forks-off of a shim
session toand uses a different locator pair than the default, shouldn't
this be signaled to the other end point, otherwise we run the risk
that each endpoint might get out of 'sync' from each other.  

If endpoint a decides to fork-off and start using locater a1' rather
than
a1, the ULP at the opposite end might still be using a1 to send packets
to endpoint a.  

John