[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: forking



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