Feeds

back to article Multipath TCP: Siri's new toy isn't a game-changer

When the iOS 7 incarnation of Siri was caught using Multipath TCP (MTCP) earlier this month, there was much excitement at it heralding a new era of communications. Which it may well do even though Siri was singing many hours before the sun begins to rise. A quick MTCP primer: TCP connections usually travel over one path. This …

COMMENTS

This topic is closed for new posts.

Page:

Silver badge

TCP/IP has been multi-path from the git-go.

It's the way we designed it.

Seriously, learn about networking & history before trying to report on it.

6
25

Re: TCP/IP has been multi-path from the git-go.

Beat me to it.

May be the problem with a phone it that the mobile and wi-fi are given different IP addresses and your phone would have to add a simple virtual host/router to use both interfaces simultaneously. However, my netbook has both on at the same time, not sure how it decides.

1
0

Re: TCP/IP has been multi-path from the git-go.

@jake, err, no it hadn't

Sure enough, IP has always been, and is now, multipath. TCP session, however, is defined by the quadruple of source and destination layer3 addresses, and source and destination (layer4) ports. For a host with multiple interfaces that means one TCP session can use only one interface (at least, the incoming packets can only arrive on one interface). What they are talking about here is having different packets with different pairs of source and desitnation addresses belong to a single TCP session. Standard published in January 2013: http://tools.ietf.org/html/rfc6824

24
2
Silver badge

@ Eugene Crosser (was: Re: TCP/IP has been multi-path from the git-go.)

"January 2013"

We were doing this in ~1985.

HTH, HAND.

1
18
Anonymous Coward

Re: @ Eugene Crosser (was: TCP/IP has been multi-path from the git-go.)

We were doing this in ~1985.

To connect to that web site you ran up single-handed in 1983?

6
1
Silver badge

@AC 07:28 (was: Re: @ Eugene Crosser (was: TCP/IP has been multi-path from the git-go.))

"To connect to that web site you ran up single-handed in 1983?"

No. Back then it was FTP and/or telnet..

MUDs, MUSHs and MOOs, on the other hand ...

I won't go into Usenet, that would probably only confuse you.

1
18
Bronze badge

Re: @ Eugene Crosser (was: TCP/IP has been multi-path from the git-go.)

I suspect some people here are missing the fundamental difference between an application managing multiple single TCP sessions in software and treating them as one, and actual Multipath TCP in the network stack on the OS presenting a single stream up the stack.

The functional difference is like you putting a conversation together from hand written letters and e-mails that are all intermingled, and someone doing this for you and presenting you with the completed conversation.

In the first case you (the application, or essentially anything above Layer 5 in the OSI model), know who the data came from and that the data has come to you via different routes and you also have to reassemble to the data in the right order.

In the second case you just get handed a complete data set and you know who it's from, but don't necessarily know or even need to know how it got to you.

9
1
Silver badge

@Phil W (wasRe: @ Eugene Crosser (was: TCP/IP has been multi-path from the git-go.))

"The OSI model" has been fucking useless for over a quarter century.

HTH, HAND.

0
22
Silver badge
FAIL

Re: @jake

"The OSI model" has been fucking useless for over a quarter century.

Seriously, learn about networking & history before trying to comment on it.

9
1
Bronze badge

Re: @Phil W (was@ Eugene Crosser (was: TCP/IP has been multi-path from the git-go.))

Ummm no. Just no.

Admittedly there are certain situations where the OSI model isn't accurate or doesn't apply, but it is still the fundamental core of networking particularly TCP/IP based networking (which is the majority of all networking).

It is particularly relevant when comparing TCP an Multipath TCP. If you don't see how I suggest you go and get some education/training. I'd suggest a CCNA, but frankly it sounds like you may need to start out a little more basic than that.

5
1
Anonymous Coward

Re: TCP/IP has been multi-path from the git-go.

Seriously, jake. Why do you feel the need to turn everything into a willy waving competition?

5
1
Anonymous Coward

Re: @AC 07:28 (was: @ Eugene Crosser (was: TCP/IP has been multi-path from the git-go.))

Hi Jake,

How did you get your multipath TCP sessions, that use multiple interfaces, that you've been doing since 1985, to pass stateful firewalls?

You know, after they became popular/mainstream, maybe ~94 ?

Thanks,

3
1
Bronze badge

Re: TCP/IP has been multi-path from the git-go.

>my netbook has both on at the same time, not sure how it decides.

Well each interface will have been given a weighting/priority and the comm's stack will decide which interface to use based on that weighting.

The advantage of the phone is that applications can use it's phone number (or other number personal/unique to it) to permit the remote application to tie the differing streams together - I suspect that a limitation with Apple's implementation is an assumption that only one instance of FaceTime or Siri is running on the device.

2
0
Silver badge

Re: TCP/IP has been multi-path from the git-go.

But only if you are prepared to run dynamic routing protocols down to user device level.

Seriously, learn about networking & history before trying to report on it.

3
1
Anonymous Coward

Re: TCP/IP has been multi-path from the git-go.

Re: Seriously, jake. Why do you feel the need to turn everything into a willy waving competition?

More importantly, once he's turned it into a competition, why does he pull out a water pistol when others are carrying six shooters and shotguns?

4
1
Anonymous Coward

Re: TCP/IP has been multi-path from the git-go.

The proper term would appear to be bonding, but with priority to Wifi.

1
0

Re: TCP/IP has been multi-path from the git-go.

"However, my netbook has both on at the same time, not sure how it decides."

Routing table decides which route to use....routes have a cost and it will use the cheapest route if more than one route exists

0
0
Bronze badge

Re: TCP/IP has been multi-path from the git-go.

With regards to having wired and WiFi on a Windows machine at the same time....

If you go into control panel to where you see your list of network adapters (not describing the path because it varies by Windows version) then go to the advanced menu (alt and N if you can't see the menu) and then Advanced Settings, you can see the list of connections and the order they are used in. Priority is top down, so the connection at the top is used first if connected.

Presumably a similar option exists on Macs and *nix OSs though I'm not sure of what/where off hand.

1
0

Re: TCP/IP has been multi-path from the git-go.

For Macs it's the order the interfaces are shown in the Networks prefs, top down again. You can mess with the priorities using the cog menu below the list, "set service order". Other *nixes will vary.

0
0
Bronze badge

Re: TCP/IP has been multi-path from the git-go.

@Jake - I downvoted you because:

(A) IP has always been multipath, yes; but

(B) the article specifically talks about multipath TCP (see the header).

2
1
Silver badge

@Neoc (was: Re: TCP/IP has been multi-path from the git-go.)

Neoc & the rest of you lot ... TCP relies on IP for transport.

Thus, TCP/IP has always been multi-path.

The mind boggles at the ignorance being displayed here ...

0
2
Silver badge

Re: @Neoc (was: TCP/IP has been multi-path from the git-go.)

"Thus, TCP/IP has always been multi-path."

Only once you leave the source host. These days, however, getting from your source host to the first hop is the least reliable part of the connection.

Yes, TCP packets may be carried across multiple routes once they leave their source IP address, but: TCP connections must have one and only one endpoint address at each end. You must choose the source and destination IP address before you initiate the connection, and you're stuck with this choice until you close the session. If one of those endpoint addresses becomes unreachable (e.g. a Wifi link fails), then the whole session fails, even if the host you were communicating with still has other viable connections.

Multipath TCP allows you to carry a TCP session with multiple interfaces at each end. A master Multipath TCP flow is established, and it delegates packets to one or more additional "plain-TCP" "sub flows". The choice of which sub-flow receives a particular packet follows the whatever TCP congestion-control algorithms you've chosen, so a slow link is not given as much traffic as a fast one, for instance. However, individual sub-flows may drop or join the master flow without bringing down the overarching Mutlipath TCP session. A crude analogy is that MPTCP is like placing the first-hop router into the TCP stack of the local host (MPTCP isn't a routing protocol, though, it's cleverer than that).

This isn't bonding. It's not load-balancing. It's not failover. It's TCP, but with the session's packet stream spread across two or more TCP links. As a result, when a MPTCP subflow goes, the overarching session continues, albeit at a lower bandwidth: just like the whole session doesn't collapse when a single packet is lost in TCP.

This is one of the killer features of MPTCP, and it's the one our industrial customers really benefit from: try running a Citrix session on a single, patchy mobile connection that keeps collapsing the TCP connection, and you'll understand how useful it is.

The second big win is that you create a TCP session that has the aggregate bandwidth of all your available interfaces available to it. This is what we're pitching to residential and small-business customers here: http://igg.me/at/mpn - but you also get the reliabliity too, because at heart, it's still TCP.

And that's the point: MPTCP is not trying to replace TCP; it builds on TCP and extends it to make better use of hosts with multiple interfaces.

1
1
Silver badge

Wouldn't IPv6 fix the NAT 'problem'?

2
0
Happy

ipv6 & nat

Ipv6 doors solve the nat problem when possible.

When I need to access an ipv6 only resource when I'm out & about then I set up a tunnel on the laptop & of I go. Works nicely on both 3g & 4g & you can then access inbound back to your local device as if there's no nat in place.

1
0
Bronze badge

IPv6 fix the NAT problem

Well the use of globally unique network addresses (eg. IP address) for all end nodes in a network would greatly facilitate MPTCP communications between them. But I wouldn't count on NAT or IPv4 going away anytime soon, so any viable MPTCP solution needs to take account of NAT (as should IPv6 - but that is a totally different debate).

1
0
Silver badge

Re: Wouldn't IPv6 fix the NAT 'problem'?

It COULD fix it. But IPV6 does not deny the use of NAT. And a lot of people like the fact that their actual IP address and location is known only to a big mobile ISP NAT table, and not to any joe soap with malicious intent on the far end of a site they stumble upon.

5
0

Well yes, but you'll need to wait a while on that.

IPv6 does indeed solve the NAT issue from a routing perspective. That said, one to one "NAT like" address mapping (in your stateful firewall) is sooooo tedious to do manually. Even a decent sized home network with 10 or 15 devices can be troublesome if you want to grant different rules to different users. Granted, many will probably find in the end that "IPv6 NATing" actually works better than creating blanket rules for a particular subnet or whatever, given the obvious granularity that becomes possible. Unfortunately, it'll be a while before decent automation for this task reaches the unwashed masses (you, me, SMBs, schools, etc.), and large enterprises aren't likely to lead the way either as size=inertia in my experience.

0
0

And what about the...

Battery life?

Granted, my phone is a gently aging Nokia N900 (and could probably do with a battery change anytime soon), but given the propensity for data-hungry connections over 3G, and almost anything over WiFi to consume battery power like a starving dog in a butchers shop, isn't this generally a bad thing?

Mobile devices are, by nature, limited in show long they can run due to the big chemical block sitting in the back. Having multiple radio emitters firing up and connecting all at the same time can't be doing wonders for the usage time figures. Pretty serious thing, when your battery is glued and screwed into your block of shiny fruit-plastic.

With the right resources, it's a good plan. But until we have usage time on battery into the 'days' figure, it's not going to do much more than sell a few more phone chargers, so people don't run out of juice halfway through the day.

0
0
Silver badge

Re: And what about the...

Well, while the rule of thumb is power = x * data rate * time, I'm not sure if that will be the limiting factor here.

A worst case scenario might be watching HD video which is using wifi + 3/4G. Simply keeping the screen lit might well be the limiter here.

It sounds to me like the approach is an attempt to anticipate the long anticipated merge of mobile phone technology and ethernet where everything becomes IP. This might make it easier for applications to switch between the two without restarting connections. Applications for this would be things like OTT voice and video communication where the latency of restarting the connection would be noticeable. But I'm not sure if they aren't already quite good at this: I've had a video call with someone on Hangout moving from their wifi to mobile data.

From what I know of 3G I don't see this really happening a lot as there's just too much going on in the carriers' networks. In 4G it's a no-brainer and there are probably already attempts to manage it in silicon - I'm not sure application should be getting the choice - where the phone presents a single interface to a device which might in reality be two or more physical interfaces. Isn't this how MIMO works?

1
0
Silver badge

Re: the rule of thumb is power = x * data rate * time..

Er no.

Not when the carrier is RF communications. There's a little matter of an inverse square law to be tucked in there somewhere..

1
1

Re: And what about the...

A starving dog in a butchers shop would consume battery power?

2
0

Facetime?

I just wandered into the house after starting a Facetime conversation on 3G and it seamlessly transferred to WiFi (It must have done as I have no signal in the middle of my house). I know this doesn't mean it is multi-tunneling, but I do wonder if Facetime is also using this tech? I know that that doesn't work with Skype, it cuts off as soon as I walk into the house and I have to re-establish over WiFi.

1
0
Silver badge

Re: Facetime?

Yep typical Reg hatchet job without all the facts. Before even understanding Apple had implemented multi-path TCP in iOS 7 I had noticed the following.

Before, when using iOS 6, I encountered a problem when leaving my apartment. The journey through my front door would take me out of WiFi range, then, as I walk past the front of my apartment, I would come back into WiFi range (but hovering on the edge of signal sufficient strength) and then after a 30 yard stretch, fully back out of WiFi range. This was annoying because I found it a frequent pattern that if I left the house in a hurry, I would want to use Siri to make a call or send a text ("I'm in my way," or "I'm running late" etc) but invariably and annoyingly, with the WiFi --> 3G --> wiFi --> 3G transitions going on the request would fail. I noted, even before reading about the muti-path implementation, that since installing iOS 7 I tried it expecting it to fail, but it didn't. I have tried multiple times since and it has worked every time. Being technically minded, I was left wondering how there could have been such an improvement, and only later read up about the multi-path TCP implementation.

But more than that I'm now using, FaceTime audio at every opportunity because the sound quality is so much better, FaceTime audio also doesn't fail while making the same transitions. Now that is a pretty good real world test and when you have an understand of the challenges, it is impressive.

Beyond that the several FaceTime audio conversations I've had with my girlfriend when she is travelling in her car (it works via hands free) have also worked reliably without dropping out (my natural inclination would be never to attempt that kind of connection if I knew she was travelling because cell to cell transition and signal lock for 3G is not as good as for GSM audio - and to be accurate this shows the Vodafone network must be quite good now for 3G rather than that multi-path TCP has an effect on cell transition - though the protocol may be a little more robust when dealing with temporary drop-outs. However it does illustrate the multi-path implementation is solving the problem of known WiFi networks popping up and taking over the connection (and often when a WiFi network is joined it is blocked from the network by a login screen). It seems driving past Costa and Starbucks is doing nothing to interrupt.

So in true The Register style, they are jumping the gun looking for theoretical negatives against a tech Apple have implemented first, before checking the real world performance. They did the same with their ill informed article on Apple 5s 64 bit processing, which has now been confirmed as ignorant speculative negative hokum:

http://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and-you.html

4
4
Bronze badge

Re: Facetime?

But the FaceTime app can achieve that handover without MTCP, although MTCP might make simplify the app. I wonder whether the app has knowledge of the WiFi and 3g/4g interfaces and hence effectively creates/maintains two TCP sessions using which ever it determines has the better service? It would seem from your experience that in iOS7 Apple have refined the algorithm for the handover between the two sessions.

Also from your experiment it would seem that iOS implements both client and server functionality.

0
0
Silver badge

Re: Facetime?

Facetime already binds Wifi and UMTS connections, and as it's a UDP application (well, the audio/video streams that account for the bulk of its traffic are UDP), Multipath TCP has no real bearing on any performance improvements you may have seen.

A change to how connections are chosen would be enough to give the improvement.

5
0
Bronze badge

Re: Facetime? @Kristian

Thanks for the gentle pencil stab! Yes UDP would keep things simple.

2
0
Silver badge

Re: Facetime?

"But the FaceTime app can achieve that handover without MTCP"

True, but I expect, since they have implemented MTCP, it will be involved, and then then as more servers become MTCP aware, other services will also benefit. I would not be surprised though if there are tweaks outside of the standard, we can only speculate, but I think a combination of MTCP and other tweaks is indeed likely. Additionally I have a suspicion, and will need to do more to confirm, that they are using the 3G channel to overcome double NAT connection problems. My girlfriends home office suffers from a double NAT problem with FaceTime. I have to wait for her to call me back if I try to call her with FaceTime on her office machine as FaceTime has a problem making the connection the first time - a typical symptom of a double NAT issue. I've noticed this "try to connect twice" problem seems to have resolved itself if I am placing calls to her iOS7 iPhone. Her phone connects to the same WiFi network and had the same problem as her desktop Mac when it was on iOS6.

0
1
Silver badge

Re: Facetime?

@Kristian Walsh

I think that misses the role TCP plays. While UDP would be the protocol for streaming the improvements must relate to connection, re-connection, and stream selection/control, which surely involve TCP. I now need to go and read up on strategies for consuming a UDP packet streams via multiple access links - but that is implementation logic for how it is done in practice and is subservient to by the bigger problem of stream set-up and ongoing QA/control.

0
1

Re: Facetime?

"So in true The Register style, they are jumping the gun looking for theoretical negatives against a tech Apple have implemented first, before checking the real world performance. They did the same with their ill informed article on Apple 5s 64 bit processing, which has now been confirmed as ignorant speculative negative hokum:

http://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and-you.html"

Don't come around here with your 'facts', young man. This is The Register, not some tawdry fact-reporting website.

4
1
Bronze badge

Re: Facetime?

Thank you, Success Case. I'll try leaving home (and my wifi hotspot) whilst listening to Internet radio. Prior to IOS7, I disabled wifi as I left home to avoid annoying drop-outs as my iphone attempted to reconnect, and then switched to LTE.

0
0
Silver badge

Re: Facetime?

Hi @ian 22,

That will be an interesting case but I'm pretty sure it will still fail. MPTCP protocol requires an MPTCP aware server to work. Siri and FaceTime we can expect to be compliant. You can be pretty sure for now pretty much all general internet radio servers won't be though. iTunes radio once it makes it over to Blighty will probably be made MPTCP compliant as the data will be streamed from Apple servers.

I wonder how long it will take before the average Apache host is compliant and if it will be possible to ensure MPTCP can be run on servers where you don't have admin control over the IP stack?

0
0
MrT
Bronze badge

It's about seamless transitioning between services...

...as much as bandwidth and channel bonding - some of the links in this ElReg article from half a year ago seem relevant here...

http://www.forums.theregister.co.uk/forum/1/2013/03/24/multipath_tcp_50_gps/

0
0
Anonymous Coward

The correct acronym is ...

MPTCP

2
0
Bronze badge

Carriers

The default right now is for smartphones to use wifi whenever possible, hard to see what objections they'd have to more data going over their networks instead do wifi.

I think you're making too much of this though, it's on Siri for performance reasons, they're very unlikely to enable it for the rest of the phones traffic for the obvious bill shock reasons you outlined.

0
0

With 3G / 4G being very expensive.

How do you turn it off?

Another reason not to upgrade to IOS7 right there.

2
0
Silver badge

Re: With 3G / 4G being very expensive.

Right now it is only used for Siri, which uses very little bandwidth. They'll obviously have to add some end user control if they decided to implement it for something that uses a lot of bandwidth like iTunes Radio or Maps.

I suspect they did it for Siri because they wanted to improve the response time in situations where you may be on a crappy public hotspot but have a great 3G/4G sitting at your disposal. You don't want to have a wait an extra second for a response if you don't have to, but if it took an extra second for a new Maps area be downloaded as you scrolled around it won't bother you too much.

0
0
Anonymous Coward

TCP is a connection protocol carried on the IP datagram connectionless protocol. In the original theory it doesn't matter how many parallel routes are used for the IP datagrams.

Large networks often load share by sending IP datagrams down internal parallel paths. When they arrive at the destination, intermediate or final, then a TCP-aware stack has to re-assemble the packets into the correct sequence before handing them to the application.

The behaviour of the sending and receiving TCP stacks can then get interesting. Some devices have been seen to ignore any out-of-sequence packets - causing many resends. Others have made immediate, unnecessary requests for a resend of a "missing" packet in order to boost the throughput. Unfortunately both these behaviours can can lead to the sender thinking there is network congestion - and it slows down its subsequent transmissions to a crawl.

TCP-aware firewalls etc just complicate the issue of using multiple paths unless it is a confluence point for all the routes.

2
0
Bronze badge

Re: @AC

The other major complication is IP segmentation.

0
0
Silver badge

Thanks for the tl;dr

It was a good summary of a subject that interests me a bit but not enough to press into the details. More of these!

0
0
Silver badge

Stupid on a phone if there is WiFi

This only makes sense on a phone if the phone can use TWO different Mobile bands at once. Then you can get more speed.

Variations of this have been used in specialist Routers for some time before the recent spec, such as 2 or more ADSL Modems when multiple phone lines exist but speed is only 1Mbps to 3Mbps due to distance. The ISP then supports it and the LAN devices and Internet Servers don't need to know.

But it illustrates the cluelessness of Apple to implement this between WiFi & Mobile unless there is an option to turn it off. I seriously doubt the iPhone can make two simultaneous connections on say 900 UMTS and 2100 UMTS. bands. Two connections on the same band will in most cases give the same channel so give no net increase in speed or reliability.

So there are two use cases (aggregate multiple phone lines or multiple bands), but the iPhone doesn't do either. Also the problem of lack of server support vanishes if the ADSL ISP or Mobile carrier implements it. Such a specialist link aggregation is useful, but Multipath on the Public Internet between Mobile and Fixed is stupidity.

Switching between links (changing between Mobile and WiFi) is a different trick to true Multipath or Link aggregation. It doesn't need any NAT support at all or Multipath. It does require application support at the Server and Client. It can be done purely at the application level on the client and with some persistent object (cookie like) at the server so when client reconnects with a different IP the server Application regards it as the same session. Plain vanilla web servers of course can use a browser cookie.

0
2

Page:

This topic is closed for new posts.