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.
I think that indeed Safari is a bit slower in IOS7 than it was on IOS6 (on ipad 2, already an older machine). In general the look and feel of IOS7 is appealing. Still not explored everything of course.
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
Safari is typically forced to use HTTP1.0 with no pipelining because it doesn't implement the standard correctly. Because of this, it has to create new connections for each object which requires a 3-way handshake over a high latency connection.
It does officially support HTTP1.1, but most servers detect Safari and use HTTP1.0 instead.
It seems to me that Siri is a bad use case for Multipath TCP. Siri transactions seem to be fast and short-lived. i.e. You wouldn't need a persistent connection that could service transitions between Wifi and 3G. So why use MultipathTCP on it?
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.
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.
Don't they get that anyway, every time they release a new iOS?
(And yes, I know, MS do the same thing with v1 of any of their Windows OS's - never trust 'em 'til SP1 comes out)
I say we take off and nuke it from orbit. It's the only way to be sure...
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)
However, iOS 7 was announced at WWDC which is a conference for developers.
Surely this is exactly the technology you want your app developers using to enhance the experience of your mutual customers?
Backup not found: (A)bort (R)etry (P)anic
That have to be redeveloped every new app- hopefully properly. If every app will benefit from having its data transport being more robust like this why not put it in the transport layer where it will be more efficient? With your attitude we should all be happy with HTTP1.0 too.
Having Multipath TCP inside the operating system allows all applications to automatically benefit from its features without forcing each application to reinvent the wheel. Operating system services help application developers by providing them with reusable services through standard APIs. In the case of Multipath TCP, at least on Linux, the standard API is the socket API.