1. WiFi-Reports: Improving Wireless Network Selection Jeffrey Pang (CMU) with Ben Greenstein (IRS) Michael Kaminsky (IRP) Damon McCoy (U. Colorado) Srinivasan Seshan (CMU)

2. Motivation tmobile attwifi (ap 1) attwifi (ap 2) seattlewifi linksys Free Public Wifi $3.99 $9.99 Free! Which networks will run my applications? Which ones have good end-to-end performance? Quality = ??? Network selection today We often have many choices of wireless networks but little information about each Jiwire.com Hotspot database Jiwire.com Hotspot database

3. Project Goal WiFi-Reports Hotspot database WiFi-Reports Hotspot database tmobile attwifi (ap 1) attwifi (ap 2) seattlewifi linksys Free Public Wifi I need to use Skype VoIP so this is the best network for me. Network selection today Bandwidth: 300 kbps Blocked ports: None Bandwidth: 100 kbps Blocked ports: None Doesn’t work! Bandwidth: 100 kbps Blocked ports: Email, Skype WiFi-Reports is a service that provides more detailed information about network performance and functionality

4. WiFi-Reports Overview WiFi-Reports Account Service WiFi-Reports Account Service Independent Report Databases Report on tmobile: Bandwidth: 1200 kbps Blocked ports: None Report on tmobile: Bandwidth: 1200 kbps Blocked ports: None Report on UBookstore Cafe: Bandwidth: 4000 kbps Blocked ports: Email, Skype,… Report on UBookstore Cafe: Bandwidth: 4000 kbps Blocked ports: Email, Skype,… Users collect measurement reports when they use networks Reports are sent to databases for others to download

5. Questions and Challenges How useful would this system be in practice? – Do users have many choices of usable wireless networks? – Is there diversity in network performance/functionality? – Is performance stable enough to be predictive? – Are networks better for some applications but worse for others? – Do enough users use real networks to gather measurements? How do we limit “report fraud” and provide anonymity? – Not even the account service should be able to link a user’s reports to each other (otherwise location privacy is violated) – But each user should only be able to report once per network

6. Part I: Measurement Study We built a measurement tool to simulate reports that users would collect – Bandwidth, latency, jitter, blocked ports, number of other users, etc. We measured all networks visible from: – 13 hotspots near The Ave – ~7 days at different times of day Measurement procedure: – Sit near center of hotspot – Perform active spot measurements (2-3 minutes per network) shinka tea tullys starbucks tullys trabant oasis lounjin yunnie bubble tea sureshot bookstore cafe cafe on the ave starbucks cafe solstice Our study is the first to examine pay networks and encrypted networks, in addition to open networks Our study is the first to examine pay networks and encrypted networks, in addition to open networks

7. Results: Are there many APs? Better

8. Results: Are there many APs? Better

9. Results: Is there diversity? Better

10. Results: Is there diversity? Better

11. Results: Are measurements predictive? Better

12. Results: Are there application trade-offs? Better Better latency Better bandwidth

13. Results: Are there enough users?

14. Part II: Private and Accountable Reporting How do we limit “vote fraud” and provide anonymity? Requirements: – No one, even the account service, should be able to link a user’s reports to each other (otherwise previous work says location privacy is violated) – Each user should only be able to report once per network

15. Anonymizing Mix Network Design Sketch WiFi-Reports Account Service WiFi-Reports Account Service Report on tmobile: Bandwidth: 1200 kbps Blocked ports: None Report on tmobile: Bandwidth: 1200 kbps Blocked ports: None Independent Report Databases tmobile seattlewifi CAFEONTHEAVE … 1.Client creates one token per AP 2.Client blinds each token 3.Account Service signs blinded tokens 4.Client unblinds tokens … 1.Client uses and measures an AP 2.Client uses token to sign report 3.Report is published via mix network Report on tmobile: Bandwidth: 1200 kbps Blocked ports: None Report on tmobile: Bandwidth: 1200 kbps Blocked ports: None Report on tmobile: Bandwidth: 1200 kbps Blocked ports: None Report on tmobile: Bandwidth: 1200 kbps Blocked ports: None Report on tmobile: Bandwidth: 1200 kbps Blocked ports: None Report on tmobile: Bandwidth: 1200 kbps Blocked ports: None

16. Design Sketch Details = random public key pair {K tmobile, K tmobile -1 } – Account Service signs the public key K tmobile – Private key K tmobile -1 is used to sign reports  can update reports Assumptions: – The account service only gives one identity to each user – Most users are honest Open issues: – Client must get all tokens signed before using them  expensive If only get signed token after AP is used, use of the AP is revealed Can obtain a subset of all tokens instead (e.g., all tokens for a city)  trade off between token signing overhead for more location privacy – Location impacts wireless performance. How to include it in reports? Current idea: use wifi beacons as a “fingerprint” for a location (ala PlaceLab)

17. Ongoing work Implementing Wifi-Reports service – Some parts of Windows client implemented – Can turn measurement tool into a Linux client Use measurement study to “simulate” effectiveness of WiFi-Reports over 1 week Goal: submit paper to MobiSys ‘09 (Dec. 3) Graduate.

18. Questions? (Other summer projects)

19. Results: Is there diversity? Better Blocked port = no measurement

20. Results: Is there diversity? Better Blocked port = no measurement

21. Results: Are measurements predictive? Better Blocked port = no measurement