Multipath TCP
The Transmission Control Protocol (TCP) is a core protocol of the Internet networking protocol suite.
This protocol transforms the underlying unreliable datagram delivery service provided by the IP
protocol into a reliable data stream protocol. This protocol was undoubtedly the single greatest
transformative moment in the evolution of computer networks.
Prior to TCP computer network protocols assumed that computers wanted a lossless reliable service
from the network, and worked hard to provide it. DDCMP in DECnet was a lossless data link control
protocol. X.25 in the telesaur world provided reliable stream services to the attached computers.
Indeed, I recall that Ethernet was criticized when it was introduced to the world because of its lack of a
reliable acknowledgement mechanism. TCP changed all of that. TCP pushed all of the critical
functionality supporting reliable data transmission right out of the network and into the shared state of
the computers at each end of the TCP conversation. TCP embodies the end-to-end principle of the
Internet architecture, where there is no benefit in replicating within the network functionality that can
be provided by the end points of a conversation. What TCP required of the network was a far simpler
service where packets were allowed to be delivered out of order, but packets could be dropped and
TCP would detect and repair the problem and deliver to the far end application precisely the same bit
stream that was passed into the TCP socket in the first place.
The TCP protocol is now some 40 years old, but that doesn’t mean that it has been frozen over all
these years.
TCP is not only a reliable data stream protocol, but also a protocol that uses adaptive rate control. TCP
can operate in a mode that allows the protocol to push as much data through the network as it can. A
common mode of operation is for an individual TCP session to constantly probe into the to see what
the highest sustainable data rate is, interpreting packet loss as the signal to drop the sending rate and
resume the probing. This aspect of TCP has been a constant field of study, and much work has been
done in the area of flow control and we now have many variants of TCP that attempt to optimize the
flow rates across various forms of networks.
Other work has looked at the TCP data acknowledgement process, attempting to improve the
efficiency of the algorithm under a broad diversity of conditions. SACK allowed a receiver to send back
more information to the sender in response to missing data. FACK addresses data loss issues during
slow start.
One approach to trying to improve the relative outcome of a data transfer, as compared to other
simultaneously open TCP sessions, is to split the data into multiple parts and send each part in its own
TCP session. Effectively opening up a number of parallel TCP sessions. A variant of TCP, MulTCP,
emulates the behavior of multiple parallel TCP sessions in a single TCP session. These behaviours
assume the same endpoints for the parallel TCP sessions and assume the same end-to end path through
the network. An evolution of TCP that uses multiple parallel sessions, but tries to spread these sessions
across multiple paths through the network, is Mutipath TCP.
Multipath TCP had a brief moment of prominence when it was revealed that Apple's release of iOS 7
contained an implementation of Multipath TCP for their Siri application, but it has the potential play a
bigger role in the mobile Internet. In this article I would like to explore this TCP option in a little more
detail, and see how it works and how it may prove to be useful in today’s mobile networks.
Multi-