1. Cabernet: Vehicular Content Delivery Using WiFi Jakob Eriksson, Hari Balakrishnan, Samuel Madden MIT CSAIL MOBICOM '08 Network Reading Group, NRL, UCLA Presented by: Manu Bansal Oct 17, 2008

2. Goal Vehicular content delivery using open 802.11 APs, downlink (main) and uplink Non-interactive applications  up/down: traffic/environment updates  down: maps, media, docs, software updates

3. Challenges Intermittent AP availability (discontinuous)‏ Fleeting connectivity (short duration)‏  70% of connection opportunities < 10s duration When connected, high loss rates  20% and higher, varying

4. Solution – 1. QuickWiFi Client side application Combines connection established protocol layers into a single process Quick connection establishment Mean connection delay: ~400ms (vs 12-13s)‏ Mean connection duration: 10s Mean time b/w encounters: ~120s (vs 260s)‏

5. Quick WiFi Operation Tuned for vehicular WiFi Authentication, association,DHCP and ARP all include timeout/retry protocols By reducing timeouts to hundreds of milliseconds, rather than seconds, we can dramatically reduce the mean connection establishment time. In quickWiFi, the time out period in each phase is set to 100ms, after which the request is sent again up to 5times. 만약 그래도 실패하면 the process starts over with the scanning phase.

6. Quick WiFi Operation(con’t) Back-to-back authentication/association Ap 들은 client 들에게 authenticate 를 요구하지만 이 과정은 언제나 성공이다. There is no need to wait for the response to our authentication request before sending the association request. Should the subthentication request be lost in the meantime, the subsequent assocation request will fail, and QuickWifi will automatically restart the process Quick WiFi includes two additional functions to monitor and report the status of an end-to-end connection.

7. Quick WiFi Operation(con’t) Ping-through WF use a quick request-response exchange with a central server to verify end-to-end connectivity. Upon success, QWF explicitly notifies applications that Internet connectivity is available, through an OS signal. Should the end-to-end connectivity test fail, the connection is torn down, and scanning is resumed.

8. Quick WiFi Operation(con’t) Connection loss monitoring We need to quickly discover when a connection is lost, and return to scanning for new APs. If we have not seen any transmissions(including beacon) for 500 millisecond, it is likely that the car has moved out of the range of the AP.

9. Optimal scanning strategy

12. Solution – 2. CTP Cabernet Transport Protocol Differentiates WiFi losses from wired-n/w congestion Key novelty: achieved using only client-side modifications Uses lightweight probing scheme to estimate congestion Supports intermittent connectivity using a proxy  DTN type apps can choose to work without proxy

13. Solution – 3. Static bit-rate Default 802.11 bit-rate selection scheme is optimized for static connections Cabernet uses fixed 11Mbps rate for uplinks Downlinks cannot be controlled (decided by APs)‏

14. Results Tested on a real testbed – 10 taxis in Boston 124 hours of drive time Average throughput: 38 MB/hour per car (86kbps)‏ Mean time for a 1MB response: 9min Average throughput in a session: 800kbps

15. QuickWiFi design

16. QuickWifi design Special scanning  based on observed channel AP-density (non- uniform)‏ Improved timeouts  based on typical wireless RTTs; each set to 100ms, 5 retries (Q: why are default so high, like ~1s?)‏ Parallelized steps  do not wait for auth-response; back-to-back assoc Eliminate manual intervention Notify apps about WiFi on/off

18. QuickWiFi performance Connection time ~400ms (vs 12-13s) Most time spend in DHCP phases (~50%)‏  DHCP disc, req both bcast, poor performance  DHCP server sends ARP req before response ARP query from client after DHCP req does through better  probably channel has improved after DHCP communication (Q: why?)‏  also, message shorter, so less prone to errors

19. Cabernet Transport Protocol Downlink scenario Sender: CTP proxy in the internet Receiver: vehicle with CTP

20. Cabernet Transport Protocol Existing TCP over WiFi:  Westwood: useful only if error rate <5%  others require modification on APs as well Main idea: distinguish last-hop errors and congestion React only to congestive losses, assumed only from AP-internet Emulate TCP with the same end-to-end RTT and sender-to-AP error rate

21. Cabernet Transport Protocol Mechanism: use a sparse probe from CTP sender (in the internet) to the AP Use this as a congestion decision Estimate drop rate based on ACKs Rate increase: similar to TCP Rate decrease: only if probe did not get ACK Rate = max(rate.(1 – c.p_loss), r_min)‏ p_loss computed as an EWMA from ACKS

22. CTP Performance Achieves 800kbps when connected 2x throughput on median, 35% gain on mean skew: long-duration connections have significantly lower packet loss rates Caveats:  probe packet needs to be as large as data packet  80% AP's do not support preferred probe scheme  other probe schemes are more expensive

23. Conclusions + Significantly shorter connection time  In my opinion, the most important contribution  Perhaps even more useful for V2V + Allows better utilization of open Aps + More customized transport, better throughput + Hides address changes on handoffs - Needs proxy for CTP - b/w improvement mainly for downlinks - Incentives for open APs

24. Thanks! Questions?