Fig1Residentialuplinkbandwidthusage - PDF document

1 Fig.1:Residentialuplinkbandwidthusage. F
Fig.1:Residentialuplinkbandwidthusage. Fig.2:AvailableAPsinWardriving.connectionthroughputcannotexceedthesinglebroadbandlinkcapacity.SincemostuplinkhoggingapplicationssuchasiCloudestablishsingletransportlayerconnectionsfordatatransfer,currentAPaggregationsolutionsarenotsuitableforsinglesessionuplinkscaling,unlesstheapplicationisredesignedtoadapttotheAPaggregationtech-nology.Recently,Link-Alike[15]multiplexessingleUDPowacrossmultipleAPs.However,Link-Alike'sdesignisspecictoUDPletransfer,resultingpiecesoflestoarriveinout-of-ordersequence,whichprohibitsTCPbasedapplications(e.g.,HDvideostreaming)thatrequireastrictlyin-orderdeliveryanddeadlinemeeting.Besides,multiplexingsingleTCPsessionsthroughmultiplepathsisachallengingproblem(andwillbediscussedlater).Moreover,clientmodicationsarerequiredtosupportTCP.Inthiswork,werequireanewAPaggregationsolutionofferingcompletetranspa

2 rencyontheclientwithgenericsupportforeit
rencyontheclientwithgenericsupportforeitherTCPorapplications.1.2FeasibilityofAPAggregationWhileWiFiaggregationallowsbypassingbroadbandlimitations,itisyetunclearwhetheraggregationispracticalinreality.WenowpresentourrecentstudyonurbanWiFiandbroadbandresources,revealingseveralinterestinginsightsregardingthefeasibilityofAPaggregationinresidentialbroadband.Mostlyidlebroadbanduplinks:SinceFeb.2011,wehavedevelopedanddeployedaWiFitestbedinBoston'surbanarea,aimingtomonitortheusagepatternofresidentialbroadband.Thistestbedconsistsof30homeWiFiAPsrunningcustomizedOpenWRTrmwarewithtwomajorbroadbandISPs,ComcastandRCN.Duringa18monthperiod,wehavecollectedover70millionrecords.Figure1showstheuplinkbandwidthusageduringa24hourtimewindow.Throughouttheday,thereisatleast50%chancethatuplinkiscompletelyidle.Evenduringpeakhours,thereisover90%chancethattheuplinkbandwidthusageisbelow100Kbps.Consequently,the

3 reexistsaconsiderableamountofidleuplinkb
reexistsaconsiderableamountofidleuplinkbandwidth,makingAPaggregationaviableapproach.WiFidenselydeployedinresidentialarea:OurrecentlyconductedWardrivingmea-surementsin4residentialareasinBostonidentify22000APs,14.2%ofwhichareunencrypted.AsshowninFigure2,thereareonaverage17APsavailableateachlo-cation,withanaverage7to12APsoneachchannel.ThisenormouspresenceofWiFijustiesthefeasibilityofAPaggregationinurbanarea.WiFibecomingopenandsocial:DrivenbytheincreasingdemandofubiquitousIn-ternetaccess,thereisanewtrendthatbroadbanduserssharetheirbandwidthaspublic Destination1.BothusersareconnectedtotheirownHome-APs.Sender1'suplinkisthrottledbyhisISPto13Mbps,preventinghimtohandlethe8MbpsHDvideoinrealtime.HoweverwithBAPU,theidleuplinkoftheneighboringMonitor-APsareexploitedtoboostuplinkthroughput.BAPU-Gateway,theHome-APofDestination1,aggregatesandforwardsmultiplexedtrafctoDestination1.Scenar

4 io2.InstantBackupofLargeFile:Sender2wish
io2.InstantBackupofLargeFile:Sender2wishestobackuphisHDvideocliptosomecloudstorageservicesuchasiCloud.Withthe3Mbpsuplinkrate,ittakesoveranhourtouploada30minuteHDvideo.WithBAPU,uploadingtimeisgreatlyreducedbydeloyingaBAPU-Gatewayinfront(orpart)ofthecloudstorageserversforhandlingparalleluploadsfromHome-APandneighboringMonitor-APs.BAPUProtocolDescriptionInBAPU,SenderisassociatedwithitsHome-AP,andtheuploadingofdataisag-gregatedviaunencryptedwirelesslink.Thedata,however,isprotectedwithsomeend-to-endsecuritymechanism(e.g.,SSL/TLS).Home-APandMonitor-APareconguredtoruninbothWiFiAPmodeandWiFimonitormode4.TheWiFilinkbetweentheSenderanditsHome-APgenerallyprovideshighbandwidth,uptohundredsofMbpswith802.11n.ThelinkbetweenaBAPU-APandtheDestination,however,isthrot-tledbytheISP.Attheremoteend,weplaceaBAPU-GatewayimmediatelybeforetheDestination.TheconnectionbetweentheBAPU-GatewayandtheDestinatio

5 niseitherwiredorwirelesshigh-speedlink.N
niseitherwiredorwirelesshigh-speedlink.Notethatbeinginproximity,unicastsbetweenSen-derandHome-AP(APmode)canbeoverheardby(someof)theMonitor-APs(monitormode).Atahighlevel,BAPUisacentralizedsystemwiththecontrollerresidingatBAPU-Gateway,providinganuplinkaggregationcarriedoutasfollows(Figure4). Fig.4:BAPUProtocolTrafcFlow.TheACKs(redcolor)aremanagedforTCPonly.1.SenderstartsaTCP/UDPuploadtoDestinationthroughitsHome-APviaWiFi.2.Home-APandMonitor-APoverhearWiFipacketsandidentify“BAPU”sessionbycheckingthedestinationIPandport.3.BAPU-APsregisterthemselvestoBAPU-Gateway.4.Home-APandMonitor-APcaptureSender'spacketsinmonitormode,andcollabo-ratetouploaddataforSender,followingascheduledeterminedbyBAPU-Gateway. 4ModernWiFidrivers(e.g.,ath9k)supportmultiplemodesforonephysicalWiFiinterface. DuplicateElimination:Unicastingapacketmayinvolveanumberof(MAC-layer)re-transmissionsduetowirelessl

6 ossbetweentheSenderanditsHome-AP.Thisinc
ossbetweentheSenderanditsHome-AP.Thisincreasesthetransmissionreliability.Nevertheless,itispossiblethatanearbyMonitor-APcanoverhearmorethanone(re)transmissionofthesamepacketandeventuallyforwardunnecessaryduplicatestoDestination,oodingMonitor-AP'suplink.Toidentifytheduplicatepackets,wekeeprecordsofIPIDeldofeachoverheardIPpacket.SinceIPIDremainsthesamevalueforeachMAC-layerretransmission,itallowsMonitor-APstoidentifyanddiscardthesamepacket.ItisworthnotingthatinTCPtransmission,theTCPsequencenumber(SEQ)isnotagoodindicatortoidentifytheduplicatepack-ets,asitisuniqueforTCPretransmission,butnotforMAC-layerretransmissions.3.2TunnelForwardingThetransparencygoalsrequiresthatthehigh-levelapplicationbeunawareoftheag-gregationprotocolinBAPU.AseeminglystraightforwardsolutionisthatHome-APandMonitor-APsforwardtheSender'spacketswithspoofedIPaddresses.Itis,how-ever,impracticalfortworeasons:1)man

7 yISPsblockspoofedIPpackets;2)forwardedpa
yISPsblockspoofedIPpackets;2)forwardedpacketsbyMonitor-APsareunreliable,becausetheyarerawpacketsoverheardfromtheair.OurapproachisthateachBAPU-APconveystheSender'sdataviaaseparateTCPtunnel.Sincewesupportatransparencyforaggregationovermultiplepaths,thetechniquesfortunnellingandaddressresolvingineachsinglepathrequireacarefuldesignatbothBAPU-APsandBAPU-Gateway.TunnelConnection:OnceaBAPU-APidentiesanewSender-Destinationsession(step2)basedonthe6-tuple,itestablishesatunnelconnectiontoBAPU-Gateway.Re-gardlessofthesessionprotocol,atunnelconnectionbetweentheBAPU-APandBAPU-GatewayisalwaysaTCPconnection.ThechoiceofTCPtunnelispartiallymotivatedbytheTCP-friendliness.WedesiretoaggregatetheidlebandwidthofBAPU-APswith-outoverloadingtheISPnetworks.Besides,sinceTCPtunnelcanprovideareliablechannel,ithelpskeepasimplelogicforhandlingareliableaggregatedtransmission.Forwarding:Intheregistration(step3)t

8 oBAPU-Gateway,theBAPU-APreceivesanAPIDas
oBAPU-Gateway,theBAPU-APreceivesanAPIDasits“contributor”identierforthenewsession.TheAPIDisusedinallmes-sagesintheprotocol.Bothcontrolmessages(registration,report,scheduling)anddatamessagesareexchangedviathereliableTCPtunnel.Onreceptionofaschedulingmes-sagewithmatchingAPID,theMonitor-APencapsulatesthecorrespondingSender'spacketinaBAPUdatamessageandsendsittoBAPU-Gateway(step8),whichthenextractstheoriginaldatapacket,deliverstotheDestination.InBAPU,shortcontrolmessagesonlyintroducesmalloverheadinthebackhaul.NAT:InWLAN,theSenderisbehindtheHome-AP,typicallyaNATbox.InBAPU,theSender'sdataareconveyedtotheDestinationviaseparatetunnelsfromeachparticipat-ingBAPU-AP,whichcarriesoutNATtranslationwithNATmappingrecordsobtainedfromBAPU-Gatewayinstep3.Besides,sincethedownlinkcapacityisenormous,weallowallreverse(downlink)trafcfromDestinationtoSendertotraversealongthedefaultdownlinkpa

9 th.Inaddition,astheremightbemultipletier
th.Inaddition,astheremightbemultipletiersofNATboxesinthemiddle,wemustensurethattheNATmappingforasessionisproperlyinstalledonallNATboxesalongthepath,andtherstfewpacketsofanewsessionarenottunnelled. mechanismisfalselytriggered,resultinginconsiderablylowthroughput.AsweshowlaterinSection5,asimpliedprototypeofBAPU,whichsharesimilaritieswiththesystemin[15],givespoorTCPthroughput.Simplesolution(SIMPLEBUFFER)doesnotwork:ToaddresstheTCPperformanceissue,weinvestigateasimpleapproach:datapacketsforwardedbyBAPU-APsarebufferedatBAPU-GatewayuntilacontinuoussequenceisreceivedorapredenedbufferingtimeoutisreachedbeforedeliveringittotheDestination.Thissolution,how-ever,encountersthefollowingissues:1)Optimality:Duetothedifferenceincapacity,latency,lossrateamongbackhauluplinks,itisunclearhowtodeterminetheoptimalbuffersizeandtimeout.2)SuboptimalRTT:Thebufferingmechanismresultsindou-bleRTTissu

10 e.3)Performance:Weimplementedthebufferin
e.3)Performance:WeimplementedthebufferingmechanismatBAPU-Gateway,andveriedthatitdoesnothelpimprovingtheTCPthroughput(Section5.2).4.2BAPU'sSolutionWeintroduceanovelmechanismcalledProactive-ACK(step7)tosupportTCPwithuplinkaggregation.Theprincipleistoactivelycontroltheexchangeofacknowledge-mentsinsteadofrelyingonthedefaultbehaviouroftheend-to-endsession.ByProactive-ACK,wesolvebothout-of-orderpacketanddoubleRTTissues.Inthefollowingpara-graphs,wecallacknowledgementsactivelysentbyBAPU-Gatewayspoofed,whiletheonessentbytheDestinationarerealacknowledgements.SpoongProactive-ACK:InBAPU,mostofout-of-orderpacketsarecausedbytheag-gregationmechanismviamultipleBAPU-APs.Toavoiddeliveringout-of-orderpacketstotheDestinationandtheresultingcut-offoftheCWNDattheSender,wemain-tainasequencemapatBAPU-Gateway,indicatingreported,deliveredorpendingsequencenumbers.OnceBAPU-Gatewaycollectsacontinuousrang

11 eofreportedse-quencenumbers,BAPU-Gateway
eofreportedse-quencenumbers,BAPU-GatewaysendsaspoofedACKbacktotheSender.Theintu-itionisthatallthepacketsthatarereportedbysomeBAPU-APsarecurrentlystoredintheirbuffer.DuetothereliabilityoftheTCPtunnel,thereportedpacketswillbeeventu-allyforwardedtoBAPU-Gatewayinreliablemanner.Therefore,immediatelysendingaspoofedProactive-ACKbacktotheSenderavoidsfalseDUPACKsandhelpsmaintainahealthyCWNDgrowthattheSender.Also,theRTTisnotdoubled.EliminatingDUPACKs:SincespoofedACKskeeptheSender'sCWNDcontinuouslygrow,BAPU-Gatewaycantaketimeandbufferallout-of-orderdatapacketsforwardedfromBAPU-APs,anddeliveronlyin-orderpacketstotheDestination.Therefore,inBAPU,out-of-orderpacketsandassociatedDUPACKsareeliminatedfromDestination.SpoongDUPACKs:ItispossiblethatsomepacketsareactuallylostintheairbetweentheSenderandBAPU-APs.Concretely,ifthereportforanexpectedTCPsequencenumberisnotreceivedwithinacertaintime,itisimp

12 liedtobelostonallparticipatingBAPU-APs.N
liedtobelostonallparticipatingBAPU-APs.NowthatBAPU-GatewaysendsaspoofedDUPACKbacktotheSenderinordertomimictheTCPfastretransmissionmechanismforfastrecovery.ManagingRealACKsandTCPSemantics:SinceBAPU-GatewaysendsspoofedACKstotheSender,onreceptionofrealACKsfromtheDestination,BAPU-GatewaydiscardstherealACKs.However,BAPU-GatewaydoessavetheTCPheadereldsintherealACKs,suchasadvertisedreceiverwindowandtimestamp,whichmaintainstheTCPsemanticsandthestateoftheTCPconnection.WhileBAPU-Gatewaygenerates [3]M.Allman,V.Paxson,andE.Blanton.Tcpcongestioncontrol,2009.[4]P.Bahl,A.Adya,J.Padhye,andA.Walman.Reconsideringwirelesssystemswithmultipleradios.SIGCOMMCompututerCommunicationReview,34:39–46,2004.ISSN0146-4833.[5]H.Balakrishnan,S.Seshan,E.Amir,andR.H.Katz.ImprovingTCP/IPperformanceoverwirelessnetworks.InProc.ofMobiCom,1995.[6]ABalasubramanian,RMahajan,AVenkataramani,BNLevine,andJZahorjan.Inte

13 ractivewiconnectivityformovingvehicl
ractivewiconnectivityformovingvehicles.Proc.ofSigComm,2008.[7]S.Barr´e,C.Paasch,andO.Bonaventure.MultiPathTCP:fromtheorytopractice.InProceedingsofNETWORKING,2011.[8]R.ChandraandP.Bahl.Multinet:connectingtomultipleieee802.11networksusingasinglewirelesscard.InProc.ofINFOCOM,2004.[9]FON.FON,2012.http://corp.fon.com/us/.[10]A.Ford,C.Raiciu,M.Handley,andO.Bonaventure.TCPExtensionsforMultipathOper-ationwithMultipleAddresses.Internet-Draft,2012.[11]D.Giustiniano,E.Goma,A.Lopez,andP.Rodriguez.Wiswitcher:anefcientclientformanagingmultipleaps.InProc.ofPRESTO,2009.[12]D.Giustiniano,E.Goma,A.L.Toledo,I.Dangereld,J.Morillo,andP.Rodriguez.FairWLANbackhaulaggregation.InMobiCom,2010.[13]H.-Y.HsiehandR.Sivakumar.Atransportlayerapproachforachievingaggregateband-widthsonmulti-homedmobilehosts.InProc.ofMobiCom,2002.[14]H.-Y.Hsieh,K.-H.Kim,Y.Zhu,andR.Sivakumar.Areceiver-centrictransportprot

14 ocolformobilehostswithheterogeneouswirel
ocolformobilehostswithheterogeneouswirelessinterfaces.InProc.ofMobiCom,2003.[15]S.Jakubczak,D.G.Andersen,M.Kaminsky,K.Papagiannaki,andS.Seshan.Link-alike:usingwirelesstosharenetworkresourcesinaneighborhood.SIGMOBILEMobileCom-putingCommunicationsReview,2008.[16]AnthonyJ.N.,ScottW.,andB.D.Noble.Juggler:Virtualnetworksforfunandprot.IEEETransactionsonMobileComputing,9:31–43,2010.[17]S.Kandula,K.C.Lin,T.Badirkhanli,andD.Katabi.FatVAP:AggregatingAPbackhaulcapacitytomaximizethroughput.InProc.ofNSDI,2008.[18]S.Kopparty,S.V.Krishnamurthy,M.Faloutsos,andS.K.Tripathi.Splittcpformobileadhocnetworks.InGLOBECOM,2002.[19]L.MagalhaesandR.H.Kravets.TransportLevelMechanismsforBandwidthAggregationonMobileHosts.InProc.ofConferenceonNetworkProtocols,2001.[20]MicrosoftResearch.Virtualwi,2012.http://bit.ly/1IjD4iw.[21]A.Miu,H.Balakrishnan,andC.E.Koksal.Improvinglossresiliencewithmulti-radiodi

15 -versityinwirelessnetworks.InMobiCom,pag
-versityinwirelessnetworks.InMobiCom,pages16–30,2005.[22]A.K.Miu,G.Tan,H.Balakrishnan,andJ.Apostolopoulos.Divert:Fine-grainedpathse-lectionforwirelesslans.InProc.ofMobiSys,2004.[23]B.Radunovi´c,C.Gkantsidis,D.Gunawardena,andP.Key.Horizon:BalancingTCPovermultiplepathsinwirelessmeshnetwork.InMobiCom,2008.[24]C.Raiciu,S.Barre,C.Pluntke,A.Greenhalgh,D.Wischik,andMa.Handley.ImprovingdatacenterperformanceandrobustnesswithmultipathTCP.InSIGCOMM'11,2011.[25]H.Soroush,P.Gilbert,N.Banerjee,B.N.Levine,M.Corner,andL.Cox.ConcurrentWi-Fiformobileusers:analysisandmeasurements.InCoNEXT,2011.[26]R.Steward.Streamcontroltransmissionprotocol.IETFRFC4960,2007.[27]D.Wischik,C.Raiciu,A.Greenhalgh,andM.Handley.Design,implementationandeval-uationofcongestioncontrolformultipathTCP.InProc.ofNSDI,2011.[28]X.Xing,S.Mishra,andX.Liu.ARBOR:hangtogetherratherthanhangseparatelyin802.11winetworks.InProc.ofI