REfactor-ing Content Overhearing to Improve Wireless Performance Shan-Hsiang Shen Aaron Gember Ashok Anand Aditya Akella abc 1d ab 1

Improve Wireless Performance Focus on throughput Leverage wireless overhearing 2 abc

Leveraging Overheard Packets Reduced transmissions => more capacity Several techniques – RTS-id: suppress transmissions [Afanasyev ‘08] – ExOR: better forwarding [Biswas ‘05] – COPE: network coding [Katti ‘08] 3 Do not leverage duplication across transfers

Content-Based Overhearing Ditto [Dogar ‘08] 4 C1 C2 C C C C B B B B A A A A A A AB ABC A A AB ABC A A AB ABC C C B B A A 4 Request Gateway Does not remove sub-packet redundancy Only works for some applications M A N Y M I S S E D O P P O R T U N I T I E S

Application Transport Network Link Physical We REfactor content overhearing Content overhearing at the network layer 5 Identify sub-packet redundancy

Outline Benefits of REfactor approach How REfactor works Challenges & design innovations Additional scenarios Evaluation results 6

Benefits of REfactor Approach Operates at finer granularity – Ditto only works in 8-32KB object chunks – Object chunks require overhearing several packets (not possible at 75% of nodes 50% of the time) 7 Savings from redundancy as small as 64 bytes Leverages any overhearing, even a single packet

Benefits of REfactor Approach Operates at the network layer – Transport-layer approach ties data to application or object chunk – Transport approach requires payload reassembly 8 Redundancy elimination (RE) across all flows Per-packet processing exceeding 600Mbps

Benefits of REfactor Approach Operates in more scenarios – Ditto design limits applicability 9 Improvements in several wireless scenarios

Redundancy Elimination (RE) [Spring ’00] REfactor Overview ChunkReception Prob Chunk AP C1C2 C1 A B E F ChunkReception Prob. 1AB 2 3EF 4 ChunkReception Prob. 1ABC1=1; C2= EFC1=1; C2=0.8 4 Chunk 1AB 2 3EF 4 Chunk 1AB 2 3EF 4 10 C1 A B E F AP does not know which clients overheard

ABGH Data: Chunk 1AB 2 3EF 4 Chunk 1AB 2 3EF 4 ChunkReception Prob. 1ABC1=1; C2= EFC1=1; C2=0.8 4 REfactor Overview AP C1C2 A B G H ChunkReception Prob. 1ABC1=1; C2= EFC1=1; C2=0.8 4 ChunkReception Prob. 1ABC1=1; C2= EFC1=1; C2=0.8 4GHC1=0.7; C2=1 Chunk 1AB 2 3EF 4 C2 A B G H C2 G H Only have estimate of whether client has chunk

GHCD Data: ChunkReception Prob. 1ABC1=1; C2= EFC1=1; C2=0.8 4GHC1=0.7; C2=1 Chunk 1AB 2 3EF 4 Chunk 1AB 2 3EF 4 REfactor Overview AP C1C2 C1 G H C D Chunk 1AB 2 3EF 4 AP 4 4 Chunk 1AB 2 3EF 4GH C1 G H C D C1 C D 4 4 C1 4 = GH 12 ChunkReception Prob. 1ABC1=1; C2=0.8 2CDC1=1; C2=0.5 3EFC1=1; C2=0.8 4GHC1=0.7; C2=1 ChunkReception Prob. 1ABC1=1; C2=0.8 2CDC1=1;C2=0.5 3EFC1=1; C2=0.8 4GHC1=0.7; C2=1 Need to be able to handle cache misses

Challenges Overhearing is probabilistic – Lack tight cache synchronization Resource constrained nodes – Need to limit cache size and processing overhead 13

Caching Two issues: – How do we store chunks? – How do we refer to them in shim headers? Hash table with pointers to log of chunks Identify with SHA-1 hash 14 Large hash is expensive Consistent across caches

Caching Self-addressing chunks – 20-bit hash used as index into cache 15 Consistent across caches Efficient use of memory Need to properly handle cache collisions

Removing Redundancy 16 Traditional RE has tight synchronization and can remove all identified redundancy – Not the case with wireless overhearing Reception probability vector – Does client cache contain chunk? Model-Driven RE – What is the benefit from removing a redundant chunk?

Reception Probability Vectors Destination client (d) definitely has chunk Overhearing client (o) may have chunk – Compare r d and r o 17 Rate used to send to destination (d) Last rate used to send to overhearing client (o) rdrd roro

Model-Driven RE 2.Cache miss => extra transmissions 18 Expected benefit = [transmission time savings] – [cache miss cost] Expected benefit = [transmission time savings] – [cache miss cost] 1.Reduced packet size air time savings higher goodput =>

C1C2C4C3 Relay Network Coding Scenario Chunk 1AB 2 3 Chunk 1 2CD 3 C3 & C4 Chunk 1AB 2 3 Chunk 1 2CD 3 E F 1 1 C3 2 2 G H C4 C3 A B E F 19 COPE [Katti ’08] + REfactor C4 C D G H C4 C D G H C3 A B E F C D G H C3 & C4

Evaluation Implemented in Click Single AP with two clients – C1: perfect overhearing; high rate – C2: varied overhearing; varied rate Traces derived from real-world traffic – 49% inter-client redundancy 20 C1C2 Near Middle Far

Testbed Results Goodput = Total Data Transferred Total Transmission Time C2’s Distance From AP REfactor Goodput No RE Goodput Percentage Improvement 3m (near)4.0 Mbps3.4 Mbps20% 6m (middle)3.0 Mbps2.6 Mbps14% 10m (far)1.3 Mbps1.2 Mbps6% 21

Simulation Results 22

Conclusion Up to 20% improvement in wireless goodput Fine-grained at network layer – Enables better leveraging of overhearing – Savings with any type of application Improvements in several wireless scenarios 23

Evaluating REfactor + Network Coding Click simulation with REfactor + COPE [Katti ‘06] C3 & C4 Overhearing Percentage Percent better than just COPE 90%14% 50%10% 3% 24

SHA-1 vs. Self-addressed Chunks 25 Minimum chunk size REfactorSHA Hash Based Redundancy Detected Effective RERedundancy Detected Effective RE

Memory vs. Unique Chunks Tradeoff Require 2 n * m bytes of memory to store 2 n chunks of maximize size m 26

Model-Driven RE 27 Use model to decide on removal of 64B chunk

Simulation Results - Airtime 28

C1C2 AP1 To: C1 ABEF To: C1 ABEF Chunk Multi-AP Scenario AP2 Chunk 1AB 2 3EF Chunk 1AB 2 3EF Chunk 1AB 2 3EF Chunk To: C2 ABCD To: C2 CD 1 1 Chunk 1AB 2CD 3 To: C1 ABCD Chunk 1AB 2 3EF 29

Ad-hoc Mesh Scenario R1 R2 C2C1 Chunk To: C2 ABEF Chunk AB 2 3EF Chunk 1AB 2 3EF Chunk 1AB 2 3EF Chunk 1AB 2 3EF To: C2 ABEF To: C1 ABCD Chunk 1AB 2CD 3EF Chunk 1AB 2CD 3EF Chunk 1AB 2CD 3EF To: C1 CD 4 4 Chunk 1AB 2 3EF To: C1 ABCD 30