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 means that when your smartphone is connected to both WiFi and a mobile data network, it will use only one of those connections. Under MTCP it will use both, which is what iOS 7 is now doing with Siri.

Does MTCP have implications for the LAN, WAN or data centre? To get a handle on what MTCP means beyond the iPhone, The Register spoke to Asia Pacific Network Information Centre (APNIC) chief scientist Geoff Huston.

For the TL;DR crowd, the short version is that you won't see ubiquitous multipath TCP anytime soon, for at least three good reasons. First, today's networks will break it in different ways; second, if it's carelessly implemented, users will disable it rather than watch their phones consume expensive mobile data when WiFi is available; and finally, if it ever poses a threat to carrier business models, they'll be able to put a stake through its heart.

Empower the host

Mutlipath TCP, Huston told Vulture South, harks back to the basic theory of the Internet, that the best network is one in which the network is dumb and the hosts are smart. An empowered host should be able to understand and use the resources available to it.

In the case of Multipath TCP, that means being able to scavenge whatever communication resources are available and use those resources in whatever way best serves the host.

Not so long ago, this couldn't make much sense. The typical Internet host was a PC connected to a LAN. It had one LAN interface, and more importantly, just one connection to the Internet. There's not much sense for the typical user (special cases exist for servers) to install two LAN cards, acquire two IP addresses, and split the traffic, when the router is presenting just one interface to the outside world.

Smartphones and tablets changed all of that: nearly every single one of them presents two interfaces to the world – the WiFi interface and the 3G / 4G interface. From the point of view of the host, that creates two possibilities:

• Bake-in a policy decision that the device should connect to WiFi whenever possible – the default that most users are familiar with.
• With Multipath TCP in the stack, let the phone split the traffic across both of its IP addresses (the WiFi and the mobile data interface), anytime both network types are available.

If we assume the ideal “dumb network” between the two hosts, the network won't notice anything happening. After all, its only role is to look at packets and route them. The hosts at either end of the conversation – in Siri's case, a server at Apple and a phone in the customer's hands – are the only ones that need a Multipath TCP stack.

Is it ever that easy?

The first catch is easily identified: it's not enough to have a Multipath-TCP stack in a client. It has to exist at the server as well. So for it to become ubiquitous, it would have to be implemented by the servers that drive the Internet's applications.

A chicken-and-egg scenario is likely to come into play: anything that gets in the way of the technology is a reason for systems administrators not to bother. Why would they take the risk of implementing a new stack in their servers – with all the risks and change management issues that involves – if it's not going to make a difference to their businesses anyhow?

And there are roadblocks – chief among them being the near-ubiquity of NAT (network address translation).

An awful lot of the Internet's middleware (for example, stateful firewalls and NATs) use two hosts' SYN-ACK exchange to decide what to pass and what to block. The network stopped being the theorists' “ideal dumb network” a long time ago.

This isn't a problem that exists between the two smart hosts. Sure, only one of the smartphone's interfaces will be used for the SYN-ACK that sets up a session – but the session information and the Multipath TCP stack provide all that's needed to sort out communications that travel over different paths.

The firewalls, NATs and “a lot of the other middleware” on the Internet, Huston told Vulture South, aren't in the same position. Multipath TCP would confuse a lot of handshake-sensitive middleware, he said.

That middleware, Huston suspects, will stand in the way of big data centres jumping on board in a hurry, because there's probably too many ways in which it would break the various layers of middleware that exist between a server and the outside world.

Other examples of exchanges that might be SYN-sensitive include:

• A user establishes a VPN to the corporate network over the home WiFi. In the Multipath TCP world, it's feasible that traffic could also traverse the available mobile network – but it won't be secure.
• Looking at what Huston called the Internet's “famous lost cause”, QoS: where it is implemented, it's often negotiated between pairs of addresses. In a Multipath TCP world, does one address pair need to know what's been negotiated between another address pair?

The scavenger of quality

The answer to the QoS question should be that it doesn't matter, Huston said, because in effect, Multipath TCP does over multiple links what Internet protocols always assumed they'd be able to do – scavenge whatever quality is available.

The idea of the Internet is that it should be self-optimising, Huston told Vulture South: “latch onto the highest quality you can, and complete the communication as quickly as you can”. People who work with the routers in the centre of the network are accustomed to these concepts; Multipath TCP merely pushes the same concept out to the end-user's hosts.

In a working deployment case, Multipath TCP would act as a nearly-automatic load balancing for the end user. If the WiFi router is attached to a multi-megabit per second fixed link, while the congested 3G link is struggling along at 500 Kbps, then most of the user traffic will flow over the WiFi link.

If, on the other hand, the home WiFi router's ADSL link is the one that's struggling, and the smartphone can see a 4G connection – then the 4G connection will carry most of the traffic.

Oh, that's not necessarily ideal, is it? Because out-of-the-box, a Multipath TCP stack doesn't know anything about the price of the connection. It's not an issue now, since Siri isn't hammering away at the connection – but what if the next Multipath TCP implementation to escape into the wild were YouTube?

It would be a world-changing implementation, and not in a good way: users could experience a brand-new bill-shock that far outstrips anything we've seen before.

If the technology ever does become widespread, it would be at least desirable for application designers to learn how to make reasonable assumptions about the paths available to end user hosts. Oddly enough, this might in the long run give Android an advantage over Apple, since the stack in the device is more directly visible to the end user.

An Android app developer could make cost inferences by simply looking at which physical interface is tied to which IP address (moreover, since mobile networks are still presented to the Internet as “great big NATs”, a 3G address that's bound to a 10-range IP address at the device is clearly attached to the Telstra mobile network). An Apple developer would have to wait for Cupertino to make suitable APIs available – if and when.

Hang on … carrier NAT?

We mentioned that NAT can get in the way of Multipath TCP, didn't we? Of course we did. And if you nominated where there's an awful lot of very big NAT …

It would be in mobile networks. Which, interestingly, puts carriers at the heart of the future of MTCP, at least in the short term.

A common wisdom about MTCP – the so-called “het-net”, or heterogeneous network – is that it will leach carrier revenues. If your iPhone is grabbing free WiFi as you walk down the street, instead of using up your lovely and relatively expensive mobile data connection, that's a revenue threat to address. If, on the other hand, traffic is being directed over the 4G network because it's faster than what's available to your home router, that's a revenue opportunity.

Carriers don't have to make any decisions today, of course, since the only Multipath TCP app seen in the wild is Siri (and it can only fire up multipath connection if you've got both the WiFi and 3G interfaces active and if both network types are available.

If the carriers decide they're not keen on Multipath TCP, then right now, it's well within their power to spoil it. ®

Bootnote: With thanks to APNIC's Geoff Huston. Any errors or omissions are the responsibility of The Register. ®