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. 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

6. 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)‏

7. 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

8. QuickWiFi design

9. 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

11. 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

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

13. 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

14. 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

15. 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

16. 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

17. Thanks! Questions?