Re: shim-aware transports

[Erik Nordmark <erik.nordmark@sun.com>]

john.loughney@nokia.com wrote:

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

I don't think there is any out of sync problem with the uncoordinated 
"forking". A has a set of locator pairs it is using when sending to B, 
and B accept all those locator pairs (and context tag) as mapping to the 
same ULID pair.

A chooses which locator pair to use for any given packet, based on its 
probing and path exploration (after a suspected failure), and it doesn't 
need to coordinate this with B.

If we add the uncoordinated forking, this just means that A might, more 
or less persistently, use different locator pairs for different classes 
of traffic (e.g., {A1, B3} for "time sensitive" and {A2, B2} for 
"bulk"), which doesn't have any impact on B, since B will map those to 
the same ULID pair.

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

Yes, but that "uncoordinated" property is what we need to handle 
unidirectional locator pairs in any case.

FWIW it isn't clear to me that we need a "coordinated forking" 
mechanism; it seems to be counter to the idea that each end can decide 
which locator pair to use when sending.

   Erik