Boosting DSL Speed with Multipath TCP

Transcription

1 Boosting DSL Speed with Multipath TCP R. Tjeerdsma Faculty of Electrical Engineering, Mathematics and Computer Science University of Twente, the Netherlands ABSTRACT Multipath TCP (MPTCP) is a newly developed protocol that enhances TCP s capability to handle multiple communication channels simultaneously. So far, well-explored applications of MPTCP are mainly found in the wireless- and datacentre sector. This paper proposes a new application for MPTCP; to speed up domestic DSL connections. It investigates the possibilities of using MPTCP as a proxy to bond the speeds of multiple separate DSL lines and measures the stability and quality of the resultant bonded connection. The proposed MPTCP solution turns out to bond DSL connections with an efficiency of 98% at the cost of a two times higher latency. Keywords Rural, Internet, Multipath, TCP, Bonding, Bandwidth, Speed,, Combining, Aggregation, DSL, VPN, Domestic 1. INTRODUCTION Fibre-companies all over the world are rushing to deploy their fibre-networks. Fibre is generally deployed in a town-by-town fashion. Because of the commercial background of most fibrecompanies, they tend to prioritize installing fibre in as densely populated areas as possible. This minimizes the investments needed and thus reduces the overall taken risk. The same holds for cable networks. Consequently, residents in rural, less dense, areas often still rely on the older copper telephone-network to access the internet. Internet speeds are starting to become insufficient for the current demands of society. DSL is already a very developed technology, and new innovations such as G.Fast and XG.Fast are mainly focused on short-distance improvements [1]. With the long deployment time for Next Generation Networks (NGN) in prospect, the interests in increasing the possibilities with the existing copper infrastructure raised higher than ever. From a broadband perspective, we can distinct the existence of three different categories when looking at the broadband penetration in a certain environment. These categories are defined by the European Commission as white, grey and black broadband areas [7]. White areas have no broadband connection, grey areas have only one type of connection and black areas have choice out of multiple sorts of internet connections. The technique described in this paper is mainly applicable to residents living in grey areas. In these areas, often only DSL internet connections via copper are available. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. 23 th Twente Student Conference on IT, June 22 st, 2015, Enschede, The Netherlands. Copyright 2015, University of Twente, Faculty of Electrical Engineering, Mathematics and Computer Science. 1 Because of the availability of a set of two copper pairs in almost all of the copper-connected households in the Netherlands [17] and the far developed techniques on single-copper pair basis, it is especially interesting to research the possibilities for combining the available copper pairs. This is where MPTCP might become relevant. Multipath TCP (MPTCP) is a relatively new technique, first published as an experimental standard in January 2013 [8]. It only recently got its first widespread implementation by Apple who uses the standard for reliably sending Siri s data to its servers [2] This demonstrates one of the current main use cases of MPTCP. It is often used as a technique that enhances the mobility of a wireless client. e.g. it is used to increase overall throughput, accomplish seamless roaming [5] [15] [19] or to safe energy on mobile devices [12] [16] [21]. Other applications are mainly found in datacentres [6] [18] [20]. In this paper, Multipath TCP is used to combine multiple DSL copper pairs and associated DSL lines to obtain a higher accumulated end-speed for the internet subscriber. In order to achieve this result, all TCP-packets, both incoming and outgoing, are relayed via an offsite MPTCP host that is connected to the internet via a fat pipe. A major advantage of MPTCP is it s high-levelness. Because MPTCP operates in the transport layer, the end-user is in control. Collaboration with an ISP is not necessary to successfully implement an MPTCP bond. This greatly simplifies the deployment of the multipath bonding technique on a larger scale. The contribution of this paper is the development of a novel use case and corresponding implementation of a MPTCP-relay which boosts the speed of a residents DSL-connection. The MPTCP-relay implementation s efficiency is measured and influence of external factors such as delay and packet loss are quantified to give a measure for the quality of the implemented solution. 2. STATE OF ART Current widely used protocols for combining multiple internet connections using a bonding technique include LACP and MPPP [9]. Both of these protocols share one important common property; they perform bonding in the link-layer. Because link-layer bonding operates on flow-level, throughput will only increase in a situation with multiple flows. This is because flows are assigned to interfaces when they initiate. All subsequent packages will be sent over this same link to avoid packages of getting out of order. Apart from a gain in overall aggregated throughput, these implementations often also provide failover and backup-functionality. Whereas these multi-flow optimized may perform good in larger (business) networks, most traffic in domestic networks is based on single flows. The MPTCP solution proposed in this paper will be able to load-balance at packet-level, thus optimally utilizing the bandwidth provided by the available connections whilst maintaining fail-over and backup functionality.

2 Solutions with a similar setup that use a relay or proxy to aggregate the users data often focus on one-way traffic or streaming [23]. Per definition, the main focus of these solutions is on UDP traffic, whereas the majority of internet-traffic, especially that of domestic internet traffic, is TCP-based [13]. Many solutions require significant alternation of all nodes involved in the bonded connection. In an ideal situation MPTCP would also profit from a situation in which it is implemented widely. If all hosts on the internet support MPTCP, the step of rerouting traffic via a relay host would become superfluous, which in term could drastically reduce overhead. In a real world setting however, not all associated nodes will be able to accept MPTCP on short term. This paper provides a solution for this matter by using a relay-based setup to circumvent the requirement for all nodes to support MPTCP. 3. DESIGN AND IMPLEMENTATION In this paper, a MPTCP driven solution for combining internet connections is presented. In this section the methodology and result will be presented. 3.1 Design MPTCP is implemented on a router that is connected to a LAN. The router is also attached to a number of separate DSL connections. Via these connections, the router contacts the MPTCP relay that is located elsewhere, e.g. in a datacentre, and has access to a fast uplink (fat pipe) to the internet. The connections between the router and relay are MPTCPconnections. The connections from the relay to the internet are normal TCP connections to guarantee compatibility with all non-mptcp-capable servers on the internet. 3.2 MPTCP Router Hardware For the MPTCP router, the author has chosen to use an OpenWRT capable router. OpenWRT is especially suitable because an experimental version that supports MPTCP is available [11]. A well-developed MPTCP-capable kernel available for Linux distributions, but for the intended goal, the form factor of a router is very suitable. It supports the necessary network interfaces and is easily integrated in home networks. The kernel and firmware for the router have been adjusted to support the VPN-Tunnel setup via MPTCP and both were then flashed on the router Tunnelling data In order to transfer a normal TCP-connection over the two available channels using MPTCP, all data that comes from the LAN and that is normally either send directly to the internet via one of both WAN-channels or load balanced between them is captured. The captured data is then redirected to the relay via MPTCP. The most commonly applied method for redirecting the data of entire LAN s to another point on the internet is by using a VPN. For this research, OpenVPN was used in combination with OpenWRT s TUN-Module for setting up a tunnel between the relay and the router. OpenVPN was custom configured to use a virtual tunnel-endpoint which consists of a MPTCP-interface that spans both available internet connections. An additional gain in speed could be made here by enabling Lempel Ziv Oberhumer real-time lossless compression [14] on both ends of the tunnel. This way, the amount of actual data that has to travel over the two slower multipath channels is reduced and the overall aggregated speed of the setup increases even more. After compression, the MPTCP implementation in the custom kernel injects the MPTCP options in the TCP packet [4] and then sets up a bonded connection with the relay Splitting with MPTCP The routing tables in the router are populated with the correct static routes to the relay for each connection. MPTCP subsequently manages multiple subflows by maintaining a master window at each of sender and receiver, and additional windows for each subflow. Its congestion control algorithm links master windows with sub- flow windows to provide congestion control across multiple paths while it keeps respecting all TCP-fairness mechanisms across all bottleneck links and gracefully handles re-ordering [3]. 3.3 MPTCP Relay Hardware The MPTCP Relay was chosen to be the same router as used on the domestic-side of the setup. It was pre-configured in an equal manner with the same modified kernel and custom build of OpenVPN Merging and redirecting The main task of the relay is to perform the merging part of the MPTCP algorithm. The packages from the two different links (with different IP addresses) are combined, reordered, decompressed and then send to the internet via the fat pipe available at the relay. Returning packets are back-routed via the MPTCP link to the router. Network Address Translation is therefore also to be executed on the relay-side of the tunnel in order to maintain the possibility for the MPTCP-accelerated network to be accessible from the internet. 4. EVALUATION Measurements were taken and evaluated in a lab-setup. The efficiency of a 2-channel MPTCP setup was subsequently verified in a real-world setup. In both setups, the compression on the OpenVPN tunnel was disabled to make sure that measurements indicate the performance of MPTCP and not that of LZO. The LZO-compression can very effectively compress synthetic data and would therefore influence the outcome of the performance tests too much. 4.1 Lab-setup In the lab setup, two TP-Link WDR3600 routers were used. These are based on the MIPS 74Kc architecture, have 5 gigabit ethernet ports that are individually configurable and contain a 560 Mhz CPU together with 128 MB RAM. measurements in this section are taken with the use of iperf [22]. The average throughput that was measured by sending iperf TCP flows between the router and relay for 60 seconds. This is used as general metric in the following sections. The router that serves the role of relay is connected to the internet and with two CAT-5-cables to the router that serves as MPTCP client router. Both links between the routers are therefore, if not altered by the traffic shaper, 100 Mbit/s links. Figure 1 - MPTCP Lab Setup 2

3 in Mbit/s in Mbit/s Figure 2 - Implementation of MPTCP solution Influence of packet loss In order to measure the influence of package loss on the MPTCP setup, a traffic shaper in the form of a WAN emulator was inserted in one of the links of the MPTCP setup. WanEM [10] was used to simulate variable packet loss. The WanEM device was transparently inserted in one of the two connections between client and host MPTCP-router. For measuring the influence of packet loss, WanEM was configured to drop a percentage of the total number of passing packets. The results are displayed in Figure 3. Measurements have been taken in a range from 1,00e -8 till 1,00e -2. If the percentage of dropped packets was increased above 1,00e -2, the traditional TCP connection ceased to work. From the results, it can be seen that Multipath TCP managed to maintain a stable connection at nearly the speed of the one remaining channel whereas the traditional TCP-connection s speed diminishes quickly as loss increases. This occurs due to increasing retransmissions Influence of packet delay In order to measure the influence of various delays in the traffic that the MPTCP solution has to handle, we configured WanEM to delay all packets on the line with an increasing number of milliseconds. The taken measurements started with no added delay, and stopped at 120ms of added delay at which the throughput for both traditional- and multipath TCP remained stable. The results are presented in Figure 4. It can be seen that Traditional TCP s throughput is not affected by the added delay whereas the throughput of MPTCP is. The drop in throughput in the MPTCP setup is caused by the three TCP-windows that MPTCP has to maintain. One general window and one for each link that the router has to maintain and update. If the RTT grows, windows are altered more, thus more retransmissions have to be send which leads to the measured drop in speed. In the appendix, the measured values used for both sections and can be found Packet loss probability Multipath TCP Traditional TCP Figure 3 Effective throughput of the MPTCP solution in relation to chance on packet loss, measured in lab-setup Multipath TCP Traditional TCP Delay in ms Figure 4 - Effective throughput of the MPTCP solution in relation to the added delay in ms, measured in lab-setup. 3

4 4.1.3 Efficiency of 2-channel MPTCP-setup In order to measure the efficiency of the MPTCP setup, we first sent iperf TCP flows over the first separate line between client and host. We repeated this process for the second line and then lastly sent the flows through the MPTCP bonded connection. Setup 1 st channel 2 nd channel 1 st channel only 2 nd channel only MPTCP : Both channels Table 1 - Measurements Lab-Setup Download Upload Latency 98 Mbps 94 Mbps 1 ms 96 Mbps 95 Mbps 1 ms 96 Mbps 94 Mbps 2 ms 94 Mbps 94 Mbps 2 ms 189 Mbps 184 Mbps 2 ms The measurements show that MPTCP bonds the two 100 Mbps links to a stable 189 Mbps link in both up- and download directions. It increased the speed of a single link with 189%. The overhead created by the MPTCP setup is less than 3% in both up- and download direction. 4.2 Real World setup In the real world setup, the same TP-Link WDR3600 routers were tested in a domestic environment with two DSL lines. Compared were throughput in a traditional setting, where only one DSL line was directly connected to the domestic LAN, an intermediate setting where one DSL line was connected to the TP-Link MPTCP client router and then to the domestic LAN and finally a setup as intended; two DSL-lines connected to the LAN via the MPTCP client router. The two available DSL connections bandwidth were specified as up to 20 Mbit/s by two separate ISP s (Online.nl and Telfort). The distance to the local DSL exchange from the test-location is approximately 3500 metres. Measurements were taken with iperf. The results of the measurements are shown in Table 1. The average throughput was measured by sending 1 minute long iperf TCP flows between the client router and relay router. Setup Table 2 - Measurements Real World setup 1 line Telfort 1 line Online 1 line Telfort 1 line Online MPTCP : 2 lines Download Upload Latency 6.87 Mbps 0.83 Mbps 15 ms 9.35 Mbps 0.73 Mbps 15 ms 6.53 Mbps 0.79 Mbps 32 ms 8.69 Mbps 0.70 Mbps 29 ms Mbps 1.45 Mbps 30 ms Figure 5 - Diagram of real-world setup The measurements show that the bonded connection in a realworld setup uses 98% of the total available capacity of both lines. When compared to the average line speed of 8,11 Mbps, an increase of 196% is realized without using LZOcompression. The measurements also show that the latency doubles when traffic is routed via the MPTCP setup. This is expected behaviour because the traffic has to travel further before it can actually enter the internet. This also occurs on the return path. The distance between the MPTCP router and it s corresponding offsite location is an important factor in reducing the latency. Latency will always be higher when compared to a traditional setup. 30ms however is still a very acceptable latency for the majority of internet applications. 5. FUTURE WORK This research mainly focused on the use of Multipath TCP for bonding domestic DSL lines. As a consequence, the research is mainly oriented on TCP traffic. No measurements have been taken with UDP traffic and the implementation does not describe what to do with non-tcp traffic. Future research is necessary to determine the best way to deal with such traffic. The efficiency gained when using LZO-compression is briefly mentioned in this paper but is not thoroughly supported or measured. It is not trivial to measure the gain provided by LZO because most measurement-methods use synthetic data that is not a good representation for normal internet traffic. Synthetic data is easier to compress and thus tends to yield better results in tests. Finally, influence of environmental parameters such as the amount of channels or the equality of the channels that are being bonded on the overall efficiency of the solution needs further research. 6. CONCLUSION In this paper, a new use case for Multipath TCP is presented. Multipath TCP has proven to have the right properties for serving as a bonding-technique for domestic DSL users. It is able to bond on a lower level then existing solutions and thus provides bonded speeds even when there is only one TCP flow. Other techniques often need multiple flows to become effective. The research has also shown that it is possible to implement an efficient bonding algorithm to boost DSL connections using Multipath TCP. With a measured efficiency of 98% in both lab- and real-life environments and proven compatibility with packet-loss and packet delay, the solution meets all expectations. The aggregated speed of a DSL connection with two channels is doubled. Latency of the connection does increase with a factor 2 when using the MPTCP relay, but remains within acceptable boundaries. Future research is to be done to determine the best way to handle non-tcp packets and to quantify the positive influence of LZO-compression on the MPTCP VPN connection. Lastly, the influence of environmental parameters (e.g. number of channels, equality of channels) could be further researched. 4

5 7. REFERENCES [1] Alcatel-Lucent. (2014, July 9). Alcatel-Lucent sets new world record broadband speed of 10 Gbps for transmission of data over traditional copper telephone lines. Visited on March 15, 2015, at lucent-sets-new-world-record-broadband-speed-10- gbps-transmission-data-over-traditional [2] Apple. (2015, February 3). Multipath TCP Support in ios 7. Visited on March 15, 2015 at [3] Boccassi, L., Fayed, M. M., & Marina, M. K. (2013). Binder: A System to Aggregate Multiple Internet Gateways. ACM Digital Library. [4] Bonaventure, O. (2013, March). Decoupling TCP from IP with Mulitpath TCP. Visited on June 1, 2015, at [5] Chen, Y.-C., Lim, Y.-s., Gibbens, R. J., Nahum, E. M., Khalili, R., & Towsley, D. (2013). A measurement-based study of MultiPath TCP performance over wireless networks. Proceedings of the 2013 conference on Internet measurement conference. New York, USA. [6] Datal, G., Paasch, C., van der Linden, S., Mérindol, P., Avoine, G., & Bonaventure, O. (2013). Revisiting Flow-Based Load Balancing: Stateless Path Selection in Data Center Networks. In Computer Networks (pp ). [7] European Commission. (2013). EU Guidelines for the application of State aid rules in relation to the rapid deployment of broadband networks. [8] Ford, et. al. (2013). TCP Extensions for Multipath Operation with Multiple Addresses., IETF RFC 6824 [9] Sklower, et. al. (1990). The PPP Multilink Protocol. IETF RFC [10] Kalitay, H. (2011). Designing WANem : A Wide Area Network emulator tool. Mumbai, India: TCS Innovation Lab.-Performance Eng., TATA Consultancy Services Ltd. [11] Krüger, M. (2014, September). MPTCP for OpenWRT. Visited May 2015, at [12] Lim, Y.-s., Chen, Y.-C., Nahum, E. M., Towsley, D., & Gibbens, R. J. (2014). How green is multipath TCP for mobile devices? Proceedings of the 4th workshop on All things cellular: operations, applications & challenges. New York, USA. [13] McCreary, S., & Claffy, K. (2000). Trends in wide area IP traffic patterns. Dallas: UT Dallas. [14] Oberhumer, M. F. (1997, February). LZO real-time data compression library. Visited on June 1, 2015, at infosys. tuwien. ac. at/staff/lux/marco/lzo. html [15] Paasch, C., Detal, G., Duchene, F., Raiciu, C., & Bonaventure, O. (2012). Exploring Mobile/WiFi Handover with Multipath TCP. ACM SIGCOMM workshop on Cellular Networks. [16] Pluntke, C., Eggert, L., & Kiukkonen, N. (2011). Saving mobile device energy with multipath TCP. Proceedings of the sixth international workshop on MobiArch. New York, USA. [17] Raffel. (sd). Controleren aderparen. Visited on June 1, 2015, at net/controleren%20aderparen.pdf [18] Raiciu, C., Barré, S., Pluntke, C., Greenhalgh, A., Wischik, D., & Hnadley, M. (2011). Improving datacenter performance and robustness with multipath TCP. Sigcomm. Toronto, Canada. [19] Raiciu, C., Niculescu, D., Bagnulo, M., & Handley, M. J. (2011). Opportunistic mobility with multipath TCP. MobiArch '11 Proceedings of the sixth international workshop on MobiArch. New York, USA. [20] Raiciu, C., Pluntke, C., Barré, S., Greenhalgh, A., Wischik, D., & Handley, M. (2010). Data Centre Networking with Multipath TCP. Ninth ACM Workshop on Hot Topics in Networks. Montery, Califonia, US. [21] Shengyang, C., Zhenhui, Y., & Muntean, G.-M. (2013). An energy-aware multipath-tcp-based content delivery scheme in heterogeneous wireless networks. Wireless Communications and Networking Conference (WCNC). Shanghai. [22] Tirumala, A. e. (2005). Iperf: The TCP/UDP bandwidth measurement tool. [23] Wang, Y. (2010). Distributed diversity in hybrid wireless. Boston, USA: Northeastern University. 5

6 APPENDIX All measurements in this section are executed with WanEM. WanEM is a network emulator that is able to transperantly manipulate traffic passing through by either dropping packets or delaying packets. The WanEM trafficshaper was installed in only one of the two channels that were measured. Packet Loss Probability Multipath TCP Traditional TCP 1,00E ,00E ,00E ,00E ,00E ,00E ,00E Packet Delay Delay (ms) Multipath TCP Positive Negative Traditional TCP Positive Negative Deviation Deviation Deviation Deviation