Lottery Meets Wireless Sharad Saha Shravan Rayanchu Dec 14, 2007
The Problem Flexible, fine-grained bandwidth allocation in enterprise wireless LANs Motivation Wireless bandwidth is a scarce resource Emerging applications require QoS guarantees Voice-over-IP, Streaming Multimedia Dec 14, 2007
Use case Enterprise WLAN Dec 14, 2007
Use case Enterprise WLAN Media contention Dec 14, 2007
Current Practice IEEE 802.11e provides service differentiation Four classes: Data, Voice, Video, Best Effort Not fine grained, (IP, port, protocol), Time Not dynamic, no proportion Dec 14, 2007
Current Practice IEEE 802.11e provides service differentiation Four classes: Data, Voice, Video, Best Effort Limitations Coarse granularity Not fine grained, (IP, port, protocol), Time Not dynamic, no proportion Dec 14, 2007
Current Practice IEEE 802.11e provides service differentiation Four classes: Data, Voice, Video, Best Effort Limitations Coarse granularity Inflexible Not fine grained, (IP, port, protocol), Time Not dynamic, no proportion Dec 14, 2007
Current Practice IEEE 802.11e provides service differentiation Four classes: Data, Voice, Video, Best Effort Limitations Coarse granularity Inflexible No concept of proportions Not fine grained, (IP, port, protocol), Time Not dynamic, no proportion Dec 14, 2007
Current Practice IEEE 802.11e provides service differentiation Four classes: Data, Voice, Video, Best Effort Limitations Coarse granularity Inflexible No concept of proportions Ignorant of traffic characteristics Not fine grained, (IP, port, protocol), Time Not dynamic, no proportion Dec 14, 2007
Our Approach Lottery Scheduling at the Access Point Policy file defines flows (similar to ACLs) and proportions Contending flows participate in lottery with tickets given in proportion Lucky winner gets to send the packet Dec 14, 2007
Does it work ? Fine grained allocation : Flows Flexibility : Dynamic policies Proportions : Tickets Traffic characteristics : Ticket inflation Scalability : Stateless, Simple Dec 14, 2007
Outline Introduction Lottery : Design and Implementation Evaluation Conclusions Dec 14, 2007
Lottery Implementation Define flow:ticket pairs (Port 5001 : 100) (IP 128.105.102.20 : 60) (TCP, Port 80 : 200) On a TX opportunity, draw a lottery and send packet Linux 2.6.17.13 Kernel, Madwifi wireless driver, Proc FS for policy inputs Dec 14, 2007
Transmit Path Dec 14, 2007
Transmit Path Dec 14, 2007
Transmit Path Dec 14, 2007
Transmit Path Currently queuing happens in the firmware Dec 14, 2007
Transmit Path Currently queuing happens in the firmware A callback function is invoked after every packet transmission Dec 14, 2007
Lottery Implementation Dec 14, 2007
Lottery Implementation Dec 14, 2007
Lottery Implementation Dec 14, 2007
Lottery Implementation Dec 14, 2007
Lottery Implementation Dec 14, 2007
Lottery Implementation Generic Framework Lottery Scheduling Stride Scheduling Dec 14, 2007
Ticket Inflation Packet size affects the throughput Flow 1 : Flow 2 = 100 : 100 Flow 1 (100 bytes) , Flow (200 bytes) Effective ratio = 1 : 2 Per-packet Ticket Inflation Actual Ticket = Ticket * (Base Size) / (Pkt Size) Flow 1 = 100 * 200/100 = 200 Flow 2 = 200 * 200/200 = 200 Effective ratio = 1 : 1 Dec 14, 2007
Outline Introduction Lottery : Design and Implementation Evaluation Conclusions Dec 14, 2007
Exp #1 : Does it work ? Setup One AP, One client UDP Flows from AP to client Flow 1 : Flow 2 = 1 : 2 Dec 14, 2007
Exp #1 : Does it work ? OFF Dec 14, 2007
Exp #1 : Does it work ? OFF ON (Desired ratio 2 : 1) Dec 14, 2007
Exp #1 : Does it work ? ON (Desired ratio 2: 1) OFF OFF Dec 14, 2007
Exp #1 : Does it work ? Yes, it works! ON (Desired ratio 2: 1) OFF OFF Dec 14, 2007
Exp #2 : How well does it work ? ON (Desired ratio 2: 1) Dec 14, 2007
Exp #2 : How well does it work ? Received Proportion 2.018 : 1 It works pretty well ! ON (Desired ratio 2: 1) Dec 14, 2007
Exp #3 : Multiple clients Setup One AP, two clients UDP Flows from AP to clients Client 1 : Flow 1, Flow 2 Client 2 : Flow 3 Flow 1: Flow 2: Flow3 = 1 : 2 : 4 Dec 14, 2007
Exp #3 : Multiple clients F1 Dec 14, 2007
Exp #3 : Multiple clients F1 F1, F2 Dec 14, 2007
Exp #3 : Multiple clients F1 F1, F2 F1, F2, F3 Dec 14, 2007
Exp #3 : Multiple clients F1 F1, F2 F1, F2, F3 Received Proportion 1 : 2.01 : 3.98 Works well across clients Dec 14, 2007
Exp #4 : Different protocols ? OFF Dec 14, 2007
Exp #4 : Different protocols ? OFF ON Dec 14, 2007
Exp #4 : Different protocols ? Received proportion 1 : 1.93 Works well across protocols F1, F2 F1, F2, F3 OFF ON Dec 14, 2007
Exp #4 : Effect of packet size OFF Dec 14, 2007
Exp #4 : Effect of packet size ON (NO Inflation) OFF Dec 14, 2007
Exp #4 : Effect of packet size ON (NO Inflation) ON (with Inflation) OFF Dec 14, 2007
Exp #4 : Effect of packet size Agg. Throughput 6.94 Mbps Agg. Throughput 5.83 Mbps ON (NO Inflation) ON (with Inflation) OFF Dec 14, 2007
Exp #4 : Effect of packet size F1, F2, F3 Ticket Inflation makes packet size irrelevant Tradeoff: Efficiency Vs Fairness ON (NO Inflation) ON (with Inflation) OFF Dec 14, 2007
Exp #5 : Effect of Bursty Traffic Dec 14, 2007
Exp #5 : Effect of Bursty Traffic No Contention Contention Dec 14, 2007
Exp #5 : Effect of Bursty Traffic No Contention Contention Lottery makes sense when there is contention Dec 14, 2007
Exp #6 : Is it Scalable ? Dec 14, 2007
Lottery is scalable, does fine-grained allocation! Exp #6 : Is it Scalable ? Contention Lottery is scalable, does fine-grained allocation! Dec 14, 2007
Exp #7 : Lottery Vs Stride Dec 14, 2007
Exp #7 : Lottery Vs Stride Stride is more accurate than Lottery But needs more state, processing Dec 14, 2007
Exp #8 : TCP and Lossy Links Bad Links Good Links Dec 14, 2007
Conclusions Lottery Scheduling Flexible, Fine-grained bandwidth allocation Works across different clients, packet sizes, traffic types, protocols Interaction with TCP in presence of lossy links Simple and a powerful concept Dec 14, 2007