Support new subflows when the kernel is the client

[cpaasch]

As of now, I do not have the impression that it is possible to allow the creationg of new subflows when the kernel is the client.

If it is possible, how can this be done?

The kernel decides on his own to send a SYN+MP_JOIN. Packetdrill somehow needs to capture this one.

[redward]

That's a good question. That could be possible by sending ADD_ADDR option to the kernel. If the kernel decides by itself there is no way to know the kernel's willing :).

[cpaasch]

The kernel is deterministic. So, we know when the kernel initiates new subflows.

All we need is a way to capture the SYN+MP_JOIN in packetdrill, which is not possible at the moment.

[redward]

The way we could implement this is: forasmuch we know when the kernel will initiate a subflow we could put simply (without connect call):

+0.0 > S 0:0(0) win 29200 <mss 1460,sackOK,TS val 100 ecr 0,nop,wscale 7,mp_capable a> sock(new_number)

the "new_number" could be an INTEGER, need to be sure this number is not already used. This kind of usage is not yet implemented in Packetdrill.

By the way, I don't see how the kernel would decide to open a second subflow by itself ?
Will it try to open on a different network interface (client NIC !=) of the kernel or on a different NIC of packetdrill (server NIC !=)?
For the first, can't see how make it. For the second could be made as previously mentioned.

[cpaasch]

Inside packetdrill we might add another IP to the kernel's tun interface. Then, the kernel triggers the creation of a new subflow.

Alternatively, we can force the kernel to open 2 subflows for the pair of IP-addresses that is being used by the initial subflow.