Tutorial: Multipath Support in IP NetworksAndreas Konsgen, Amanpreet Singh, Carmelita Goerg

Communication Networks Working GroupCentre for Information and Communication Technology

University of Bremen, Bremen, GermanyEmail: {ajk,aps,cg}@comnets.uni-bremen.de

Abstract—Networked devices are often equipped with multipleinterfaces. Legacy routing and transport protocols only supportthe transport of data over a single interface resp. paths. Thistutorial discusses extensions for IP and TCP in order to supportmultiple interfaces. Multihoming and mobility management allowthe simultaneous usage of interfaces by independent applicationdata flows, while multipath transport also supports the transferof a single flow over multiple interfaces by splitting the flowat the sender and reassembling it at the receiver. In order toperform this task, extensions of the protocol stack and signallingare required which are discussed in recent drafts at the IETF.

I. INTRODUCTION

Nowadays, wireless devices are often equipped with multi-ple interfaces such as fixed network, wireless LAN, UMTS,WiMAX, Bluetooth and so on. Theoretically, it is possibleto transport data simultaneously over more than one interfacein order to increase the transfer speed. In practice, however,legacy transport protocols such as TCP only support a singleend-to-end connection over one interface.

The first step to overcome this problem is to send differentflows over different interfaces; for example, a VoIP phonecall is routed over the UMTS interface which provides awide coverage; for the download of bulk data, the WLANinterface is used. The download of the file is started or resumedwhenever WLAN coverage is available. Recent developmentsin the Internet Engineering Task Force (IETF) try to tacklethe problem of multiple interfaces in IP networks. As the firstattempt [1] investigates the usage of multiple interfaces resp.connections for fixed IPv4 networks. In [2], multihoming forfixed and mobile networks is described for Mobile IPv6 [3]and Network Mobility (NEMO) [4]. The MIPv6 protocol isextended by assigning a care-of address to multiple interfacesattached to a device while an interface is connected to a foreignnetwork [5].

II. MULTIPATH TRANSPORT OF APPLICATION DATASTREAMS

In the IP mobility approaches, multiple paths are usedto transfer independent data flows over multiple interfacessimultaneously. The next step is to transport a single datastream over multiple interfaces which is apparently morecomplex than the previous one. The reason is that the flow hasto be split into multiple subflows which are then transferredover the different interfaces. Each subflow contains a subsetof the packets which form the data stream. At the receiving

station, these subflows have again to be reassembled beforebeing handed over to the application.

Current research is focused on Multipath TCP (MPTCP)which is a set of extensions for TCP that allows spreadingof a single TCP flow across multiple Internet paths. Eachsubflow looks to the network as a normal TCP flow, with theonly difference that it carries new multipath TCP signalling.Multipath TCP signalling is used to declare MPTCP support,exchange alternate addresses and other control messages. TheMPTCP proposal uses a dual sequence number space: Eachsubflow has its own sequence space that identifies bytes withina subflow as if it were running alone. There is also a data(or connection level) sequence space, which allows reorderingat the (aggregated) connection level. Each segment carriesboth subflow and data sequence numbers. Retransmissions aredriven only by the subflow sequence number; hence MPTCPavoids problems due to connection level reordering of packets.In MPTCP, congestion control is coupled across paths, so as toensure fairness without needing to detect shared bottlenecks.Flow control is performed in aggregate, but not on individualsubflows.

The challenge to be met is that the different links over whichthe subflows are transported may have different throughputsand delays, so the arrival order of the packets at the receiver isunpredictable which requires an additional buffer which keepsthe packets of all subflows for reordering. This buffer must beplaced on top of the TCP stacks which handle the individualsubflows. In addition, when setting up a connection, signallingis needed to identify if both ends of the communication supportmultiple interfaces.

The enhancements which should be achieved when deploy-ing multipath transport are [6]:

• Improve Throughput: Multipath TCP must support theconcurrent use of multiple paths to increase the efficiencyof the resource usage, and thus increase the networkcapacity available to end hosts.

• Improve Resilience: Multipath TCP must support the useof multiple paths interchangeably by permitting packetsto be sent and re-sent on any available path.

• Balance congestion: A multipath flow should move asmuch traffic as possible off its most congested paths,subject to meeting the first two goals.

Multipath TCP must be transparent in three different as-pects:

978-1-4244-8551-2/10/$26.00 c©2010 IEEE ICIAfS10

37

• Application Compatibility: Multipath TCP should becompatible with existing TCP APIs and follow the in-order, reliable and byte-oriented delivery service modelof TCP. No change of existing applications should berequired. However, a special API should be provided formultipath-enabled applications.

• Network Compatibility: Multipath TCP should be com-patible with the Internet as it exists today. It should forexample be able to traverse middleboxes such as firewallswhich may filter packets, NAT-enabled routers whichchange the addresses and/or ports, and proxies whichseparate the internet from the intranet by opening anindependent connection to the internet when they receivea connection request from the intranet.

• Compatibility with other Network Users: Multipath TCPshould do no harm to legacy connections. It shouldsupport fair behaviour when resources such as a capacity-limited line must be shared and coexist with legacy TCPflows.

MPTCP operations need additional signalling information inthe TCP segments, either in the TCP options field or payload.

• The sender/receiver/middleboxes must negotiate multi-path capability.

• When an additional interface is available, the other end-point needs to be notified about this fact.

• For the setup of additional subflows, it must be identifiedto which connection the additional subflow belongs to.

• A connection-level data sequence number is added tokeep in-order delivery over the multiple subflows.

• A data acknowledgement is utilized to record connection-level accumulative acknowledgement.

• A data FIN is used to terminate the whole MPTCPconnection.

The beforementioned topic of multipath TCP transmissionis currently under investigation at the IETF where differentsolutions recently have been published as drafts: MultipathTCP (MPTCP)1 [7], [8], Multiple Connection TCP (MCTCP)[9] and Payload Multi-connection Transport (PLMT) [10]. Thesolutions differ both in the signalling as well as in the structureof the protocol stack.

• In MPTCP, each multipath TCP subflow looks to thenetwork as a normal TCP flow, with the only differencethat it carries new TCP options for MPTCP signalling. Itis a kernel-based solution where the existing TCP stackis modified.

• PLMT encodes all the signalling information in thepayload of TCP connections. It operates as an additionalprotocol layer on top of existing TCP. No changes in ex-isting TCP stacks are required. The initiation and controlof multipath operation is performed via a separate controlconnection to a well-known port. It can be realizedentirely in the user-space of an operating system, whichis easier to implement than a kernel-based solution.

1In this context, MPTCP is the name of one multipath TCP solution, notof the general multipath concept.

• MCTCP is a hybrid variant that encodes control in-formation, as far as possible, in the payload of theTCP connections. It uses the TCP option field for theconnection setup messages (SYN/ACK for MPCapabilityand Join messages) It is transparent in the single-pathcase.

The connection-specific information is held in a new struc-ture at the connection-level, called meta-socket. The mastersocket is a special socket as it is the only connection to theapplication. Data arriving on the subflows is serviced by themaster and slave sockets (checking for in-order, in windowsequence numbers, etc.), and passed to the meta-socket onceit is in order at subflow level.

III. CONCLUSIONS

MPTCP solutions adhere to the requirement goals of themultipath TCP architecture. They increase the throughput, aremore resilient and move congestion away from the congestedpaths. They offer reliable, in-order transport being transparentto applications.

There are different proposed multipath TCP solutions withinthe MPTCP WG which span different design choices (option,payload and hybrid) for exchange of multipath signallinginformation. They have different mechanisms for multipathinitiation PLMT comes around as the easiest solution for de-ployment and testing along with the possibility of extensions.

The number of subflows which can be opened for a MPTCPflow and its dependence on different transmission parameterssuch as throughput and delay needs to be further investigated.Furthermore, the criteria when to close an under performingsubflow needs to be further investigated. With respect tomultipath-aware applications, specific APIs to control thesetup and operation of a multipath TCP connection need tobe developed.

REFERENCES

[1] J. Abley et al., “RFC 4116: IPv4 Multihoming Practices and Limita-tions,” IETF, 2005.

[2] K. Nagami et al., “RFC 4908: Multihoming for Small-Scale FixedNetworks Using Mobile IP and Network Mobility (NEMO),” IETF,2007.

[3] D. Johson, C. Perkins, and J. Arkko, “RFC 3775: Mobility Support inIPv6,” IETF, 2004.

[4] V. Devarapalli et al., “RFC 3963: Network Mobility (NEMO) BasicSupport Protocol,” IETF, 2005.

[5] R. Wakikawa et al., “RFC 5648: Multiple Care-of Addresses Registra-tion,” IETF, 2009.

[6] A. Ford, C. Raiciu, S. Barre, and J. Iyengar, “Architectural Guidelinesfor Multipath TCP Development,” IETF, June 2010, draft-ietf-mptcp-architecture-01 (work in progress) (work in progress).

[7] C. Raiciu, M. Handley, and D. Wischik, “Coupled Multipath-AwareCongestion Control,” IETF, July 2010, draft-ietf-mptcp-congestion-00(work in progress).

[8] A. Ford, C. Raiciu, and M. Handley, “TCP Extensions for MultipathOperation with Multiple Addresses,” IETF, June 2010, draft-ietf-mptcp-multiaddressed-00 (work in progress).

[9] M. Scharf, “Multi-Connection TCP (MCTCP) Transport,” IETF, July2010, draft-scharf-mptcp-mctcp-01 (work in progress).

[10] A. Singh and M. Scharf, “PayLoad Multi-connection Transport usingMultiple Addresses,” IETF, August 2010, draft-singh-mptcp-plmt-00(work in progress).

38