Re: forking

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

marcelo bagnulo braun wrote:

> The other option is that App2 also want that forking affects the reply 
> packets.

I don't think such a model makes any sense, because it creates a tension 
between:
 - A telling B which locator pair to use for return traffic, but the 
ULP on B might have a different idea on what locator pair to use for 
traffic sent to A. Would the shim layer have to resolve who should win?
 - A telling B which locator pair to use for return traffic, but the 
shim on B determines that this locator pair doesn't work (no 
reachability) in the B->A direction.
It also adds unneeded complexity in the shim AFAIK, because the shim 
would need to be able to handle packet filter expressions (sent from A?) 
so that it can determine which packets sent from B qualify as "return 
traffic".

> After some mail exchanges with Erik, a possible approach for this would 
> be the following:
> - App2a decides to do forking and through the shim API would detect the 
> shim and learn the locator sets (local and peer)
> - App2a decides to establishes a forked shim context i.e. a secondary 
> context within the initial context, which can use the selected locator 
> pair. For doing this, App2a need to signal the shim that new context 
> needs to be created using the shim API. Upon the reception of this 
> signal, the shim at host A would initiate a context establishment 
> exchange (I1,R1,I2,R2) for this new secondary context, that would 
> require the inclusion of some form of context instance identifier.

I'm a bit confused.

I think there is a need for a forked instance identifier due to the 
interaction of the context recovery and forking. I don't see this 
introducing a different model for forking though.

The issue is that with context recovery we have the case where B has 
lost the context for A1<->B1, and B tries to create a context A1<->B1.
Thus B sends an I1 packet to A.
A can easily see that this packet matches the existing context. Thus it 
can immediately reply with an R2 packet, which makes B re-establish the 
context. So far so good. An I1 packet where the ULID pair matches an 
existing context gets an R2 packet in response.

Enter forking. A and B have a context for A1<->B1. The ULP on B wants to 
fork to create a new context A1<->B1. So it sends an I1.
The problem is that A will follow the above context recovery rule, and 
will respond with a R2 for the existing context and no new, forked 
context will be created.

We can easily solve this if we include a context instance number in the 
I1, R1, I2, R2 packets, and make the check for "should I recover this 
context" match on the context instance number in addition to the ULID 
pair. Unless the ULPs do forking the context instance number would be zero.

   Erik