Glad you guys did an article on this. Was disappointed that it was not mentioned in the iOS 7 review.

However, as far as I know, using multi-path is not App dependent. It is part of the TCP stack, and Apps have zero control over this. The developer basically says "Make a connection to this end point" and the TCP Stack handles the rest.

EDIT: Unless Apple is specifically limiting other Apps from using it, and Siri has its own channel down to the driver.

Glad you guys did an article on this. Was disappointed that it was not mentioned in the iOS 7 review.

However, as far as I know, using multi-path is not App dependent. It is part of the TCP stack, and Apps have zero control over this. The developer basically says "Make a connection to this end point" and the TCP Stack handles the rest.

EDIT: Unless Apple is specifically limiting other Apps from using it, and Siri has its own channel down to the driver.

This is true...TCP must still present itself to the higher layers as a single TCP stack.

It should also be noted that for true multipathing, both ends of the connection must support MPTCP.

I remember an earlier article where Apple had moved to a single antenna for WiFi and 3G signals. If I'm remembering correctly there was some concern that because it was a single antenna it couldn't handle both at the same time. Would someone be able to correct me? I would assume Apple devices CAN handle both signals at the same time so obviously one of my assumptions is incorrect. (This is related because Apple would be using 3G and WiFi with this protocol on the same antenna at the same time).

I'm excited about his because it may relieve a real-world headache I have on a daily basis: When I get in my car, I use Siri to say "call my wife". I do this as I'm driving past my work, with just enough connection to hit the main wifi.

However, since I'm driving in my car, the Wifi connection is lost before the query can get a response from the server, and so I have to wait 30 seconds to a minute for the WiFi to time out before Siri tries again the cell network. Or sometimes it just drops the request entirely and I have to initiate it again.

Hopefully this + the M7 chip turning off wifi automatically when I start driving will be what I need to alleviate these woes.

And yes, I realize I just spent a few minutes typing up this post about a 30-60 second delay I occasionally face in the week, bug dang it, it just frustrates me!

Glad you guys did an article on this. Was disappointed that it was not mentioned in the iOS 7 review.

However, as far as I know, using multi-path is not App dependent. It is part of the TCP stack, and Apps have zero control over this. The developer basically says "Make a connection to this end point" and the TCP Stack handles the rest.

EDIT: Unless Apple is specifically limiting other Apps from using it, and Siri has its own channel down to the driver.

It is all handled by the TCP/IP stack as best i can tell. But it would not surprise me if Apple has made it dependent on a Apple-only API call, so that Apple's apps are the only ones that can make use of it.

I wonder if a broken MTCP implementation can be blamed for Siri's reticence of late. For the past two weeks, Siri tells me "Sorry, but I can't take any requests right now" (or some variant) about 50% of the times I talk to her.

I remember an earlier article where Apple had moved to a single antenna for WiFi and 3G signals. If I'm remembering correctly there was some concern that because it was a single antenna it couldn't handle both at the same time. Would someone be able to correct me? I would assume Apple devices CAN handle both signals at the same time so obviously one of my assumptions is incorrect. (This is related because Apple would be using 3G and WiFi with this protocol on the same antenna at the same time).

Bluetooth and Wifi have their own antennas (under the glass parts on the back of a 5/5S), the cell connection has two antennas (top and bottom outer edges of case on 5/5S)

1) This is a pretty clever solution for "what if you're connected to WiFi but packets aren't getting through for some reason". I know I do have to sometimes turn off WiFi, because I'm connected to a network that originally was working and has now ground to a halt (sometimes happens at restaurants).

2) As Frennzy noted, both ends have to support MPTCP, so this isn't something that would "just work" for other apps if Apple switched it on. But there are plenty of apps where the developer controls the server-side enough to implement this on their servers.

3) I, for one, don't want to see this expanded beyong "Siri can automatically switch to cellular when WiFi isn't working", without having pretty good user control. I have a cap on my cellular plan, so pretty much want my phone to be either on WiFi or cellular, and indicate which in the UI. I'd hate to be watching a movie on Netflix on WiFi and find out I just blew through a big chunk of my plan because it was doubling up on the bandwidth using my cellular connection (or that it switched completely to cellular but doesn't show that in the UI). Siri doesn't use a whole lot of bandwidth, so I'm not worried about this one use. But any expanded use really needs appropriate user control and indication in the UI of what's happening, so users can maintain control over their cellular usage.

As a bit of background, I do a lot of traveling, so end up using both cellular and restaurant/hotel WiFi networks for a lot of my usage. So I tend to bump up against my cellular cap every month, and I can tell you that restaurant/hotel WiFi dependability can be spotty. You can have a really good WiFi signal, but their WAN connection may be saturated.

I'm excited about his because it may relieve a real-world headache I have on a daily basis: When I get in my car, I use Siri to say "call my wife". I do this as I'm driving past my work, with just enough connection to hit the main wifi.

However, since I'm driving in my car, the Wifi connection is lost before the query can get a response from the server, and so I have to wait 30 seconds to a minute for the WiFi to time out before Siri tries again the cell network. Or sometimes it just drops the request entirely and I have to initiate it again.

Hopefully this + the M7 chip turning off wifi automatically when I start driving will be what I need to alleviate these woes.

And yes, I realize I just spent a few minutes typing up this post about a 30-60 second delay I occasionally face in the week, bug dang it, it just frustrates me!

Oh no, you are not the only one with that annoyance. It may seem like a little thing but having Siri tell you she cant help you now becuase you are in that space between wifi and 3G is annoying.

I have been waiting for someone to use something like this for a long time. I previously never knew about MPTCP, but it seemed like a fairly simple thing to implement (using UDP that is). It has always bugged me how poorly cell phones handle the hand off from WiFi to mobile data. Now if the OS itself abstracted all of this away from the application using the network, that would be even better. It would also follow the proper TCP/IP stack...

Edit:I just read above that MPTCP needs to be supported on both ends of the communication. This makes a lot more sense now. So now I think that this just needs to become a tad bit more standard.

It is a feature of iOS 7. I do not see it as being a hardware limitation. TCP flags are not hardware dependent.

The hardware has to support keeping a data connection to the cell network open while using WiFi. For all I know, all cell phone hardware supports this, but my point is that it's not just a software thing.

It is a feature of iOS 7. I do not see it as being a hardware limitation. TCP flags are not hardware dependent.

The hardware has to support keeping a data connection to the cell network open while using WiFi. For all I know, all cell phone hardware supports this, but my point is that it's not just a software thing.

If you think about it, you would never get MMS messages while on wifi if it didn't. The hardware has to support a presence connection to the cell network while on WiFi, or else nothing (calls, texts, etc) would get through from the cellular network.

And realistically, for most apps, if you open a data connection while on cellular, and then turn on wifi, they'll either drop and reconnect, or continue communicating over the cell network.

It is a feature of iOS 7. I do not see it as being a hardware limitation. TCP flags are not hardware dependent.

The hardware has to support keeping a data connection to the cell network open while using WiFi. For all I know, all cell phone hardware supports this, but my point is that it's not just a software thing.

If you think about it, you would never get MMS messages while on wifi if it didn't. The hardware has to support a presence connection to the cell network while on WiFi, or else nothing (calls, texts, etc) would get through from the cellular network.

And realistically, for most apps, if you open a data connection while on cellular, and then turn on wifi, they'll either drop and reconnect, or continue communicating over the cell network.

It's not necessarily that obvious. The network could request a data connection when an MMS is required.

MPTCP is an extension to the TCP protocol that's used for about 85 percent of all Internet traffic.

Through about half of the article, I was wondering why it was such a big deal that Siri uses MPTCP if it’s used for 85% of all Internet traffic. Then I realized what that sentence was actually supposed to mean.

Facetime really works well over cellular networks now - even when riding in a car. I wonder how much of this is because of Apple's Multipath TCP implementation.

Well when your in your car you are most likely using your cell service only... so it has nothing to do with MPTCP, but more to do with your service provider making prioritization for certain packets...

1) This is a pretty clever solution for "what if you're connected to WiFi but packets aren't getting through for some reason". I know I do have to sometimes turn off WiFi, because I'm connected to a network that originally was working and has now ground to a halt (sometimes happens at restaurants).

2) As Frennzy noted, both ends have to support MPTCP, so this isn't something that would "just work" for other apps if Apple switched it on. But there are plenty of apps where the developer controls the server-side enough to implement this on their servers.

3) I, for one, don't want to see this expanded beyong "Siri can automatically switch to cellular when WiFi isn't working", without having pretty good user control. I have a cap on my cellular plan, so pretty much want my phone to be either on WiFi or cellular, and indicate which in the UI. I'd hate to be watching a movie on Netflix on WiFi and find out I just blew through a big chunk of my plan because it was doubling up on the bandwidth using my cellular connection (or that it switched completely to cellular but doesn't show that in the UI). Siri doesn't use a whole lot of bandwidth, so I'm not worried about this one use. But any expanded use really needs appropriate user control and indication in the UI of what's happening, so users can maintain control over their cellular usage.

As a bit of background, I do a lot of traveling, so end up using both cellular and restaurant/hotel WiFi networks for a lot of my usage. So I tend to bump up against my cellular cap every month, and I can tell you that restaurant/hotel WiFi dependability can be spotty. You can have a really good WiFi signal, but their WAN connection may be saturated.

You can, under Settings->General->Usage deny 3G access to applications.

But things get much, much harder when the traffic is encrypted using a block cipher in CBC (cipher block chaining) mode. (AES-CBC is commonly used for encrypted SSL/HTTPS communication.) In that case, even if the key is known, all previous data blocks are required to decrypt the next one.

This is incorrect - CBC requires only the previous ciphertext bock and the key to be able to decrypt the next block.

Apple wasn't involved in the development of MPTCP, but the company simply adopted the IETF specification. Although Apple uses MPTCP for a rather pedestrian purpose, it's not just an optimization to eke out a bit more speed. This is a fundamentally different approach to network communication.

I'm really confused here. Is the "fundamental difference" the fact that Google is inventing stuff, and Apple is piggybacking on those inventions (which would make sense) or that Apple simply making use of this protocol (which is the way the sentence parses)?

The biggest thing with MPTCP is around buffer size though, because siri uses very little bandwidth this makes sense to utilize MPTCP for this purpose, but to have reliable switching between paths you need to have substantial buffers in place, otherwise the packet loss would be too much to recover and it would have just been easier to switch to the other connection.

RTSP do not usually play well with these services and would have issues as all the packets are processed in real-time. And buffer size does not mean much because if a packet it lost it is already lost in the stream. So I would not expect this to play well with things that require real-time packet transmission (IE Facetime)...

1) This is a pretty clever solution for "what if you're connected to WiFi but packets aren't getting through for some reason". I know I do have to sometimes turn off WiFi, because I'm connected to a network that originally was working and has now ground to a halt (sometimes happens at restaurants).

2) As Frennzy noted, both ends have to support MPTCP, so this isn't something that would "just work" for other apps if Apple switched it on. But there are plenty of apps where the developer controls the server-side enough to implement this on their servers.

3) I, for one, don't want to see this expanded beyong "Siri can automatically switch to cellular when WiFi isn't working", without having pretty good user control. I have a cap on my cellular plan, so pretty much want my phone to be either on WiFi or cellular, and indicate which in the UI. I'd hate to be watching a movie on Netflix on WiFi and find out I just blew through a big chunk of my plan because it was doubling up on the bandwidth using my cellular connection (or that it switched completely to cellular but doesn't show that in the UI). Siri doesn't use a whole lot of bandwidth, so I'm not worried about this one use. But any expanded use really needs appropriate user control and indication in the UI of what's happening, so users can maintain control over their cellular usage.

As a bit of background, I do a lot of traveling, so end up using both cellular and restaurant/hotel WiFi networks for a lot of my usage. So I tend to bump up against my cellular cap every month, and I can tell you that restaurant/hotel WiFi dependability can be spotty. You can have a really good WiFi signal, but their WAN connection may be saturated.

You can, under Settings->General->Usage deny 3G access to applications.

I don't want to deny 3G access to all applications. I just want to deny applications the ability to switch to 3G when the phone is showing me it's using WiFi. See the difference?

EDIT: That is, in the theoretical condition where Apple implements this for all apps, I want to have that control.

Apple will hopefully make MPTCP available to third-party applications soon. Maybe combining Wi-Fi and 3G bandwidth will finally let my YouTube videos play from start to finish without stopping a few times in the middle for rebuffering.

MPTCP does nothing for bandwidth. A connection is simply opened on multiple networks. But only one of the connections is used. If the connection being uses drops, then it uses the other connection. The server sees the second connection being used, looks at the TCP flag to see what endpoint it is associated with, and accepts it.

EDIT: I missed the one line in the RFC that stated otherwise. Please ignore the above statement.

Apple will hopefully make MPTCP available to third-party applications soon. Maybe combining Wi-Fi and 3G bandwidth will finally let my YouTube videos play from start to finish without stopping a few times in the middle for rebuffering.

MPTCP does nothing for bandwidth. A connection is simply opened on multiple networks. But only one of the connections is used. If the connection being uses drops, then it uses the other connection. The server sees the second connection being used, looks at the TCP flag to see what endpoint it is associated with, and accepts it.

It may not do anything with bandwidth per-say, but will increase your good-put because you can have tolerances setup that decide when you bail a path... So if your wifi is working, but dropping packets like crazy, etc... then MPTCP can kick off to another connection, it may be a "lower bandwidth" connection, but your good-put is higher due to packet loss on the other path..

Apple will hopefully make MPTCP available to third-party applications soon. Maybe combining Wi-Fi and 3G bandwidth will finally let my YouTube videos play from start to finish without stopping a few times in the middle for rebuffering.

MPTCP does nothing for bandwidth. A connection is simply opened on multiple networks. But only one of the connections is used. If the connection being uses drops, then it uses the other connection. The server sees the second connection being used, looks at the TCP flag to see what endpoint it is associated with, and accepts it.

This is not true. From the RFC:

Quote:

3.3.8. Subflow Policy

Within a local MPTCP implementation, a host may use any local policy it wishes to decide how to share the traffic to be sent over the available paths.

In the typical use case, where the goal is to maximize throughput, all available paths will be used simultaneously for data transfer, using coupled congestion control as described in [5]. It is expected, however, that other use cases will appear.

For instance, a possibility is an 'all-or-nothing' approach, i.e., have a second path ready for use in the event of failure of the first path, but alternatives could include entirely saturating one path before using an additional path (the 'overflow' case). Such choices would be most likely based on the monetary cost of links, but may also be based on properties such as the delay or jitter of links, where stability (of delay or bandwidth) is more important than throughput. Application requirements such as these are discussed in detail in [6].

The ability to make effective choices at the sender requires full knowledge of the path "cost", which is unlikely to be the case. It would be desirable for a receiver to be able to signal their own preferences for paths, since they will often be the multihomed party, and may have to pay for metered incoming bandwidth.

Whilst fine-grained control may be the most powerful solution, that would require some mechanism such as overloading the Explicit Congestion Notification (ECN) signal [17], which is undesirable, and it is felt that there would not be sufficient benefit to justify an entirely new signal. Therefore, the MP_JOIN option (see Section 3.2) contains the 'B' bit, which allows a host to indicate to its peer that this path should be treated as a backup path to use only in the event of failure of other working subflows (i.e., a subflow where the receiver has indicated B=1 SHOULD NOT be used to send data unless there are no usable subflows where B=0).

In the event that the available set of paths changes, a host may wish to signal a change in priority of subflows to the peer (e.g., a subflow that was previously set as backup should now take priority

Apple will hopefully make MPTCP available to third-party applications soon. Maybe combining Wi-Fi and 3G bandwidth will finally let my YouTube videos play from start to finish without stopping a few times in the middle for rebuffering.

MPTCP does nothing for bandwidth. A connection is simply opened on multiple networks. But only one of the connections is used. If the connection being uses drops, then it uses the other connection. The server sees the second connection being used, looks at the TCP flag to see what endpoint it is associated with, and accepts it.

This is not true. From the RFC:

Quote:

3.3.8. Subflow Policy

Within a local MPTCP implementation, a host may use any local policy it wishes to decide how to share the traffic to be sent over the available paths.

In the typical use case, where the goal is to maximize throughput, all available paths will be used simultaneously for data transfer, using coupled congestion control as described in [5]. It is expected, however, that other use cases will appear.

For instance, a possibility is an 'all-or-nothing' approach, i.e., have a second path ready for use in the event of failure of the first path, but alternatives could include entirely saturating one path before using an additional path (the 'overflow' case). Such choices would be most likely based on the monetary cost of links, but may also be based on properties such as the delay or jitter of links, where stability (of delay or bandwidth) is more important than throughput. Application requirements such as these are discussed in detail in [6].

The ability to make effective choices at the sender requires full knowledge of the path "cost", which is unlikely to be the case. It would be desirable for a receiver to be able to signal their own preferences for paths, since they will often be the multihomed party, and may have to pay for metered incoming bandwidth.

Whilst fine-grained control may be the most powerful solution, that would require some mechanism such as overloading the Explicit Congestion Notification (ECN) signal [17], which is undesirable, and it is felt that there would not be sufficient benefit to justify an entirely new signal. Therefore, the MP_JOIN option (see Section 3.2) contains the 'B' bit, which allows a host to indicate to its peer that this path should be treated as a backup path to use only in the event of failure of other working subflows (i.e., a subflow where the receiver has indicated B=1 SHOULD NOT be used to send data unless there are no usable subflows where B=0).

In the event that the available set of paths changes, a host may wish to signal a change in priority of subflows to the peer (e.g., a subflow that was previously set as backup should now take priority

This would seem to be less ideal for a phone though, because it means you're going to burn your data plan even while on wifi, and data plan overages are pure extortion.

This would seem to be less ideal for a phone though, because it means you're going to burn your data plan even while on wifi, and data plan overages are pure extortion.

Understood, and as the section states, it's up to the host how to handle it, but presuming true multipath, you can and should be able to make use of the extra bandwidth if it makes sense to do so. This is an IETF RFC, not just how apple is handling things.

Negotiating multiple connections routes has been a huge pain for me. Some campuses, like mine, will have WiFi in the residences that share the same network ID as in the research buildings, but the residences have additional restrictions that prevent my phone from connecting to the internet, even though it connects to the WiFi. So if I ever enter one of those areas, I have to go explicitly turn off WiFi. If my phone could use multiple routes, I wouldn't ever have this problem.

Negotiating multiple connections routes has been a huge pain for me. Some campuses, like mine, will have WiFi in the residences that share the same network ID as in the research buildings, but the residences have additional restrictions that prevent my phone from connecting to the internet, even though it connects to the WiFi. So if I ever enter one of those areas, I have to go explicitly turn off WiFi. If my phone could use multiple routes, I wouldn't ever have this problem.

(Lumia 920 here)

Edited for clarity.

Not sure if this case would apply. The WiFi policy wouldn't trigger a "lets go around this fence". AFAICT, of course.

Negotiating multiple connections routes has been a huge pain for me. Some campuses, like mine, will have WiFi in the residences that share the same network ID as in the research buildings, but the residences have additional restrictions that prevent my phone from connecting to the internet, even though it connects to the WiFi. So if I ever enter one of those areas, I have to go explicitly turn off WiFi. If my phone could use multiple routes, I wouldn't ever have this problem.

(Lumia 920 here)

Edited for clarity.

Not sure if this case would apply. The WiFi policy wouldn't trigger a "lets go around this fence". AFAICT, of course.

If the packets aren't making it through, then it switches to cellular. The "why" doesn't matter.