Content Distribution in Vehicular Ad Hoc Network Computer Science Dept, UCLA Dec. 14, 2006 IBM 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! C 1 Sends Block 1 C3C3 C2C2 C1C1 C6C6 C5C5 C4C4 B1 C 3 Sends Block 2 B2 C 2 Sends Block 2 B1B2 C 5 Sends Block 2 B2 B1 is STILL missing!!

5 Network Coding  Let a file has k blocks: [B 1 B 2 … B k ]  Encoded block E i is generated by E i = a i,1 *B 1 + a i,2 *B 2 + … + a i,k *B k a i,x : randomly chosen over the finite field  Any “k” linearly independent coded blocks can recover [B 1 B 2 … B k ] by matrix inversion  Network coding maximizes throughput and minimizes delay a 1,1 =1 a 1,2 =0 Coded Block 10 E1E1 Coded Block 11 E2E2 Matrix Inversion B110 B201 B1 B2 a 2,1 =1 a 2,2 =1 Network coding over the finite field GF(2)={0,1}

6 Network Coding Helps Coupon Collection C 1 Sends Block 1 C3C3 C2C2 C1C1 C6C6 C5C5 C4C4 B1 C 3 Sends Block 2 B2 C 2 Sends a Coded Block: B1+B2 B1B2 B1+B2 B1 C 5 Sends a Coded Block: B1+B2 B1+B2 B2B1 C 4 a nd C 6 successfully recovered both blocks

7 Outline  CarTorrent  Basic Idea  CodeTorrent  Simulation  Conclusion  CarTorrent Demo  CodeTorrent Demo

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

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

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 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 GetBlock G sends a GetBlock message to R G R Y R prepares a re-encoded blockR broadcasts the re-encoded block Check helpfulness: If helpful, store it! Random Linear combination

13 Simulations - Setup  Qualnet 3.9  IEEE b / 2Mbps  Real-track mobility model (Westwood map) 2.4x2.4 km 2  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  Overall downloading progress 200 nodes 40% popularity Time (seconds) Fraction of the # pieces/rank of all the interested nodes

15 Simulation Results  Avg. number of completion distribution 200 nodes 40% popularity Time (seconds)

16 Simulation Results  Multi-hop pulling in CarTorrent As content spreads, CarT shows locality 200 nodes 40% popularity CarTorrent Time (seconds) Avg. hop count exceeding 1 hop

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

18 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

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

20 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 AODV Routing Layer CarTorrent Application

21 Architecture RecvPacketThread Client ReceiveGossipThreadSendGossipThreadFileSplitter RecvPacketThread ListenThread RecvPacketThread CarTorrent File Manager

22 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

23 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

24 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

25 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

26 Demo Setup A: B:

27 Demo A:

28 Sharing a File A:

29 Downloading a File

30 Viewing a Downloaded File Rate(Mbps)

31 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

CodeTorrent Demo Seunghoon Lee and Sung Chul (Brian) Choi

33 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(n 3 )  Plus, disk I/O becomes a big issue! Solution: Split the file into “generations”  (Chou, et al. “Practical Network Coding”)

34 Multi-Generation Network Coding Gen 1Gen 2Gen 3Gen 4Gen 5 14

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

36 Demo Setup 2415 Node 1Node 2Node 3

37 Demo Node 1Node 2Node 3

38 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