Technical Perspective: Multipath, A New Control Architecture For the Internet

Multipath transmission for the Internet—that is, allowing users to send some of their packets along one path and others along different paths—is an elegant solution still looking for the right problem.

The most obvious benefit of multipath transmission is greater reliability. For example, I’d like my phone to use WiFi when it can, but seamlessly switch to cellular when needed, without disrupting my flow of data. In general, the only way to create a reliable network out of unreliable components is through redundancy, and multipath transmission is an obvious solution.

The second benefit of multipath transmission is that it gives an extra degree of flexibility in sharing the network. Just as packet switching removed the artificial constraints imposed by splitting links into circuits, so too multipath removes the artificial constraints imposed by ‘splitting’ the network’s total capacity into separate links (see the accompanying figure).

Flexibility comes with dangers. By building the Internet with packet switching, we no longer had the control over congestion that circuit switching provides (crude though it may be), and this led in 1988 to Internet congestion collapse. Van Jacobson³ realized there needed to be a new system for controlling congestion, and he had the remarkable insight that it could be achieved by end systems on their own. The Internet has been using his transmission control protocol (TCP) largely unchanged until recently.

The flexibility offered by multipath transport also brings dangers. The claim of the following paper is that, once we do away with the crude control of “each flow may use only one path,” there should be some new control put in place—and, in fact, the proper control can be achieved by end systems on their own. That is to say, if multipath is packet switching 2.0, then it needs TCP 2.0.

Internet congestion collapse in 1988 was a powerful motivator for the quick deployment of Jacobson’s TCP. There is not yet a killer problem for which multipath congestion control is the only good solution. Perhaps we will be unlucky enough to find one. (It has been shown¹ that simple greedy route choice by end users, combined with intelligent routing by network operators, can in theory lead to arbitrarily inefficient outcomes, but this has not been seen in practice.)

Lacking a killer problem, the authors present four vignettes that illustrate the inefficiency and unfairness of a naïve approach to multipath, and that showcase the benefit of clever multipath congestion control.

The niggling problems of naïve approaches to multipath could probably all be mitigated by special-case fixes such as “only use paths whose round trip times are within a factor of two of each other” or “no flow may use more than four paths at a time,” perhaps enforced by deep packet inspection. So, in effect, the authors present a choice between a single clean control architecture for multipath transmission, and a series of special-case fixes.

The naïve approach to multipath, as studied in this paper, is to simply run separate TCP congestion control on each path. The clever alternative is to couple the congestion control on different paths, with the overall effect of shifting traffic away from more-congested paths onto less-congested paths; two research groups^2,4 have independently devised an appropriate form of coupling. This is the approach under exploration in the mptcp working group at the IETF, although with some concessions to graceful coexistence with existing TCP.

The differences between the two sorts of congestion control show up both in the overall throughput of the network, and also in how the network’s capacity is allocated. The authors use the framework of social welfare utility maximization to address both metrics in a unified way. This framework has been mainstream in theoretical research on congestion control for the past decade. But it is not mainstream in systems work, where more intuitive metrics such as average throughput and Jain’s fairness index hold sway, along with views like “Congestion is only a problem at access links, and if I’ve paid for two connections then I ought to be able to use two TCP flows.” These differences in language and culture have meant that the paper’s conclusions have not become systems orthodoxy.

Now that multipath transport protocols are a hot topic in the network systems community, it is a good time to highlight this work, and to translate its conclusions into practical answers about systems such as data centers and multihomed mobile devices. The authors only address congestion control and path selection for an idealized model of moderately long-lived flows. There are still important questions to answer, such as: When is a flow long enough to make it worth opening a new path? When is a path so bad it should be closed?

Back to Top

Back to Top

Back to Top

Back to Top

Back to top