Towards WiFi Mobility without Fast HandoverAndrei Croitoru, Dragos

,Niculescu, Costin Raiciu

University Politehnica of Bucharest

ABSTRACTWiFi is emerging as the preferred connectivity solution formobile clients because of its low power consumption andhigh capacity. Dense urban WiFi deployments cover entire(central) areas, but the one thing missing is a seamless mo-bile experience. Mobility in WiFi has traditionally pursuedfast handover, but we argue that this is the wrong goal tobegin with. Instead, we propose that mobile clients shouldconnect to all the access points they see, and split traffic overthem with the newly deployed Multipath TCP protocol. Weshow via detailed experiments and simulation that this solu-tion is highly promising.

1. INTRODUCTIONMobile traffic has been growing tremendously to the point

where it places great stress on cellular network capacity, andoffloading traffic to the ubiquitous WiFi deployments haslong been touted as the solution. The potential for offloadis tremendous, especially in highly dense urban areas, wherealmost always there exist deployments from several hotspotproviders: for instance, only in the Bucharest city centerthere are at least three wide-area deployments, and more arebeing planned. In fact, in dense WiFi deployments WiFi tocellular transitions are not needed at all: entire areas are cov-ered entirely by WiFi, so mobiles should rely only on WiFibecause it offers higher capacity and lower energy consump-tion. That is why we believe that WiFi mobility is not onlyback in fashion, but will likely be the determining factor indeciding whether WiFi offload is feasible.

Traditional WiFi mobility techniques (as with all other L2mobility mechanisms) are based on the concept of fast han-dover: when a mobile client exits the coverage area of oneAccess Point (AP), it should very quickly find another APto connect to, and quickly associate to it. There is a greatwealth of research into optimizing fast handover includingscanning in advance, re-using IP addresses to avoid DHCP,synchronizing access points via a backplane protocol, eventhe use of an additional card to reduce the association delay- see section 2 for more details. However, we think this isthe wrong approach, for multiple reasons:

i. To start the handover mechanism, a client has to loseconnectivity to the AP, or break beforemake

ii. There is no standard way to decide which of the manyAPs to associate with for best performance.

iii. Once the decision has been made, there is no way to dy-namically adjust to changes in AP signal strength.

We conjecture that the emerging standard of MultipathTCP enables radical changes in how we use WiFi: use of

multiple APs becomes natural, whether on the same channelor different ones, and the perennial handoff problem at layer2 gets handled at layer 4 allowing for a clean, technologyindependent, end-to-end solution for mobility.

In this paper we test the following hypothesis:

All WiFi clients should connect to all the accesspoints in their vicinity for better performance.

We carefully analyze the performance experienced by amobile client locked into using a single WiFi channel and as-sociating automatically to all the access points it sees, with-out using any explicit layer 2 handover. We run a mix oftestbed experiments to test a few key use-cases and ns2 simu-lations to analyze the generality of our testbed findings acrossa wide range of parameters and scenarios.

We find that, surprisingly, the performance of this verysimple solution is very good out of the box for a wide rangeof scenarios and for many WiFi flavours (802.11a/b/g/n): aWiFi client connecting to all visible APs will get very closeto the maximum achievable throughput. We discuss in de-tail the reasons for this performance, namely the WiFi MACbehaviour and its positive interaction with Multipath TCP.

We also find that performance is not very good for 802.11nand some (hypothetical) rate control algorithms: in such casesthe client downloads too much data from APs far away, re-ducing total throughput. To address this issue, we implementand test a simple and very effective client-side modificationthat helps the Multipath TCP congestion controller findthe right access points by setting a low rate of ECN markson packets from APs sending at low WiFi rates.

We ran a mobility experiment in our CS building, com-paring our proposal to using regular TCP connected to theindividual APs. The results show a true mobile experience:our clients throughput closely tracks that of a TCP clientconnected to the best AP at any given location.

2. BACKGROUNDFast Handover. The 802.11 standards were originally de-signed for uncoordinated deployments, and are not particu-larly amenable for high speed handovers. The handover isperformed in three phases: scanning, authentication, and as-sociation. The first phase has been empirically shown [1]to be 95% of the handover time, and has been the target formost optimizations proposed in the literature.

One approach to reduce the scanning delay is to probe fornearby APs before the mobile loses its current link. Sync-Scan [2] goes offchannel periodically to perform the scan,so that the mobile has permanent knowledge about all APson all channels. DeuceScan [3] is a prescan approach that

1

uses a spatiotemporal graph to find the next AP. Mishra et al.[4] uses neighbor graphs to temporarily capture the topologyaround the mobile and speed up the context transfer betweenAPs using IAPP. When additional hardware is available, [5]delegates the task of continuous probing to a second card.

For enterprise networks there are several opportunities tooptimize the handover process. The first one is the use ofa wireless controller that has a global view of all the APsand the associated mobiles in the entire network. This archi-tecture is supported by all major vendors, because it offersmany other advantages in addition to controlled associationand guided handover. Another avenue for optimizing fasthandover is to eliminate it altogether, with the adoption ofa single channel architecture [6] where multiple coordinatedAPs pose as a single AP by sharing the MAC; this archi-tecture is currently in use by Meru, Extricom and Ubiquiti.In these architectures, the wireless controller routes the traf-fic to and from the appropriate AP, so that a mobile neverenters the handover process.

802.11r [7] optimizes the last two components of the han-dover ensuring that the authentication processes and encryp-tion keys are established before a roam takes place. Authen-tication occurs only once, when a client enters the mobilitydomain. Subsequent roams within a mobility domain usecryptographic material derived from the initial authentica-tion, decreasing roam times and reducing load on back-endauthentication servers. 802.11k [8] provides for roaming as-sistance from the AP: when it perceives the mobile movingaway, it sends a notification and possibly a site report withother AP options to maintain connectivity.

Finally, a survey of handover schemes [9] mentions sev-eral other efforts in this direction and classifies them basedon the incurred overhead, necessity of changes (mobile, AP,or both), compatibility with standards, and complexity.

All these layer 2 solutions do improve handover perfor-mance, but their availability depends on widespread supportin APs, as well as in the client. More fundamentally, doinga handover is a decision that locks the client into one AP fora certain period of time, which leads to poor performancewhen truly mobile: there is no good way of predicting thethroughput the client will obtain from one AP in the verynear future. By using a transport layer mobility solution, wesidestep the need to upgrade all APs / client hardware formobility and, more importantly, we allow a client to utilizemultiple APs at the same time.Multipath TCP is a recently standardized extension of TCP[10] that has been implemented by Apple in the IOS 7 mo-bile operating system; more mobile phone manufacturers areexpected to follow suit. Multipath TCP is enticing to mobiledevices because it can effectively use the multiple interfacesavailable in a single transport connection: it allows users touse both cellular and WiFi links be it concurrently or alter-natively, as an offloading solution.

Multipath TCP works with unmodified applications thatuse the well-known socket API. A Multipath TCP connec-

Figure 1: Instead of fast handovers, we propose thatwireless clients associate to all the APs in range anduse Multipath TCP to spread traffic across them.

tion contains one or many subflows, where each subflowlooks to the network like a regular TCP connection, and isbound to one interface on the mobile device. Multipath TCPtakes care of splitting data across these subflows and puttingit back in order at the receiver, and resending data from failedsubflows over alternative ones (see [11] for details).

A key component of Multipath TCP is its congestion con-troller, that was built to ensure fairness to TCP and to load-balance traffic, pushing more traffic onto less congested links[12]. Another congestion controller that has been proposedrecently is OLIA, which performs a more aggressive loadbalancing [13]; this is the controller we use in this paper un-less mentioned otherwise.

3. SINGLE CHANNEL MOBILITYWe observe that the emergence of Multipath TCP enables

a radically different approach to WiFi mobility: instead ofusing only one AP at a time and doing handovers, mobileclients should connect to all APs at any given time. Thesolution is conceptually very simple, and is shown in Figure1: we have the client associate to multiple APs, obtainingone IP address from each, and then rely on MPTCP to spreaddata across all the APs, with one subflow per AP. As themobile moves, new subflows are added for new APs, whileold ones expire as the mobile loses association to remoteAPs. In this paper, we focus on the case when the wirelessNIC is restricted to use a single channel (e.g. 1,6 or 11 inthe 2.4Ghz range). Multi-channel solutions can be devisedby extending our findings, as we discuss in 5.

If we disregard WiFi interference between APs, the the-oretically optimal mobility solution is to always connect toevery visible AP, and let MPTCP handle load balancing atthe transport layer: if an AP has poor signal strength, thebytes will simply migrate to the APs with better connectiv-ity to the client. This way, handover delays are eliminatedand the mobile enjoys continuous connectivity.

Interference, of course, can be a major issue. We imple-mented a prototype client that is locked in on a single chan-nel and continuously looks for beacons of known APs; whena such an AP is found, the client creates a new virtual wire-less interface and associates to the AP. We ran this code onour 802.11a/b/g/n testbed without external interference, aswell as in simulation to understand the feasibility of our pro-posal. We discuss our experiments next, wrapping up with amobility trace of our client roaming through our building.

2

0

0.2

0.4

0.6

0.8

1

0 5 10 15 20 25 30 35

Thro

ughp

ut [%

]

Position

TCP via AP1TCP via AP2

MPTCP over AP1+2

(a) Throughput of a client moving between AP1 andAP2: the MAC favors the sender with the betterchannel. Max throughput is 22Mbps.

0 10 20 30 40 50 60 70 80 90

100

0 1 2 3 4 5 6 7 8 9

Pack

et d

elive

ry ra

tio [%

]

Time [s]

Channel to AP1Channel to AP2

(b) A fixed node has channels with a raw PDR50%to each AP. The quality of the two channels variesindependently in time.

0102030405060708090100

1 10

CDF [%]

Packet interarrival time[ ms]

AP1AP2

AP1+2

shorter t

ail = few

er retries

(c) Packet interarrival rate exhibits a longer tailwhen a single AP is used. When both APs aresending, the tail is much shorter.

Figure 2: Carrier sense experiments: the client using MPTCP gets the throughput of the best TCP connection when closeto either AP, and better throughput when in-between.

3.1 Carrier-sense experimentsThe first case we test is when a client connects to two

APs on the same channel in 802.11a and within carrier senserange of each other, so that the WiFi MAC will prevent bothAPs sending simultaneously. The mobile associates to bothAPs and then we move the client from one AP to the otherin discrete steps. We measure the throughput of an MPTCPconnection through both APs and compare it with that ofusing a TCP via either AP, which represents the status-quo.

The results are given in Fig. 2a, and they show that thethroughput of the MPTCP client connected to both APs is ashigh as the maximum offered by any of the two APs.

The reasons for this behaviour are not obvious. Considerfirst the cases when the client is closer to one AP; in suchcases the most efficient use of airtime is to use only the APthats closest to the client. In fact, the Linux WiFi rate selec-tion algorithm (Minstrel) favours higher bitrates even at lowsignal strengths with lower frame delivery rate, which leadsto more retransmissions per packet for the far away AP. Eachretransmission imposes an exponentially larger backoff timeon the transmitter, which allows the AP with better signalstrength to send more packets. This behaviour is strictly en-forced by the L2 conditions, and we verified that the choiceof TCP congestion control has no effect on the distributionof packets over the two paths. In fact, the same results wereobtained in an experiment using UDP. We also verified in thens2 simulator that the MAC preference for the better senderholds regardless of the maximum number of retransmissionsallowed (0 - 10).

When in-between the two APs, the client sometimes ob-tains slightly more throughput (10% - 20%) by using bothAPs than if we were using either AP in isolation. This isvery surprising, and the explanation is more involved.

The fundamental reason lies at the physical layer: due tofading effects, individual channel quality varies quickly overtime, despite both channels having a roughly equal longer-term capacity. To test this hypothesis, we simultaneouslysent a low rate broadcast stream from each AP and measuredtheir delivery ratio at the client. As broadcast packets arenever retried, their delivery ratio captures the channel qualityaccurately; the low rate is used to ensure the two APs dontfight each other over the airtime, while still allowing us to

probe both channels concurrently. The instantaneous packetdelivery ratios computed with a moving window are shownin Figure 2b, confirming that channels from the two APs arelargely independent.

What mechanism manages to exploit this channel diver-sity? Our first guess was the MPTCP congestion controller,but this turned out to be wrong: both subflows had fairlylarge congestion windows, and the buffers at the APs wherenever empty during our experiment. It turned out it is the802.11 MAC that exploits physical channel diversity, whichis a form of multiuser diversity: the sender that sees a betterchannel will decrease its contention window, and will be ad-vantaged even more over the sender with a weaker channel.This behaviour is experimentally verified by previous work[14] with several clients and bidirectional traffic to/from theAP. For our client downloading from two APs, when one hasa slightly worse channel, it will lose a frame and double itscontention window before retrying, leaving the other AP tobetter utilize the channel.

To check this hypothesis, we analyzed interarrival timesbetween packets for the client using either AP or both atthe same time, and the CDF is plotted in Figure 2c. Thedata shows that most packets arrive 1ms apart, and that AP1prefers a higher PHY rate (24Mbps) while AP2 prefers alower PHY rate (18Mbps) when used alone. Using bothAPs leads to interarrival times in between the two individ-ual curves for most packets. The crucial difference is in thetail of the distribution, where using both APs results in fewerretries per packet. When one AP experiences repeated time-outs, the other AP will send a packet, thus reducing the tail.

We conclude that in this carrier-sense scenario, bandwidthis harvested optimally by the combination of 802.11 MACpreference for the better channel, rate adaptation (minstrel),and MPTCP that streams packets across APs.

3.2 Hidden terminal experimentsWhen the two APs are outside of CS range and the client

is connected to both, the CSMA mechanism no longer func-tions and the frames coming from the two APs will collide atthe client. In fact, each AP is a hidden terminal for the other.

To run this experiment, we reduced the power of our twoAPs until they were out of carrier sense, but the client is stillable to achieve full throughput to at least one of them at all

3

0

0.2

0.4

0.6

0.8

1

1 2 3 4 5 6 7 8

Thro

ughp

ut [%

]

Position

UDP1UDP2

UDP1+2MPTCP1+2

(a) Experimental results with 802.11a, 6Mbps:UDP flows systematically collide each other, whileMPTCP subflows take turns on the medium.

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

1

0 20 40 60 80 100 120 140 160

Thro

ughp

ut [%

]

Distance [m]

UDP1UDP2

UDP1+2TCP1+2

(b) ns2 simulation of the same situation in 3a. Inthe middle region MPTCP exhibits higher variabilitybecause one subflow starves the other.

0

20

40

60

80

100

0 2 4 6 8 10 12 14

Pack

ets

lost

(%)

Number of retransmissions

Subflow 1Subflow 2

(c) The subflow sending packets infrequently expe-riences a much higher loss rate. This makes it hardfor a (MP)TCP flow to escape its slowstart.

Figure 3: Hidden terminal (HT) experiments: using Multipath TCP results in very good throughput because one subflowmonopolizes the air, while the other is starved.

locations. To test this setup, each AP broadcasts packets asfast as possible. When sending alone, each of the two APcan send a maximum 1000 575B UDP packets per secondwith a MCS of 6Mbps. When in CS and sending simultane-ously, each AP will send roughly half that number of pack-ets. As we further decrease the power of the APs, the twoAPs can simultaneously send 1000 packets/s each, indicat-ing they cant hear each other.

Then, we move our client between the APs, and measurethroughput for UDP, TCP and Multipath TCP. As shown infigure 3a, the graph exhibits three distinct areas. In the twoareas close to either AP, neither UDP nor TCP throughput isaffected: here the capture effect of WiFi can be seen, wherepackets coming from the closer AP are much stronger, andthe effect of a collision is very smallthe client will justdecode the stronger packet as if no collision took place, andthe subflow via the furthest AP will reduce its rate to almostzero because of repeated packet losses.

The area in the middle is more interesting. As we ex-pected, the combined UDP throughput of two simultaneousiperf sessions is greatly diminished by the hidden terminalsituation. However, by running two simultaneous MPTCPsubflows, the combined throughput is surprisingly good. Re-peated runs showed this result is robust, and we also con-firmed this via ns2 simulation (see figure 3b). MPTCP con-nection statistics show that the high-level reason for the highthroughput is that traffic is flowing entirely over one of thetwo subflows, while the other one is starved, experiencingrepeated timeouts. This would suggest that the starved sub-flow is experiencing (much) higher loss rates, which wouldexplain why it never gets off the ground properly. However,as the two channels have roughly the same quality, it is notobvious at first why this would be the case.

To understand the reason of this behaviour, we used sim-ulation to measure the loss probability of the two subflowswhen contending for the medium. Say subflow 1 is sendingat full rate, while subflow 2 sends a single packet which col-lides with a packet of subflow 1. The WiFi MACs will thenbackoff repeatedly until the max retransmission count hasbeen reached, or until one or both packets are delivered. Werun the simulation for a long time to experience many suchepisodes, and show the percentage of episodes each subflow

experiences a loss in Fig. 3c as a function of the retry count.When few retransmissions are allowed, both subflows lose

a packet each when a collision happens, but the effect of theloss is dramatic for the second subflow pushing it to anothertimeout. As we allow more retransmissions, the loss prob-ability is reduced dramatically: the second subflow losesaround 40% of its packets if 6 or more retransmissions areallowed. The reason for the flattening of the line at 40%is the fact that the first sender always has packets to send,and when subflow 1 wins the contention for the first packet,its second packet will start fresh and again collide with theretransmissions from the second subflow, further reducingits delivery ratio. This also explains why subflow 1 experi-ences no losses after six retransmissions: either it wins thecontention immediately, or it succeeds just after the secondsubflow successfully sends its packet.

In effect, we are witnessing a capture effect at the Mul-tipath TCP level triggered by the interaction with the WiFiMAC. Luckily, this behaviour is ideal for our MPTCP client.

3.3 Rate Control with packet-level fairnessOur experiments so far have relied on the 802.11a/g proto-

cols, which cover most of the deployed WiFi base, and usedthe default rate control algorithm of Linux (Minstrel). Avalid question is whether our findings also hold for 802.11nor for different rate control algorithms. In order to verify thevalidity of our proposal, we tested it on APs and clients run-ning 802.11n in the 5GHz frequency band. We repeated theexperiment with the client in different positions between theAPs; in-between the APs MPTCP gave throughput compa-rable to that of the TCPs. However, when the client is closeto one of the APs, the results differed from 802.11a/g: thethroughput obtained with MPTCP was only approximatelyhalf the throughput obtainable via the closest AP.

We investigated the reasons for this behaviour by mon-itoring the PHY bitrates used by the transmitters and ob-served that the rate control algorithm Linux uses for 802.11n(Minstrel-ht) differs from Minstrel significantly: instead ofusing aggressive bitrates and many retransmissions, Minstrel-ht chooses the rates to ensure maximum delivery probabilityof packets. The block ACK feature of 802.11n is likely themain factor in this decision, as the loss notification now ar-rives at the sender after a whole block of frames has been

4

transmitted (as much as 20): the sender cant afford to ag-gressively use high bitrates because feedback is scarce.

In fact, the block ACK mechanism together with the cau-tious choice of bitrates by the transmitters ensures block-level fairness between the two APs: the client will receiveone block from AP1 at high bitrate, then one block from AP2at lower bitrate, and so on.

This issue is not limited to 802.11n: any WiFi rate controlalgorithm that offers packet-level fairness between multiplesenders in Carrier Sense range greatly harms the combinedthroughput achievable by MPTCP when utilizing multipleAPs. Rate control is a modular element and is not regulatedby the 802.11 standard, thus wireless NIC manufacturers canimplement different algorithms in their drivers. Linux, bydefault, uses the Minstrel algorithm implemented in the ker-nel, but that algorithm can be overridden by the WiFi driver.Also, most types of commercial APs are not Linux-based,and the rate control is handled in the NIC driver.

Solution. WiFi load balancing is not working well for ourproposal in this setup, and the most obvious solutions areeither a) rely on changes at APs (e.g different rate controlmechanisms) or b) try to associate to fewer APs when wesuspect we are in this situation. The former is not only diffi-cult to deploy but will also impact other clients of the APs.The latter is against our philosophy of using many APs.

Instead, we have devised a heuristic solution that we be-lieve is both efficient and simple. Our key idea is to use theability of the MPTCP congestion controller to direct traf-fic to the most efficient access points. For this to happen,MPTCP must observe a higher loss rate on the subflow cross-ing the less efficient AP. Unfortunately, in the current sce-nario, the loss rates on both paths are equal as both APssend an equal number of packets per second, and the MPTCPsender cannot choose between them.

Note that the MPTCP client can tell which AP sends athigher rates, and is preferable. To relay this information tothe sender we could drop packets but this is rather crude, sowe rely on ECN instead. The server then shifts traffic awayfrom this path, but it will still probe it in case it gets better.

We have implemented this approach in the 802.11 sub-system of the Linux kernel by maintaining an exponentialmoving average of the bitrates of incoming packets on thedifferent virtual interfaces. When the average bitrate of oneinterface is significantly smaller than the other (20% less),the client code marks 1% of its incoming packets with theCE (congestion experienced) ECN codepoint. This markinghappens before the L2 packets get delivered to L3 processingcode at the client.

Our heuristic performs very well for 802.11n when theclient is close to one AP: within a couple of seconds, traf-fic is shifted by MPTCP to the better AP, and throughputreaches 90% of TCP using that AP alone. We reran all theexperiments presented so far (including 802.11a/g) with ourclient-side load balancing algorithm on. We found that themarking made no difference to the actual results: in particu-

!"#

$!%#&'()*+#

!,#

$!%#&'()*+#

-%"#

-%,#

!#

.%$!%#&'()*+#

Figure 4: Experimental setup to test fairness

lar, we verified that marking was not triggered in the channeldiversity setup we discussed before.

Finally, note that we can construct artificial scenarios wherethis mechanism hurts throughput. Say AP1 is using a smallbitrate (e.g. 12Mbps, no retries) but has higher overall through-put than AP2 which uses a high bitrate but many retransmis-sions (e.g. 54Mbps with 5 retries per packet). In such cases,our mechanism will introduce a 1% loss rate on AP1, whichmight affect its throughput. Luckily, the effect should berather small: a 1% loss rate will result in a congestion win-dow of around 10 packets, which at 20ms RTT leads to athroughput of 6Mbps - far from a catastrophe. However, forsane rate control algorithms this situation is highly unlikelyin practice. More experiments are needed, though, to test thesensitivity of our algorithm in many different scenarios withdifferent rate control algorithms used in practice.

3.4 FairnessWe have focused our analysis so far on the performance

experienced by a client connecting to multiple access points,and showed that there are significant benefits to be had fromthis approach. We havent analyzed the impact this solu-tion has on other WiFi clients: is it fair to them? Does oursolution decrease the aggregate throughput of the system?In answering these questions, our goals are neither absolutefairness (since WiFi is a completely distributed protocol andalso inherently unfair, this goal in unattainable) nor maxi-mizing aggregate throughput (which may mean some distantclients are starved). Rather, we want to ensure our solutionsimpact on other clients is no worse than that of a TCP con-nection using the best available AP.

The theory of Multipath TCP congestion control reassuresus that two or more MPTCP subflows sharing the same wire-less medium will not get more throughput than a single TCPconnection would. Also, if an AP has more customers, Mul-tipath TCP will tend to steer traffic away from that AP be-cause it sees a higher packet loss rate.

We used the simple setup shown in Figure 4 to test thebehaviour of our proposal. There are two access points eachwith a TCP client in their close vicinity, using 802.11a, andan MPTCP client C using both APs.

The first test we run has both APs using maximum power:when alone, all clients will achieve the maximum rate in802.11a, around 22Mbps. The results of the experiment areshown in table 1: when the client connects to both APs, thesystem achieves perfect fairness. In comparison, connectingto either AP alone will lead to an unfair bandwidth alloca-tion. In this setup, MPTCP congestion control matters. Ifwe use regular TCP congestion control on each subflow, the

5

C conn.to

AP1-C1 AP2-C2 C

AP1 5Mbps 10Mbps 5MbpsAP2 10Mbps 5Mbps 5MbpsAP1&AP2 7Mbps 7Mbps 7MbpsTable 1: APs and clients in closerange: MPTCP provides perfectfairness

C conn.to

AP1-C1 AP2-C2 C

AP1 3.5Mbps 13Mbps 3.5MbpsAP2 10Mbps 5Mbps 5MbpsAP1&AP2 10Mbps 5Mbps 5MbpsTable 2: Client close to AP2:MPTCP client behaves as TCP con-nected to AP2

C conn.to

AP1-C1 AP2-C2 C

AP1 3.5Mbps 13.5Mbps 3MbpsAP2 14Mbps 3Mbps 3MbpsAP1&AP2 8.5Mbps 6.5Mbps 5MbpsTable 3: Client in-between APs:MPTCP client improves overall fair-ness

resulting setup is unfair: the MPTCP client receives 10Mbpswhile the two TCP clients each get 5Mbps.

We next study another instance of the setup in Fig. 4where the APs, still in CS, are farther away, and while theTCP clients remain close to their respective APs, they get alesser channel to the opposite AP.

First, we place C close to AP2. When C connects to AP1,which is farther, it harms the throughput of C1, and the over-all fairness is greatly reduced. When C connects to bothAPs, its traffic flows via the better path through AP2, offer-ing optimal throughput without harming fairness (table 2).When the client is between the two APs, traffic is split onboth paths and the overall fairness is improved, while alsoincreasing the throughput obtained by our client (table 3).

In summary, by connecting to both APs at the same timeand splitting the downlink traffic between them, MPTCPachieves better fairness in most cases, and never hurts trafficmore than a TCP connection would when using the best AP.

4. A MOBILITY EXPERIMENTWe now discuss a mobility experiment we ran in the CS

building of our university: the user starts from our lab situ-ated on the second floor of the building, goes down a flight ofstairs and then walks over to the cafeteria. En route, the mo-bile client (a laptop) is locked on channel 6 and can associateto five different access points, each covering different partsof the route. We repeat the experiment by doing consecutiveruns (each run takes around 1 min or so), and in each runthe client is either locked into using a single AP, or is usingMPTCP and associating to all APs it sees all the time.

The results are shown in Figure 5. In the beginning of thewalk, the client has access to the two APs in our lab (namedUberAP), and these are also accessible briefly on the stairs(in the middle of the trace). The tempus access points areour departments deployment of uncoordinated access points(Fortinet FAP 220B), available both in our lab (at very lowstrength), on the stairs and closer to the cafeteria. Our mo-bile client connects to at most three APs simultaneously.

Throughout the walk, the throughput of our MPTCP mo-bile client closely tracks that of TCP running on the best APin any given point, showing that our careful coordinated ex-periments do capture the crux of the interesting behavioursnoticed in practice. There is however an area around 65swhere TCP outperforms MPTCP; we believe this is due torepeated timeouts experienced by the subflow running overthe Tempus2 AP before the signal improves. The easy fix isto cap the RTO to some reasonable value (e.g. 1s).

0

0.2

0.4

0.6

0.8

1

0 10 20 30 40 50 60 70 80

Thro

ughp

ut [%

]

Time (s)

MPTCPuberAP1uberAP2tempus 1tempus 2

Figure 5: Mobility experiment: indoor client walk(max throughput is 22Mbps)We also noticed that in the beginning of the trace our

ECN-based load balancing algorithm penalizes the subflowover the Tempus2 APif we disable it, the throughput ofMPTCP in that area drops dramatically.

5. DISCUSSIONIn this paper we have proposed a paradigm shift for wire-

less mobility: instead of using a single AP at any one timeand racing to quickly change to the next when signal fades,we propose to use all APs in range and use Multipath TCPto spread traffic amongst them.

Our experiments have shown that, in many cases, the loadbalancing job is done by the WiFi MAC (our carrier-senseexperiments) or by interactions of the MAC and MultipathTCP congestion control (hidden terminal). Our ECN-basedheuristic algorithm triggers the MPTCP congestion controlwhen WiFi load balancing reduces the clients throughput.Beyond our controlled experiments, our mobility experimentis strong indication that our findings hold in real-life.

This is preliminary work. More experiments are neededto understand interactions with other rate control algorithmsdeployed in practice, as well a wider range of mobility exper-iments. Finally, we need to quantify the energy consumptionof our proposal and contrast it to using TCP on the best path.

A major direction of future work is extending our solutionto multiple channels. So far, we have assumed our client usesa single channel out of the three channels in wide-spread usetoday (1, 6 and 11 in the 2.4Ghz band). At the minimum,the client needs to decide which channel to use, which willdepend on the density of APs on the channels. A more inter-esting direction is to use channel switching as proposed byFatVap [15] or Juggler [16], and associate to all APs on allchannels. Within a channel we will apply the solutions dis-cussed in this paper; additionally, a multi-channel solutionmust decide how long to spend on each channel, dependingon the throughput received.

6

6. REFERENCES[1] A. Mishra, M. Shin, and W. Arbaugh, An empirical

analysis of the IEEE 802.11 MAC layer handoffprocess, SIGCOMM Comput. Commun. Rev., vol. 33,April 2003.

[2] I. Ramani and S. Savage, SyncScan: practical fasthandoff for 802.11 infrastructure networks, inINFOCOM 2005. 24th Annual Joint Conference of theIEEE Computer and Communications Societies.Proceedings IEEE, vol. 1, pp. 675684, IEEE, 2005.

[3] Y.-S. Chen, M.-C. Chuang, and C.-K. Chen,Deucescan: Deuce-based fast handoff scheme inIEEE 802.11 wireless networks, VehicularTechnology, IEEE Transactions on, vol. 57,pp. 11261141, March 2008.

[4] M. Shin, A. Mishra, and W. A. Arbaugh, Improvingthe latency of 802.11 hand-offs using neighborgraphs, in Proceedings of the 2Nd InternationalConference on Mobile Systems, Applications, andServices, MobiSys 04, (New York, NY, USA),pp. 7083, ACM, 2004.

[5] V. Brik, A. Mishra, and S. Banerjee, Eliminatinghandoff latencies in 802.11 WLANs using multipleradios: Applications, experience, and evaluation, inProceedings of the 5th ACM SIGCOMM Conferenceon Internet Measurement, IMC 05, (Berkeley, CA,USA), pp. 2727, USENIX Association, 2005.

[6] Virtual cells: The only scalable multi-channeldeployment. MERU white paper, 2008.

[7] IEEE standard for information technology local andmetropolitan area networks specific requirementspart 11: Wireless LAN medium access control (MAC)and physical layer (PHY) specifications amendment 2:Fast basic service set (BSS) transition, IEEE Std802.11r-2008 (Amendment to IEEE Std 802.11-2007as amended by IEEE Std 802.11k-2008), pp. 1126,July 2008.

[8] IEEE standard for information technology local andmetropolitan area networks specific requirementspart 11: Wireless LAN medium access control (MAC)and physical layer (PHY) specifications amendment 1:Radio resource measurement of wireless LANs,IEEE Std 802.11k-2008 (Amendment to IEEE Std802.11-2007), pp. 1244, June 2008.

[9] S. Pack, J. Choi, T. Kwon, and Y. Choi, Fast-handoffsupport in IEEE 802.11 wireless networks, IEEECommunications Surveys and Tutorials, vol. 9,no. 1-4, pp. 212, 2007.

[10] A. Ford, C. Raiciu, M. Handley, and O. Bonaventure,TCP Extensions for Multipath Operation withMultiple Addresses, rfc6824, IETF, 2013.

[11] C. Raiciu, C. Paasch, S. Barre, A. Ford, M. Honda,F. Duchene, O. Bonaventure, and M. Handley, Howhard can it be? designing and implementing adeployable multipath TCP, in Proceedings of the 9th

USENIX Conference on Networked Systems Designand Implementation, NSDI12, (Berkeley, CA, USA),pp. 2929, USENIX Association, 2012.

[12] D. Wischik, C. Raiciu, A. Greenhalgh, andM. Handley, Design, implementation and evaluationof congestion control for multipath TCP, in Proc.Usenix NSDI 2011.

[13] R. Khalili, N. Gast, M. Popovic, and J.-Y. Le Boudec,MPTCP is not Pareto-optimal: Performance issuesand a possible solution, Networking, IEEE/ACMTransactions on, vol. 21, pp. 16511665, Oct 2013.

[14] S. Choi, K. Park, and C.-k. Kim, On the performancecharacteristics of WLANs: Revisited, SIGMETRICSPerform. Eval. Rev., vol. 33, pp. 97108, June 2005.

[15] S. Kandula, K. C.-J. Lin, T. Badirkhanli, andD. Katabi, FatVAP: aggregating AP backhaulcapacity to maximize throughput, in Proceedings ofthe 5th USENIX Symposium on Networked SystemsDesign and Implementation, NSDI08, (Berkeley, CA,USA), pp. 89104, USENIX Association, 2008.

[16] A. J. Nicholson, S. Wolchok, and B. D. Noble,Juggler: Virtual networks for fun and profit, IEEETransactions on Mobile Computing, vol. 9, pp. 3143,Jan. 2010.

7

1 Introduction2 Background3 Single Channel Mobility3.1 Carrier-sense experiments3.2 Hidden terminal experiments3.3 Rate Control with packet-level fairness3.4 Fairness

4 A mobility experiment5 Discussion6 References