[multipathtcp] Multipath deployment and fate sharing

[Costin Raiciu <[e-mail]>]

Hi,

I have been thinking about this for a bit now, and have chatted with various people from different OSes. 
Murari (from Microsoft) said that they will probably not turn multipath on by default at first release; apps wll be able to use it, but will need to opt in. This will give app writers a chance to update their apps for multipath - since the apps that break are likely a small subset, it seems it will be possible to upgrade these given the time window between OS releases. I would guess most other OSes would do the same in the initial release. So, by default, client hosts will not have multipath "on".

Let's consider mobiles. This is where multipath is badly needed for supporting connection handover between interfaces. Here most of the apps typically run as high level managed code - mostly for security reasons; I bet one can change the stack without breaking these apps even if multipath is on by default. The low level apps that would break are already written mostly by the company running the OS - hence will be natural to upgrade. 
In short, I think multipath could be turned on by default for mobiles, if the mobile providers want this.

Finally, servers: Linux currently has ecn turned on by default for servers, and off on clients. I would assume the same could hold for multipath. This would ensure that initially mobiles can talk multipath to servers, but standard client-server communication is unipath. 

This deployment model seems natural to me, as it gives the much needed benefits to mobiles immediately, and allows the more mature desktop market to slowly sink in multipath.

Coming back to fate sharing of multipath connection and initial subflow: I would assume fate sharing will be a sysctl flag on the host, telling the stack whether the connection should go down or not with the first subflow. I imagine three settings here:
a) connection doesn't go down with first subflow
b) connection dies when local interface dies
c) connection dies when subflow times out (this implies b)

As long as the protocol itself does not make assumptions about fate sharing, the endpoints can do whatever local policy says.  I would imagine mobiles will do policy a), servers can probably do policy b), and clients c) - assuming it is hardest to tell what apps break on client hosts (the apps that use TCP to test path properties will break so they would like c).

I think the combination of these two choices (multipath on/off + fate sharing policy) allows everyone to get what they want, when they want.

Thoughts?
Costin