Slashdot Mirror

← Back to Stories (view on slashdot.org)

A Little-Heralded New iOS 7 Feature: Multipath TCP

Posted by timothy on from the this-way-and-that dept.

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

172 comments

  1. Maybe ... by Anonymous Coward · · Score: 0

    Maybe they can use this to speed up the lethargic Safari iOS 7 delivered. I had better performance in Safari from my iPhone 3G than I do with this slug on my 5.

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

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

    3. Re:Maybe ... by Anonymous Coward · · Score: 0

      Keep in mind it also requires a 3 way handshake over low, lower and no latency connections too. Not just the high latency ones.

    4. 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)
    5. Re:Maybe ... by cyberchondriac · · Score: 1

      Try Dolphin. I've been pretty happy with that.

      --

      Look back up at my post, now look back down, you're on the Internet. Now look back up. I'm a signature.
  2. 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
  3. Re:closed source triumphs again by slash.jit · · Score: 4, Interesting

    How could Tim Cook forgot to present this feature ?

  4. 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 ggraham412 · · Score: 1

      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]

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

    4. Re:You're Not Making Sense by MightyYar · · Score: 1

      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.

      --
      W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
    5. 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?

    6. Re: You're Not Making Sense by Anonymous Coward · · Score: 1

      Why would both ends of the connection have to be multi tcp compatable? It sounds to me that only the device connecting to multiple tcp connections would need to supports that. So what this would mean, I would think, is that the lock up of Siri when I leave work and it still has a connection to the wifi at work, but is too faint to reach the internet, it would switch to 3G or LTE faster and not give the spinning circle for a extended period to the point that I home button out of it and re-Siri whatever I was looking for

    7. Re:You're Not Making Sense by Anonymous Coward · · Score: 0
      This is at the TCP level, not the application level. The TCP packets are sent on multiple IP addresses and the server's tcp stack has to merge them back together.

      As it is, your phone can change ip addresses (wifi/cellular) so that's nothing new.

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

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

    10. Re:You're Not Making Sense by gbjbaanb · · Score: 1

      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.

    11. Re:You're Not Making Sense by rsborg · · Score: 1

      (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

      --
      Make sure everyone's vote counts: Verified Voting
    12. Re:You're Not Making Sense by Belial6 · · Score: 1

      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.

    13. Re:You're Not Making Sense by Anonymous Coward · · Score: 0

      This seems like a good idea for improving reliability with automatic failover. Would it be possible to set up a multipath capable SOCKS proxy server on a reliable, wired internet connection that your phone would connect to that would proxy to the real destination using regular TCP?

    14. Re:You're Not Making Sense by pspahn · · Score: 1

      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 like a useful addition to the mobile device standards tree. Will we see Apple encourage the world at large to adopt it on their servers openly? Or will we see Apple force anyone who wants to use it into narrow licensing options, meaning only a few big players with niche uses will adpot it?

      In the end, I would put my money on the latter, as that's what Apple tends to do. It will be some other company that releases a more desirable competitor that will find greater market adoption.

      --
      Someone flopped a steamer in the gene pool.
    15. Re:You're Not Making Sense by gbjbaanb · · Score: 1

      the difference this time is that they can't slap a hugely expensive, proprietary port on it.

    16. Re:You're Not Making Sense by X0563511 · · Score: 1

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

      --
      For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
    17. Re:You're Not Making Sense by MightyYar · · Score: 1

      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.

      --
      W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
  5. 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 Sockatume · · Score: 1

      IIRC they've implemented this in Dictation on MacOS, so it might not be too far away.

      --
      No kidding!!! What do you say at this point?
    2. Re:An odd way to speed up Siri by Anonymous Coward · · Score: 0

      My guess is... Patents.

    3. Re:An odd way to speed up Siri by danomatika · · Score: 1

      Because Google Now utilizes an enhanced Qualcomm ARM chip with a "contexual computing processor" so the voice recognition is done largely in hardware on the phone (http://www.itproportal.com/2013/07/25/motorolas-new-x8-arm-chip-underpinning-the-always-on-future-of-android) :

      > The CCP is billed as adept at processing sensor data from the device and using it in the always-on display features of the new Motorola handsets. L-NLP monitors > the microphone input, noise cancellation, and runs speech recognition to make the phone a hands-free device.

      The new iPhone's don't have that, so they have to keep with the "record audio, send to server" method.

    4. Re:An odd way to speed up Siri by Anonymous Coward · · Score: 1

      I don't know why Apple chose to do it this way, but one one possible reason is for (potentially) better quality speech recognition... It's unnatural and error prone to comprehend speech as a sequential two step "word recognition then semantic analysis" process; the better way to do it the human way where word recognition is intimately integrated with semantic analysis such that disambiguation of unclear words can take advantage of semantic context. Since Siri is implemented remotely, it therefore makes sense for the word recognition part to also be remote.

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

    6. Re:An odd way to speed up Siri by gl4ss · · Score: 1

      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.

      --
      world was created 5 seconds before this post as it is.
    7. Re:An odd way to speed up Siri by Grizzley9 · · Score: 1

      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 Android phones and it will need to understand context more. For instance, you can program in only your "home" and "work" for locations. Anything else though is not understood unless you substitute something in for one of those. "Remind me when I get to Target to get eggs" Siri:"I don't know who Target is" or it is a simple reminder that has nothing to do with location based services. I would have to change my "work" to the stores/destinations address and use the term 'work' when talking about it.

    8. Re:An odd way to speed up Siri by jon3k · · Score: 1

      It was faster before the new coprocessor.

    9. Re:An odd way to speed up Siri by jon3k · · Score: 1

      I should clarify: It was faster than Siri, even BEFORE the new coprocessor.

    10. Re: An odd way to speed up Siri by Anonymous Coward · · Score: 0

      Only on the Moto X. There isn't any kind of specialized hardware in any other phone that support Google Now, and yet it's faster than Siri.

      P.s. the coprocessor in the Moto X is here to enable it to recognize speech all the time, and to save battery in the meanwhile. Not to speed-up recognizing.

    11. Re:An odd way to speed up Siri by Anonymous Coward · · Score: 0

      Because Google Now utilizes an enhanced Qualcomm ARM chip with a "contexual computing processor" so the voice recognition is done largely in hardware on the phone (http://www.itproportal.com/2013/07/25/motorolas-new-x8-arm-chip-underpinning-the-always-on-future-of-android) :

      No. It works quite fast on my Galaxy Nexus and Nexus 7 FHD. Neither have this contexual computing processor. That only exists in the Moto X, Droid Mini, Droid Ultra, and Droid Maxx.

      Software can leverage hardware when present, but the hardware doesn't drive the entire software experience.

    12. Re:An odd way to speed up Siri by Anonymous Coward · · Score: 0

      It helps but isn't required.

      The Google iOS app performs the recognition client-side not server-side. The chip is good enough, they just don't use it.

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

    14. Re:An odd way to speed up Siri by stenvar · · Score: 1

      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.

    15. Re:An odd way to speed up Siri by Anonymous Coward · · Score: 0

      I really don't notice any network lag in iOS7, on my 4S. I definitely did in iOS6, but it's much better now.

    16. Re:An odd way to speed up Siri by Anonymous Coward · · Score: 0

      Same here. The Siri response in iOS 7 is VASTLY improved. Accuracy seems far better as well. My initial tests this morning show improvement across the board for dictation with no lag in response.

    17. Re:An odd way to speed up Siri by Anonymous Coward · · Score: 0

      Holy crap, guys, you mean the voice recognition on my $120 Kyocera Edge (Android) is better than your $600 status symbol?

    18. Re:An odd way to speed up Siri by Grizzley9 · · Score: 1

      This finally works. It did not work like this in the beginning no matter what I had in for the locations contacts address. Good to know.

  6. 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 hendrikboom · · Score: 1

      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

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

    3. Re:Good idea, but ... by mlts · · Score: 1

      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 set up a key. Of course, some connections can be marked more secure than others (say one has fast WAN bandwidth, but an extremely slow LAN link), so the machines can sync keys along the slow, secure link while doing the most of their communication encrypted via the fast, insecure one.

    4. 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.'"
    5. 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:Good idea, but ... by Anonymous Coward · · Score: 0

      A properly done multipath protocol (I didn't look at the actual one, so I don't know if it does) would announce all possible IPs on the initial handshake. Then the other side could distinguish between a packet from the same multipath, and a packet from an unrelated address.

    7. Re:Good idea, but ... by Megane · · Score: 1

      I'm doing good just to have my DHCP at home assign the same fixed IP to both the wired and wireless interfaces of my laptops. That way I get a limited sort of multipath, where the laptop will default to using the wired if it's connected, and the TCP stacks will see the same IP coming from a different MAC address on the same LAN. Once I've done the big file transfer that I dug out the wired cable for, if it falls out, neither I nor the computers involved care.

      --
      #naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
    8. Re:Good idea, but ... by Anonymous Coward · · Score: 0

      How could a phone, that's hopping Wifi & cellular stations, *know* all possible IPs it's going to have?

    9. Re:Good idea, but ... by x0ra · · Score: 1

      Please, don't try to extend IPSEC. Just burn the damn thing for good...

    10. Re:Good idea, but ... by Anonymous Coward · · Score: 1

      There's no barrier to people having it running, though. An MPTCP implementation figures out during the three-way handshake whether the other side also knows about MPTCP, and if it doesn't, MPTCP seamlessly falls back to TCP.

    11. Re:Good idea, but ... by hendrikboom · · Score: 1

      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 routing problems.

      -- hendrik

    12. Re:Good idea, but ... by Anonymous Coward · · Score: 0

      Are these the same sort of "minor changes" that are needed to move from IPv4 to IPv6? Because I don't see them happening very quickly.

  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. IPv6 by hendrikboom · · Score: 1, Interesting

    Anybody know if IPv6 is any better in this regard?

    -- hendrik

    1. Re:IPv6 by Anonymous Coward · · Score: 0

      Not inherently.

    2. Re:IPv6 by Anonymous Coward · · Score: 0

      There was an attempt to do something like this in ipv6, called Shim6. Shim6 proposed that end sites not be given thier own ip space if they multihomed...instead shim6 proposed that end sites would get an IP block from each of their IPSs, and assign and IPs from each of those ISPs blocks to all their end hosts. The end hosts would then have multiple IPs, and would negotiate with any server they reached out to in order to figure out which IP to use for the connection

      Shim6 has been deprecated, though. It is not something that anyone is going to implement.

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

    4. Re:IPv6 by Anonymous Coward · · Score: 0

      I think it is silly to implement routing functions in the Transport Layer. If the link is down, IPv* ought to route around it transparently. The fact that it doesn't happen in reality is an implementation bug in the network layer.

    5. Re:IPv6 by Anonymous Coward · · Score: 0

      Except that the bug is really in the transport layer. Theoretically, the network layer packet can go out any interface, but the server will always send replies to the same one. The problem is that a socket contains the IP address (also TCP checksums take the IP header into consideration, another annoyance). Thus with a socket, there's one IP address for each end of the socket and that's it. There's no reason that this has to be the case if you design your own transport layer, but that's how TCP specified it. MPTCP is an attempt to re-abstract this broken abstraction by adding options to the transport. The network layer is just fine as-is.

    6. Re:IPv6 by Anonymous Coward · · Score: 0

      Author of this again. One thing that I failed to mention is that rather than doing this at the transport layer, it COULD be done at the network layer, and that mechanism exists: multicast groups. However, nobody uses them and so much infrastructure is based on assumptions that TCP makes that the easiest thing to do is to create a virtual TCP socket over multiple TCP sockets.

  9. Re:closed source triumphs again by liamevo · · Score: 3, Informative

    It is open source itself. troll.

    http://multipath-tcp.org/pmwiki.php/Users/DoItYourself

  10. Major extension to TCP? by Anonymous Coward · · Score: 0

    Major extension to TCP, when you can already route a message through multiple paths over the internet?
    Sounds more like a major extension to the kernel to me.

    1. Re:Major extension to TCP? by shreak · · Score: 1

      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 support that connection. When the wifi drops out the everything will just go over the mobile network and your TCP connection is never lost.

    2. Re:Major extension to TCP? by StripedCow · · Score: 1

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

      --
      If Pandora's box is destined to be opened, *I* want to be the one to open it.
    3. 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.

    4. Re:Major extension to TCP? by vux984 · · Score: 1

      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 packet down, but it has no idea that A0 and A1 are different interfaces on the same device, and that it can send packets addressed to A0 to A1.

      Indeed, packets arriving on the A1 interface addressed to A0 would be ignored unless the interface was in promiscuous mode.

      Only the kernel (it has to set up "virtual" routers for wifi and mobile).

      That doesn't solve the problem that the two interfaces have different IP addresses, in completely disparate networks.

    5. Re:Major extension to TCP? by StripedCow · · Score: 1

      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.

      --
      If Pandora's box is destined to be opened, *I* want to be the one to open it.
    6. Re:Major extension to TCP? by CastrTroy · · Score: 1

      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. With phones now having gigabytes of memory, having 10 megs dedicated to an audio buffer isn't a lot to ask. Even if you're streaming video, you could easily store up enough of the video for the amount of time that you would lose a connection for.

      --

      Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    7. Re:Major extension to TCP? by Anonymous Coward · · Score: 0

      mmmm arrogance. so delicious.

      out of curiosity, have you implemented anything even approaching the complexity of TCP? i hope not, because undeserved arrogance is the tastiest of all. lucky for me it's so common on the internet!

    8. Re:Major extension to TCP? by statusbar · · Score: 1

      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.

      --
      ipv6 is my vpn
    9. Re:Major extension to TCP? by rsclient · · Score: 1

      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 servers need to affinitize your session to a single server. Those load balancers are currently (AFAICT) knowledgeable about Multipath.

      My prediction: apps will have to opt-in to get this feature, but beyond setting a flag when they set up the connection, nothing more is needed.

      --
      Want a sig like mine? Join ACM's SigSig today!
    10. Re:Major extension to TCP? by StripedCow · · Score: 1

      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?

      --
      If Pandora's box is destined to be opened, *I* want to be the one to open it.
    11. Re:Major extension to TCP? by Anonymous Coward · · Score: 0

      Well it's also stupid design from way back. In theory (especially with IPv6 address space), the device could have the same IP address on both interfaces, and there would just need to be two separate routes. In reality, NAT breaks this, and nothing consumer-level would support this situation since the device itself would need to participate in a routing protocol such as RGP.

      MPTCP is a great design given the history and inertia of past choices.

    12. Re:Major extension to TCP? by the_other_chewey · · Score: 1

      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.

    13. Re:Major extension to TCP? by Anonymous Coward · · Score: 0

      It's not a design error in TCP but in the IP implementation. The edge device can't do dynamic routing around a lost link. Clearly a networking layer bug.

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

      --
      Bill Clinton: Pimp we can believe in. - The Shirt!!!
    3. Re:Siri: Bad use case? by bradgoodman · · Score: 1, Redundant
      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.

    4. Re:Siri: Bad use case? by Anonymous Coward · · Score: 1

      I think you basically nailed it. I bet that Siri is the beta test for multipath TCP before iTunes Radio starts to use it.

    5. Re:Siri: Bad use case? by Anonymous Coward · · Score: 0

      That would be all great except this groundwork is not laid for that.

      This is working up to a NSA mandated feature*. If you can segregate important data from bulk stupid data then the NSA doesn't need to process as much and can maybe finally run some queries on the data they already have and actually catch some terrorist.

      It is all for your benefit, citizen, so they can listen in on the bad guys better while still listening to you. Think of the children.

      *Mwahahaha

    6. Re:Siri: Bad use case? by immaterial · · Score: 1

      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.

    7. Re:Siri: Bad use case? by peter.kingsbury · · Score: 0

      >> 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. You and the couch are going to become BFFs?

    8. Re:Siri: Bad use case? by bradgoodman · · Score: 1
      Apple invented HTTP Live Streaming (HLS) which breaks up assets (media) into individual "fragments" which can be downloaded via individual TCP requests - in a way in which they are easily and transparently spliced back together on the player. Thus, when an individual fragment download failed it is retried. i.e. If it failed because Wifi had gone away - the retry would (automagically) go over 3G via even the current network stack.

      Furthermore HLS has provisions to tell when bandwidth is too restricted - and to allow pulling in subsequent fragments at a lower bitrate until more bandwidth becomes better (i.e. gong from crappy 3G connection to a good Wifi connection).

      Thus - HLS would be a much more ideal way of handling something like iTunes radio. "Internet Radio" is even described as an ideal use case in Apple's own docs.

    9. Re:Siri: Bad use case? by Anonymous Coward · · Score: 0

      Why use MP-TCP on Siri? Because you're hot to get MP-TCP up and running on *something* but you don't want to risk it on Push.

    10. Re:Siri: Bad use case? by yeshuawatso · · Score: 1

      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 simultaneously though since it still has to wait for the acknowledgement (or lack thereof) .

      Often times, when I drive around the city, my phone will pick up a known wifi hotspot, negotiate an IP, then timeout when I drive too far away and my apps go ape shit crazy because the connection changed. My alternatives are to route all the traffic through a VPN (not the best since I only have 2.5G where I live and negotiation of the certificates takes forever), route the traffic for each hotspot through a proxy (an annoyance of Android for not having a system wide proxy), or turn off the wifi until I reach my destination. I tend to just turn it off since that's a one-click solution.

  12. Keynote for Dummies by mynameiskhan · · Score: 1

    For dummies, Cook presents, silence is the rest.

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

    1. Re:The best thing I've heard about the new iPhone by Shatrat · · Score: 1

      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.

      --
      09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
    2. Re:The best thing I've heard about the new iPhone by timeOday · · Score: 1

      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.

    3. Re:The best thing I've heard about the new iPhone by mattack2 · · Score: 1

      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

    4. Re:The best thing I've heard about the new iPhone by Shatrat · · Score: 1

      Yes, I can't think of too many applications for copper/fiber ad hoc networking.

      --
      09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
    5. Re:The best thing I've heard about the new iPhone by mattack2 · · Score: 1

      Thanks, then I'm confused by your comment of "but so far it's never made it into a production environment that I know of".

      Because I have used ad hoc wifi networks between computers, and until I found a better way (through iTunes), using it to copy stuff to VLC on my iPad (since through my main wifi network was less reliable, since the devices were next to each other).

    6. Re:The best thing I've heard about the new iPhone by Shatrat · · Score: 1

      I don't think that really counts as true ad hoc networking. There's no layer 3 routing accounted for there, so the gateway and subnet are pretty much fixed, and you've got your 'client' devices acting as wi-fi repeaters. If ad hoc networking is the flying car of the network world, this would be a hovercraft.

      --
      09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
    7. Re:The best thing I've heard about the new iPhone by mattack2 · · Score: 1

      Then either I worded my question poorly, or you shouldn't've answered "yes" to my previous question whether that was actually ad hoc networking or not.

  14. Re:closed source triumphs again by Stratus311 · · Score: 1

    meanwhile everyone with an iPhone is now enjoying the benefits of multipath tcp.

    ...in Siri.

    Obvious troll is obvious.

  15. Android does it all on the server. by YesIAmAScript · · Score: 1

    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.

    --
    http://lkml.org/lkml/2005/8/20/95
  16. Re:closed source triumphs again by Anonymous Coward · · Score: 1

    Um, they're still benefiting. Even if it's only in Siri.

    And Apple gets a widespread beta test that no one knows about, but most people will participate in.

  17. AT&T by Anonymous Coward · · Score: 0

    Theoretical at best. AT&T can't move from one tower to another without dropping a call, and that technology has been around forever.

  18. Another hacker's dream by Anonymous Coward · · Score: 0

    I hope that this is implemented better than 99% of the software out there. This sounds like an excellent way of impersonating another device's connection. lol

  19. IOS devices not very network friendly? by Anonymous Coward · · Score: 0

    I have run into issues with IOS devices appeared to be very "selfish" when trying to communicate. In one instance, the Netgear router at a vacation home was having problems and I traced it back to my iPad2 doing bunches of DHCP requests and exhausting the range. Another example is when we had issues with iPhones establishing, but not properly closing sessions when updating the mail client.

  20. Wait, isn't this... by bmo · · Score: 1

    what UDP is for?

    An example of an application that uses UDP is Mosh

    http://mosh.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

    1. Re:Wait, isn't this... by Richy_T · · Score: 1

      And when you want a reliable connection?

    2. Re:Wait, isn't this... by bmo · · Score: 1

      And when you want a reliable connection?

      There is no such thing.

      --
      BMO

    3. Re:Wait, isn't this... by Richy_T · · Score: 1

      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

      If you need what TCP provides and you try and do it over UDP, you're just going to end up reinventing TCP.

    4. Re:Wait, isn't this... by geekoid · · Score: 1

      False.
      Reliability is the probability of failure and the frequency of failures.

      Maybe you should understand system reliability instead of showing off your ignorance?

      --
      The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
    5. Re:Wait, isn't this... by Gibgezr · · Score: 1

      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/

    6. Re:Wait, isn't this... by Richy_T · · Score: 1

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

    7. Re:Wait, isn't this... by Anonymous Coward · · Score: 1

      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

      If you need what TCP provides and you try and do it over UDP, you're just going to end up reinventing TCP.

      Well, yeah, but if you look at UDP-based TCP replacements (like mosh, or utorrent's uTP), you'll notice that, while they do essentially reinvent TCP, the application gets to stick its fingers down in the resulting TCPoid and do interesting things with the results, things it couldn't do if it used the system's TCP implementation.

      The "right way" of course, is to implement a new protocol at the transport layer that exposes the requisite information to the application (or in the case of uTP, just a new rate-control algorithm that plugs into TCP), not to build your own transport layer in the application layer. (Or, alternatively, the right way could be to go microkernel and have everything in userspace, including TCP, and implement your transport layer in userspace -- but that's still not doing it in the application as mosh, uTP, et al. do.) But in a world where practically no users ever compile their own kernels, much less apply some patch just so they can try out a new beta application, what are you supposed to do: Beg a dozen distributions to roll your still-kinda-experimental protocol into their kernel patchset? Try to get it included in mainline before it's out of beta, and when there's no user-base wanting it? Or just implement it over UDP in your python (or whatever) application?

      Sure, the end result is a silly mess, but I can see why they decide to do it that way.

    8. Re:Wait, isn't this... by olivier.bonaventure · · Score: 1

      MOSH only works with ssh, while Multipath TCP works with any unmodified application that runs on top of TCP. ssh is one of them of course.

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

  21. no it doesn't by stenvar · · Score: 3, Informative

    Android got offline speech recognition a while ago:

    http://www.androidcentral.com/google-search-update-allows-third-party-developers-use-offline-speech-recognition

    1. Re:no it doesn't by Quila · · Score: 1

      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.

    2. Re:no it doesn't by stenvar · · Score: 1

      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.

    3. Re:no it doesn't by Quila · · Score: 1

      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.

    4. Re:no it doesn't by stenvar · · Score: 1

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

    5. Re:no it doesn't by Quila · · Score: 1

      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.

    6. Re:no it doesn't by stenvar · · Score: 1

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

    7. Re:no it doesn't by Quila · · Score: 1

      So it's based on old training and heuristic data. Got it.

    8. Re:no it doesn't by stenvar · · Score: 1

      Yes, just like the server based system; it doesn't have any advantage in that respect.

    9. Re:no it doesn't by Quila · · Score: 1

      A server based system learns and updates constantly.

      But I could see moving some of the simpler, well-known recognition onto the phone to avoid lag. If the phone can't process the request with near 100% confidence it forwards it to the server.

    10. Re:no it doesn't by stenvar · · Score: 1

      A server based system learns and updates constantly.

      Nonsense. Server-based systems are usually batch-trained, just like phone based systems. The primary difference is in the amount of memory and CPU power they have available for recognition.

      But I could see moving some of the simpler, well-known recognition onto the phone to avoid lag.

      Well, you can imagine lots of things. But the fact is that Google has built two recognizers, one running on the phone and one running on the server. They use different technologies, and the phone based one is newer and apparently works quite a bit better than if you simply took the server based one and made it resource constrained.

    11. Re:no it doesn't by Quila · · Score: 1

      There's a difference between a server farm learning and distributing the latest among the local servers, and periodiocally sending updates to phones.

      Again, the paper would be nice.

  22. Re:closed source triumphs again by Anonymous Coward · · Score: 0

    Shut up Ballmer!

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

  24. 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...
  25. Protection against snooping? by Anonymous Coward · · Score: 1

    In cases where the NSA/five eyes hasn't compromised one of the two endpoints (or a spot close to an endpoint in the sense of multipath diversity), how much more difficult would multipathing make it to reconstruct the stream flowing through the connection?

  26. Can I lock the screen orientation yet? by Anonymous Coward · · Score: 0

    The only thing I care about, WRT iOS, is whether I can lock the screen orientation. If I'm lying down while using my iPhone, I want to be in a position that I'm comfortable in, and not have to prop myself in one that will keep the screen oriented correctly.

    1. Re:Can I lock the screen orientation yet? by Anonymous Coward · · Score: 0

      Good news! It's been in there for literally years. No longer must your ignorance prevent you from obtaining the iPhone of your dreams!

    2. Re:Can I lock the screen orientation yet? by Anonymous Coward · · Score: 0

      Care to share how it's done? I've done a fair amount of searching with Google, but I can't find anything about locking the screen orientation so it doesn't flip when I lie down.

    3. Re:Can I lock the screen orientation yet? by Anonymous Coward · · Score: 0

      Nevermind. I found it. I don't know why I couldn't find it all those other times I looked.

  27. It's a good step, let's get that to VoIP. by intermodal · · Score: 1

    Smooth transitioning from 802.11abgn to mobile networks would sure be nice. Granted, it's not all VoIP, but that would be awesome.

    --
    In SOVIET RUSSIA... erm...NSA AMERICA, the Internet logs onto YOU!
  28. Re:closed source triumphs again by CODiNE · · Score: 1

    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 network. Or when leaving the house and it goes from wifi to cellular.

    --
    Cwm, fjord-bank glyphs vext quiz
  29. More useful by Anonymous Coward · · Score: 0

    I hope they also enable an apps to run in the background for more than 10 minutes (i.e. for an ssh tunnel over wifi)

  30. for(;;); by Anonymous Coward · · Score: 1

    Funny how old technology becomes new all over again. Multitasking, improved UI, and tcp protocol improvements? Sounds like it came straight out of the DOS era. :)

  31. can't stand when terms like this get dumbed down by Anonymous Coward · · Score: 0

    "use case"? sure it's not a literally disruptive monetizing use case for early adopters with a steep learning curve?

  32. Why not SCTP? by TuringCheck · · Score: 1

    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!

    1. Re:Why not SCTP? by olivier.bonaventure · · Score: 1

      SCTP is cleaner than Multipath TCP, but unfortunately there are on today's Internet many devices such as NATs that do not understand SCTP and simply block SCTP packets.

  33. Performance issues? by greg_barton · · Score: 1

    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.

  34. Re:closed source triumphs again by tqk · · Score: 1

    I know, MS do the same thing with v1 of ...

    WTF cares what they do, and why drag them into this triumph/tragedy?

    --
    "Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.
  35. Re:closed source triumphs again by nine-times · · Score: 1

    Where it also helps is when you are connnect to both cellular and wifi, but one of them isn't actually responding. The multipath TCP will notice that traffic isn't flowing and try directing traffic over the other one. I believe (though I may be misremembering) it's also possible to use this technology to bond different network connections, so if you have 10Mbps over WiFi and 10Mbps over LTE, you could turn them into something comparable to a 20Mbps connection.

  36. 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
  37. can anybody explain? by noh8rz10 · · Score: 1

    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.

    1. Re:can anybody explain? by Kielistic · · Score: 1

      When you walk into your house from outside you don't get weird interruptions in service, missed / lost messages or any of the other things that happen when communication is interrupted.

    2. Re:can anybody explain? by noh8rz10 · · Score: 1

      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.

    3. Re:can anybody explain? by Kielistic · · Score: 1

      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.

    4. Re:can anybody explain? by dan325 · · Score: 1

      I've gotten into a routine of asking Siri several questions when I leave my house in the morning. Inevitably, I have several questions go unanswered as I pull away and my phone switches from wifi to cellular. I didn't try this morning, but will definitely give this a shot tomorrow.

    5. Re: can anybody explain? by Anonymous Coward · · Score: 0

      One acronym: SIP. If your server supports this than you can do media hopping without losing the call. I hate Apple and I like this. I hope asterisk implements the opposite end of this.
      I would hope this is implemented based on ACKs so if we don't get an ack within a certain few miliseconds we know it's time to try a new path. My plan assumes that we don't have a moment when we've lost connection 1 but have not yet established a connection 2. That would result in a drop.

    6. Re:can anybody explain? by bluemonq · · Score: 1

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

  38. Re:closed source triumphs again by nine-times · · Score: 1

    Yeah, except (a) their isn't an indication from what I'm reading that Apple is opening up this tech for use by developers yet; (b) the keynote for the WWDC is still aimed at the non-technical; and (c) I'm pretty sure there was some mention of it when iOS was announced, because I knew that Apple was starting to use multipath TCP at the time (though I don't remember where I learned it).

  39. xRe:Major extension to TCP? by Anonymous Coward · · Score: 0

    Only the kernel (it has to set up "virtual" routers for wifi and mobile).

    That doesn't solve the problem that the two interfaces have different IP addresses, in completely disparate networks.

    No, no, I don't think StripedCow really comprehends the solution he's recommending, but it theoretically works.

    Step 1: obtain a routable IP network (i.e. not 127.x.x.x, 169.254.x.x, 10.x.x.x, 172.16-31.x.x, or 192.168.x.x); if you go through ARIN, the smallest they will issue you is a /24, but since that's way more than you need, perhaps you can beg a subnet assignment from an employer, LUG, or who knows where, or pay for it from your ISP.
    Step 2: obtain an AS number.
    Step 3: run a "'virtual' router" speaking real BGP on your phone.

    Your phone can now have the same IP address no matter how it's connected to the internet.

    In theory, that should work. In practice, the whole BGP scheme the internet runs on is designed around relatively short and slow-changing (other than occasional drop-outs) paths to the backbone; I'm not at all sure how it would work out with you swapping from McDonalds WiFi+3G to 3G to 3G (connected to a different tower) to Starbucks WiFi+3G to 3G etc., and NAT will break things for sure. But the core idea isn't really wrong, StripedCow just doesn't understand the huge difference between the "router" sitting at his ISP's uplink and the "router" sitting on his DSL line, and doesn't get how evil-yet-prevalent NATting is.

    Anyway, the simple answer is to use autossh to form a ssh connection to a host on the internet, and to reconnect automatically if it drops. Use a tun interface, you get vpn. Hopefully, you can set up MPTCP on that host, thus saving you a drop/reconnect every time your connection changes, but it'll work without (when you reconnect, the TCP connections should sync back up). Once you've got MPTCP to that host, you don't need it to the rest of the internet, because everything else only sees that host's IP, which of course doesn't change.

  40. But we've already 'solved' this in practice by Phil+Urich · · Score: 1

    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.

    --
    I remember sigs. Oh, a simpler time!
    1. 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.

  41. Re:closed source triumphs again by Belial6 · · Score: 1

    I am getting to the point that I hate the free Wifi at McDonalds and Starbucks. In theory it is great, but because of their TOS page, it ends up blocking data from various apps when you drive past one. Constantly adding and removing the connection manually isn't the answer. On the other hand, I feel a bit rediculous complaining about a free service that I could just ignore and not have these issues.

  42. Don't worry if you're Sprint customer though by gelfling · · Score: 1

    There is no network. Been sitting here in Raleigh for 2 full years listening to them tell me they're 'improving' and 'rolling out' LTE. If anything it's gotten worse. Of course no data but now dialtone is an iffy thing.

  43. Re:closed source triumphs again by Anonymous Coward · · Score: 0

    meanwhile everyone with an iPhone is now enjoying the benefits of multipath tcp.

    ...in Siri.

    ...on iPhone 4S or later (since earlier models won't run Siri, for whatever reason). My iPhone 4, for instance, won't enjoy the benefits of multipath TCP since only Siri uses it and Siri don't play in my sandbox.

  44. Re:closed source triumphs again by bluemonq · · Score: 1

    Couldn't you just quickly turn off WiFI with the new Control Center?

  45. Re:closed source triumphs again by Belial6 · · Score: 1

    Yes, but driving down the road with music streaming, the solution of spotting McDonald's and turning off WiFi, and turning it back on when you get out of range isn't really a viable solution.

  46. Re:closed source triumphs again by gottabeme · · Score: 1

    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.

    --
    "Those who consume the bulk of goods are those who make them. We must never forget this secret of our prosperity."
  47. Unfortunately DHCP limited to certain subnets by Anonymous Coward · · Score: 0

    I run a vpn for a client of mine. We needed to change the lan subnet to a non conflicting one with most coffee shops and hotels. We chose 192.168.8.x. Unfortunately when trying to connect to the lan locally the iPhone running ios 7 refused to connect. The moment we used a common subnet (ie .0, .1 or .2) it connected immediately. It seems the ios 7 dhcp client may have some limitations built in. I can connect no problem with my Android.