Years ago I used to commute to and from work. What was normally a 30-minute drive off-peak was easily three times that during rush hour. Luckily for me, I was a geek back then, too. I “read” so many Audible books back then that I quickly lost count. Often my mind would wander. I’d see cars and trucks, not as vehicles taking people and products from home to work then back again, but as packets flowing on a vast interconnected network of cement and asphalt. On-ramps and off-ramps were new requests or destinations. Everything flowed smoothly — until it all got bogged down.

Slow-and-go traffic was miserable. It was generally caused by too many cars and trucks trying to occupy the same road at the same time, but sometimes it was because of construction, a hazard, or even a collision.  As time grew on the roads began to evolve. Some gained new lanes, others got higher speed limits. On-ramps were metered so traffic entered the freeway at a slow and regular pace, not all at once. Eventually segregated lanes emerged that let “special” traffic flow more quickly from source to destination. Occasionally a new freeway would open up and the flow of traffic was quelled while half the load used the new route, but all too soon, both roads became saturated again.

The Internet is almost exactly the same as the highway system. Unfortunately, congestion exists on cyber-highways much like it does on its analog counterparts. So far, we’ve adopted essentially the same coping mechanisms to handle this “virtual congestion”.  There are different routes to get from one place to another. Some packets are prioritized over others. Some data flows like a train, constantly streaming past in one giant collection. Traffic is metered onto backbones so the back-haul lines aren’t overloaded all at once. But unlike the highway system, computer networks have one distinct advantage: today most of us have multiple networks to which we can connect.

That’s the good news.

Multiple networks & virtual intersections

The solution to all these problems is redundancy. The more networks that are out there, just like with more roads, the less congested each one becomes. Of course there’s a problem with that: the more roads you have, the more intersections you have to have to make the roads usable. That’s the bad news.

It’s these virtual “intersections” where things start to get really interesting.

Since we’re talking about smartphones and tablets here, the “roads” are wireless links to various networks. Those networks may be somewhat local like WiFi A/B/G/N/AC, or more distant like HSPA/HSPA+, LTE, WiMax, or even EDGE and GPRS.

Breaking these down even more, each one of these networks likely uses a different frequency over which to communicate.

Your phone or tablet has multiple radios inside it’s sleek shell. It can probably even connect to more than one network at a time. For example, as I’m writing this article my hacked Nexus 4 is connected to both T-Mobile’s LTE network and my home WiFi network over 802.11n (2.4GHz). Packets, however, are being sent and received over my WiFi network rather than the LTE network. Which is as it should be since WiFi is my preferred network. Similarly, LTE is preferred over HSPA+, and that over EDGE and GPRS.

Things start to break down at the edges

As one signal fades or interference increases, so does your user experience. Eventually the network is switched to the “next best”. Generally speaking, the various radios that are inside your device aren’t being used for redundant connections, you only have one operating at any given time.

That’s great news for your battery life, but if you’re on the edge of any network (which can happen fairly often if you’re moving around) your network connection will drop until a new one is set up.

One way to solve network congestion and the annoying drop in connectivity while your device finally gives up on the poor connection and negotiates over to another, is to use multipath TCP.

In this scenario, your mobile device is connected to your cellular network with one radio, and connected to one or two WiFi networks with its WiFi radios. Packets are sent over each network. As one network fades, the congestion protocols figure out that fewer packets should be sent over that network in lieu of the others. Additionally, your network connection doesn’t drop completely.

Well, that’s not entirely correct. With multipath TCP your network connections could be dropping all over the place, but because you have a redundant connection to another network, you never notice it. Your overall throughput is increased and your perceived network stability is almost 100%. It’s a beautiful solution!

Only iOS 7 has it — sort of

Chances are that you’re not going to find multipath TCP in many mobile operating systems today. In addition to being a little complex to implement, it can also be a lot more demanding on your battery. However, Apple has apparently gone ahead and included multipath TCP in iOS 7 — sort of. Siri, Apple’s “personal assistant”, may use multipath TCP when conditions are right.

“You won’t see Multipath TCP for regular TCP connections from applications like Safari,” Olivier Bonaventure, a computer science professor at the IP Networking Lab in Belgium writes, “but if you use SIRI, you might see that the connection with one of the Apple servers runs uses Multipath TCP.”

When you’re asking Siri a question, you want to make sure she (or he, now that iOS 7 lets you have that option) gets the information where it needs to go, and that your answer is delivered back in a timely fashion. Failure to do so makes for a very jarring and disappointing experience, and Apple certainly doesn’t want that.

To address the concern, it looks like Apple enabled multipath TCP to handle inquiries that you ask of Siri — but only Siri. Your web browsing, video watching, email getting, social networking, music listening, gaming, and even FaceTime doesn’t get the same special multipath treatment. I suppose it’s to save precious battery life, but that’s something Apple must have been willing to sacrifice to make your Siri experience a little bit better.

Regardless, we’ve got the equipment in our smartphones and tablets (regardless of OS or manufacturer), it’s time for us to have multipath TCP built-in. If they’re worried about chewing up our batteries, why not leave it turned off by default, but let us turn the feature on if we want?

Sources: Oliver Bonaventure, Department of Computer Science at University College London