This is the main feature of the design, transparent handoff smoother than anything today, without any existing tcp connections dropping and faster throughput recovery. They demo skype handing off from 3g to wifi keeping the call alive and only suffering ~2seconds of delay during transition.

The project has a number of working kernels for various android phones available.

Carriers would widely deploy ISM nets or whitespace if the handoff was painless and your streaming video worst case lagged out a couple of seconds.

An important difference between using Multipath TCP versus other techniques for 3G/WiFi offload is that Multipath TCP would be a completely end-to-end solution. The handover is entirely controlled by the smartphone and does not require any cooperation from the network. Existing 3G/WiFi offload techniques assume that the network operator controls both the WiFi and the 3G network. This is sometimes the case, but even if your 3G provider as several WiFi access points, there are probably many more access points that are not controlled by the 3G operator and that Multipath TCP would enable you to use.

There are levels of transparency. The level you are talking about still require the wifi to either be entiredly open or to have the authenticaten details stored in the phone manually. The level I'm talking about is where your phone automatically authenticates using the sim card when you happen to go near an access point, and then manage to do a handoff with no manual steps involved.

I'm not saying multipath TCP will be very nice for mobiles, but it will mostly be home and work networks that will be used, just like how it is for wifi use in the mobiles today.

As for 2 second handoff being smoother than anything else out there today, that is just not true. The situation for phones doing handoff with EAP-SIM/AKA is pretty similar if not better.

For what it's worth that's two seconds between when one signal was unexpectedly cut, detected, shifted to the other, windows scaled up for a mulimedia stream and the app buffered enough to decide to start playing audio again.

Something considered a two second handoff is going to result in a far longer stream interruption than that in any method I've seen used especially considering the app is not assisting with the process or getting state transition info which it could be if built with mptctp aware libs.