27
Fat Virtual Access Points Taken from Srikanth Kandula

Fat Virtual Access Points Taken from Srikanth Kandula

Embed Size (px)

Citation preview

Page 1: Fat Virtual Access Points Taken from Srikanth Kandula

Fat Virtual Access Points

Taken from Srikanth Kandula

Page 2: Fat Virtual Access Points Taken from Srikanth Kandula

Connect to the AP with the highest RSSI

State-of-the-art (802.11):

Page 3: Fat Virtual Access Points Taken from Srikanth Kandula

Wireless Link ~ 54Mbps(Theoretical Max)

AP Uplink ~ 2Mbps(DSL/Cable Modems)

Can Aggregate Bandwidth from nearby APs!Can Aggregate Bandwidth from nearby APs!

Problem 1: In Homes, Hotspots…

2+2+2+…2+2+2+…

Uplink Bottleneck

Page 4: Fat Virtual Access Points Taken from Srikanth Kandula

Load Imbalance

Unnecessary congestion; nearby APs are idle

Spread load

Individual changes help globally

Problem 2:

Divide Total Bandwidth Among Users Divide Total Bandwidth Among Users

20Mbps

15Mbps

At Work …

4Mbps4Mbps 7Mbps7Mbps

Page 5: Fat Virtual Access Points Taken from Srikanth Kandula

Join closest AP Join a Virtual AP, that is the sum of nearby APs

State-of-the-art: Abstraction:

1. User can aggregate bandwidth from all APs

2. Compete for total balance load across APs

1. User can aggregate bandwidth from all APs

2. Compete for total balance load across APs

2 Problems, 1 Solution

Page 6: Fat Virtual Access Points Taken from Srikanth Kandula

Realize a “fat virtual AP” withonly client-side changes

Page 7: Fat Virtual Access Points Taken from Srikanth Kandula

Basic Operation

2Mbps

20Mbps

But, what about receive?

2Mbps

Page 8: Fat Virtual Access Points Taken from Srikanth Kandula

Basic Operation

Drop

Power-Save Q

Pretend in power-save, so AP buffers when disconnected (similar to Chandra et. al. VirtualWiFi)

Divide Time and Data Across APs to get “Fat Virtual AP” Divide Time and Data Across APs to get “Fat Virtual AP”

2Mbps

20Mbps

2Mbps

Page 9: Fat Virtual Access Points Taken from Srikanth Kandula

Realizing a Fat Virtual AP is Hard

• Sustain TCP flows through each AP– Cannot lose packets yet Switch quickly

• Which APs to connect to and for how long?– Some APs are more valuable than others

• How to divide traffic across the APs?

FatVAP, an 802.11 driver design1. divides time across APs to maximize throughput

2. is transparent to APs and remote ends

FatVAP, an 802.11 driver design1. divides time across APs to maximize throughput

2. is transparent to APs and remote ends

Page 10: Fat Virtual Access Points Taken from Srikanth Kandula

FatVAP Overview

1. Scan for available APs2. Compute a schedule to divide time across APs3. Switch APs as per schedule4. Spread traffic by pinning flows to APs

Channel 1Channel 6 Channel 6

Channel 36

Page 11: Fat Virtual Access Points Taken from Srikanth Kandula

How much time to spend at an AP?

w

e

Useful fraction of time w

e≤

Achievable Bandwidths– end-to-end e, wireless w

Subsumes Wireless Link Quality, Contention at AP, APs uplink capacity

Subsumes Wireless Link Quality, Contention at AP, APs uplink capacity

Page 12: Fat Virtual Access Points Taken from Srikanth Kandula

How to Divide Time Across APs?

AP Bandwidth (Mbps) AP1 AP2 AP3

End-to-end Achievable 5 4 3

Wireless Achievable 5 8 8

Usable Fraction 100% 50% 38%

Optimal = 7 Mbps

Pick APs Greedily, on End-to-end rate

5 Mbps, 100% busy

! more bang for the buck if wireless b/w is large

Page 13: Fat Virtual Access Points Taken from Srikanth Kandula

Pick APs Greedily, on End-to-end ratePick APs Greedily, on Wireless rate

AP Bandwidth (Mbps) AP1 AP2 AP3 AP4 AP5 AP6

End-to-end Available 1 1 1 1 1 4.5

Wireless Available 5 5 5 5 5 4.5

Usable Fraction 20% 20% 20% 20% 20% 100%

5 Mbps, 100% busy

! cost to switch is ≈ 5 ms! can’t linger too long (100ms period)

No Greedy Solution!No Greedy Solution!

How to Divide Time Across APs?

Only 75% usable

Page 14: Fat Virtual Access Points Taken from Srikanth Kandula

Say, fi is fraction of time at APi

⎡ ⎤( )∑

≤+

≤≤

DsfDf

w

efts

wf

ii

i

ii

iifi

0..

max

Usefulness Constraint

Value (Bandwidth)

Cost (Time)

Let s be switching time and D be the period

(pseudo)-polynomial solution(pseudo)-polynomial solution

Like Bin Packing, maximize value with bounded cost!

Page 15: Fat Virtual Access Points Taken from Srikanth Kandula

But, How to Estimate Bandwidths?Wireless Achievable

Client TX Queue

Time from head of tx queue to end of transmission (ack)

Naively– send-rate of probe burst, APs report load

AP Buffers

Idea: Use synchronous acks

w

Page 16: Fat Virtual Access Points Taken from Srikanth Kandula

But, How to Estimate Bandwidths?Wireless Achievable End-to-end

Client TX Queue

Time from head of tx queue to end of transmission (ack)

Naively, send-rate of probe burst or APs report load

AP Buffers

Idea: Use synchronous acks

e

tCount bytes rcvd in a window

Page 17: Fat Virtual Access Points Taken from Srikanth Kandula

But, How to Estimate Bandwidths?

Wireless Achievable End-to-end

Client TX Queue

Time from head of tx queue to end of transmission (ack)

Naively, send-rate of probe burst or APs report load

AP Buffers

Idea: Use synchronous acks

e

tCount bytes rcvd in a windowMay not receive data alwaysIdea: only count back-to-back large packets!

Page 18: Fat Virtual Access Points Taken from Srikanth Kandula

How to Spread Traffic Across APs?

Page 19: Fat Virtual Access Points Taken from Srikanth Kandula

How to Spread Traffic Across APs?

Put flows through all APs• virtualize 802.11 state• an IP for each interface• toggle APs (and channels)

By default, kernel sends all traffic to one AP

T-Mobile 192.168.3.0/24

MIT 128.30.79.0/24

Hardware (Wireless Card)802.11 State

AP1 AP2

AP1 State AP2 State

Two Interfaces

Toggler

Page 20: Fat Virtual Access Points Taken from Srikanth Kandula

How to Spread Traffic Across APs?

Put flows through all APs• virtualize 802.11 state• an IP for each interface• toggle APs (and channels)

By default, kernel sends all traffic to one AP

• Spread flows to APs• Fast header re-writing

Hardware (Wireless Card)

AP1 AP2

AP1 State AP2 State

Two Interfaces

Toggler

Spreader

Distribute load w/o changing APs and applicationsDistribute load w/o changing APs and applications

Page 21: Fat Virtual Access Points Taken from Srikanth Kandula

FatVAP Realizes a Fat Virtual AP

• Which APs to connect to and for how long?– Estimate Bandwidths, Solve Optimization

• How to divide traffic across the APs?– Virtualize, Pin Flows to APs, rewrite headers

• Switch quickly but without losing packets– In-driver, Private Queues, Isolation

And, with only client-side changesAnd, with only client-side changes

Page 22: Fat Virtual Access Points Taken from Srikanth Kandula

Related Work

VirtualWiFi (Microsoft Research)AP Selection (Intel Research, U Michigan)SyncScan (UCSD)MadWifi (open-source)

o Divide Time across APs to maximize throughputo Sustain TCP flows through multiple APso Transparently spread traffic across APs

Page 23: Fat Virtual Access Points Taken from Srikanth Kandula

Results

Page 24: Fat Virtual Access Points Taken from Srikanth Kandula

Experimental Setup

Compare FatVAP driver with unmodified MadWifi• Scenarios

– Testbed built from Cisco, NetGear and MadWifi APs– Residential deployments– Commercial hotspots

• Traffic– Long-lived TCP flows– BitTorrent (Azureus client, Planetlab peers)– Mimic Web Browsing (modified WebStone)

Page 25: Fat Virtual Access Points Taken from Srikanth Kandula

Can FatVAP Aggregate Bandwidth?

6Mbps

5.8

11.4

17

20.6 20.5

5.8 5.8 5.8 5.8 5.8

0

5

10

15

20

25

1 2 3 4 5

FatVAP Unmodified MadWifi

Thr

ough

put

(Mb/

s)

Number of APs Aggregates end-to-end up to the wireless bottleneck Aggregates end-to-end up to the wireless bottleneck

~22 Mbps

Page 26: Fat Virtual Access Points Taken from Srikanth Kandula

Can FatVAP Balance Load?

12Mbps2Mbps

C1 C2 C3 C4 C5

Page 27: Fat Virtual Access Points Taken from Srikanth Kandula

Can FatVAP Balance Load?

12Mbps2Mbps

Thr

ough

put

(Mb/

s)5

4

3

2

1

0

FatVAP

2.93.5

3.1 2.8 2.7

.9.9

4.4

3.33.8

Unmodified MadWifi

Simplifies Network Deployment!Simplifies Network Deployment!

C1 C2 C3 C4 C5

C1 C2 C3 C4 C5 C1 C2 C3 C4 C5