Content Distribution in Vehicular Ad Hoc Network

1. Content Distribution in Vehicular Ad Hoc Network Computer Science Dept, UCLA http://www.cs.ucla.edu/NRL Dec. 14, 2006 IBM ITA @ UCLA

2. Content Distribution in VANET • Multimedia-based proximity marketing: • Virtual tours of hotel rooms • Movie trailers in nearby theaters • Vehicular ad hoc networks (VANET): • Error-prone channel • Dense, but intermittent connectivity • High, but restricted mobility patterns • No guaranteed cooperativeness (only, users of the same interests will cooperate) • How do we efficiently distribute content in VANET? • Traditional approach: BitTorrent-like file swarming

3. BitTorrnet-like File Swarming • A file is divided into equal sized blocks • Cooperative (parallel) downloading among peers From Wikipedia

4. Swarming Limitation: Missing Coupon! C1 Sends Block 1 C2 Sends Block 2 C3 Sends Block 2 B2 B2 B2 B1 B1 B2 C1 C2 C3 B2 B2 B1 B2 B2 C4 C5 C6 C5 Sends Block 2 B1 is STILL missing!!

5. a1,1=1 E1 10 Coded Block a2,1=1 E2 11 Coded Block a1,2=0 Matrix Inversion a2,2=1 10 B1 01 B2 Network Coding • Let a file has k blocks: [B1 B2 … Bk] • Encoded block Ei is generated by • Ei = ai,1*B1 + ai,2*B2 + … + ai,k*Bk • ai,x : randomly chosen over the finite field • Any “k” linearly independent coded blocks can recover [B1 B2 … Bk] by matrix inversion • Network coding maximizes throughput and minimizes delay B1 B2 Network coding over the finite field GF(2)={0,1}

6. Network Coding Helps Coupon Collection C1 Sends Block 1 C2 Sends a Coded Block: B1+B2 C3 Sends Block 2 B1+B2 B1+B2 B2 B2 B1 B1+B2 B1 B1 B2 C1 C2 C3 B1+B2 B2 B1+B2 B1 B1 B1+B2 B2 C4 C5 C6 C4 and C6 successfully recovered both blocks C5 Sends a Coded Block: B1+B2

7. Outline • CarTorrent • Basic Idea • CodeTorrent • Simulation • Conclusion • CarTorrent Demo • CodeTorrent Demo

8. Multi-hop pulling w/ proximity-based piece selection Y R R R R Y Y Y Y2 G Previous Work: Cooperative Downloading with CarTorrent Internet Gossiping Availability of Blocks Exchange Blocks via multi-hop pulling Downloading Blocks from AP

9. Single-hop pulling (instead of CarTorrent multihop) Buffer Buffer Buffer B1 *a1 B2 *a2 *a3 File: k blocks B3 + “coded” block *ak Bk Random Linear Combination CodeTorrent: Basic Idea Internet Re-Encoding: Random Linear Comb.of Encoded Blocks in the Buffer Outside Range of AP Exchange Re-Encoded Blocks Downloading Coded Blocks from AP Meeting Other Vehicles with Coded Blocks

10. Design Rationale • Single-hop better than multihop • Multi-hop data pulling does not perform well in VANET (routing O/H is high) • Users in multi-hop may not forward packets not useful to them (lack of incentive)! • Network coding • Mitigate a rare piece problem • Maximize the benefits of overhearing • Exploits mobility • Carry-and-forward coded blocks

11. + + + CodeTorrent - Beaconing • Periodic broadcasting of peer ID and its code vector • Used for searching helpful nodes: those who have at least one linearly independent code block Red is Helpful!

12. Random Linear combination CodeTorrent - Single-hop pulling • A peer pulls coded blocks from the helpful peers 1. G pulls a coded block from R 2. G checks helpfulness and repeats R GetBlock Y G G sends a GetBlock message to R R prepares a re-encoded block R broadcasts the re-encoded block Check helpfulness: If helpful, store it!

13. Simulations - Setup • Qualnet 3.9 • IEEE 802.11b / 2Mbps • Real-track mobility model (Westwood map) • 2.4x2.4 km2 • Distributing 1MB file • 4KB/block * 250 blocks • 1KB per packet • # of APs: 3 • Randomly located on the road sides • Comparing CarTorrent (w/ AODV) with CodeTorrent • AODV w/ net-diameter 3 hops • CodeTorrent with GF(256) Near UCLA Campus

14. Simulation Results • Avg. number of completion distribution 200 nodes40% popularity Time (seconds)

15. Simulation Results • Multi-hop pulling in CarTorrent • As content spreads, CarT shows locality CarTorrent Avg. hop count exceeding 1 hop 200 nodes40% popularity Time (seconds)

16. Simulation Results • Impact of mobility • Speed helps disseminate from AP’s and C2C • Speed hurts multihop routing (CarT) • Car density+multihop promotes congestion (CarT) Avg. Download Time (s) 40% popularity

17. Conclusion • Multihop-based CarTorrent: • Not scalable due to routing overhead • Cooperation may be a problem • Coupon problem • CodeTorrent: • Scales to mobility; favors cooperation; eliminates a coupon problem

18. CarTorrent Demo:Cars get to have fun too Kevin C. Lee and Ian S. Yap

19. CarTorrent Application AODV Routing Layer Overview • Main Idea: CarTorrent uses proximity-based piece selection • Instead of traditional “rarest”-first strategy, use rarest-closest-first or closest-rarest-first strategy • CarTorrent implementation details • CarTorrent layer: browse/share/download files • Core and GUI written in Java • AODV layer: route maintenance tasks and discovery of neighbors • Linux version from Uppsala University

20. Client FileSplitter SendGossipThread ReceiveGossipThread ListenThread CarTorrent File Manager RecvPacketThread RecvPacketThread RecvPacketThread Architecture

21. Components • Client: • A tabbed frame that encapsulates information for subcomponents • 3 tabs; share, download, and search • FileSplitter: • Splits a shared file into parts • Combines downloaded parts into a file • CarTorrent File Manager: • Keeps track of pieces of files from gossips • Includes the algorithms to find rarest pieces, closest pieces, and rarest closest pieces

22. Components (cont.) • SendGossipThread: • A thread that sends gossip msgs periodically • Two types of gossips: • Gossips originated from itself • Gossips received from nearby neighbors • Gossips received from nearby neighbors are sent based on probabilities assigned to interesting and not interesting gossips • Gossips are interesting if client wants the file • Gossips are not interesting if the client does not • ReceiveGossipThread: • A thread that unblocks when receiving a gossip • Discards the gossip if from itself else queues the gossip • Gossips are sent to CarTorrent File Manager for managing

23. Components (cont.) • ListenThread: • Listens for incoming download request • Spawns a RecvPacketThread to process incoming packets • RecvPacketThread: • Processes the incoming packets based on packet type • If packet type == DATA_REQ, send parts that are requested • If packet type == DATA, write the data to the local file-system and combine it if all parts have been received

24. Demo • Series of pictures demonstrating the sharing of a picture file from one source to two clients • Three laptops( two running Linux, one with Windows) • If you are interested in seeing the live demo, do drop by BH4681

25. Demo Setup A: 10.0.0.4 B: 10.0.0.5

26. Demo A: 10.0.0.4

27. Sharing a File A: 10.0.0.4

28. Downloading a File 10.0.0.5

29. Viewing a Downloaded File Rate(Mbps) 10.0.0.5

30. Future Work • Variable piece length to adapt to client’s bandwidth • Test in environments with larger distances between nodes (true multi-hop) • Cross-layer optimization: • Gossip exploits AODV’s RREQ flooding • Add a mechanism to detect the absence of a file in the network by either: • expiring file pieces (after no gossips) • sending out explicit leaving gossip messages • Being able to identify failed transfers and get same file piece(s) from other nodes

31. CodeTorrent Demo Seunghoon Lee and Sung Chul (Brian) Choi

32. Overview • CodeTorrent • Single-hop pulling using network coding • To mitigate a rare piece problem and maximize the benefits of overhearing • Exploits mobility; carry-and-forward coded blocks • Implementation challenge: How to share LARGE files? • Coding/decoding latency: Large file → more blocks → bigger coefficient matrix to invert • Inversion takes O(n3) • Plus, disk I/O becomes a big issue! • Solution: Split the file into “generations” • (Chou, et al. “Practical Network Coding”)

33. 1 4 Multi-Generation Network Coding Gen 1 Gen 2 Gen 3 Gen 4 Gen 5

34. Architecture Communication Module CodeTorrent Network Coding (NC) Galois Field (GF)

35. 2 4 1 5 Node 1 Node 2 Node 3 Demo Setup

36. Node 1 Node 2 Node 3 Demo

37. Future Work • Multi-hop pulling • Content can be pulled from remote peers (just as CarTorrent) • Interference aware data pulling (parallel downloading) • Network coded P2P caching? • Intermediate nodes on the multi-hop path can snoop TCP stream and “cache” for future use • Disk I/O scheduling for “mobile” wireless networks • Reading 100MB takes 10s!  Short wireless link duration! • Efficient scheduling of data blocks for encoding is a must! • If a number of requests come in burst, we must schedule them “efficiently” to optimize disk access