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
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.
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.
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).
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.
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)