The Linux kernel MultiPath TCP project

Re:The Linux kernel MultiPath TCP project by trotsky on Friday April 19, 2013 @03:08PM (#5578198)

Seems like this is extremely wireless carrier friendly. Once you're able to do transparent tcp handoffs your ability to exploit unlicensed spectrum to offload traffic from your saturated licensed bands without a very obvious service interruption gets much easier. If you deploy devices set to auto associate with a whitelisted set of provider and partner hotspots as soon as the connection is up you can offload the bulk of it, letting you serve more customers with the same amount of spectrum. Addressing heavy demand locations with wifi is way cheaper than minicells or DAS systems and wouldn't involve any regulatory approval or backhaul requirements.

I had to laugh when I saw the charts of LTE+wifi beating wifi alone in throughput. Even if the phone os was setup to try to exploit that, any wireless provider able to tie their own shoelaces is going to monitor multipath traffic like that and once they infer your alternate link is reasonably fast they'll start intentionally congesting their side of the path to force the bulk onto the local route.

I wonder what sort of additional profiling this could enable. Right now my phone is on 3g and my dual homed wifi network. It seems possible that being able to see my traffic from wireless, wireline ip4 and via my ip6 tunnel provider at the same time along with each path's latency would leak more data than existing hard handoffs.

[ Parent | on HN ]

Re:The Linux kernel MultiPath TCP project by yxhuvud on Saturday April 20, 2013 @12:31AM (#5580216)

It will probably be usable from the perspective of a mobile carrier, but really, the hard part is the 'transparent tcp handoff' part. They already know all too well how nice it is to offload traffic to wifi. Two problems exist, and that most carriers don't have the servers or the wifi nets to support it nicely, and that mobile phones doesn't support automatic and transparent handover in a nice way (iOS 5 brought support though, so it is not all bad. Android support is mostly lacking though).

Also, wifi already tend to be so much better that the bulk of the traffic would already go that way if possible without carrier interference.

[ Parent | on HN ]

Re:The Linux kernel MultiPath TCP project by trotsky on Saturday April 20, 2013 @02:08AM (#5580498)

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.

[ Parent | on HN ]

Re:The Linux kernel MultiPath TCP project by obo on Saturday April 20, 2013 @07:09AM (#5581023)

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.

[ Parent | on HN ]

Re:The Linux kernel MultiPath TCP project by yxhuvud on Saturday April 20, 2013 @08:35AM (#5581186)

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.

[ Parent | on HN ]

Re:The Linux kernel MultiPath TCP project by trotsky on Saturday April 20, 2013 @10:38AM (#5581533)

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.

[ Parent | on HN ]