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."
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.
Re: (Score:3, Insightful)
As you said yourself, both ends needs to be MTCP aware. Apple controling its servers can implement/activate on the ones hosting SIRI.
But for Safari to show MTCP behavior, it means that the webserver should also support MTCP and it seems none do.
Re: (Score:3, Interesting)
An interesting feature to push for my employer. Getting our servers to support MPT would mean much of the internet will support it.
No, I don't work for MS. I work for Akamai.
Re: (Score:2)
I wonder if an enterprising developer could make a browser that works like Silk on Kindles or Opera Mini, where it sends a modified version of the page to the device. Then they could enable MTCP on their own server if iOS will let them enable it for their app.
Re: (Score:2)
That's called a proxy, and no - keep your hands out of my bits.
Re: (Score:2)
Fair enough, but I use Silk preferentially on my Kindle because it is faster. I'm not worried that Amazon knows what I say on Facebook. Facebook and my ISP already know anyway, and a faceless corporation is a faceless corporation.
Re: (Score:2, Interesting)
(Anonymous to preserve modding)
In most cases the web server would receive two requests from two different IP addresses, one per path, with the same session cookies. Let's say one request for the HTML and one for the CSS. That would be enough to serve the right content without any modification to the code on the web server. But I bet that some webapps will be extremely confused by those two addresses. Time to start designing them without the assumption of one-IP-per-session, even inside the same burst of req
Re: (Score:2)
(Anonymous to preserve modding)
In most cases the web server would receive two requests from two different IP addresses, one per path, with the same session cookies. Let's say one request for the HTML and one for the CSS. That would be enough to serve the right content without any modification to the code on the web server. But I bet that some webapps will be extremely confused by those two addresses. Time to start designing them without the assumption of one-IP-per-session, even inside the same burst of requests?
Isn't this ripe for security issues (ie, a FireSheep style cookie-jacker could theoreticlly playback the cookie on a different IP and hijack your session)? Of course, nonces [1] would eliminate this problem, but that's not a server-level setting and requires the applications (or framework) to support it.
[1] http://en.wikipedia.org/wiki/Cryptographic_nonce [wikipedia.org]
Re: (Score:2)
But the map of the world with all of the pretty dots on it makes a convincing case otherwise. How could it be wrong? [/sarcasm]
Re: (Score:2)
well, if iOS7 didn't have this sometime, then 100% of connections would not have it.
You have to start somewhere, giving it to loads of apple boys will encourage some takeup and maybe one day everyone will have it.
Re: (Score:2)
Re: (Score:2)
If there's anything Apple knows how to do well, it's releasing technology nobody else uses in an effort to change the technology everyone does use.
I suppose I'm being a bit sarcastic. I suspect Thunderbolt to ultimately see the same "success" as Firewire. Quicktime is still the same afterthought it was years ago. Etc. Etc.
Being different simply for the sake of it isn't going to make some new standard awesome. Being different because the status-quo is outdated is another story.
This multipath TCP sounds li
Re: (Score:2)
the difference this time is that they can't slap a hugely expensive, proprietary port on it.
Re: (Score:3)
Because packets coming from another interface look like they're coming from a different device and will have a different 4-tuple.
Re: (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
An odd way to speed up Siri (Score:5, Insightful)
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.
Re: (Score:2)
IIRC they've implemented this in Dictation on MacOS, so it might not be too far away.
Re: (Score:2)
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.
And this is why I don't use it. The network lag to get a response, while usually quick, is slow enough that I'd rather not wait most of the time for simple, quick tasks. If it had on-board recognition and processing instead of throwing it to Apple servers it would be much more useful (to me), as long as it's on-board results were good. Now I just use it mainly to dictate long text messages or while in the car.
For Siri to really start to be more useful it will need to be always on like some of those Andr
Re: (Score:3)
Android does it all on the server. (Score:2)
It does recognize you said "google" to start recognition, but assuming you pressed the button to start instead of that, it's all done on the server. Even on the Moto X, the processor just figures out that you said the trigger phrase, the recognition of the natural-language speech you say after that is all done on the server.
If you don't believe me, just try it when your phone only has an EDGE connection some time.
Google just has better feedback, they seem to have a better design.
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: (Score:2)
I'll just take a guess here, but I'd think speech recognition using the CPU and storage capacity of a phone will be nowhere near the quality of speech recognition using the resources of a large datacenter.
Re: (Score:2)
There was an article about it recently. Apparently, the phone software uses newer, more efficient technology than the server software, so the difference isn't as big as you might think.
Re: (Score:2)
The datacenter takes the input from tens of millions of users, their results, retries, pronunciation corrections, etc., and uses the learning from that to produce better results. I doubt the phone software is using magic.
Re: (Score:2)
The speech sent to the data center is obviously used to train both server-based and phone-based speech recognition, so neither system has an advantage there.
No, the phone software isn't using "magic", but it seems to be using newer and more efficient techniques than Apple is getting from Nuance (both based on what is known about Nuance software and what has been published about Google's recent efforts).
Re: (Score:2)
So it does use the server. I'd like to see the article though.
Re: (Score:2)
No, you don't understand. It uses a model that was trained weeks or months earlier somewhere and then is shipped as part of the software. The offline recognizer itself is completely offline and doesn't "use the server".
Re: (Score:2)
So it's based on old training and heuristic data. Got it.
Re: (Score:2)
Google can do that because they have developed two separate speech recognition engines themselves, one for phones and another for servers. Apple is simply licensing Nuance speech recognition, and they get whatever Nuance can give them.
Re: (Score:3)
Re: (Score:2)
doesn't it just detect that it is speech? having not that much to do with if it's processed into text on the phone or elsewhere.
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
Bittorrent could do use muultiple paths, even if the other end(s) weren't specially rigged for it.
The others would just see you as several bittorrent sites.
-- hendrik
Re:Good idea, but ... (Score:4, Informative)
Re: (Score:2)
Yes, of course Bittorrent is at a different layer, and it's not all that suited to streams of data, which TCP handles (or have I missed something?) But it's capable of handling multiple connections more or less as a side effect of it being a protocol between multiple hosts.
In the original ARPAnet, though, didn't packets wander through the net more or less on their own? I suspect that gave the effect of ganging several TCP streams together. But those were simpler days, with a smaller net that had smaller
Re: (Score:2, Insightful)
Mod parent up. Whoever wrote the summary does not understand how TCP works. You can't just switch client IP at random between packets. TCP connections are end-to-end. This is why this is an *extension* and is not really used anyway.
Heck, most semi-safe protocols (eg. game interactive content) have some sort of connection tracking that involves client's IP address to prevent interference and/or hijacking. Multipath wouldn't work there either.
Re: (Score:2)
Another downside is that sometimes I don't data to go through a LTE link if it is expensive. On iOS 7, this is controllable on an app basis, but having a switch to allow/disallow it would be nice.
Multipath TCP would be extremely useful though regardless.
What I wonder about would be adding some form of crypto between the endpoints. That way, unless the attacker could watch all connections at the same time, the traffic would be useless. Perhaps Diffie-Hellman key negotiations that use all multiple links to
Re: (Score:3)
Apparently it is theoretically possible to extend IPSEC to work with multipath. No idea if this has actually happened or not.
IPv6 (Score:2, Interesting)
Anybody know if IPv6 is any better in this regard?
-- hendrik
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).
Siri: Bad use case? (Score:3)
Re:Siri: Bad use case? (Score:5, Insightful)
But it is a great mass-market testcase.
Re:Siri: Bad use case? (Score:5, Interesting)
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.
Re: (Score:2, Redundant)
As for Siri - you have quite the edge case. It is an *extremely* small window between the transmission and then reception of the Siri transaction that you lose your Wifi.
Re: (Score:2)
Re: (Score:2)
Furthermore HLS has provisions to tell when bandwidth is too restricted - and
Re: (Score:2)
If you use a proxy or VPN, then Pandora won't cut out (actually it just restarts the connection and moves to the next song). I've tested this numerous times with Pandora on Android with VPNs and proxy servers. Pandora only seems to complain if you change IPs suddenly (makes sense since you're changing networks).
As for the Siri use case, that's more applicable as you send the request to Siri down one pipe and receive it down the other. It doesn't support sending the same packets down both pipes simultaneousl
The best thing I've heard about the new iPhone (Score:5, Interesting)
Re: (Score:2)
You're talking about Ad Hoc networking there. People have been working on it forever, but so far it's never made it into a production environment that I know of.
Re: (Score:2)
Re: (Score:2)
Is "wireless ad hoc networking" the same as what you're referring to, or at least a subset thereof?
http://en.wikipedia.org/wiki/Wireless_ad_hoc_network [wikipedia.org]
Re: (Score:2)
Yes, I can't think of too many applications for copper/fiber ad hoc networking.
Wait, isn't this... (Score:2)
what UDP is for?
An example of an application that uses UDP is Mosh
http://mosh.mit.edu/ [mit.edu]
You can have various disconnections and reconnections (Since it's written by someone at MIT, say you're going in to the T @Davis and coming out at Kendall/MIT) and the connection with mosh looks like you never disconnected.
--
BMO
Re: (Score:2)
And when you want a reliable connection?
Re: (Score:2)
And when you want a reliable connection?
There is no such thing.
--
BMO
Re: (Score:2)
No, not in the common use of the term. But in terms of what TCP provides,
http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Reliable_transmission [wikipedia.org]
If you need what TCP provides and you try and do it over UDP, you're just going to end up reinventing TCP.
Re: (Score:2)
False.
Reliability is the probability of failure and the frequency of failures.
Maybe you should understand system reliability instead of showing off your ignorance?
Re: (Score:2)
Many modern video games do this by writing their own "reliability" layer into their game; the game uses UDP for the multiplayer connectivity, but emulates some of the reliability of TCP.
There is a good explanation of this at http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/ [gafferongames.com]
Re: (Score:2)
It can definitely be appropriate in some circumstances. I have a few apps that use UDP myself (though I'm usually not concerned about reliability at all).
Re: (Score:2)
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.
Why not SCTP? (Score:2)
Wait, I know, because it's Apple!
Performance issues? (Score:2)
This feature may be causing performance issues. Since upgrading to iOS 7 wifi connectivity has been crap. When I turn off wifi and just use LTE it's great. I just tested wifi without the cellular data connection active...and it's great! Both turned on at the same time? Timeouts and heavy lag for anything that needs an internet connection.
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?
Re:closed source triumphs again (Score:4, Interesting)
How could Tim Cook forgot to present this feature ?
Re:closed source triumphs again (Score:5, Insightful)
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.
Re: (Score:2)
I'd imagine they'll gradually add it to services they control such as maps, iMessage, FaceTime and lastly iCloud.
With that final addition it would probably be an added feature of iOS 8.0 or 9.0 and extended to developers. Once they pick it up and the idea becomes more widely known hopefully it'll spur adoption in Apache and web browsers.
It's real annoying when I'm in the passenger seat looking for directions and we drive past a McDonalds or Starbucks and my page loading stalls as it jumps on the known netwo
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Couldn't you just quickly turn off WiFI with the new Control Center?
Re: (Score:2)
Re: (Score:2)
There are a bunch of apps in the Play Store that can turn wifi on and off automatically. Llama can do it too, among many other things, and it's free.
Re: (Score:3)
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?
Re: (Score:2)
Re: (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.
can anybody explain? (Score:2)
I think I get the mechanics of what goes on (switch from LTE to wifi without breaking the connection). Can anybody explain the significance, or how it would improve phone functionality and app functionality? I'm sure there's a killer application, but I don't see it.
Re: (Score:2)
Re: (Score:2)
true but what sort of mobile apps require a continuous connection? am I watching netflix on LTE while I drive then walking into the house with it? sounds wierd.
Re: (Score:2)
But we've already 'solved' this in practice (Score:2)
You certainly would use streaming audio in that situation... And you might check your phone when getting out of the car and send a message of some kind. Now that message fails to send because you interrupt the connection mid way through. Or it just does something else unexpected. An uninterrupted internet connection is pretty much always better than an interrupted one.
But the thing is, since mobile devices have so long been in that situation of often dropping/switching connections, almost any decently written application or function already does that, and will silently retry or reconnect. Sure, this is a more elegant solution in theory, but we already have solutions in practice.
Re: (Score:3)
Re: (Score:2)
>You certainly would use streaming audio in that situation...
Considering the size of a music file, you would most likely already have the entire song buffered, so that's pointless.
>And you might check your phone when getting out of the car and send a message of some kind.
Easy solution: system waits to switch from cellular to WiFi until after the message has been sent.
Re: (Score:3, Informative)
It is open source itself. troll.
http://multipath-tcp.org/pmwiki.php/Users/DoItYourself [multipath-tcp.org]
Re: (Score:3)
(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)
Re: (Score:2)
I know, MS do the same thing with v1 of ...
WTF cares what they do, and why drag them into this triumph/tragedy?
Re: (Score:2)
Re: (Score:3, Informative)
It does officially support HTTP1.1, but most servers detect Safari and use HTTP1.0 instead.
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: (Score:2)
Re: (Score:2)
multipath TCP doesn't really have anything to do with message routing. It's just an extension that allows multiple TCP connections to be bound together but presented to the application layer as a single socket. One use case would be where you're sitting at a coffee shop streaming over wifi and you walk away and lose the connection because you walk out of range of the wifi network and break your TCP connection. With multipath TCP you'd have established a connection over both wifi and mobile networks to suppo
Re: (Score:2)
But let's say I connect from A to B over the normal (wired) internet. The packet goes through router X or router Y. Then, when X fails, the message may be routed through Y or the other way around.
Same with multipath: when wifi fails, use mobile network, and vice versa.
No modification of TCP necessary!
Only the kernel (it has to set up "virtual" routers for wifi and mobile).
Re:Major extension to TCP? (Score:5, Interesting)
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.
Re: (Score:2)
So, you are saying that when you have a stable connection from A to B through X, and X goes dead, your connection drops even though there is another route through Y?
In that case, I'd say TCP contains some serious design error.
Re: (Score:2)
In this example, X and Y are each providing a different subnet address. Your device just moved to a different network and now has a different IP address. This is not a design error but an appropriate design. Multipath TCP is a standard that allows your device to have uninterrupted mobility.
Re: (Score:2)
Re: (Score:2)
Yeah, but if you're streaming something wouldn't it be better just to have like a big buffer? If your connection dies, you keep grabbing data out of the buffer, and in the meantime, the connection is re-established on a working network. You could easily store 5 minutes of audio in memory incase your connection drops.
Phone calls with a five minute lag can be fun, but are not what most people want.
Re: (Score:2)
But let's say I connect from A to B over the normal (wired) internet.
Slow down cowboy. What is "A" and "B"?
They are IP addresses.
The packet goes through router X or router Y.
Correct.
Same with multipath: when wifi fails, use mobile network, and vice versa.
No, In the A-B scenario above there are 2 routes from A to B. Or to be more precise there are 2 routes from "IP Address A" to "IP Address B".
With multipath, A has 2 different IP addresses: A0 and A1. A router knows the routes it has available to send a pac
Re: (Score:2)
Yes, but that not how IP networks work. When the server sends you a packet, it needs to pick exactly one IP address as the destination. Because your WiFi and Cell are on different networks, they give you different IP addresses. So the server has to pick either your WiFi or your cell IP address. Once that packet is sent, it's not going to ever get to you via the "other" network.
That's why the multipath needs special support. Among other things, lots of web sites which are on multiple load-balanced serv
Re: (Score:2)
But, as I was trying to say, the same can happen on a regular network.
When sending from A to B through X, and X dies, the path may have to go through Y, where Y is on a completely different part of the network.
So what makes this phone-case so special?