Re: shim-aware transports

[Geoff Huston <gih@apnic.net>]

At 11:05 PM 19/08/2005, Erik Nordmark wrote:
> Geoff Huston wrote:
>
> > 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 am not sure whether peer-to-peer coordination is a strict requirement or 
not, hence
my comment about a richer vertical and horizontal signalling API that at 
least leaves
a signalling placeholder there in any case.


> 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.


Exactly my thought as well! The other end may see the use of multiple 
source locators
in the incoming stream and will correctly map these to the same ULID 
and  then demux
them to the active transport entities as normal.



> 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 think we should allow for the possibility for one shim entity to signal 
to the remote shim
entity to attempt a switch to a specific locator set for a specific 
"state", forking its state
as necessary, but its a weakly formed thought at this stage!


regards,

    Geoff