If iOS is exposing the API, I believe it should at least provide a parameter whether it should be a MPTCP or a classic TCP. Sometimes you don't need that reliable trasmission; using MPTCP would cause unnecessary cellular data usage.

Multipath TCP could be used for smoothly handing over from the slower, more expensive, less-reliable cellular system, to the faster, cheaper, more reliable WiFi.

Without multipath TCP, you have to drop and restart each connection, which in some applications can cause hiccups, latency, or even complete loss of state.

Of course, all of this depends on server-side MPTCP support as well, which most systems don't ship with out of the box.

Right. What I'm saying is that, by keeping alive both path, you need to use some traffic. Although when there's WiFi available, you are primarily using WiFi, there are traffic going through cellular network in order to keep the path alive.

would be really cool if slower / more expensive connections could ultimately be drained, and the whole data transfer just switches over to a single more faster connection.

edit-1: note that this is not the same as subflow 'deletion' that would happen if an access mechanism was not available at all.

edit-2: section-3.4 of the mptcp paper indicates that FIN has a more limited 'no more data on this subflow' semantics. so, in theory it should be possible to do just that. would be so much better to not go the ANDSF route at all ;)

Hey! I didn't go into that deep! So if FIN is used in a subflow, does it terminate that path? Is it possible to wake this path up again?

the shorter answer first: i don't think there is any possibility of resurrecting a subflow once it is gone.

longer one: with mptcp, there needs to be some way to distinguish connection-teardown vs subflow-teardown. with, RST the subflow is terminated. FIN is more subtle (since it occupies the sequence space in normal tcp) however. FIN is handled via an explicit DATA-FIN within TCP option to indicate the end of data-sequence-space (which maps subflow sequence numbers to data sequence numbers in TCP options). gracefully terminating a connection, thus involves sending DATA-FIN on all subflows together with a FIN.

> to the faster, cheaper, more reliable WiFi

This is far from universally true and a wonderful illustration of why multipath is great: I frequently see wifi where the back link is down or behind a payment gateway, requiring me to turn off wifi to get a reliable connection. This is sadly common at conferences where the venue skimped on AP placement and left entire rooms at max range or with inadequate backhaul.

The true beauty of MPTCP is that you don't need to make assumptions and hope — instead we can let the kernel sort things out based on the current environment.

Cellular mobile units are likely to have a short dwell time on any particular WiFi if they are in a moving vehicle. Can the underlying connections be initialized quickly enough for this case?

apllications use just the socket api for their interactions with the n/w stack. there is no change there, and hence the "unmodified applications" part.

from the mptcp paper, we have the following :

In brief, here is how MPTCP works. MPTCP is nego- tiated via new TCP options in SYN packets, and the end- points exchange connection identifiers; these are used later to add new paths—subflows—to an existing con- nection. Subflows resemble TCP flows on the wire, but they all share a single send and receive buffer at the end- points. MPTCP uses per subflow sequence numbers to detect losses and drive retransmissions, and connection- level sequence numbers to allow reordering at the re- ceiver. Connection-level acknowledgements are used to implement proper flow control.

so yes, both endpoints need to support mptcp for this to work.

Here is a video where they show it running, droping wifi and network connections.

http://www.youtube.com/watch?v=VWN0ctPi5cw

It will, however, require changes at the kernel level.