Designing a Resource Pooling Transport Protocol Michio Honda * Keio University micchie@sfc.keio.ac.jp Elena Balandina Nokia Research Center elena.balandina@nokia.com Pasi Sarolahti Nokia Research Center pasi.sarolahti@nokia.com Lars Eggert Nokia Research Center lars.eggert@nokia.com Abstract— This paper presents a design for an end-to- end transport protocol for multi-homed end systems that pools the communication resources of multiple network paths to support a single communication session. This approach offers improved performance and resilience compared to communicating over a single path. Compared to previous efforts, deployability in the current commercial Internet, i.e., in the presence of middleboxes, filtering and restricted connectivity, was a key driver for the design of the Resource Pooling Protocol (RPP). I. I NTRODUCTION Efficient, lightweight and scalable allocation of net- work resources is among the key requirement for a future Internet. Resource pooling [1] has recently been proposed as a principle by which an end-to-end transport architecture can simultaneously utilize multiple, distinct paths between two communicating end systems in a way that will result in improved resource allocation. The theoretical foundation for resource pooling was laid in earlier work by others, including [2]–[4], and has demonstrated significant performance and reliability improvements for end systems, as well as significant traffic engineering benefits for the network. For end systems, these benefits derive from the ability to pool the bandwidth and reliability offered by all their network interfaces to support each individual end-to-end path, compared to using only the network resources along a single path for each. For the network, the benefit comes from a much finer-grained traffic engineering control loop, which executes at timescales of network round-trips and operates at the flow level, compared to traditional traffic engineering mechanisms that operate on longer timescales and on coarser traffic aggregates. The majority of bytes on the Internet are being trans- mitted over TCP. Compared to about ten years ago, the fraction of longer-lived TCP flows has been increasing, likely fueled by the widespread use of video streaming * Michio Honda was as an intern at Nokia Research Center in Finland during most of the duration of this research effort. and peer-to-peer file sharing [5], [6]. This development is important, because the resource allocation provided by TCP’s congestion control only becomes fully effec- tive for connections that reach steady-state, which short connections rarely do. It also illustrates that a resource pooling protocol should be designed as a TCP extension that is transparent to applications and the network, if it is to have any chance at deployment. Hence, an RPP connection exposes the same communication primitive and API to applications as TCP, and its transmissions look like a set of TCP connections to the network. During the same ten years, more and more end systems have shipped with multiple network interfaces. Most notebooks ship at least with Ethernet and WLAN interfaces, and many handhelds and mobile phones offer several different wireless interfaces, such as WLAN and 3G. This means that a significant fraction of current end systems already has the necessary equipment to benefit from resource pooling transport protocols. This paper is by no means the first to describe a trans- port protocol based on multipath transmission. pTCP [7], mTCP [8], cTCP [9], AMS [10] and MPLOT [11], among others, extend TCP for multipath communication, and CMT [12] extends SCTP. The design of RPP pre- sented in this paper has many of the same mechanisms explored in these earlier designs. The key difference is that the design of RPP is driven by the deployment necessities of today’s commercial Internet, i.e., the pres- ence of middleboxes, filtering and otherwise restricted connectivity. The design is also as minimal as possible, in order to be tractable for eventual IETF standardization. This paper discusses these design requirements and presents the rationale behind the key features of RPP. Due to space constraints, companion papers will describe the prototype implementations of RPP under develop- ment and present an experimental evaluation of RPP. II. DESIGN OVERVIEW The design of RPP was driven by the desire for widespread deployability. This section discusses the de-