1 / 17

Goal

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. Goal. Vehicular content delivery using open 802.11 APs, downlink (main) and uplink

leroy
Télécharger la présentation

Goal

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  11. Cabernet Transport Protocol • Downlink scenario • Sender: CTP proxy in the internetReceiver: vehicle with CTP

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

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

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

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

  16. Thanks!Questions?

More Related