170 likes | 339 Views
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
E N D
Cabernet: Vehicular Content Delivery Using WiFiJakob Eriksson, Hari Balakrishnan, Samuel MaddenMIT CSAILMOBICOM '08Network Reading Group, NRL, UCLAPresented by: Manu BansalOct 17, 2008
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
Challenges • Intermittent AP availability (discontinuous) • Fleeting connectivity (short duration) • 70% of connection opportunities < 10s duration • When connected, high loss rates • 20% and higher, varying
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)
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
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)
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
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
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
Cabernet Transport Protocol • Downlink scenario • Sender: CTP proxy in the internetReceiver: vehicle with CTP
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
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
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
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