A Little-Heralded New iOS 7 Feature: Multipath TCP 172
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."
Re:closed source triumphs again (Score:5, Informative)
Missed the whole, "Until now, Multipath TCP has been mainly used by researchers with a modified Linux kernel," part did ya?
You're Not Making Sense (Score:5, Informative)
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.
Good idea, but ... (Score:3, Informative)
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.
Re:closed source triumphs again (Score:3, Informative)
It is open source itself. troll.
http://multipath-tcp.org/pmwiki.php/Users/DoItYourself [multipath-tcp.org]
Re:Maybe ... (Score:3, Informative)
It does officially support HTTP1.1, but most servers detect Safari and use HTTP1.0 instead.
Re:IPv6 (Score:5, Informative)
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).
Re:Good idea, but ... (Score:4, Informative)
no it doesn't (Score:4, Informative)
Android got offline speech recognition a while ago:
http://www.androidcentral.com/google-search-update-allows-third-party-developers-use-offline-speech-recognition [androidcentral.com]
Re:closed source triumphs again (Score:3, Informative)
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.
Re:Maybe ... (Score:5, Informative)
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 [tech.vg.no], 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).
Re: You're Not Making Sense (Score:2, Informative)
As linked by the article, Multipath TCP is a way for a device to use several different interfaces for a single connection. This works by forming several ordinary TCP connections to the one endpoint - one for each different interface. These connections are associated by the endpoints, so that packets can be sent down either connection to get to the other end. They may be connected through entirely different networks, and take very different paths, but because the endpoints know they're related, everything can be put back into the proper order and used like a normal connection.
Like TCP, both the endpoints need to know how to speak the protocol. The network in between does not.
If only one of the endpoints knows how to do multipath TCP, the connections aren't properly associated, and it becomes just like 2 ordinary, independent connections - they can be made, but you can't split the packets between the two.