Is an Office Without WiresFeasible?
Sharad Agarwal
Jakob Eriksson, Victor Bahl, Jitu Padhye
2.JUNE.2006
2
2
All-Wireless Office
•No wires
•No switches
•No APs
2.JUNE.2006
3
3
All-Wireless Office
•Not large corporation
•Small offices
–10-100 PCs
–Rapid deployment
–Short-term office
–Low-cost solution
•Not replacement for wire
•Looking for good performance
–how long a user waits for a transaction
–small additional delay
2.JUNE.2006
4
All-Wireless Office
•Office PCs
–Two 802.11 interfaces
•simultaneous xmit & rcv on non-interfering channels
•frequency diversity; range-rate tradeoff
•Office servers
–mail, domain controllers, code repositories
–proxies with wires
•Mesh routing
–A lot of prior work
•Routing protocols
•Link quality metrics
2.JUNE.2006
5
5
Questions
•What additional delay penalty will a meshnetwork impose
–In typical office configurations
–With typical office traffic
•How should an administrator pick :
–Wireless hardware
–IEEE 802.11 band
–Routing metric
–User-server placement
–Spatial reuse, hidden terminal
2.JUNE.2006
6
6
Don’t We Already Know?
•Typical evaluation
–Select sender, receiver at random; 1 TCP flow, 2 mins
–Repeat 100 times, calculate median
2.JUNE.2006
7
7
Methodology
•Capture traffic from 11 office users
–Packet level capture insufficient
•TCP effects in wireless, multihop very different
–Socket level is best: open, send, receive, close
•Replay on mesh testbed among office users
–MCL by Draves, Padhye, Zill @ MSR (2004)
•DSR-like routing with virtual link layer optimizations
•Link metrics: hop, RTT, PKTPAIR, ETX, WCETT
–Assign users, application servers to testbed
•Examine several design choices
•Not disrupt actual users
2.JUNE.2006
8
8
Captured Traffic
•Very diverse traffic types, sizes, concurrency
•Map each type to 1-2 mesh machines for replay
•Non-winsock traffic not captured
–Get user RPC; miss SMB, NBT (almost all IDS for us)
2.JUNE.2006
9
9
Replay Model
•Concurrentsessions
•Session
–connect todisconnect
–multipletransactions;not concurrent
•Transaction
–1 send, 0+receives
•Response time
–start of send
–end of lastreceive of thetransaction
2.JUNE.2006
10
10
Mesh Testbed
Central
Distant
Extreme
User 01
203
203
203
User 02
205
205
205
User 03
207
206
206
User 04
208
208
208,207
User 05
209
209
209,210
User 06
211
211
211,214
User 07
226
215
215,216
User 08
225
217
217,202
User 09
218
218
218,204
User 10
227
219
219,225
User 11
204
220
220,226
Domain Controllers
214,215
204,226
201,227
Source Depots
217
227
201,227
Exchange
220
202
201,227
Proxies
216,219
201,225
201,227
Config
NetgearWG
NetgearWAB/G
ORiNOCOProxim
TransmitPower
RTS /CTS
A
a-56
a-36
100%
B
a-56
a-36
100%
on
C
a-56
g-10
100%
D
g-10
a-56
100%
E
g-10
a-56
50%
F
g-10
a-56
12.50%
2.JUNE.2006
11
11
Light Load, Central Placement
2.JUNE.2006
12
12
Heavy Load, Distant Placement
2.JUNE.2006
13
13
Summary of Results
•Results are unusual
–Captured traffic is very different than synthetic
–Prior work’s throughput results not very helpful
•Many configurations – median delay <20ms
–802.11 hardware had upto 2.5x difference
–802.11 band had upto 2x difference
–Server placement had upto 3x difference
–No benefit of spatial reuse, hidden node avoidance
–2 routing metrics bad, 3 good & very similar
2.JUNE.2006
14
14
Open Issues / Limitations
•1 testbed, 1 set of user traces
–but many configurations, different time periods
•Performance can be improved further
–cross interference detection & adaptation
–gateway balancing
•Skipped some real world issues
–fairness
–security / DoS
•Jamming, routing disruption, resource consumption