Amar Phanishayee Fahad Dogar Himabindu Pucha Olatunji Ruwase Dave Andersen Carnegie Mellon University CMU Speaking Skills Talk Wireless Networks Wired Link Wireless Router Wireless Link ID: 684174
Download Presentation The PPT/PDF document "Ditto : Eavesdropping for the Common Go..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Ditto: Eavesdropping for the Common Good in Multi-hop Wireless Networks
Amar PhanishayeeFahad Dogar, Himabindu Pucha, Olatunji Ruwase, Dave Andersen
Carnegie Mellon University
CMU Speaking Skills TalkSlide2
Wireless Networks
Wired
Link
Wireless
Router
Wireless
Link
Cable Modem
Access-Point Based
(Single Wireless Hop)Slide3
No Infrastructure Cost Effective, Greater Coverage
Poor throughput
Wireless Networks
Multi-hop Wireless (Mesh) Networks
GatewaySlide4
Hop Count Affects Throughput
Pairwise
transfers in a 28 node campus testbed
More hops
slower transfers (low throughput)
Median
3.2Mbps
0.5Mbps
0.2MbpsSlide5
Ditto: Key ContributionsDitto improves throughput by reducing hop count to acquire commonly requested data
Caching of overheard dataAlso cache data on the path of a transferApplication independent cachingDitto improves throughput (on 2
testbeds)Up to 7x better than on-path cachingUp to 10x better than no cachingSlide6
Caching In Ditto Helps Speed Transfers
On-Path +
Opportunistic
Caching
Ditto
Path of the transfer:
Alice--
A1--A2-
-Gateway
A1 and
A2 --
on-path
caching
A3 --
opportunistic
caching
A2
A3
Gateway
A1
Request
Response
Cached copySlide7
Outline
OverviewWhy poor throughput in mesh networks?Ditto’s DesignEvaluationFuture WorkSlide8
Transmit Range:
Range in which router’s transmission can be
fully
decoded
Interference Range:
Range in which router’s transmission
can interfere
but may not be fully decoded
Interference
Interference: Receivers in Interference Range cannot decode simultaneous transmissionsSlide9
Avoiding Interference:
Don’t Transmit If You Know Others Are
Transmitting one at a time avoids interferenceSlide10
Gateway
A3
A1
A2
Subsequent Hops Interfere
D1’s transmission from A2 to A3 stalled
Cause for poor throughput in mesh networks
Subsequent Wireless Hops Interfere
D1
D1
D2Slide11
Mesh Networks Have Poor Throughput
Some links have a high loss rate
Subsequent hops interfere with each other
More hops
slower transfers (low throughput)
Gateway is a bottleneck
A1
A2
A3
GatewaySlide12
Outline
OverviewWhy poor throughput in mesh networks?Ditto’s DesignOpportunities to improve throughput
How does Ditto utilize these opportunities?EvaluationFuture WorkSlide13
Opportunities To Improve ThroughputLocality in access patternsMany clients from different parts of the network request the same data over time
e.g. Operating System Updates, Streaming videoWireless routers can overhear other transfersThe positive aspect of broadcast
Looks like a job for … Opportunistic CachingSlide14
Challenge:
Lossy OverhearingWireless networks have high loss ratesLoss recovery: link layer retransmissions
Overhearing node also experiences lossesLosses independent of that at Receiver
Cannot
ask for retransmissions
Successfully overhearing a large
file
is unlikely
1
1
2
2
A3
A1
A2
1
2
2
A1
A2Slide15
Chunk Based Transfers
Lossy overhearing cannot overhear entire fileSmaller caching granularity
Divide file into smaller chunks (8 – 32 KB)Use chunk as a unit of transferDitto uses Data Oriented Transfer (DOT)
1
for chunk based transfers
1
Tolia
et al,
An Architecture for Internet Data Transfer
. NSDI 2006.Slide16
A Ditto Transfer
chunkID3
chunkID1
chunkID2
foo.txt
Cryptographic Hash
Chunking
App
App
DITTO
chunk ids
Chunk request
DITTO
Chunk response
request
response
request
response
Receiver
Sender
Ditto Proxy
Ditto Proxy
Request – foo.txt
Response: chunk ids{1,2,3}
chunk idsSlide17
Proxy Serves Chunk Request Directly If Chunk In Local Cache
Proxy
Proxy
Proxy
Chunk
Request
Chunk
Response
CacheSlide18
Proxy Routes Request Towards Gateway If Chunk Not In Cache
Next-Hop based on routing table information
Separate TCP connection on each hop
On-Path Caching
Proxy
Proxy
Proxy
Chunk
Request
Chunk
Response
Cache
Chunk
Request
Chunk
Response
GW
Next HopSlide19
Sniffer Module Caches Overheard Chunks
Opportunistic Caching
Proxy
Sniffer
Cache
Overhear
and r
eassemble streams
Identify c
hunks in streams
Handoff entire chunk to proxy for cachingSlide20
Outline
OverviewWhy poor throughput in mesh networks?Ditto’s DesignWhy caching, overhearing?
Chunk based transfers and cachingHow does Ditto overhear and reconstruct chunks?Evaluation
Future WorkSlide21
Sniffer Module Reassembles Overheard Streams
A3
(Overhearing)
Path of the transfer:
Alice – A1 – A2 …
Stream identification & placement
within the
stream
Next
Steps: identify chunk
A1
A2Slide22
Chunk Identification
A3
(Overhearing)
Path of the transfer:
Alice – A1 – A2 …
A1
A2
Chunk Boundaries
Look for Ditto header
What if there were losses within the overheard chunk?
C1Slide23
Optimization: Inter-Stream Chunk Reassembly
Look for Ditto header
Chunk Boundaries
Sniffer identifies the
same chunk
across streams
Correlates and fills in the blanks
A1
A2
C1Slide24
Outline
OverviewWhy poor throughput in mesh networks?Ditto’s Design
EvaluationReconstruction EfficiencyTransfer ThroughputFuture WorkSlide25
Emulab Indoor Wireless TestbedSlide26
MAP Campus Testbed (Purdue Univ.)
Gateway
11
28 node Indoor/Outdoor Campus-wide Mesh NetworkSlide27
Experiment
Can we overhear complete chunks?
Receiver
Observer
A r
eceiver
initiates transfer
1MB file, 8KB chunks
Observers report % of chunks reconstructed
Receiver reports throughput
Caches are cleared & next node
becomes
a receiver
If n nodes
in network,
[n* (n - 1)] observers in all
100
90
80
100
100
100
30
10
0
0
0
0
0
0
50
0
20Slide28
Overhearing Complete Chunks Is Feasible
Around 30% of the observers reconstruct at least 50% chunks
For any transfer, ~30% of the nodes can overhear a large fraction of the chunks
Complete chunks overheard (%)Slide29
Nodes farthest from the gateway & transfer paths overhear nothing
Complete chunks overheard (%)Slide30
Gateway
11
31
19
12
25
18Slide31
Nodes closer to the gateway & transfer paths overhear effectively
Complete chunks overheard (%)Slide32
Gateway
11
34
5
30
14
Shield the gateway from becoming a bottleneckSlide33
Factors Affecting Chunk Reconstruction
Factor
Insight
Proximity
N
odes closer to
gateway overhear more chunks.
Can shield the gateway from becoming a hotspot.
Chunk Size
Smaller Chunk Size
Better Reconstruction
8 KB provides good reconstruction efficiency with low overhead.Slide34
Experiment: Throughput Evaluation
Receiver
Observer
Leaf nodes
are receivers
A r
eceiver
initiates transfer
reports throughput
Next receiver downloads the same fileSlide35
Opportunistic Caching >> On-path Caching
Receiver
On-path Caching
Overhearing & CachingSlide36
Throughput Improvement Using Ditto
Median
Log Scale!
~900 Kbps
No CachingSlide37
Throughput Improvement Using Ditto
Median
Log Scale!
~1200Kbps
~900 Kbps
No CachingSlide38
Throughput Improvement Using Ditto
Opportunistic caching
>> On-path caching > No caching
Median
Log Scale!
~1200Kbps
~900 Kbps
9000 Kbps
No CachingSlide39
Future WorkSupport for mobilityAlternate proxy selection techniques
Application specific Ditto gatewaysSlide40
ConclusionDitto improves throughput by reducing hop count to acquire commonly requested data
Caching of overheard dataAlso cache data on the path of a transferChunk based transfer, inter-stream chunk reconstructionDitto improves throughput (on 2
testbeds)Up to 7x better than on-path cachingUp to 10x better than no cachingSlide41
Thank you!Slide42
Extra SlidesSlide43
Experimental Setup
Mode802.11 b
RateAuto
Other Parameters
Default
Routing
Static
OLSR (Setup)
Cross Traffic
No
Cache Eviction
No
File
Sizes
1MB - 5 MB
Chunk Sizes8KB, 16KB, 32KBSlide44
Hop Count Affects Throughput
85% > 1Mbps
35% > 1Mbps
10% > 1Mbps
Pairwise
transfers in a 28 node campus
testbed
More hops
slower transfers (low throughput)Slide45
Evaluation Summary
Metric/FactorInsight
Proximity
N
odes closer to
gateway have a very high reconstruction efficiency .
Can shield the gateway from becoming a hotspot.
Chunk Size
Smaller the chunk size better the reconstruction efficiency.
8 KB provides good reconstruction efficiency with low overhead.
Throughput
Up to an order
of magnitude improvement with Ditto.
Inter-Stream Reassembly
A few opportunities for multiple overhearing;
10% improvement where applicableSlide46
Related WorkHierarchical Caching [Fan98, Das07,..]Caching more effective on
lossy wireless linksDitto’s overhearing feature is uniquePacket Level Caching [Spring00, Afanasyev08]Ditto is purely opportunisticDitto exploits similarity at inter-request timescale Making the best of broadcast [MORE, ExOR
,..]Largely orthogonalSlide47
Packet FormatSlide48
(Chunk) Size Matters
Average Reconstruction Effectiveness (% chunks)
8KB
70% of the observers reconstructed at most 50% of total chunks
Complete chunks overheard (%)Slide49
(Chunk) Size Matters
32KB
70% of the observers reconstructed at most
10%
of total chunks
8KB
70% of the observers reconstructed at most
50%
of total chunks
Smaller Chunk Size
Better Reconstruction Effectiveness
Complete chunks overheard (%)Slide50
Inter-Stream Reassembly Reconstruction EfficiencySlide51
Useless Bytes --- Different Chunk SizesSlide52
Useless Bytes Reduction Due to Inter-Stream ReassemblySlide53
Rabin Fingerprinting
4
7
8
2
8
File Data
Rabin Fingerprints
Given Value - 8
Natural Boundary
Natural Boundary
Hash 1
Hash 2Slide54
Rabin Fingerprinting: Examples of Edits1. Original File
2. Addition in chunkChanges only one hash3. Addition creating a new breakpoint4. Deletion changing size of chunk
Figure from “
A Low-bandwidth Network File System”Slide55
Does Ditto work with encrypted data?If the data is only meant for one user
Then opportunistic caching doesn’t work and it need not workIf the data is shared by many users all of them can have a shared key and data can be encrypted using this shared keyConvergent EncryptionUses content hash as the encryption keyMiddle ground between strong encryption and low overheardSlide56Slide57
How much traffic locality is there in mesh network?No accurate estimate as yet!Reasonable to assume that locality is present
Similar users in mesh networks --- e.g: software updates, video viewing, DARPA’s military appsInternet access exhibits localityPacket Level (roughly 30 - 60% traffic is redundant)HTTP caching (lower than packet level caching)Slide58
Overhead: Cache SizePractically need some cache eviction policy
Cheap Storage -> bigger caches can be maintainedWorst case analysis using numbers from Meraki’s mesh deployments2 Deployments --- 20 and 10 Meraki minis respectively
Assuming a mesh node overhears ALL traffic passing through other mesh nodesMost software updates take place within 24 hours3 GB cache size is enough to serve software updatesSlide59
OverheadOverhead of Sniffer
Sniffer overhears at line speedSniffer runs as a separate process and doesn’t affect performanceDidn’t miss a picket at 802.11 g 54 Mbps transferWe filter out non-Ditto trafficOverhead of ProxyingGoing up the stack can be costlySeparate TCP connection can be beneficial (lower RTT)
We observe that things balance out in practice i.e., performance with/without proxying is similarSlide60
FAQShould one design multi-hop networks with overhearing in mind?
Our approach --- No --- we didn’t want the request that doesn’t benefit from caching to sufferOther approach can be adopted based on the goals (for example: goal is to minimize the wired bw used by the gateway)What if routes change?System wouldn’t breakBut you would have longer/sub-optimal paths (next-hop Ditto proxy remains the same)Recent study(PAM 2007) shows that in mesh networks you only have 1-2 very good paths to the
gw, so better route selection can minimize this problemSlide61
FAQIs Ditto’s evaluation the best-case scenario?Yes, in terms of cache hit
No, in terms of request pattern (we consider a random order request pattern)Cost of missing the chunk header?Offline analysis shows that we could’ve constructed approx. 5% more chunks had we received the chunk headersSlide62
FAQImpact of different things?
Multi-Radio: Less interference but still reducing number of transmissions and hence interference is importantDifferent mode (a/g): Opportunistic caching still possible (we tested that on a smaller set of nodes) --- we don’t know how #s will compare to our current eval.Directional antennas: less overhearing -> opportunistic caching less usefulRate selection: we only tried auto-rate, shouldn’t fundamentally change results with other mechanisms
Cross Traffic: Reconstruction #s shouldn’t be too different, throughput #s may be lower for all schemesSlide63
FAQDo we necessarily need Ditto on the server side?
No --- we can have an application level proxy at the gateway that translates between the application and Ditto’s chunk based transfer Do we need Ditto on all the nodes?No, some nodes in the mesh could just forward traffic (simple mesh routers)Do we need Ditto on the client?Yes! You can’t skip that. Slide64
icons