Bapu Techreport

8/12/2019 Bapu Techreport

1/14

BaPu: Efficient and Practical Bunching ofAccess Point Uplinks

Tao Jin Triet Vo-Huu Erik-Oliver Blass Guevara NoubirNortheastern UniversityBoston, MA, USA

{taojin|vohuudtr|blass|noubir}@ccs.neu.edu

Abstract

Todays increasing demand for wirelessly uploading alarge volume of User Generated Content (UGC) is stillsignificantly limited by the throttled backhaul of res-idential broadband (typically between 1 and 3Mbps).We propose BaPu, a carefully designed system withimplementation for bunching WiFi access points back-

haul to achieve a high aggregated throughput. BaPu

isinspired by a decade of networking design principles andtechniques to enable efficient TCP over wireless linksand multipath. BaPuaims to achieve two major goals:1) requires no client modification for easy incrementaladoption; 2) supportsnot onlyUDP, but also TCP traf-fic to greatly extend its applicability to a broad classof popular applications such as HD streaming or largefile transfer. We prototyped BaPu with commodityhardware. Our extensive experiments shows that de-spite TCPs sensitivity to typical channel factors suchas high wireless packet loss, out-of-order packets arrivalsdue to multipath, heterogeneous backhaul capacity, and

dynamic delays, BaPuachieves a backhaul aggregationup to 95% of the theoretical maximum throughput forUDP and 88% for TCP. We also empirically estimatethe potential idle bandwidth that can be harnessed fromresidential broadband.

1. INTRODUCTION

Nowadays, the mobile devices are equipped with high-resolution cameras and a variety of sensors and arequickly becoming the primary device to generate per-sonal multimedia content. Both the quality and quan-tity of User Generated Content grows continuously. This

naturally leads to end users ever increasing demand ofsharing these high volume of UGC with others in aninstant way. Prominent examples of services allowingmultimedia content sharing are YouTube, Dailymotion,and various social networking platforms like Facebookand Google+. In addition, there is also a trend of in-stantly backing up personal files in the Cloud Storage,such as Dropbox and iCloud. To obtain a satisfactoryuser experience, users need sufficient uplink bandwidthto do the fast bulk data transfer to the Internet. How-

ever, todays ISPs generally offer highly throttled up-link bandwidth around 1 to 3Mbps. As a result, in-stant sharing of HD content or fast data backup inthe Cloud is generally infeasible in todays residen-tial broadband. For example, iPhone 5 takes video at1080p and 30fps, which translates to around 200MB perminute. With 3Mbps uplink, it takes over an hour toupload a 10 minute video clip to iCloud! These lim-

itations are even more critical for users who desire toretain the control over their content and intend to sharethem directly from their homes. This calls for solutionsto scale backhaul uplink.

In this work, we propose a complete software basedsolution on WiFi Access Point for aggregating multiplebroadband uplinks, with the assistance of the WiFi in-frastructure in the same neighborhood. Our solutionfeatures complete transparency to client devices andhigh aggregated throughput for both TCP and UDP,even in lossy wireless environment. Our work is pri-marily motivated by the following observations:

Asymmetric WiFi and broadband capacity:

In contrast to the broadband uplink, WiFi has amuch higher bandwidth. 802.11n supports up to600Mbps data rate. With sufficiently high WiFibandwidth, it is beneficial to wirelessly commu-nicate with multiple proximate APs and harnessthe idle broadband uplink bandwidth behind them.

Mostly idle broadband uplinks: Since Febru-ary 2011, we have developed and deployed a WiFitestbed [24] in Boston urban area, aiming to moni-tor the usage pattern of residential broadband net-works. As shown in Table 1, this testbed con-

sists of 30 home WiFi APs running customizedfirmware based on OpenWRT [25]. Each AP re-ports the network statistics every 10 second. Dur-ing a 18 month period, we have collected over 70million records. We observe that the broadbanduplink utilization is very low. Figure 1 shows theprobability of uplink bandwidth being consumedat most certain value during a 24 hour time win-dow. Throughout the day, there is at least 50%chance that uplink is completely idle. Even dur-

1


2/14

Location Boston urban areaHome APs Comcast (26), RCN (4)Data collection time Feb. 2011 Dec. 2012Network stats samples 70 million

Table 1: Data summary of Broadband usage statisticscollected from residential WiFi testbed

ing peak hours, there is over 90% chance that theuplink bandwidth usage is below 100Kbps. Thisimplies that there exists a considerable amountof idle uplink bandwidth resources, which makesbandwidth harnessing through neighboring APs aviable approach for scaling the uplink capacity.

WiFi densely deployed in residential area:

The density of WiFi APs is very high in residentialareas. Already in 2005, authors in [2] measuredmore than 10 APs per geographical location. Re-cently, we conducted Wardriving measurements in4 urban residential areas in Boston. Our results

(Table 2) indicate 3192 unencrypted WiFi APs,accounting for 14.2% of total APs detected dur-ing our wardriving. As shown in Figure 2, thereare on average 17 APs available at each location,with on average 7 to 12 APs on each channel. Thisenormous presence of WiFi APs also justifies thefeasibility of the concept of bandwidth aggregationvia open APs.

Total APs 22,475 (100%)Unencrypted APs 3,192 (14.2%)

Table 2: Boston Wardriving Data Summary

WiFi becoming open and social: Nowadays,end users have an ever increasing demand of ubiq-uitous Internet access. Driven by such demand,there is an emerging model that broadband sub-scribers host two WiFi SSIDs, one encrypted forprivate use, the other unencrypted to share partof their bandwidth as public WiFi signal to mobileusers for free or for some payment in return. Unen-crypted guest-WLAN is now a standard feature inmainstream home WiFi AP products like LinkSysand D-Link. FON [9], a leading company in thisarea, claims to have over 7 million hotspots world-

wide. In addition, WiFi APs are quickly becomingcloud-managed devices, such as FON and Meraki[19]. AP firmware updates are regularly pushedfrom the Cloud. Given such trend of WiFi quicklybecoming social and cloud-powered, we believe asoftware based solution on WiFi AP can make aquite easy incremental adoption of our technology.

Lack of efficient and practical solution: De-spite a set of prior work exploring how to aggre-gate wired bandwidth through WiFi, they either

0am 4am 8am 12pm 16pm 20pm 0am40

50

60

70

80

90

100

Prob[BWb

elowcertainvalue]

idle

< 1Kbps< 10Kbps

< 100Kbps< 1Mbps

Figure 1: CDF of uplink bandwidth usage (per house-hold) in residential broadband.

0 20 40 600

0.2

0.4

0.6

0.8

1

Available APs

CDF

ofAvailableAPs

CH 1

CH 6

CH 11

All Channels

Figure 2: Available APs per scanning in Wardriving.

require heavy modification on client, or supportonly specific application, such as UDP based bulkfile transfer [15]. Our goal is to design a clienttransparent, software based solution, which is easyto deploy and offer generic support for both TCPand UDP applications.

With the above motivations and goals bearing in mind,we design our BaPu system. Our major contributionsin this work are summarized as follows:

Transparency to client: BaPu does not requireany modification to client devices. The client device,running in Station mode, transfers data via unicast linkto its home AP. Given the broadcast nature of wire-less communication, such unicast packets can beheardby both home AP and the neighboring APs on thesame channel. They each upload a share of received(overheard) packets to the destination in a collabora-tive manner. Such transparency to client devices allowsall kinds of wireless client devices and a broad classof legacy network applications, such as streaming andlarge file transfer, to seamlessly utilizeBaPu system.

Efficient aggregation for both TCP and UDP:Given our design goal of client transparency, some com-

monly adopted technique in the existing bandwidth ag-gregation solutions, such as parallel TCP flows [16], areno longer valid, because it requires client applicationsto intentionally establish multiple connections throughdifferent APs and transfer data in parallel. The mul-tiplexing of a single TCP flow through multiple pathsraises many technical challenges which makes efficientaggregation non-trivial. Our initial approach relied oncoding across paths, however, we could show that a con-ceptually simpler mechanism, which we call Proactive-

2


3/14

309: !"/7)07':

;0

-./0'.1%2#, 3.4(%2# -./0'.1%2#5

6(/7(1 ,

A A A

86# E:1.''F(7

GHF0/> ,%I-JHD

C(D'0/"'0./ ,

3.4(%2#

@!"#$%&"'()"*B

8KF.$7 &"'()"*

@!"#$%&"'()"*B

C(D'0/"'./ 5

@(A9A 0KF.$7

6'.1"9( 6LMB

-./0'.1%2#, 3.4(%2# -./0'.1%2#5

6(/7(1 5

A A A

Figure 3: BaPusystem architecture and two exampleapplication scenarios. Scenario 1 (left): Sender 1 sharesan HD video with a remote end user through a BaPu-enabled Home-AP and neighboring Monitor-APs. Sce-nario 2 (right): Sender 2 backs up a large file to iCloudthrough a BaPu-enabled Home-AP and Monitor-APs.

ACK, combined with a reliable 802.11 unicast to the

home AP, and adequate scheduling are sufficient.Prototype with commodity hardware: We pro-

totyped our complete BaPu system on commodity WiFiAPs. We flash Buffalo 802.11n APs with Linux basedOpenWRT [25] firmware. As of today, OpenWRT sup-ports devices by more than 50 manufacturers and hun-dreds of models. This gives us a great selection of com-patible devices to deploy BaPu.

Evaluation: We have conducted an extensive set ofexperiments to evaluate BaPu in various realistic net-work settings. Our results show that BaPu achieveshigh aggregated throughput in UDP transmission, har-nessing over 95% of total uplink bandwidth. With the

Proactive-ACK mechanism, BaPu harnesses over 88%of total uplink bandwidth in TCP transmission.

Design guideline for bandwidth sharing: Wepropose a simple traffic shaping method on AP, whichallows us to harness as much idle bandwidth as possiblewithout affecting home users regular network usage.We also give an estimation of idle uplink bandwidthunder a typical residential broadband usage pattern.

Our paper is organized as follows. We first presentan overview ofBaPusystem. The details of our designis discussed in Section 3. We evaluate the performanceof BaPu in Section 4. In Section 5, we quantitativelyevaluate the potential impact of uplink sharing to home

users regular network usage. We discuss related workin Section 6 and conclude the paper in Section 7.

2. SYSTEM OVERVIEW

2.1 Application Scenarios

For ease of understanding, we first introduce two typ-ical application scenarios that benefit from BaPu seeFigure 3.

Figure 4: BaPu-AP Building components.

Scenario 1: Instant Sharing of HD Video: Inorder to retain the control of personal content, Sender 1shares his HD video directly from his hard drive andstreams it instantly, i.e., in real-time, to the other user Destination 1. Both users are connected to theirHome-APs, with an uplink connection from Sender 1to Destination 1 throttled to 1 3Mbps by Sender 1sISP. The HD video has 8Mbps playback rate (standard1080p video bit rate), so Sender 1s single uplink cannot

handle this content in real-time. However with BaPu,the idle uplink of the neighboring Monitor-APs are ex-ploited to boost the uplink throughput. The BaPu-Gateway, the Home-AP of Destination 1, plays the roleas the aggregator to receive and forward multiplexedtraffic to Destination 1.

Scenario 2: Instant Backup of Large File: Sender 2wishes to backup his HD video clip to some cloud stor-age service such as iCloud. With the 3Mbps uplink rate,it takes over an hour to upload a 30 minute HD video.With BaPu, neighboring Monitor-APs and Home-APupload data in parallel. iCloud just needs to deploya gateway server in front of the cloud storage servers.This gateway server runs the BaPu-Gateway softwareto handle parallel uploading from multiple paths. UsingBaPu, file uploading time is greatly reduced.

Security and Privacy: In both application scenar-ios, the APs are configured to have two SSIDs, an en-crypted SSID (i.e., WPA) for private use, and an unen-crypted (open) SSID. The BaPu traffic is carried overneighbouring unencrypted SSIDs with end-to-end secu-rity (e.g., SSL/TLS), while allowing the main SSID ofparticipating APs to remain encrypted.

2.2 BaPuDescription

First, we introduce the notation used in this paper:

Sender: device uploading data to a remote desti-nation.

Receiver: device receiving uploaded data from aremote sender.

Home-AP: AP which Senderis associated to. Monitor-AP: in physical proximity to Receiverand

Home-AP, a couple of neighboring APs, the Monitor-APs, run inmonitor modeon the same WiFi chan-

3


4/14

!"#$"% &'(")*+ ,'#-.'%)*+ /0+1)20."304 5"6.-#0.-'#

7"8"9.-'#7"9'%.

!8;"$


5/14

large file transfer). Yet our ultimate goals of the trans-parency for the users, and the high-throughput trans-mission for all kinds of user applications require a newsolution with unique characteristics.

3.1 Network Unicast

First, the transparency goal requires that legacy trans-port protocols be usable for data transmission from

Sender to Receiver. Accordingly, the Sender must beable to transmit data to the Receiver via network uni-castthrough its Home-AP. The second reason for theneed of network unicast is to increase the reliability ofthe transmission, because BaPu supports TCP, whoseperformance depends on the reliability of the underly-ing MAC layer. To be clearer, according to the IEEE802.11 standard, a packet with a broadcast destinationaddress is transmitted only once by the WiFi device,whereas up to 12 MAC-layer retransmissions are triedfor a failed unicast destination address, therefore a uni-cast is much more reliable than a broadcast. Conse-quently, supporting network unicast is an essential re-quirement in BaPu, while in prior work [15], broadcastis preferred due to the simplicity goal of their system.

Packet Overhearing:In WiFi network, although bothnetwork unicast and network broadcast use the samemethod of wireless broadcast to transfer data, the differ-ence lies in the MAC layer, where the next-hop physicaladdress is specified to the unicast address or broadcastaddress. This complicates the packet overhearing capa-bility at Monitor-APs. As Home-AP is the first hopin the transmission path, the Sender, according to theunderlying routing protocol, has to use the Home-APsphysical address as the next-hop address in the 802.11

header. While Home-APas a next hop can receive thepacket, Monitor-APs automatically discard the packetdue to mismatched physical address. Therefore, barelyrelying on the default network behavior does not letMonitor-APs capture packets sent by Senders in otherWLANs.BaPus solution is to configure BaPu-APs to oper-

ate simultaneously in two modes: AP modeand monitormode. The former mode is used for serving clients in theAPs own WLAN, whereas the latter is used for over-hearing packets in the air. In monitor mode, packetsare captured in raw format via the use oflibpcap.

Packet Identification: Each packet sent from theSender(step 1) contains the session information in thepackets IP header such as the protocol identifier, thesource and destination IP addresses and ports. Withthis information, Home-AP can uniquely identify theSender (step 2). In contrast, Monitor-APs may haveambiguity in identifying the Sender, as Senders fromdifferent WLANs may (legally) use the same IP ad-dress. To resolve such conflict, we write a frame parserfor the packets MAC header to obtain the BSSID that

identifies the WLAN the session belongs to. Therefore,any session in BaPu is now uniquely determined onthe following 6-tuple .

Duplicate Elimination: As mentioned earlier, uni-casting a packet may involve a number of (MAC-layer)retransmissions due to wireless loss occurred between

the Sender and its Home-AP. This benefits the datatransmission between them. Nevertheless, it is possiblethat a nearbyMonitor-APcan overhear more than one(re)transmission of the same packet, which creates du-plicates and floods the Monitor-APs uplink if all theretransmitted packets get scheduled. To identify the du-plicate packets, we keep records ofIPID field in the IPheader of each overheard packet. Since IPID remainsthe same value for each MAC-layer retransmission, itallows Monitor-APs to identify and discard the samepacket. It is worth noting that in TCP transmission,the TCP sequence number is not a good indicator toidentify the duplicate packets, as it is unique for TCP-

layer retransmitted packets, but not unique for MAC-layer retransmissions.

3.2 Tunnel Forwarding

The transparency goals requires that the Sendersdata transfer session is unaware of the aggregation pro-tocol in BaPu. A seemingly straightforward solution isthatHome-AP andMonitor-APs forward the Senderspackets with spoofed IP addresses. It is, however, im-practical for two reasons: 1) many ISPs block spoofedIP packets; 2) forwarded packets by Monitor-APs areunreliable, because they are raw packets overheard from

the air. Our approach is that eachBaPu

-AP conveysthe Senders data via a separate TCP tunnel. Since wesupport a transparency for aggregation over multiplepaths, the techniques for tunnelling and address resolv-ing in each single path require a careful design at bothBaPu-APs and BaPu-Gateway.

Tunnel Connection: Once a BaPu-AP identifies anew Sender-Receiver session (step 3) based on the 6-tuple, it establishes a tunnel connection to BaPu-Gateway.Regardless of the session protocol, a tunnel connectionbetween the BaPu-AP and BaPu-Gateway is alwaysa TCP connection. The choice of TCP tunnel is par-tially motivated by the TCP-friendliness. We desire

to aggregate the idle bandwidth ofBaPu-APs withoutoverloading the ISP networks. Besides, since TCP tun-nel can provide a reliable channel, it helps keep a simplelogic for handling a reliable aggregated transmission.

Forwarding: In the registration (step 3) to BaPu-Gateway, the BaPu-AP receives an APID as its con-tributoridentifier for the new session. TheAPIDis usedin all messages in the protocol. Both control messages(registration, report, scheduling) and data messages are

5


6/14

exchanged via the TCP tunnel, which ensures reliabletransmissions. On reception of a scheduling messagewith matching APID, the Monitor-AP encapsulates thecorrespondingSenders packet in a BaPudata messageand sends it to BaPu-Gateway(step 8), which then ex-tracts the original data packet, delivers to the Receiver.In BaPu, the control messages are short, thus intro-ducing only a small overhead in the backhaul.

NAT: In WiFi network, the Senderis behind the Home-APand theSendermight also reside behind a gateway.By default, a NAT (network address translation) is per-formed for the session between the Senderand the Re-ceiver. In BaPu, the Senders data are conveyed tothe Receivervia separate tunnels from each participat-ing BaPu-AP. Therefore, different from the addresstranslation in a traditional network, BaPu requires thatthe NAT mapping information of the end-to-end sessionmust be known to transfer the embedded data to the de-sired Receiver. Consequently, in the registration step,each BaPu-AP, besides APID, also receives the NAT

mapping records from BaPu-Gateway.Besides, since the downlink capacity is enormous, we

allow all reverse (downlink) traffic fromReceiverto Sen-der to traverse along the default downlink path. In ad-dition, as there might be multiple tiers of NAT boxesin the middle, we must ensure that the NAT mappingfor a session is properly installed on all NAT boxesalong the path between Sender and Receiver in orderfor the returning traffic to traverse the NAT boxes prop-erly. Therefore, the first few packets in a session mustgo along the default uplink path. This means the firstpacket in UDP sessions or the 3-way handshake trafficin TCP sessions are not tunnelled.

3.3 TCP with Proactive-ACK

TCP ensures successful and in-order data delivery be-tween the Sender and the Receiver. In TCP, eachpacket is identified with a sequence number and must beacknowledged by theReceiverto indicate the proper de-livery. The Sendermaintains a dynamic CWND (con-gestion window) during the on-going session, which in-dicates the maximum number of packets that can besent on the fly, therefore determines the TCP through-put.

The Senders CWND size is affected by the acknowl-

edgements received from the Receiver. First, the growthrate of CWND depends on the rate of receiving acknowl-edgements, i.e., the link latency. Second, missing ac-knowledgement within a RTO (retransmission timeout)causes the Sender to issue a retransmission. On theother side, if the Receiver receives some out-of-ordersequence, it sends a DUPACK (duplicate acknowledge-ment) to inform the Sender of the missing packet. Bydefault [3], the Senderwill issue a fast retransmissionupon receiving 3 consecutive DUPACKs. Both retrans-

mission and fast retransmission cause the Senderto cutoff the CWND accordingly to slow down the sendingrate and adapt to the congested network or slow re-ceiver.

Performance issues with aggregation: TCP wasdesigned based on the fact that the out-of-order se-quence is generally a good indicator of lost packets or

congested network. However, such assumption no longerholds in BaPu.

Out-or-order packets: In BaPu, the packets be-longing to the same TCP session are intention-ally routed through multiple BaPu-APs via di-verse backhaul connections in terms of capacity,latency, traffic load, etc. This results in seriousout-of-order sequence at BaPu-Gateway, whicheventually injects the out-of-order packets to theReceiver.

Double RTT: Also, due to the aggregation proto-col, data packets in BaPuare delivered to the Re-ceiverwith a double round-trip-time (RTT) com-pared to a regular link. This causes the SendersCWND to grow more slowly and peak at lowervalues.

Consequently, with an unplanned aggregation method,the TCP congestion control mechanism is falsely trig-gered, resulting in considerably low throughput. As weshow later in Section 4, a simplified prototype of oursystem, which share similarities with the system in [15],gives poor TCP throughput.

Solution: To address the performance issue, we firstinvestigated a simple approach: data packets forwardedby BaPu-APs are buffered at BaPu-Gateway until acontinuous sequence is received before injecting to theReceiver. This solution, however, encounters the fol-lowing issues: 1) Efficiency: Introducing a buffer foreach session at BaPu-Gateway is wasteful of memory,since the Receiveralready maintains a TCP buffer forits own session. Furthermore, this does not scale wellwhen more simultaneous sessions are established. 2)Optimality: Due to the difference in capacity, latency,loss rate among backhaul uplinks, it is not clear how todetermine the optimal buffer size. 3) Performance: Infact, we implemented a buffering mechanism at BaPu-Gateway, and the results (Section 4.2) showed that us-

ing buffering mechanism does not help improving theTCP throughput.Now we introduce a novel mechanism called Proactive-

ACK, which is used in step 7 of BaPu protocol. Theprinciple of Proactive-ACK mechanism is to activelycontrol the exchange of acknowledgements instead of re-lying on the default behaviour of the end-to-end session.With Proactive-ACK, we solve bothout-of-order packetanddouble RTTissues. In the following paragraphs, wecall acknowledgements actively sent by BaPu-Gateway

6


7/14

spoofedacknowledgements, while the ones sent by theReceiver are real acknowledgements.

Managing DUPACK:In BaPu, most of out-of-orderpackets are caused by the aggregation mechanism viamultiple BaPu-APs. To avoid the cutting off of theCWND at the Sender, we intentionally discard all DU-PACKs received from the Receiver, as we observed that

most of DUPACKs generated by the Receiver inBaPu

are due to the multiple-path aggregation.However, by dropping DUPACKs from the Receiver,

we need to handle the case of actual lost packets in theair between the Sender and BaPu-APs. Concretely, ifthe report for expected TCP sequence number is notreceived within certain time window, it is implied thatthis sequence is lost on all participating BaPu-APs.Now that BaPu-Gateway sends a spoofed DUPACKback to the Sender in order to mimic the TCP fastretransmission mechanism for fast recovery from packetloss.

Managing ACK:Besides the effect of DUPACKs, the

CWND size of the Senderis also highly affected by thedouble RTT introduced by the protocol. Not only theCWND grows slowly, but the chance of CWND beingcut off is also higher. With Proactive-ACK mechanism,in step 7, BaPu-Gatewaysends back to the Sender thespoofed ACK after receiving the report from BaPu-APs. The intuition is that all the packets that arereported by some BaPu-APs are currently stored inthose BaPu-APs buffer. Due to the reliability of theTCP tunnel between BaPu-APs and BaPu-Gateway,the reported packets will be eventually forwarded toBaPu-Gateway in reliable manner. Therefore, as longas BaPu-Gateway identifies a continuous range of re-ported TCP sequence, immediately sending a spoofedACK back to the Senderhelps maintaining a high andconstant throughput, as the RTT with respect to theSenderis reduced to a value around the real RTT. Thisapproach prevents the cutting off of CWND at the Sen-der.

Since BaPu-Gatewaymanually sends spoofed ACKsto the Sender, on reception of real ACKs the Receiver,BaPu-Gatewaysimply discards the real ACKs.

TCP semantics: We have two important remarks onthe TCP semantics:

Immediately sending the spoofed ACKs after re-ceiving the reports may result in spoofed ACKSbeing received at the Sender before data packetsbeing forwarded to the Receiver. This increasesthe CWND in a more aggresive manner than thestandard mechanism.

Dropping real DUPACKs and sending spoofed DU-PACKS can increase the time for recovery of anactual loss of packet, because the loss reflected bythe Receiver is not immediately signaled to the

!"#$"%

&'#() +,-"./'#0/'1#

&'#() +,2%033'4 !506'#7 81)

95/: ; #"/"?0/"@0A

+,B CD2 81)

E 80+(>D+.

%(##'#7 F6"#GH2

IJ:6.

IKJ:6.

Figure 6: BaPu Experiment Setup. 7 BaPu-APs and1 BaPu-Gateway are inter-connected. A traffic shapingbox is set up in between to emulate a typical residentialnetwork setting.

Sender. For example, if an AP who has beenscheduled to forward the selected packet is sud-denly offline, it takes a longer time for the packetto be scheduled again after a timeout and laterforwarded to the Receiver.

Despite the slightly difference in TCP semantics, theProactive-ACK mechanism has been proved to give asignificant improvement to the TCP throughput. Wepresent these results in Section 4.

3.4 Scheduling

The bandwidth aggregation performance depends onthe efficiency of multiplexing data among BaPu-APsto best utilize the idle uplink bandwidth.

In BaPu, we adopt a centralized schedulerat BaPu-Gateway. There are two main factors to select thisdesign. First, with the centralized design, it does notonly simplify the implementation, but also allow easy

extension of the design with extra logic to further opti-mize the scheduling strategy. Second, a scheduler usu-ally requires complex processing and memory capabil-ity, which might overload the BaPu-APs with muchlower capability if scheduling decisions are migrated tothe APs.

The scheduling strategy is based on the received re-ports in step 6 and 7 of the protocol. Each report from aBaPu-APcontains a sending buffer size obtained fromthe Linux kernel via ioctl() function call. This valuespecifies how much a BaPu-APcan contribute to theaggregation. Based on reports, BaPu-GatewayappliesFirst-Come-First-Served strategy to select a forwarder

amongBaPu-APs who have captured the same packet.This approach is similar to those applied in [15, 16]. Therationale for choosing this approach are

Fairness: Sharing bandwidth for aggregation takesinto account the available bandwidth of participat-ing BaPu-APs, as because AP owners have differ-ent subscription plans.

Protocol independence: Scheduling decision is madebased on the BaPu-APs sharing capability, not

7


8/14

0

2

4

6

8

10

12

14

1 2 3 4 5 6 7AggregatedThroughput(Mbps)

Number of APs

BaPu UDP

BaPu TCP

(a) UDP and TCP throughput

40

50

60

70

80

90

100

1 2 3 4 5 6 7

Aggregationefficiency(%)

Number of APs

BaPu UDP / max UDP

BaPu UDP / max BaPu UDP

BaPu TCP / max TCP

BaPu TCP / max BaPu TCP

(b) UDP and TCP aggregation efficiency

Figure 7: BaPu aggregation for UDP and TCP with 2Mbps 32ms RTT uplinks.

Distance RTT

Regional: 500 - 1,000 mi 32ms [1]Cross-continent: 3,000 mi 96ms [1]Multi-continent: 6,000 mi 192ms [1]inter-AP in Boston 20ms 80ms

Table 3: Network RTT Latency. Inter-AP RTTmeasured by our Open Infrastructure WiFi testbed ingreater Boston, representing typical RTT between homeAPs, covering Comcast, RCN, and Verizon [24].

on the particular transport protocol.

4. EVALUATION

In this section, we evaluate the performance ofBaPufor UDP and TCP in various system settings.

Experiment Setup: Our experiment setup is shownin Figure 6. Our testbed consists of a Sender, 7 BaPu-APs, a BaPu-Gateway, a Receivernode, and a trafficshaping box. All APs are Buffalo WZR-HP-G300NH802.11n wireless routers. This router model has a 400MHzCPU with 32MB RAM. We reflashed the APs withOpenWRT firmware, running Linux kernel 2.6.32 andath9k WiFi driver. In our experiments, we select oneBaPu-AP to act as a Home-AP which the Sender isalways associated to. The other 6 BaPu-APs act asMonitor-APs to capture the traffic in monitor mode.The BaPu-Gatewayruns on a Linux PC, and the Re-ceiver runs behind the BaPu-Gateway. The Sender

and the Receiver are both laptops with 802.11n WiFicard, running the standard Linux TCP/IP stack.To emulate traffic shaping as with residential broad-

band, we use the traffic shaping box between the BaPu-APs and BaPu-Gateway. We use Linuxiptablesandtc with the htb module to shape the downlink band-width to 20Mbps and the uplink to 2Mbps. Also, to em-ulate network latency between BaPu-APs and BaPu-Gateway, we usenetemto shape the RTT with differentvalues. The bandwidth and latency parameter are se-

max UDP 1.94 Mbpsmax BaPu UDP 1.82 Mbpsmax TCP 1.9 Mbpsmax BaPu TCP 1.8 Mbps

Table 4: Maximum theoretical goodput for UDP and

TCP with and without BaPu overhead. Data payloadsize is 1350Bytes. Uplink capacity is 2Mbps.

lected to represent the typical bandwidth capacity andregional latency in residential cable broadband that wehave measured in Bostons urban area (Table 3).

In our experiments, we issue long-lived 30 minutesiperfflows (both TCP and UDP) from Sender toRe-ceiver. We choose 1350Byte as TCP/UDP payload sizein our iperf test to make sure that the whole clientIP packet can be encapsulated in one IP packet whilean BaPu-AP sends it through its TCP tunnel. All

throughput values reported in our experiment are theiperfthroughput, which is the goodput.

In the evaluation, we compare throughput of UDPand TCP in different system scenarios. More precisely,we evaluate the following scenarios:

BaPu: BaPu system without any buffering orProactive-ACK mechanism.

SimpleBuffer: BaPu system without Proactive-ACK mechanism, but enhanced by buffering atBaPu-Gateway.

BaPu-Pro: this is the full BaPu system.

4.1 BaPu: Efficient UDP, Poor TCP

4.1.1 System efficiency with UDP throughput

The practicality ofBaPulies in its efficiency. In con-trast to related work, BaPus transparency goal, notrequiring any modifications at the client side, has moti-vated the design ofBaPus underlying technical details.We now first measureBaPus efficiency by the through-put with UDP, as it provides a light-weight end-to-end

8


9/14

0

40

80

120

160

20 40 60 80 100 120CWNDSize(KB)

Time (sec)

BaPu CWND Regular TCP CWND

Figure 8: Senders TCP CWND growth compared be-tweenBaPuand regular single AP with 32ms RTT andtotal 14Mbps uplink.

transmission between Sender and Receiver. Figure 7ashows the achieved aggregated UDP throughput withnumbers of participating BaPu-APs increasing from 1to 7. We observe that the aggregated UDP through-put increases proportionally with the number ofBaPu-APs, and achieves 12.4Mbps with 7 BaPu-APs. Toput this figure into perspective, note that related workby Jakubczak et al. [15] achieves similar UDP through-

put but without support for TCP or client transparency.

4.1.2 Low TCP throughput

We conduct the same experiments also for TCP trans-mission. Figure 7a shows that the aggregated TCPthroughput does not benefit much when the number ofBaPu-APs increases. The TCP aggregated throughputis always lower than the UDPs in the same setup, andthe gap between UDP and TCP performance increasesalong with the number ofBaPu-APs. For example, weachieve only 6.83Mbps with 7 BaPu-APs.

4.1.3 Aggregation efficiency

In addition to measuring aggregated throughput, weevaluate our system based on another metric, aggre-gation efficiency. We define aggregation efficiency asthe ratio between practical throughput over the maxi-mum theoretical goodput. Due to the TCP/IP headerand BaPu protocol overhead, the actual goodput isless than the uplink capacity. With all protocol headeroverhead accounted, we derive the maximum theoreti-cal goodput as the given backhaul capacity of 2Mbps.Table 4 lists the maximum throughput when data istransmitted via standard UDP/TCP and via BaPu.

As shown in Figure 7b, BaPuUDP can harness closeto 100% idle bandwidth. Even if we consider the extraoverhead incurred by BaPu protocol messages, UDPaggregation efficiency is still over 90% in all cases. Incontrast, the aggregation efficiency for TCP degradesquickly as more BaPu-APs join the cooperation. With7 BaPu-APs, BaPutransforms only 50% of idle band-width to effective throughput.

4.1.4 Discussion:BaPus poor TCP performance

We can observe several factors in Section 3.3 that de-

1

2

3

4

5

6

7


Number of APs

Basic TCPSimpleBuffer TCP

Figure 9: BaPu vs. SimpleBuffer comparison inTCP throughput with 2Mbps 32ms RTT uplinks.

crease the aggregated TCP throughput. In this section,we carry out an analysis on the Senders CWND size inBaPu. To justify our analysis, we inspect the TCP be-havior by examining the Linux kernel TCP stack vari-ables. We call getsockopt() to query the TCP_INFOLinux kernel data structure. TCP_INFO includes thesystem time stamp, the Senders CWND, number of

retransmissions, etc. We have modified the iperfcodeto log TCP_INFOeach time iperf calls send() to writethe application data to the TCP socket buffer.

Figure 8 shows the CWND growth in a 120 secondiperftest with 7 BaPu-APs. The theoretical through-put here 2Mbps7 = 14Mbps. In comparison, we carryout another iperf test with standard TCP through asingle, regular AP with 14Mbps uplink capacity. TheCWND growth in a normal TCP connection is alsoshown in Figure 8. As shown, the Senders CWNDremains at a very low level. Our captured packet traceat the Sendershows that lots of DUPACK packets andRTO incur a lot of retransmissions, which results in verylow TCP throughput.

4.2 Does SimpleBuffer help?

As discussed in Section 3.3, a simple buffering mech-anism doesnotsolve the TCP performance issue due todifference in BaPu-APuplink characteristics (latency,packet loss). In this section, we show experimentallythat a buffering mechanism cannot help in improvingthe TCP throughput. The experiment is performed forequal uplink capacity and latency, i.e., we eliminate ex-ternal factors such as asymmetric links among BaPu-APs.

Figure 9 depicts the throughput comparison betweenBaPuand SimpleBuffer. Surprisingly, the through-put is worse with SimpleBuffer. We have also ad-

justed the buffer size at BaPu-Gateway, but the through-put still remains as low as shown in Figure 9. We haveinvestigated Senders CWND, and we have seen that itpeaks at low values, similarly to the behavior in BaPu.The packet trace also shows a lot of retransmissions.

4.3 BaPu-Pro Performance

9


10/14

0

2

4

6

8

10

12

14


Number of APs

BaPu TCP

BaPu-Pro TCP

(a) Aggregated TCP throughput

40

50

60

70

80

90

100

1 2 3 4 5 6 7Efficiencyofaggregation(%)

Number of APs

BaPu-Pro TCP / max TCP

BaPu-Pro TCP / max BaPu TCP

BaPu TCP / max TCP

BaPu TCP / max BaPu TCP

(b) Aggregation efficiency

Figure 10: BaPu-Provs. BaPu: comparison with 2Mbps 32ms RTT uplinks.

0

50

100

150

200

250

100 200 300 400 500 600CWNDSize(KB)

Time (sec)

BaPu CWND BaPu-Pro CWND Regular TCP CWND

Figure 11: TCP sender CWND growth comparison: BaPu-Provs. BaPu vs. normal TCP.

Now, we conduct a comprehensive set of experimentsto evaluate the performance of BaPu-Pro. First, wevalidate our Proactive-ACK mechanism by comparingBaPu-Pro against BaPu. Second, we measure theperformance of BaPu-Pro under a variety of networksettings (network latency, wireless link quality, etc.).Finally, we demonstrate that BaPu-Prois feasible forboth, streaming and large file transfer applications.

4.3.1 TCP Throughput BaPu-Provs. BaPu

We carry out the same iperf test as described inSection 4.1 with BaPu-Pro. As shown in Figure 10a,the aggregated TCP throughput of BaPu-Pro signif-icantly outperforms the one ofBaPu. With 7BaPu-APs, BaPu-Pro achieves 11.04Mbps, i.e., 62% im-provement over BaPu. Furthermore, Figure 10b showsthat BaPu-Pro achieves at least 88% aggregation ef-ficiency in our setup, and it achieves at least 83% ofthe upper limit of standard TCP throughput. Theseresults demonstrate that BaPu-Pro can achieve highaggregated throughput with high aggregation efficiencyfor TCP in practical settings.

4.3.2 Proactive-ACK benefit

To justify our Proactive-ACK mechanism, we adoptthe same method as in Section 4.1.4 to examine theTCP CWND growth. Figure 11 shows that BaPu-Pro allows the CWND to grow to very high values,contributing to the high throughput. For convenience,we also run a regular TCP session with a throttled band-width 11Mbps (similar to the BaPu-Pros resulted through-put). The CWND growth for BaPu-Pro and regular

TCP shares a similar pattern, which implies that ourdesign and implementation can efficiently and transpar-ently aggregate multiple slow uplinks.

4.3.3 Impact of network latency

For TCP transmissions, RTT is an important factorthat has impact on the throughput. In another experi-ment, we measure the performance ofBaPuwith 4 dif-ferent network latency settings listed in Table 3. Eachlatency represents certain application scenarios. For ex-ample, when users upload HD video with BaPu to CDNedge servers, the latency to CDN servers is generallythe regional latency (32ms). When users upload datato their friends in another continent, the RTT is on av-erage 192ms. Besides, according to our measurementsin a residential WiFi testbed [24], we observe that thelatency between broadband subscribers may vary con-siderably, ranging between 20ms and 80ms. This de-pends on whether users are with the same or a differentISP. Consider the case that a user uploads data withBaPuthrough neighboring APs to another user in thesame city, the latency between the BaPu-APs and the

end user can be quite different.Given a certain number of APs, we assign to eachBaPu-APa random RTT value between 20ms and 80ms.We carry out this test for 10 runs and report the av-erage throughput. As shown in Figure 12a, BaPu-Prothroughput slightly declines as network latency in-creases. In random latency setting, the resulted through-put shows no significant difference.

4.3.4 Impact of lossy wireless links

10


11/14

0

2

4

6

8

10

12


Number of APs

32ms RTT

96ms RTT

192ms RTT

Random RTT

(a) Different RTT

0

2

4

6

8

10

12

2 3 4 5 6 7AggregatedThroughput(Mbps)

Number of APs

P=0%

P=20%

P=40%

P=60%

(b) Different packet loss rate P on Monitor-APs

Figure 12: BaPu-Pro TCP throughput.

0

5

10

15

20

25

30

35

40

0 20 40 60 80 100

Throughput(Mbps)

Time (sec)

streaming 11Mbpsiperf unlimited rate

Figure 13: Instantaneously received throughput com-parison: 11Mbps Streaming vs. Unlimited rate.

The wireless links in a real neighbourhood can bevery lossy for a variety of reasons, such as cross chan-nel interference and distant neighboring APs. Besides,sinceMonitor-APs switch between transmit and receivemode, they cannot overhear all transmitted packets. Toestimate the potential of BaPu highly lossy wirelessenvironments, we emulate packet loss at Monitor-APsby dropping received packets with a probability P. Nolosses were inflicted on Home-AP, because Sender car-ries out unicast toHome-AP, and 802.11 MAC alreadyhandles packet loss and retransmissions automatically.We conduct the experiment with 3 values of P: 20%,40%, and 60%.

As indicated in Figure 12b, the throughput reductionon lossy wireless links is very limited in all cases. Thegood performance can be explained by the link diversitycombined with the centralized scheduling mechanisms.

The probability of some packet not overheard byat least

one Monitor-AP is negligible small, especially in caseof high number of participating APs. This also explainswhy 7 BaPu-APs achieve higher throughput with P =60% than with P= 20%.

4.3.5 Streaming vs. large file transfer

One important goal in BaPus design is to supportinstant sharing of high-bitrate HD videos directly be-tween users using streaming. The motivation behind

0 500 1000 1500 2000 2500 3000 35000

5

10

15

20

25

Time (s)

Thr

oughput(Mbps)

User DownloadBackground Upload

Figure 14: Regular user download behaviour with andwithout background upload traffic. No impact is appar-ent in the presence of competing background traffic.

is that today the major online streaming services (e.g.,Netflix) run on TCP based streaming technologies, suchas HTTP based Adaptive Bitrate Streaming. Real timestreaming generally requires stableinstantaneous through-put. In this experiment, we study the potential ofBaPuas a solution to high-bitrate real-time streaming.

To emulate the streaming traffic, we use nuttcp toissue a TCP flow with a fixed 11Mbps sending rate.Figure 13 shows Receivers instantaneous throughputin a 100 second session. Receiverachieves a reasonablystable throughput in the whole session. It indicates thatBaPu can sustain high-bitrate streaming through ag-gregated uplinks. In comparison, the iperf flow withunlimited sending rate shows much higher fluctuation.

5. IMPACT OF UPLINK SHARING

BaPu is essentially a crowd-sourcing approach thatshares users idle bandwidth to help others. The goalis to harness as much idle bandwidth as possible withminimal impact on home users network usage. We firstshow that with standard Linux traffic shaping tools,bandwidth sharing has minimal impact on regular traf-fic. Next, we study how much bandwidth can be har-nessed with a testbed in residential broadband.

5.1 Prioritizing Home Users Traffic

11


12/14

0 200 400 600 800 1000 1 200 1 400 1 600 1 800 2 0000

0.5

1

1.5

2

2.5

3

Time (s)

Throughput(Mbps)

User UploadBackground Upload

Figure 15: Regular uplink observation with and withoutbackground traffic. The low-priority background trafficbacks off as soon as regular traffic starts.

Techniques and tools for traffic shaping, such as Linuxstcare widely available. While a full-fledged system mayuse complicated traffic prioritization, it is sufficient forBaPu to simply classify traffic in two classes: regular

user traffic with the highest priority, and backgroundsharing traffic with a minimum bandwidth guarantee,but allowed to grow if more bandwidth is available. Toimplement this, we use Hierarchical Token Bucket andStochastic Fair Queuingmodules withintcto fairly dis-tribute traffic belonging to the same class.

We set up the traffic shaping on one OpenWRT homerouter, and validate the correctness of the traffic shap-ing with two tests. In the first test, we first generate reg-ular download traffic for 10 minutes to obtain a baselineof APs download throughput. After the baseline mea-surement, we start the background upload for 20 min-utes, emulating the uplink sharing. As the upload goes

on, we relaunch the regular download traffic. As shownin Figure 14, the users regular download throughputis not affected, because the TCP ACKs related to theuser download have been prioritized. Also, TCP ACKsconsume limited uplink bandwidth, and thus has negli-gible impact to the background upload. In the secondtest, we examine the analogous case for regular uploadtraffic. We first start emulated background upload witha minimum bandwidth guarantee of 500Kbps. Duringthe background upload, we start the regular user up-load. As shown in Figure 15, the regular upload traffictakes over more bandwidth, while the background up-load backs off properly (but not lower than 500Kbps).

We conclude that with proper traffic shaping, BaPucan provide uplink sharing with a minimal impact onusers regular traffic.

5.2 Push Uplink Sharing to the Limit

To find out how much idle uplink bandwidth can beharnessed, we instrument an uplink throughput exper-iment to 17 residential APs, covering 2 major ISPs inBoston (Table 5). Each AP is configured with proper

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 170

20

40

60

80

100

APs

PercentageofAPOnlineTime(%)

< 1Mbps 12Mbps 23Mbps >3Mbps

Figure 16: Fraction of time spent by each AP with cer-tain background upload throughput over the APs totalonline time.

101

102

103

104

105

106

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Flow Duration (s)

CDFofFlows

> 1.5Mbps> 2.0Mbps> 2.5Mbps

Figure 17: Duration of background traffic flow of certainthroughput classes.

traffic shaping. With constant background upload, eachAP reports background upload throughput every 10 sec-onds, lasting for 16 days.

Table 5: Uplink experiment data summary

Home APs Comcast (14), RCN (3)Data collection time May 22 Jun 13, 2012Mean AP online time 381 hours ( 16 days)Throughput samples 2.3 millions

As shown in Figure 16, all APs can share 1-3Mbpsuplink throughput during most of the experiment time.Each APs mean shared throughput is very close to itsuplink limit set by ISP. Also, we investigate how longa certain upload throughput can last. Figure 17 showsthe the CDF of duration for which the background up-load can sustain certain throughput during peak hours(18pm23pm). We see that, there is over 80% chancethat the background upload throughput can stay above2Mbps for over 30 minutes. To conclude, there is abun-dant idle uplink bandwidth in residential broadbandthat can be exploited for upload sharing.

6. RELATED WORK

BaPusystem is inspired by design principles of sev-eral earlier protocols, it however addresses unique con-

12


13/14

straints and goals and results in a novel combination oftechniques that achieves high efficiency. Several earlierresearch works proposed to improve the performanceof TCP over wireless links by using intermediate nodesto assist in the recovery of lost packets include SnoopTCP [5], and Split TCP for ad hoc networks [17]. Mul-tiple radio links to improve devices throughput havealso been explored from several perspectives including

traffic aggregation [16], mutipath forwarding [15], mit-igation of wireless losses [21, 22]. In addition to sys-tems that rely on multiple radio interfaces [4], manysolutions and algorithms were proposed for a single ra-dio interface that carefully switches across multiple ac-cess points while providing the upper layers of the net-work stack a transparent access through a virtual in-terface [8, 16, 20, 31]. Solutions to overcome the lim-ited APs backhaul through aggregation using a virtu-alized radio interface include the initial Virtual-WiFisystem where two TCP connection might be services bythrough two different APs [20], FatVAP that achievesfast switching a smart AP selection [16], ARBOR thatadd security support [31], Fair WLAN that providesfairness [12]. Many of these systems require techniquesfor fast switching across access points to reduce the im-pact on TCP performance in terms of delay and packetloss as proposed in Juggler [23], and WiSwitcher [11].In [28], an analytical model is proposed to optimze con-current AP connections for highly mobile clients. Theyalso implement Spider, a multi-AP driver using optimalAP and channel scheduling to improve the aggregatedthroughput. Unlike BaPu, these works do not aggregatethe throughput for single transport layer connection,which is critical for client transparency. Divert [22] pro-

pose a central controller to select the optimal AP acrossmultiple BSes in WLANs in order to reduce the path-dependent downlink loss from AP to client. Rather thanimproving the wireless link quality, BaPu is aimed to ag-gregate the wired capacity behind APs. In BaPu, thesender communicates with its home AP as usual. How-ever, BaPu does benefit from the link diversity acrossAPs while aggregating the backhaul capacity. ViFi [6]propose a probabilistic algorithm for coordination be-tween basestations to improve the opportunistic con-nectivity of the client-BS communication. Similar toDivert, ViFi is not for aggregating throughput. Also,in section 3.4, we show that such probabilistic solution

sets limitations on throughput aggregation. The closestapproach to our work is the Link-alike system whereaccess points coordinate to opportunistically schedulethe traffic over their backhaul links [15]. Our approachdiffers from previous work in requiring that the clientdevices remain unchanged (unicast connection to theAP) and transparently supports protocols like TCP.

Being completely transparent to the clients and con-straining each link AP-Destination flow to be TCP-

friendly makes efficient multipath transport, a key com-ponent of our system. There has been a significantamount of work in this area for quite some time fromvarious perspectives that are fairly different from oursetup. Previous work identified the issues with differ-ential delay, and rates and mostly focussed on provid-ing reliability, flows balancing, and maintaining fair-ness. Proposed solutions, require the modification of

the client devices network stacks, and usually do notaim at increasing capacity through simultaneous use ofall paths. For example, the IETF has two standardson transport protocols using multipath. The StreamControl Transmission Protocol (SCTP) was primarilydesigned for multi-homed devices that require fail-oversupport [29], the more recent Multi-Path TCP (MPTCP)is a TCP extension that aims at enabling nodes to effi-ciently communicate utilizing multiple parallel paths [10].In recent work, [30] proposed a congestion control mech-anism for MPTCP with the objective of reliability andfairness. Other transport protocols that require themodification of the client devices, include pTCP [13] anend to end transport protocol that achieves bandwidthaggregation on multi-homed mobile hosts, RCP [14] aReceiver Centric Protocol that aggregates heterogeneousinterfaces traffic and carries link specific congestion con-trol, R-MTP [18] balances and coordinates the trafficover wireless links with varying characteristics, Hori-zon [26] uses back-pressure technique to balance thetraffic across forwarding paths. Beyond mobile com-munication environments, multipath TCP features havealso been finding applications in various networking en-vironments such as data [7, 27]. The distinguishingelement ofBaPu is that it aims at transparently sup-

porting unmodified client devices and TCP/IP stackswhile efficiently aggregating the APs backhauls.

7. CONCLUSION

In this work, we present the design and implemen-tation of BaPu, a complete software based solution onWiFi APs for aggregating multiple broadband uplinks.First, with a large scale wardriving data and a long termmeasurement in Boston residential broadband, we showthat the high AP density and under utilized broadbanduplinks calls for a solution to harness the idle bandwidthfor a boosted uplink throughput.

With our client transparent design, BaPu offers genericsupport for legacy client and a large variety of networkapplications. However, the client transparency designraises many new technical challenges. In particular, wepropose a novel mechanism, called Proactive-ACK, toaddress the challenge of multiplexing single TCP ses-sion through multiple paths without degrading perfor-mance. The benefit of such mechanism is analysed withexperimental data. We carry out an extensive set ofexperiments to evaluate the BaPu throughput perfor-

13


14/14

mance for both UDP and TCP, in a variety of realisticnetwork settings. BaPu achieves over 95% aggregationefficiency for UDP and over 88% for TCP, even in lossywireless environment.

Besides, to further justify the feasibility of BaPu asa crowd-sourcing mechanism, we empirically show thepotential idle uplink bandwidth that can be harnessedfrom residential broadband networks. We also provide

a design guideline for such bandwidth sharing system toeliminate the negative impact to home users. Also, thesoftware based solution makes BaPu an easy incremen-tal deployment, especially as APs are becoming socialand cloud-managed.

References

[1] Akamai HD Network.Akaimai Technical Report, 2011.http://www.akamai.com/dl/brochures/Akamai_HD_Network_Solution_Brochure.pdf.

[2] A. Akella, G. Judd, S. Seshan, and P. Steenkiste. Self-management in chaotic wireless deployments. WirelessNetworks, 2007.

[3] M. Allman, V. Paxson, and E. Blanton. Tcp congestioncontrol, 2009.

[4] P. Bahl, A. Adya, J. Padhye, and A. Walman. Re-considering wireless systems with multiple radios. SIG-COMM Compututer Communication Review, 34:3946,2004. ISSN 0146-4833.

[5] Hari Balakrishnan, Srinivasan Seshan, Elan Amir, andRandy H. Katz. Improving TCP/IP performance overwireless networks. In Proceedings of MobiCom, 1995.

[6] A Balasubramanian, R Mahajan, A Venkataramani,BN Levine, and J Zahorjan. Interactive wifi connec-tivity for moving vehicles. Proc. of SigComm, 2008.

[7] S. Barre, C. Paasch, and O. Bonaventure. MultiPathTCP: from theory to practice. In Proceedings of NET-WORKING, 2011.

[8] R. Chandra and P. Bahl. Multinet: connecting to mul-tiple ieee 802.11 networks using a single wireless card.In Proc. of INFOCOM, 2004.

[9] FON. FON, 2012.http://corp.fon.com/us/.

[10] A. Ford, C. Raiciu, M. Handley, and O. Bonaventure.TCP Extensions for Multipath Operation with MultipleAddresses. Internet-Draft, 2012.

[11] D. Giustiniano, E. Goma, A. Lopez, and P. Rodriguez.Wiswitcher: an efficient client for managing multiple

aps. In Proceedings of PRESTO, 2009.[12] D. Giustiniano, E. Goma, A.L. Toledo, I. Dangerfield,

J. Morillo, and P. Rodriguez. Fair WLAN backhaulaggregation. In MobiCom, 2010.

[13] H.-Y. Hsieh and R. Sivakumar. A transport layer ap-proach for achieving aggregate bandwidths on multi-homed mobile hosts. In Proceedings of MobiCom, 2002.

[14] H.-Y. Hsieh, K.-H. Kim, Y. Zhu, and R. Sivakumar.A receiver-centric transport protocol for mobile hostswith heterogeneous wireless interfaces. In Proceedingsof MobiCom, 2003.

[15] S. Jakubczak, D. G. Andersen, M. Kaminsky, K. Pa-pagiannaki, and S. Seshan. Link-alike: using wirelessto share network resources in a neighborhood. SIG-MOBILE Mobile Computing Communications Review,2008.

[16] S. Kandula, K.C. Lin, T. Badirkhanli, and D. Katabi.FatVAP: Aggregating AP backhaul capacity to maxi-mize throughput. In Proceedings of NSDI, 2008.

[17] Swastik Kopparty, Srikanth V. Krishnamurthy,Michalis Faloutsos, and Satish K. Tripathi. Split tcpfor mobile ad hoc networks. In GLOBECOM, 2002.

[18] L. Magalhaes and R.H. Kravets. Transport Level Mech-anisms for Bandwidth Aggregation on Mobile Hosts. InProceedings of Conference on Network Protocols, 2001.

[19] Meraki. Meraki, 2012.http://www.meraki.com/.

[20] Microsoft Research. Virtual wifi, 2012.http://research.microsoft.com/en-us/um/redmond/projects/virtualwifi/.

[21] Allen Miu, Hari Balakrishnan, and Can Emre Koksal.Improving loss resilience with multi-radio diversity inwireless networks. MobiCom 05.

[22] Allen K. Miu, Godfrey Tan, Hari Balakrishnan, andJohn Apostolopoulos. Divert: Fine-grained path selec-tion for wireless lans. In Proc. of MobiSys, 2004.

[23] Anthony J. Nicholson, Scott Wolchok, and Brian D. No-ble. Juggler: Virtual networks for fun and profit. IEEETransactions on Mobile Computing, 9:3143, 2010.

[24] Open Infrastructure. Open infrastructure: A wirelessnetwork research framework for residential networks.http://www.ccs.neu.edu/home/noubir/projects/openinfrastructure/, 2012.

[25] OpenWRT. OpenWRT Wireless Freedom, 2012.http://openwrt.org/.

[26] B. Radunovic, C. Gkantsidis, D. Gunawardena, andP. Key. Horizon: Balancing TCP over multiple pathsin wireless mesh network. In Proc. of MobiCom, 2008.

[27] C. Raiciu, S. Barre, C. Pluntke, A. Greenhalgh, D. Wis-chik, and Ma. Handley. Improving datacenter p erfor-mance and robustness with multipath TCP. In SIG-COMM 11, 2011.

[28] Hamed Soroush, Peter Gilbert, Nilanjan Banerjee,Brian Neil Levine, Mark Corner, and Landon Cox. Con-current Wi-Fi for mobile users: analysis and measure-

ments. In CoNEXT 11, 2011.

[29] R. Steward. Stream control transmission protocol.IETF RFC 4960, 2007.

[30] D. Wischik, C. Raiciu, A. Greenhalgh, and M. Handley.Design, implementation and evaluation of congestioncontrol for multipath TCP. In Proc. of NSDI, 2011.

[31] X. Xing, S. Mishra, and X. Liu. ARBOR: hang togetherrather than hang separately in 802.11 wifi networks. InProc. of INFOOCM, 2010.

14

Documents

Bapu Techreport