Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
IOS Networking The Internet

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."
This discussion has been archived. No new comments can be posted.

A Little-Heralded New iOS 7 Feature: Multipath TCP

Comments Filter:
  • by Anonymous Coward on Thursday September 19, 2013 @09:17AM (#44893319)

    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)

      by Anonymous Coward

      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)

        by Anonymous Coward

        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.

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

        • That's called a proxy, and no - keep your hands out of my bits.

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

        by Anonymous Coward

        (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

        • by rsborg ( 111459 )

          (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]

    • 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]

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

      • by Belial6 ( 794905 )
        Agreed. IOS alone could be enough to get servers to start supporting it. If we could also get it onto Android, it would be a done deal. While it would be a nice feature for Laptops, phones seem to be the kill application for this.
      • by pspahn ( 1175617 )

        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

  • by s.o.terica ( 155591 ) on Thursday September 19, 2013 @09:21AM (#44893337)
    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.
    • IIRC they've implemented this in Dictation on MacOS, so it might not be too far away.

    • 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

      • Or you could, I don't know, add Target to your contacts? You can refer to any location in your contacts, not just your own home or work. It *would* be nice if it could seach for nearby addresses, such that if you don't have a contact for your local Target, it'll find the address anyway.
    • 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)

        by stenvar ( 2789879 ) on Thursday September 19, 2013 @11:03AM (#44894253)
        • by Quila ( 201335 )

          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.

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

            • by Quila ( 201335 )

              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.

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

                • by Quila ( 201335 )

                  The speech sent to the data center is obviously used to train both server-based and phone-based speech recognition

                  So it does use the server. I'd like to see the article though.

                  • 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".

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

  • Good idea, but ... (Score:3, Informative)

    by Anonymous Coward on Thursday September 19, 2013 @09:24AM (#44893353)

    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.

    • 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

      • by pak9rabid ( 1011935 ) on Thursday September 19, 2013 @10:03AM (#44893735)
        Bittorrent does this at the application layer, meaning it's only applicable to that specific application. Multipath TCP accomplishes this at the transport layer, meaning existing applications don't specifically have to be coded to support this, they would just need minor changes (if any) to make use of it. See the OSI model [wikipedia.org] for more info.
        • 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)

      by Anonymous Coward

      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.

    • by mlts ( 1038732 ) *

      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

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

      by shreak ( 248275 ) on Thursday September 19, 2013 @09:56AM (#44893667)

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

  • by bradgoodman ( 964302 ) on Thursday September 19, 2013 @09:51AM (#44893611) Homepage
    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?
    • by Tim12s ( 209786 ) on Thursday September 19, 2013 @10:02AM (#44893719)

      But it is a great mass-market testcase.

    • by Rude Turnip ( 49495 ) <valuationNO@SPAMgmail.com> on Thursday September 19, 2013 @10:13AM (#44893847)

      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)

        by bradgoodman ( 964302 )
        Pandora I can totally see. It's the antithesis of Siri. Very long, persistent, lots of data - a continuous stream. (Though other technologies, such as fragmentation at the application/asset level are often used here too - especially for video).

        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.

        • However, I've noticed I tend to use Siri on my way out of the house - getting directions somewhere, or setting up a reminder for the day, whatever. As such, the request tends to fall during the transition from my home wifi to the cellular network. I wouldn't be surprised if this is a common thing, since this would be a very common use case.
      • 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

  • by timeOday ( 582209 ) on Thursday September 19, 2013 @09:59AM (#44893691)
    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.
    • by Shatrat ( 855151 )

      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.

      • Yeah, I don't know if ad hoc will ever work. MAYBE with the pull of somebody huge, like Apple enabling it by default. Maybe the super-dense infrastructure will take some other form, like a repeater you just plug into any outlet, that relays a WiFi (or bluetooth?) signal through GSM? Anyways, low power devices are inherently going to have to migrate from one transponder to another very often, and between providers quite often, and you don't want to drop your IP connections every time.
      • 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]

  • 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

  • If a new protocol is needed at both ends of the connection why not use a less experimental and more capable one like SCTP? It is heavily used in telephony networks for SIGTRAN and is also supported by some servers for SIP and HTTP.
    Wait, I know, because it's Apple!
  • 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.

"The vast majority of successful major crimes against property are perpetrated by individuals abusing positions of trust." -- Lawrence Dalzell

Working...