In the past, Google has created alternatives to widely used networking protocols such as SPDY in order to deliver search results as fast as possible. Apple is now doing something similar by having Siri use Multipath Transmission Control Protocol (MPTCP). MPTCP is an extension to the TCP protocol that's used for about 85 percent of all Internet traffic. Generally, it allows TCP to operate over multiple paths at the same time. However, Apple seems to use MPTCP for one very specific purpose: to allow Siri to switch between Wi-Fi and 3G or LTE as quickly and seamlessly as possible.
An interesting difference between Google's and Apple's approaches to networking improvements is that Google came up with SPDY first and then went to the Internet Engineering Task Force (IETF) to have SPDY adopted as a standard. 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.
Within the large backbone networks that make up the Internet, there are always multiple paths between A and B. Routing protocols make sure packets follow the "best" path. That works well if you have one really good path and one really bad path, but it's less than ideal if you have two paths that are about the same quality. In that case, pushing all packets through one path and leaving the other idle is a waste of resources. This is where MPTCP comes in: it allows the packets that make up a TCP session to flow over multiple paths at the same time.
In theory, a router could just load balance packets over two or more paths by sending packet 1 over path A, packet 2 over path B, 3 over A, 4 over B, and so on. It turns out that this doesn't work so well, because one path is always a bit faster than the other path, meaning packets will arrive out of order. For instance, if path A is a bit shorter or path B has a bit more traffic, packet 3 may arrive at the receiver before packet 2. If this happens too often, TCP thinks packets were lost because it was transmitting too fast. So it slows down, which is not what we want.
To avoid this, when routers and switches have parallel links (but usually not entire paths), they make sure all the packets belonging to the same TCP session flow over the same link. This works reasonably well when you have a thousand or so TCP sessions, but it's still pretty common to see one link filled up completely while the other has capacity to spare. And it doesn't work at all when you only have one very big TCP session, because that single session can't use more than the capacity of a single link.
MPTCP avoids these issues by having the sending system determine which packets go down which path. It can then measure the properties of each path independently and send more packets over the faster path. This is a key part of MPTCP, because without it, the system would simply send half of its traffic over a 10Mbps path and the other half over a 100Mbps path (the system would impose the limit of the first on the second, splitting the delivery equally for a total of 20Mbps). By dynamically balancing traffic, MPTCP can use the full 110Mbps in this scenario. And if one path stops working, it is smart enough to retransmit any lost packets over another, working path. This part seems to be the thing that Apple is after by having Siri use MPTCP.
Then there's the question of whether all of this is fair. To make sure the network doesn't collapse under a barrage of packets it can't handle, TCP comes with a family of congestion control algorithms. These make sure TCP ramps up its transmission speed relatively slowly and backs off quickly when packets are lost. There can be many reasons why packets get lost, but TCP assumes it's sending too many packets too fast, so the network gets congested. Routers and switches can buffer some packets, but if more packets keep coming in than are transmitted, buffer space runs out and packets are "dropped."
So there's a direct relationship between the percentage of packets that get lost and how fast TCP transmits. This means that all else being equal, two computers that send packets over the same path see the same number of lost packets and thus settle on the same transmission rate. Essentially every sending system gets an equal share of the bandwidth pie—until MPTCP, that is. MPTCP splits a single TCP session into "subflows" and then sends each subflow over a different path. However, there's no guarantee that what a system running MPTCP thinks are multiple paths—basically, different source/destination address pairs—are actually separate, completely non-overlapping paths. Two or more subflows belonging to the same MPTCP session may flow through the same network link. At that point, MPTCP asks for multiple pieces of the bandwidth pie to the detriment of the traditional single-path TCP users. To avoid this, MPTCP uses a modified congestion control algorithm.
Olivier Bonaventure was the first to note that the TCP sessions an iOS 7 device sets up when Siri is used have MPTCP enabled. Bonaventure is a professor at Université Catholique de Louvain (UCL), not to be confused with University College London (UCL)—but coincidentally, both UCLs were involved with the early MPTCP work. (Disclosure: even more coincidentally, I was partially funded by the Trilogy project where all of this took place, and multipath networking is the subject of my PhD work.)
In the comments on Bonaventure's blog post, Kristian Evensen writes that it looks like Siri doesn't actually use MPTCP to send packets over Wi-Fi and 3G/LTE at the same time. Rather, it sets up MPTCP and then continues to communicate over Wi-Fi. If the Wi-Fi network then goes down or stops working, the communication can switch seamlessly from Wi-Fi to 3G or LTE without the need to reconnect, renegotiate a secure connection, and retransmit the audio making up the question to Siri.
Still, that's not really what MPTCP was designed for. If this is what Apple is doing, then it's using MPTCP as a mechanism for mobility. However, Mobile IP (MIP) never gained much traction. And although Mobile IPv6 (MIPv6) is a very clever way to allow a device to keep using its "home" IP address when away from home, MIPv6 obviously requires IPv6. Not many people have IPv6 on their Wi-Fi and cellular networks today.
MPTCP, on the other hand, has been designed with today's packet-mangling firewalls and Network Address Translators in mind. And it seems to be successful, because even though some networks may do strange things to the MPTCP options, Siri appears no worse for attempting some cutting-edge networking.
The interesting side effect of using multiple paths is that this makes it harder for interested third parties to observe your traffic. If the traffic is unencrypted, then someone who can observe the traffic on one path still gets to look at the contents of the packets going down that path. It's slightly worse 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.) To decrypt a CBC block, you also need the previous block. So if someone wants to decrypt your encrypted MPTCP traffic, he or she needs to be able to tap both paths and then spend CPU cycles finding which packets belong to the same MPTCP session. Oh, then they must also break the encryption.
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.
Update: previously, this story incorrectly stated that all previous CBC blocks are needed to decrypt a given CBC block.
reader comments
81