Multipath Congestion Control for Shared Bottleneck Michio Honda * , Yoshifumi Nishida * , Lars Eggert † , Pasi Sarolahti † , Hideyuki Tokuda *‡ Keio University * , Nokia Research Center † , JST-CREST ‡ {micchie,nishida}@sfc.wide.ad.jp, {lars.eggert,pasi.sarolahti}@nokia.com, hxt@ht.sfc.keio.ac.jp ABSTRACT Multipath transport protocols, which transmit data over multiple distinct paths in an end-to-end connection are in- troduced. However, they have a problem in terms of fairness. When the transmissions along several paths share the same bottleneck link, the multipath connection receives higher throughput than a competing regular TCP flow, because it executes congestion control per path with the same algo- rithm as TCP. We investigate a congestion control scheme that addresses this problem with the weighted congestion control approach. In our scheme, an end-to-end connection that uses flows along multiple paths can fairly compete with TCP flows at the shared bottleneck. Our scheme also maxi- mizes the utilization of different path characteristics, such as bandwidth capacity and RTT. Our simulation results show that a bundle of multiple flows based on our scheme fairly competes with TCP flows at the shared bottleneck. 1. INTRODUCTION In 2006, P2P traffic was 37%, and HTTP traffic contain- ing video and audio (e.g., YouTube) was 19% of the total Internet traffic [22]. These applications require high band- width allocations for a long time. TCP traffic still comprises a major share of the total Internet traffic [13]. Hence, we assume that high-speed and long-lived TCP connections are becoming more frequent. Such TCP connections remain in the congestion-avoidance phase, and hence compete against each other at the shared bottlenecks. This means that users or applications require more network capacity. Simultaneous multipath utilization is a promising way in which end hosts can increase available network capacity. As the market for networking technology is evolving, it is be- coming more common that the end hosts are equipped with multiple network interfaces (e.g., WLAN, GPRS and 3G). They have multiple links connected to the Internet, which results in availability of multiple paths between a source and a destination end host. Such multi-homed hosts can use more available network capacity if they aggregate the available bandwidth of multiple paths. We assume that transport protocols will have capabilities to utilize multiple paths simultaneously between a source and a destination host. We call the entity over which ap- plications communicate a multipath connection. For ex- ample, a multipath connection looks like a TCP connection to the application and provides a reliable and ordered byte stream. The endpoint of the multipath connection stripes user data across multiple distinct paths, using one subflow along each path. Figure 1: Unfair share at the shared bottleneck Current connection-oriented transport protocols (e.g., TCP, SCTP and DCCP) transmit data only over a single path be- tween a source and a destination hosts at any given time. Although SCTP supports multi-homing, standard SCTP does not transmit data over multiple paths simultaneously. Several proposals extend transport protocols to simultane- ously utilize multiple paths [11, 24, 20, 12], achieving higher throughput than the base protocols. However, multipath connections of these extensions are not compatible with TCP friendliness, which are overly ag- gressive at the shared bottleneck, because each subflow in- dependently performs congestion control with an algorithm similar to TCP. When N subflows in a multipath connection compete against TCP flows at the same bottleneck, the mul- tipath connection is approximately N times as aggressive as each of the TCP flows. In Fig. 1, one multipath connec- tion that contains N subflows competes with M background TCP flows at the shared bottleneck between two intermedi- ate nodes I1 and I2. While each of background flows receives a1/(N + M ) share of the bottleneck, a bundle of N subflows receives a N /(N + M ) share. In Internet congestion control, a congestion-controlled flow between two transport endpoints (e.g., a single TCP connec- tion) uses a single flowshare [16], which equally shares the bottleneck bandwidth with each other. N flowshares receive throughput N times a single flowshare at the same bottle- neck, which are called multiple flowshares [16]. Multiple flowshares are mainly utilized to achieve weighted propor- tional fairness [6] between aggregation points that bundle multiple flows transmitted by multiple users. For example, distributed-multimedia applications [15] and wireless TCP proxies [5] use aggregation points. Some applications lever- age parallel TCP connections between the same hosts to ob- tain more bandwidth or avoid head-of-line blocking. Such use of multiple TCP connections is unfair to the other traffic sharing the path. Congestion control of these connections