Cabernet: Vehicular Content Delivery Using WiFi

Jakob Eriksson, Hari Balakrishnan, Samuel MaddenMIT CSAIL

MOBICOM '08

Network Reading Group, NRL, UCLAPresented by: Manu Bansal

Oct 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)

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.

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.

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.

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.

Optimal scanning strategy

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

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 internet

Receiver: 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

Thanks!

Questions?