forking

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

Hi,

I would like to understand a bit more in depth what is the expected 
behaviour of forking.

Suppose we have hosts A and B that establish a shim context.

Now suppose that we have a couple of apps running in A App1a and App2a, 
communicating with App1b and App2b respectively
suppose that App1 is the one that has established the initial 
communication for which the shim context was established
App2 was established later, but App2 wants to do forking. In order to 
do that App2 must detect that the shim is in use and then discover the 
available locator sets (local and peer) and then select the locator 
pair to use.
Now, detecting that the shim is in use and discovering the locator sets 
imply changes in the API (not in the protocol)
App2 can select the locator pair to use when sending packets through a 
new shim API and again for this we don't need changes in the shim 
protocol
In this case, the behaviour would be:
- App2a wants to do forking, so through the shim API detects the 
presence of the shim context and learns the locator sets (local and 
peer)
- App2a through the shim API selects the locator pair to use for the 
packets that App2a sends
- when packets reach App2b (App2 running in host B) they are delivered 
to the app and it wold be possible that the shim through the shim API 
informs App2b about the locator pair included in the packet. At this 
point, App2b can also do forking and select through the shim API the 
locator pair to be used for sending App2 packets from B to A.

The nice part of this is that we don't need to add complexity to the 
shim protocol. I would argue that it is reasonable that the app needs 
to be involved in forking since it is itself the one that is selecting 
the locator pair to be used

The other option is that App2 also want that forking affects the reply 
packets.
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.
- After the new secondary context is established, App2a would start 
sending packets to App2b through this new secondary context. App2b 
would need to be informed, through the shim API that a secondary 
context is being used to exchange packets and App2b could use it to 
send reply packets

These are basically the two ways identified so far to do forking, do 
you have any other idea of how forking would be? do you have any 
preference for any of these two approaches?

The main difference afaict, is that the first approach does not 
requires protocol support while the second one does. Both of them 
require App involvement and API support

Regards, marcelo