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

32 of 172 comments (clear)

  1. Re:closed source triumphs again by CanHasDIY · · Score: 5, Informative

    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
  2. Re:closed source triumphs again by slash.jit · · Score: 4, Interesting

    How could Tim Cook forgot to present this feature ?

  3. You're Not Making Sense by Anonymous Coward · · 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.

    1. Re:You're Not Making Sense by Anonymous Coward · · 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.

    2. Re:You're Not Making Sense by Anonymous Coward · · 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.

    3. Re:You're Not Making Sense by Anonymous Coward · · 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 requests?

    4. Re: You're Not Making Sense by Richy_T · · Score: 2

      Because packets coming from another interface look like they're coming from a different device and will have a different 4-tuple.

    5. Re: You're Not Making Sense by Anonymous Coward · · 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.

  4. An odd way to speed up Siri by s.o.terica · · Score: 5, Insightful

    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.

    1. Re:An odd way to speed up Siri by larwe · · Score: 2

      The semantic engine is part of all modern speech recognition libraries (grammar hints are used, and the application provides the grammar based on what commands it expects to receive). And by "all modern speech recognition libraries" I basically mean Nuance, since they own the field and buy anyone who does anything interesting in it.

    2. Re:An odd way to speed up Siri by immaterial · · Score: 2

      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.

  5. Good idea, but ... by Anonymous Coward · · 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.

    1. Re:Good idea, but ... by Anonymous Coward · · 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.

    2. Re:Good idea, but ... by drinkypoo · · Score: 2

      Apparently it is theoretically possible to extend IPSEC to work with multipath. No idea if this has actually happened or not.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    3. Re:Good idea, but ... by pak9rabid · · Score: 3, Informative

      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 for more info.

  6. Re:Maybe ... by Camembert · · Score: 2

    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.

  7. Re:closed source triumphs again by nine-times · · 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.

  8. Re:closed source triumphs again by liamevo · · Score: 3, Informative
  9. Re:Maybe ... by Bengie · · Score: 2, Informative

    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.

  10. Siri: Bad use case? by bradgoodman · · Score: 2

    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?

    1. Re:Siri: Bad use case? by Tim12s · · Score: 5, Insightful

      But it is a great mass-market testcase.

    2. Re:Siri: Bad use case? by Rude+Turnip · · 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.

  11. Re:IPv6 by shreak · · 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).

  12. The best thing I've heard about the new iPhone by timeOday · · Score: 4, Interesting

    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.

  13. Re:Major extension to TCP? by shreak · · 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.

  14. no it doesn't by stenvar · · Score: 3, Informative
  15. Re:closed source triumphs again by Anonymous Coward · · 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.

  16. Re:closed source triumphs again by ozbon · · Score: 2

    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...
  17. Re:Maybe ... by bill_mcgonigle · · 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, 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)
  18. Re:closed source triumphs again by timmyf2371 · · Score: 2

    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
  19. Re:But we've already 'solved' this in practice by Kielistic · · Score: 2

    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.

  20. Re:Wait, isn't this... by olivier.bonaventure · · 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.