Goal

1. Cabernet: Vehicular Content Delivery Using WiFiJakob Eriksson, Hari Balakrishnan, Samuel MaddenMIT CSAILMOBICOM '08Network Reading Group, NRL, UCLAPresented by: Manu BansalOct 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. • InquickWiFi , 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 internetReceiver: 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?