Transcript Title

Project Status Update
“Postcards from the Edge”: The
Cache-and-Forward Architecture
FIND Wireless Workshop @ BBN
Sept 27, 2007
Dipankar Raychaudhuri, Sanjoy Paul, Roy Yates
WINLAB, Rutgers University
{ray, sanjoy, ryates} @winlab.rutgers.edu
&
Jim Kurose, U Mass, [email protected]
1
CNF Project: Architecture Concepts

Network is optimized for efficient content delivery to mobile devices





Large storage (~TB) at each network node
Single- or multi-hop wireless access with occasional disconnections
Strict hop-by-hop transport (…entire file sent via reliable link protocol)
“Post Offices” for opportunistic delivery to mobile clients
Integration of conventional routing with retrieval of cached content
Receiver’s
Post Office
Sender’s
Post Office
Receiver
Sender
Reliable
Link Layer
MN
MN
CNF Network
MN
Routers with
Storage
2
CNF Project: Protocol Stack



Routing protocol with integrated
support of address- and content-based
modes of delivery (get “filename”,
deliver ”filename” to “address”, etc.)
Support for in-network caching of
content
Multi-hop wireless access with
disconnections and mobility at access
edge (..”postbox” concept)
Sender’s
Post Office
Sender
CNF_2
CNF_5
CNF_3
CNF_4
Receiver’s
Post Office
CNC_1
Receiver
Core
MN
MN
CNF_6
CNF_1
MN
Link Protocol
Link Protocol
Link Protocol
3
CNF Project: Simulation Results – Network
Topology and Simulation Parameters
D


GT-ITM’s transit-stub model
Transit-transit links

S
S


Transit-stub links



D






1000Mbps bandwidth
Uniform (2,11)msec delay
15 source-destination pairs
D
S

155Mbps bandwidth
Uniform (20,23)msec delay
Stub-stub links

S
10000Mbps bandwidth
Uniform (20,23)msec delay
D
ON State: Exponentially distributed with mean 100sec
OFF State: Exponentially distributed with 3600sec
An ON state is always followed by an OFF state (vice versa)
Initial state of the source is ON
During ON State: Fixed file size (50MB), Poisson arrivals
4
CNF Project: Simulation Results (1) – CNF
vs. TCP Delay vs. Traffic Type & File Size



In-network
storage in
CNF serves
to smooth
traffic bursts
However, this
must be
balanced
against loss
of pipeline
gain
Overall, CNF
performs well
relative to
TCP except
at low loads
TCP outperforms CNF for
“always on” traffic and at
low arrival rate
Advantage of TCP over
CNF reduces for ON-OFF
traffic
Advantage of TCP over CNF
for “always on” traffic is
higher at smaller file size
Advantage of TCP
over CNF for ONOFF traffic is lower
at smaller file size
5
CNF Project: Simulation Results (2) –Delay Histograms
for Alternative Content Routing/Caching Strategies
“Content Broadcast” scheme has more “low delay” file transfers compared to “Caching and Capture”
Experiments
Average Delay
Improvement
Caching only, h=1
0.69539
22.3%
Broadcast, h=1
0.54013
Caching only, h=2
0.75455
Broadcast, h=2
0.575
Caching only, h=max
0.92206
Broadcast, h=Max
0.6590
23.8%
28.5%
When nodes exchange “content caching” information with neighbors Average Delay in locating
content reduces and the reduction is more when caching is limited to fewer nodes
6
CNF Project: Status & Next Steps

Basic protocol architecture done, some details being worked on





System level simulation studies to be completed this year (12/07)



Link layer protocol
Name resolution and file name resolution services
Caching service protocol
Routing algorithms
More results on caching and integrated routing protocol
Addition of wireless multi-hop scenarios to network model
Started work on prototype implementation of CNF protocol on
ORBIT/PlanetLab/VINI



Using BBN’s DTN code base as starting point
Staged implementation and evaluation of protocol modules
Proof-of-concept service demos by the end of year 2 (8/08)
7