Slashdot Mirror
A Little-Heralded New iOS 7 Feature: Multipath TCP
Olivier Bonaventure writes "Besides changes in UI, multitasking and other features that the press discusses, iOS7 also includes support for Multipath TCP. Multipath TCP is a major extension to TCP that is able to use different interfaces for the same connection. Until now, Multipath TCP has been mainly used by researchers with a modified Linux kernel. iOS7 changes that, with millions of Multipath-TCP enabled devices that can switch from 3G to WiFi without losing existing TCP connections. This is not yet the case on iOS7, which currently seems to only enable it for SIRI, but other use cases will likely appear in the future."
Missed the whole, "Until now, Multipath TCP has been mainly used by researchers with a modified Linux kernel," part did ya?
An enigma, wrapped in a riddle, shrouded in bacon and cheese
How could Tim Cook forgot to present this feature ?
The headline says IOS7 has it, but the synopsis says that it doesn't yet.
The reality is that for Multipath TCP to work, both ends of the connect must be Multipath TCP capable. That is NOT the case in 99.999% of connections.
It seems that Apple has made Siri multipath TCP capable, ergo... What all this means to you or me is, not much, but hopefully a more reliable Siri connection and response. That means she might ask you if you want her to search the web for you more quickly than in the past.
I can understand that Apple wants to speed up Siri (the latency on Siri can be horrible, even over a fast WiFi connection), but why do it this way rather than enabling simultaneous client-side speech recognition a la Google Now (even in the Google app on iOS)?
Google's method allows the speech recognition process to appear instantaneous. On a Nexus 4, Google Now recognizes speech almost as fast as you can speak.
Siri on the other hand can often take several seconds to understand a request, even under iOS 7. To me, this more than anything else is what diminishes the user experience.
Multipath TCP is a very cool idea, but there are lots of barriers keeping people from really using it. Those barriers have jack shit to do with peoples' own computers, and everything to do with everyone else they want to talk to, whose machines aren't expecting a single conversation to be taking place with two different addresses.
If I could get away with it, I would be delighted to have my home router use several different ISPs, wrapped together. Sure, I can do that now, but not at the individual connection level.
Maybe because:
This is not yet the case on iOS7, which currently seems to only enable it for SIRI
If it's just for Siri, then at this point, it's still a highly technical feature that the user won't be able to see obvious benefits from. Apple generally won't present technical features in their Keynote unless they can explain how users will benefit.
It is open source itself. troll.
http://multipath-tcp.org/pmwiki.php/Users/DoItYourself
Multipath TCP is implemented through TCP options so everything happens above the base IP (v4 or v6) layer. There's not specific advantage with IPv6. It can even happen transparently with one link over IPv4 (say wifi) and another link going over IPv6 (like your mobile bearer).
This seems like a very fundamental improvement to the Internet for handling mobility, and a popular product like the iPhone should really boost adoption. Cellular communication is defined by the ability to pair with the best of several available routers, and switch from one to the other without dropping the connection - this is essentially what makes a cellphone different than a plain old cordless phone. But there has always been this annoying disconnect between the cellular network and the Internet, and this sounds like a big step in that direction. If we want super-mobile devices, like dick-tracy wristwatches, they will only have enough power for short-range communication so they will need super-dense infrastructure of some sort, like dynamically pairing with the nearest available wifi or smartphone - migrating connections to the Nth degree.
But it is a great mass-market testcase.
One of my everyday rituals is walking out of my office building and across the parking lot. During my walk across the parking lot, I ask Siri to call my wife. At some varying point, the building's Wifi cuts out and 3G kicks in. As soon as I read this headline, I knew exactly how it would apply to my life.
This would also be good for Pandora. My home's Wifi reaches almost to my street corner, so I can be several hundred feet away from my house using Pandora and still on Wifi. When I turn the corner, 3G goes on and Pandora cuts out because it lost Wifi. Again, another very practical use of this technology.
Bill Clinton: Pimp we can believe in. - The Shirt!!!
You're right but consider this scenario. You're at a coffee shop that offers wifi and you also have mobile network. You're streaming something to your phone which naturally prefers the wifi network. You get up and walk away and lose wifi. The TCP connection is lost, even though you have a perfectly good moble network also available. The TCP connection needs to be reestablished.
With multipath TCP in the same scenario your phone would have the option of setting up two TCP connections, one over each network. It would present a single socket to the streaming application (who is none the wiser). The multipath TCP socket sends packets over both networks (using whatever spread it feels appropriate). When you walk out of the coffee shop and lose the wifi the multipath TCP socket would stop using the dead network and only use the good network (mobile in this case). No loss in connection.
Android got offline speech recognition a while ago:
http://www.androidcentral.com/google-search-update-allows-third-party-developers-use-offline-speech-recognition
Yes, it really actually is extremely hard. Even detecting when a TCP connection has died is extremely hard, and ends up coming down to "try to ping them every few seconds and see if it gets there" type hacks, which have high latency of detection.
It does officially support HTTP1.1, but most servers detect Safari and use HTTP1.0 instead.
I haven't hit this problem myself on any of our large websites, but googling yields this, which seems to indicate that the problem may be on caching proxies. I haven't seen it with Linux Virtual Server (using Direct Routing), Apache, Squid, or Apache Traffic Server (with pipelining support enabled).
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)