Multi-Path TCP with Network Coding for Mobile Devices in Heterogeneous Networks
Jason Cloud, Flavio du Pin Calmon, Weifei Zeng, Giovanni Pau, Linda Zeger, Muriel Medard
MMulti-Path TCP with Network Coding for Mobile Devices inHeterogeneous Networks
Jason Cloud †∗ , Flávio du Pin Calmon †∗ , Weifei Zeng † , Giovanni Pau ‡ , Linda M. Zeger ∗∗ , and Muriel Médard †† Research Laboratory of Electronics, Massachusetts Institute of Technology, Cambridge, MA ‡ Computer Science Department, University of California, Los Angeles, CA ∗ MIT Lincoln Laboratory, Lexington, MA ∗∗ Auroral LLCEmail: {jcloud, flavio, weifei}@mit.edu, [email protected], [email protected], [email protected]
Abstract —Existing mobile devices have the capability to use multiplenetwork technologies simultaneously to help increase performance; butthey rarely, if at all, effectively use these technologies in parallel. We firstpresent empirical data to help understand the mobile environment whenthree heterogeneous networks are available to the mobile device (i.e., aWiFi network, WiMax network, and an Iridium satellite network). Wethen propose a reliable, multi-path protocol called Multi-Path TCP withNetwork Coding (MPTCP/NC) that utilizes each of these networks inparallel. An analytical model is developed and a mean-field approximationis derived that gives an estimate of the protocol’s achievable throughput.Finally, a comparison between MPTCP and MPTCP/NC is presentedusing both the empirical data and mean-field approximation. Our resultsshow that network coding can provide users in mobile environmentsa higher quality of service by enabling the use of multiple networktechnologies and the capability to overcome packet losses due to lossy,wireless network connections.
I. I
NTRODUCTION
Simultaneous use of multiple network interfaces on a single mobiledevice has the potential to increase quality of service, seamlesslyoffload traffic from expensive networks to cheaper ones, increasesession reliability, etc.; yet current technology does not utilize theavailable resources efficiently to meet these objectives. Instead, only asingle network interface is preferred while the others are left unused.For example, consider a standard smart phone that has a cellulardata connection, such as 3G or LTE, and a WiFi connection. Data issent over either one or the other, but not both. Given that existinginfrastructure currently supports the use of both WiFi and cellulartechnologies ([1], [2]), new techniques must be developed to properlyleverage all available resources, regardless of their quality, to increasemobile user performance.A significant amount of research has been performed that attemptsto utilize these heterogeneous network connections. For example,Multi-Path TCP (MPTCP) is a new protocol currently in the workinggroup level of the IETF [3]. The protocol adds a new layer abovethe transport layer which provides packet scheduling across multipleTCP sub-flows and guarantees packet delivery through the use of asomewhat complex management scheme. Furthermore, MPTCP usesTCP as its primary flow control mechanism on each of the sub-flows.While the use of TCP ensures fairness with other TCP flows, theperformance of TCP over lossy networks (e.g., wireless networks) isknown to be poor [4]. Network coding is one possible solution thatboth reduces the need for a complex management scheme and canincrease TCP’s performance over lossy networks.Several suggestions on how to incorporate network coding withMPTCP have been proposed. Gheorgiu et. al. [5] propose a protocolcalled CoMP that uses network coding for multi-path transmissionthat incorporates only some aspects of TCP. [6] and [7] add amulti-path scheduler below the TCP, network coding, and IP layersnegating the congestion control benefits of TCP over single paths.
This work is sponsored, in part, by the Assistant Secretary of Defense(ASD R&E) under Air Force Contract
Finally, ParandehGheibi et. al. [8], and implemented by [9] in OpNet,provide a sub-flow selection control policy for network coded packetsover heterogeneous networks that optimizes the trade-offs betweenthe network usage costs and the Quality of user Experience (QoE)for media-streaming applications. Many approaches have also beenproposed to increase TCP’s performance in the presence of high losses([10], [11], [12], [13] to name a few). One promising approach isTCP/NC proposed by Sundararajan et. al. , [14]. TCP/NC introducesa layer between TCP and IP that uses random linear network coding[15] to produce linear combinations of all packets contained inthe TCP congestion control window. These coded packets are thentransmitted over the network and decoded by a client. As shown in[14], network coding helps to alleviate the effects of packet loss dueto poor channels while preserving the congestion control and fairnessmechanisms provided by TCP.In this paper, we first present empirical measurements for thesimultaneous use of three heterogeneous network connections (e.g.,WiFi, WiMax, and an Iridium satellite network) in a mobile envi-ronment. These measurements highlight the fact that none of thenetworks provide 100% reliable communication; but in combination,the simultaneous use of these networks can provide significant gainsover the use of only one at a time. We then present a model basedon [16] and [17], as well as derive a mean-field approximation forthe throughput of both MPTCP and MPTCP with network coding(MPTCP/NC). MPTCP/NC uses network coding prior to packet sub-flow scheduling to simplify the MPTCP management scheme, anduses network coding a second time below TCP to provide a mecha-nism to overcome packet losses induced by lossy, wireless networks.We conclude with a comparison of MPTCP and MPTCP/NC usingboth the mean-field approximation and the experimentally collecteddata to show that network coding can provide beneficial enhancementsto the existing protocols.The remainder of the paper is organized as follows. In SectionII, we outline the experimental measurement setup and present anoverview of the collected data. Section III provides a brief descriptionof MPTCP and MPTCP/NC, develops the analytical models used,and derives the mean-field approximations for both protocols. Wethen compare the performance of both MPTCP and MPTCP/NC inSection IV and conclude in Section V.II. E
MPIRICAL M EASUREMENTS
Using a WiMax base station, a WiFi mesh network, and an Iridiumsatellite data modem [18], simultaneous network traces were collectedbetween the Network Research Laboratory (NRL), Department ofComputer Science, UCLA and a vehicle driving a fixed route aroundthe UCLA campus. Each experiment sent packets, varying between64 bytes, 512 bytes , and 1,350 bytes in size, at rates based on thedirection of travel. For example, traffic generated by the computer inthe NRL and sent to the vehicle, referred to as downlink (D/L) traffic,was sent at rates determined by the individual network (WiMax: 20Mbps, WiFi: 20 Mbps, and Iridium: 1 kbps). Traffic generated by a r X i v : . [ c s . N I] J un (a) Network Configuration (b) WiMax/WiFi base station placementand vehicle route. Fig. 1: Empirical measurement collection setup.the computer in the vehicle and sent to the computer in the NRL,referred to as uplink (U/L) traffic, was also sent at rates determinedby the individual network (WiMax: 1 Mbps, WiFi: 20 Mbps, andIridium: 1 kbps). In each experiment, only D/L traffic or U/L trafficwas generated.
A. Testbed Configuration
Measurements were taken between a mobile commodity laptop anda fixed server located within the NRL. The computer in the NRL wasconnected to the NRL LAN which has gateways to both the WiMaxbase-station and WiFi mesh network. A 56 kbps modem was usedto connect the computer to the public switched telephone network(PSTN) in order to utilize the Iridium satellite network. In the vehicle,a single computer with separate WiMax and WiFi cards, as well asa connection to an Iridium data modem, was used to transmit andreceive data. A diagram of the setup is shown in Figure 1(a). UDPnetwork traffic was generated using Iperf [19] and network traceswere collected using tshark (a command line version of Wireshark)[20] on both the computers.The vehicle containing the mobile computer travelled a fixed routethrough the UCLA campus chosen so that the vehicle passed inand out of the coverage areas of all three networks. For example,connections through all three networks was established prior to eachexperiment. The vehicle would then drop from and reconnect to eachof the individual networks, depending on the location of the vehicleand coverage of the specific network, throughout the duration of theexperiment. Figure 1(b) provides the vehicle route and placement ofthe WiMax and WiFi mesh base stations on the UCLA campus.
B. Collected Data
Ten mobile experiments were conducted over a period of five daysin August 2011. For each of these experiments, traces were collectedand compared for each of the different networks. A sample of thecollected traces are shown in Figure 2. These traces show the UDPthroughput for each network when all traffic is sent either to (D/L)or from (U/L) the vehicle.The round-trip time (RTT) and packet loss probability for eachnetwork was also collected. The CDFs for both the RTT and packetloss probability during the D/L experiment where 1,350 byte packetswere used is shown in Figure 3. The RTT was measured usingping messages that were sent throughout the experiment on both theWiFi and WiMax networks, while ping messages were only sent forapproximately 60 seconds at the beginning of the experiment on theIridium network due to the bandwidth constraints of the network. The Round−Trip Time (rtt) [ms] F (r tt ) IridiumWiFiWiMax (a) RTT CDF
Packet Loss Probability (p) F ( p ) IridiumWiFiWiMax (b) Packet Loss CDF
Fig. 3: CDFs of the RTT and packet loss probabilities during the D/Lexperiment using 1,350 byte packets.packet loss probabilities were determined by comparing the trace fileson both the NRL server and the vehicle computer.
C. Discussion and Comments on the Experimental Results
Data collected during each of the experiments provides informationabout the expected environment that mobile users are likely toexperience. However, there are caveats concerning the methods inwhich the data was collected that must be noted. First, the onlyuser on each network was the vehicle; although the WiFi meshnetwork performance was affected by significant interference fromadjacent WiFi networks and the Iridium network was setup over anoperational system. As a result, the WiMax throughput presented inFigure 2 is much larger than what would be expected when fullyloaded, while the WiFi and Iridium throughput is close to what wewould expect in the real-world. The RTT shown in Figure 3(a) isalso affected by this situation. Since only one user has access to theWiMax network, the RTT is fairly consistent throughout each of theexperiments. The WiFi RTT is largely affected by contention withadjacent WiFi networks resulting in a wide range of possible RTTs,and the Iridium RTT is consistent except for periods where we believehorizontal handoffs between satellites occurred. Second, the datacollection methods were designed so that data could be used to replayeach experiment off-line enabling easy evaluation of future protocoldesigns. This prevented us from collecting reliable statistics on thepacket loss probabilities. However, Figure 3(b) shows the overallreliability of each network and indicates that the satellite networkprovides the most reliability and the WiFi network provides the least.Finally, the use of a modem and the PSTN for the Iridium network(and consequently the low throughput) is due to the Iridium systemdesign. Iridium was developed for world-wide voice communications.Modern satellite systems do provide higher bandwidth, and thereforebetter performance for packet based communication. Unfortunately,the use of these systems was prohibitively expensive.Regardless, the traces shown in Figure 2 indicate that using a multi-path solution can potentially provide significant performance gainsover that of using only one of the networks exclusively. Throughouteach experiment, the vehicle was connected to at least one networkthe majority of the time; and in many cases, it was connectedto two or more networks. Leveraging this connectivity can helpensure that reliable, continuous data transport is an option in mobileenvironments. The benefits of leveraging simultaneous networks fordata transport will be quantified in the following sections using thecollected data. Specifically, packet loss and RTT statistics will beused to provide a comparison between the performance of MPTCPand MPTCP/NC in multi-path, wireless scenarios.III. A
NALYTICAL M ODELS FOR M ULTI -P ATH
TCP
AND M ULTI -P ATH
TCP
WITH N ETWORK C ODING
Approaches similar to that of [16] and [17] are used to providea mean-field approximation of the throughput for both MPTCPand MPTCP/NC. The MPTCP analysis will assume the standard .05 1.1 1.15 1.2 1.25x 10 Epoch − 1312500000 Seconds T h r oughpu t ( bp s ) IridiumWiFiWiMaxA B C D A (a) U/L, Packet Size: 512B Epoch − 1312500000 Seconds T h r oughpu t ( bp s ) IridiumWiFiWiMaxA B C D A (b) U/L, Packet Size: 1350B Epoch − 1312500000 Seconds T h r oughpu t ( bp s ) IridiumWiFiWiMaxA B C D A (c) D/L, Packet Size: 64B Epoch − 1312500000 Seconds T h r oughpu t ( bp s ) IridiumWiFiWiMaxA B C D A (d) D/L, Packet Size: 1350B
Fig. 2: Sample traces showing the UDP throughput for two U/L and two D/L experiments with varying packet sizes. The labels A, B, C,and D provide the approximate location of the vehicle when compared with Figure 1(b).
MPTCPTCP TCPApplication DataNetworkA NetworkB (a) MPTCP
MPTCP/NCTCP TCPApplication DataTCP/NC TCP/NCNetworkA NetworkB (b) MPTCP/NC
Fig. 4: Assumed network stack configuration for both MPTCP andMPTCP/NC.implementation as shown in Figure 4(a) and defined by [3]. TheMPTCP/NC analysis will assume that the MPTCP/NC layer shownin Figure 4(b) provides a first layer of network coding before packetsare injected into a TCP sub-flow, and the TCP/NC layer provides asecond layer of network coding, similar to [14], in order to overcomerandom packet losses due to lossy networks.The analysis for MPTCP will use the model presented by [16]while assuming that perfect scheduling of packets across variousTCP sub-flows takes place. Once the analytical throughput for eachindividual sub-flow is determined, the results can be summed todetermine MPTCP’s overall throughput. In reality, perfect schedulingis not possible due to packet losses, termination of a specific sub-flow,etc. This, in-turn, results in the need to collect feedback regardingwhich packets were lost, retransmit each lost packet on a second (orthird) TCP sub-flow, and verify receipt of that packet by the receiver.This process significantly decreases the efficiency of MPTCP by bothlowering the throughput and increasing the transport time. With thisin mind, the analytical results presented later will over estimate theperformance of MPTCP.In the case of MPTCP/NC, network coding can be used to aid in thesub-flow scheduling problem by eliminating the need to track specificpackets sent over the network. With respect to the analysis, we willassume that network coding is performed prior to a packet’s injectioninto a sub-flow. If the coding operations are carried out properly, thereceiver only needs to collect enough coded packets, or degrees offreedom (DOF), in order to successfully transfer data over multiplesub-flows without the need to track individual packets through themultiple networks. Not only does this significantly decrease thecomplexity of the protocol, but also provides greater freedom fordetermining how to allocate packets among the collection of sub-flows. We will also assume that a second layer of network codingoccurs below TCP and redundant packets are transmitted to overcome random packet losses. In general, the number of transmitted packetsfor every DOF sent should be R ≥ / − p where R is the redundancyand p is the packet loss probability of the network path. [14] providesa full description of the network coding operations and gains that canbe achieved using network coding in this manner.Finally, we will assume that both protocols use a TCP Reno styleof congestion control on each sub-flow. This assumption keeps theresults presented here in line with those presented by [16] and alsosimplifies the analysis for MPTCP/NC. Because we assume thatnetwork coding is performed below TCP on each sub-flow, networkcoding eliminates the need to consider the effects of triple-duplicateson TCP’s window size. A more detailed discussion will be providedin subsequent sections. A. MPTCP Analytical Throughput
The analytical throughput for MPTCP follows directly from [16].In [16], the analytical throughput, B ( p ) , of a single TCP connectionwas derived where p is the independent and identically distributed(i.i.d) loss probability of a single packet. The equation for B ( p ) canbe found in equation (32) of [16]. We extend this analysis to themulti-path case by taking the calculated B j ( p j ) for each sub-flow, j = { , . . . , n } , and summing them together to form the MPTCPthroughput: B ( p , . . . , p n ) = n (cid:88) j =1 B j ( p j ) . (1)As noted earlier, this does not let us take into account theinefficiencies introduced by the MPTCP layer and will over-estimatethe achievable MPTCP throughput. B. Modeling MPTCP/NC’s End-to-End Throughput
Two metrics will be used to develop the MPTCP/NC mean-field ap-proximation: the average throughput T , and the expected MPTCP/NCcongestion window evolution E [ W ] . We model MPTCP/NC’s behav-ior in terms of rounds. The natural choice for determining the durationof a round is to use the RTT from the sender to the receiver (i.e., t rnd = RT T ). While this works if there is a single TCP connection,each sub-flow is expected to have different round trip times makingit difficult to determine which RTT to use. This is accounted forby setting the duration of each round, t rnd , equal to the greatestcommon divisor (GCD) of the sub-flows’ RTTs. Figure 5 providesan illustration of this concept.
1) MPTCP/NC Sub-Flow Analysis:
We now use the most basicimplementation of TCP in our analysis and initially assume that eachround’s duration is equal to the RTT of sub-flow j . We assume that thecongestion window size during round i is determined by the numberof acknowledgements a indicating successfully transmitted packetsobtained during round i − : W ( j ) i = W ( j ) i − + a ( j ) i − W ( j ) i − . (2) TT R TT RTT t ro und W W W W W t ro und Fig. 5: Round duration used for MPTCP/NC for two sub-flows.The blue blocks indicate packets and the green blocks indicateacknowledgements.This concept is also shown in Figure 5 where the congestion windowsize of each sub-flow grows as a function of the number of acknowl-edgements received. We now assume that R j linearly independent,redundant, network coded packets are sent for each uncoded packetcontained the TCP congestion window, there are i.i.d. packet losses,and a packet loss rate of p j . Taking the expectation of the windowsize, E [ W ( j ) i ] , we obtain: E (cid:104) W ( j ) i (cid:105) = E (cid:104) W ( j ) i − (cid:105) + min (1 , (1 − p j ) R j ) (3) = E (cid:104) W ( j )1 (cid:105) + ( i − min (1 , (1 − p j ) R j ) , (4)where the minimization is required because the window size can onlyincrease by a maximum of one packet per round.Since the throughput T ( j ) i per round is related to the number ofpackets sent in that round, T ( j ) i = E (cid:104) W ( j ) i (cid:105) RT T j min (1 , (1 − p j ) R j ) . (5)The minimization in this equation is necessary to account for packetsthat are received that do not deliver new degrees of freedom. Since theTCP/NC layer codes all packets within the TCP congestion window,delivered packets 1 through W ( j ) i contain new degrees of freedom. Ifmore than W ( j ) i packets are received in the round, the MPTCP/NClayer disregards them since they contain no new information.The above analysis assumed that the RTTs for each sub-flow wasthe same. Because this is not necessarily the case, we must adjustequation (4) to account for the shorter round durations by defining α j = RTT j / t rnd and substituting (cid:100) i / α j (cid:101) for i , E (cid:104) W ( j ) (cid:100) i / αj (cid:101) (cid:105) = E (cid:104) W ( j )1 (cid:105) + ( (cid:100) i / α j (cid:101) − min (1 , (1 − p j ) R j )= γ ( j ) i . (6)The throughput for each TCP sub-flow j then becomes T ( j ) i = γ ( j ) i / ( α j · t rnd ) min (1 , (1 − p j ) R j ) , which can be further reduced ifwe consider a large enough redundancy factor R j . For R j > / ( − p j ) ,the instantaneous throughput becomes, T ( j ) i = 1 α j · t rnd (cid:16) E (cid:104) W ( j )1 (cid:105) + (cid:100) i / α j (cid:101) − (cid:17) . (7)Finally, we account for the fact that the number of packets sent ineach RTT is upper-bounded by TCP’s maximum congestion windowsize, W ( j ) max . This results in: T ( j ) i = 1 α j · t rnd (cid:16) min (cid:16) W ( j ) max , E (cid:104) W ( j )1 (cid:105) + (cid:100) i / α j (cid:101) − (cid:17)(cid:17) . (8) The model we used in our analysis of the MPTCP/NC sub-flowperformance makes several assumptions that, in practice, should beconsidered. First, we assume that packet losses are i.i.d. with lossprobability p i . Therefore, the analysis does not account for correlatedpacket losses due to congestion and other factors. Second, weassumed that R j is sufficiently large enough to ignore the possibilityof time-outs. While the probability of a time-out decreases withincreasing R j , time-outs still occur in practice and the impact ofeach time-out on the throughput is significant (i.e., the congestionwindow size is reset to E [ W ( j )1 ] ). Specifically, a time-out occurswhen the sum of received acknowledgements over two rounds, i and i + 1 , is less than the window size during round i with probability P r ( a i + a i +1 < W i ) . Generalizing equation (2) to account for time-outs, with respect to W max and R j , may allow for a bound on thedecrease in throughput to be determined resulting in a more accurateapproximation. Third, we assume that RT T j remains constant. Inpractice, this is not true, and implementations of TCP generally use anaveraged round-trip time often referred to as the “smoothed” round-trip time SRT T .
2) MPTCP/NC’s Window Evolution and End-to-End Throughput:
Using the above results, the average end-to-end MPTCP/NC through-put over k rounds is determined using a round duration of t rnd anddefining α j = RTT j / t rnd , T ( k ) = 1 k k (cid:88) i =1 T i = 1 k k (cid:88) i =1 n (cid:88) j =1 T ( j ) i . (9)Assuming that k / α j ∈ Z , γ ( j ) i ≤ W ( j ) max , and relaxing (cid:100) i / α j (cid:101) so thatit is i / α j for all j , T ( k ) = 1 k n (cid:88) j =1 (cid:32) α j · t rnd k (cid:88) i =1 γ ( j ) i (cid:33) (10) = 1 t rnd n (cid:88) j =1 (cid:18) α j E (cid:104) W ( j )1 (cid:105) + k + 12 α j − α j (cid:19) , (11)If k / α j / ∈ Z , ∀ j , the above equation will contain additional terms thatcontain packets sent in the rounds from (cid:98) k / α j (cid:99) to k / α j . Furthermore,the relaxation of (cid:100) i / α j (cid:101) to i / α j decreases the throughput since we areno longer accounting for (cid:100) i / α j (cid:101) − i / α j packets sent per round. As k grows, these approximations have less of an effect on the throughput.Finally, we take into account the maximum window size of eachsub-flow W ( j ) max ; but first, we define: r ( j ) = α j (cid:16) W ( j ) max − E (cid:104) W ( j )1 (cid:105)(cid:17) . (12)Using equation (11) and assuming that R j > / (1 − p j ) , the averageend-to-end throughput T e e , in packets per second is: T e e ( k ) = n (cid:88) j =1 T ( j ) e e ( k ) , (13)where T ( j ) e e ( k ) = α j · t rnd (cid:16) E (cid:104) W ( j )1 (cid:105) + k +12 α j − (cid:17) for k ≤ r ( j ) , ρ ( j ) α j · k · t rnd for k > r ( j ) , (14)and ρ ( j ) = r ( j ) E (cid:104) W ( j )1 (cid:105) + r ( j ) (cid:16) r ( j ) + 1 − α j (cid:17) α j + W ( j ) max (cid:16) k − r ( j ) (cid:17) . (15)It should be noted that as k → ∞ for R j > / (1 − p j ) , the averageend-to-end throughput T e2e ( k ) → (cid:80) nj =1 W ( j ) max / ( α j · t tnd ) . .5 1.55 1.6 1.65x 10 −4 −2 Epoch − 1312500000 T h r oughpu t ( pa ck e t s / s e c ) MPTCPMPTCP/NC (a) D/L, Packet Size: 1350B −3 −2 −1 Epoch − 1312500000 T h r oughpu t ( pa ck e t s / s e c ) MPTCPMPTCP/NC (b) U/L, Packet Size: 1350B
Fig. 6: Comparison of the theoretical MPTCP and MPTCP/NCthroughput using the data presented in Section II.IV. C
OMPARISON OF M ULTI -P ATH
TCP
AND M ULTI -P ATH
TCP
WITH N ETWORK C ODING USING E MPIRICAL D ATA
We now compare the theoretical throughput of MPTCP, equation(1), with that of the theoretical throughput of MPTCP/NC, equation(13). Figure 6 shows the performance of both protocols using thedata presented in Section II as a baseline. The maximum windowsize for each TCP sub-flow was set to W max = 12 ; and a meanRTT, based off of empirical data, was used for each network where RT T
Iridium = 1 . s, RT T
WiFi = 0 . s, and RT T
WiMax = 0 . s.Empirical packet loss data, averaged over 5s, on each separate pathfrom two of the experiments was used as a baseline for determiningboth throughputs. It was assumed that the network capacity for eachnetwork was large enough to send W max packets in the case ofMPTCP and R j W max packets in the case of MPTCP/NC where R j isassumed to be large enough so that time-outs are very unlikely (i.e., R j is much larger than the 5s average of the packet loss probability).In addition, Figure 6 uses the mean-field approximations developedin the last section and does not show a simulated behavior of eachprotocol.The figures show that MPTCP/NC provides a better throughputthroughout the “simulated” experiment than MPTCP. While MPTCPis severely hindered by high packet losses as a result of poor channelconditions, MPTCP/NC is able to mask the majority of packet lossesand maintain a high throughput. Scheduling of packets on eachsub-flow is also easier with MPTCP/NC than with MPTCP due tothe network coding operations performed immediately below theapplication layer. The throughput shown for MPTCP assumes thatthere is perfect scheduling among the sub-flows with no need toretransmit a packet on more than one sub-flow. This provides a best-case scenario for the achievable throughput. This assumption is notmade in MPTCP/NC because each packet transmitted on a sub-flowis viewed as a degree of freedom. If a packet is lost, any packet senton a different sub-flow can be used in the lost packet’s place.V. C ONCLUSION
We have presented empirical measurements for the simultaneoususe of three heterogeneous networks showing that the combined useof all three is needed in order to provide an improved level ofperformance in mobile environments. We then suggested the use ofa multi-path protocol based on MPTCP that uses network codingto overcome the challenges of packet scheduling and lossy wirelessnetworks. A mean-field approximation of the throughput for bothMPTCP and MPTCP/NC was developed and used, along with theempirical data, to provide a comparison of the two protocols. Thiscomparison showed that the use of network coding in multi-path,lossy scenarios can significantly increase the quality of service formobile users. A
CKNOWLEDGEMENTS
A large team was required to collect and analyze the experimental dataand the authors would like to acknowledge their contribution. Giovanni Pau and Mario Gerla from UCLA, as well as Au Teerapittayanon and
Danail
Traskov from MIT, were critical to the success of the datacollection efforts. Jamie Simons from MIT was also critical to the dataprocessing efforts. This paper would not be possible if it was not for theirhelp. R EFERENCES [1] X. Chen, R. Jin, K. Suh, B. Wang, and W. Wei, “Network performance ofsmart mobile handhelds in a university campus WiFi network,” in
Proc.ACM Conference on Internet Measurement Conference (IMC) , pp. 315–328, 2012.[2] J. Sommers and P. Barford, “Cell vs. WiFi: on the performance ofmetro area mobile connections,” in
Proc. ACM Conference on InternetMeasurement Conference (IMC) , pp. 301–314, 2012.[3] “MPTCP IETF working group.” https://datatracker.ietf.org/wg/mptcp/.[4] G. Xylomenos, G. C. Polyzos, P. Mahonen, and M. Saaranen, “TCP per-formance issues over wireless links,”
IEEE Communications Magazine ,vol. 39, no. 4, pp. 52–58, 2001.[5] S. Gheorghiu, A. L. Toledo, and P. Rodriguez, “Multipath TCP withnetwork coding for wireless mesh networks,” in
Proc. IEEE InternationalConference on Communications (ICC) , pp. 1–5, 2010.[6] X. Zhuoqun, C. Zhigang, Y. Hui, and Z. Ming, “An improved MPTCP incoded wireless mesh networks,” in
Proc. IEEE International Conferenceon Broadband Network & Multimedia Technology (IC-BNMT) , pp. 795–799, 2009.[7] Z. qun Xia, Z. gang Chen, Z. Ming, and J. qi Liu, “A multipathTCP based on network coding in wireless mesh networks,” in
Proc.IEEE International Conference on Information Science and Engineering(ICISE) , pp. 3946–3950, 2009.[8] A. ParandehGheibi, M. Médard, A. Ozdaglar, and S. Shakkottai,“Access-network association policies for media streaming in heteroge-neous environments,” in
CDC’10 , pp. 960–965, 2010.[9] A. Kulkarni, M. Heindlmaier, D. Traskov, M.-J. Montpetit, and M. Mé-dard, “An implementation of network coding with association policiesin heterogeneous networks,” in
Proc. IFIP TC International Conferenceon Networking (NETWORKING’11) , pp. 110–118, 2011.[10] J. Liu and S. Singh, “ATCP: TCP for mobile ad hoc networks,”
IEEEJournal on Selected Areas in Communications , vol. 19, no. 7, pp. 1300–1315, 2001.[11] R. Caceres and L. Iftode, “Improving the performance of reliabletransport protocols in mobile computing environments,”
IEEE Journalon Selected Areas in Communications , vol. 13, no. 5, pp. 850–857, 1995.[12] K. Xu, Y. Tian, and N. Ansari, “TCP-Jersey for wireless IP communi-cations,”
IEEE Journal on Selected Areas in Communications , vol. 22,no. 4, pp. 747– 756, 2004.[13] K. Chandran, S. Raghunathan, S. Venkatesan, and R. Prakash, “Afeedback-based scheme for improving TCP performance in ad hocwireless networks,”
IEEE Personal Communications , vol. 8, no. 1,pp. 34–39, 2001.[14] J. K. Sundararajan, D. Shah, M. Médard, S. Jakubczak, M. Mitzen-macher, and J. Barros, “Network coding meets TCP: theory and im-plementation,”
Proceedings of the IEEE , vol. 99, no. 3, pp. 490–512,2011.[15] T. Ho, M. Médard, R. Koetter, D. R. Karger, M. Effros, J. Shi, andB. Leong, “A random linear network coding approach to multicast,”
IEEE Transactions on Information Theory , vol. 52, no. 10, pp. 4413–4430, 2006.[16] J. Padhye, V. Firoiu, D. F. Towsley, and J. F. Kurose, “ModelingTCP reno performance: a simple model and its empirical validation,”
IEEE/ACM Trans. Netw. , vol. 8, no. 2, pp. 133–145, 2000.[17] M. Kim, M. Médard, and J. a. Barros, “Modeling network coded TCPthroughput: a simple model and its validation,” in