technical Perspective
multipath: a new control
architecture for the internet
By Damon Wischik

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 Jacobson3 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

if flows have access to multiple paths, then spikes in traffic on one link can make use of spare capacity on other links.

 

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 shown1 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 groups2, 4 have in-
dependently devised an appropriate
form of coupling. This is the approach
under exploration in the mptcp work-
ing group at the IETF, although with
some concessions to graceful coexis-
tence with existing TCP.

References

1. Acemoglu, D., Johari, R. and Ozdaglar, A.E. Partially optimal routing. IEEE Journal of Selected Areas in Communication 25 (2007), 1148–1160.

2. Han, H., Shakkottai, S., Hollot, C.V., Srikant, R. and Towsley, D. F. Multi-path TCP: A joint congestion control and routing scheme to exploit path diversity in the Internet. IEEE/ACM Transactions on Networking 16 (2006), 1260–1271.

3. Jacobson, V. Congestion avoidance and control. In Proceedings of SIGCOMM 1988 Conference.

4. Kelly, F.P. and Voice, T. Stability of end-to-end algorithms
for joint routing and rate control. ACM/SIGCOMM
Computer Communication Review 35 (2005), 5–12.

Damon Wischik ( [e-mail]) is a Royal Society university research fellow in the Networks Research Group in the Department of Computer Science at University College London.