Transcript Paper Presentation - Information Services and Technology

Less Pain, Most of the Gain:
Incrementally Deployable ICN
Seyed K. Fayazbakhsh, Yin Lin, Amin Tootoonchian,
Ali Ghodsi, Teemu Koponen, Bruce Maggs,
KC Ng, Vyas Sekar, Scott Shenker
Presented by:
Nirali Mistry
Tushar Sharma
1
Internet’s Architecture - what we
know
Core Abstraction:
• Interfaces identified by IP
address
• Data (bytes) flows between
interfaces
• Stateless wherever possible
(fast)
This result in internet which is
• Host centric (end to end)
• Focus on who to communicate
with
ICN Commnication model
Key Ideas:
• Clients send request asking
for named data
• Routers in network requests
towards publishers
• Any node with a cached
copy can provide
corresponding information
object
This result in internet which:
• Declares information as
first-class
• Focus on what within a
communication
A high-level view of ICN
S1
e.g., CCN, DONA, NDN, 4WARD ….
C
S2 C
C
• Decouple “what” from “where”
•
Bind
content
names
to
intent
Today: Fetch from server IP
• Equip network with content caches
• Route based on content names
e.g., find nearest replica
4
Gains of deploying ICN
e.g., CCN, DONA, NDN, 4WARD ….
C
C
•
•
•
•
Lower latency
Reduced congestion
Support for mobility
Intrinsic security
5
Pains of deploying ICN
e.g., CCN, DONA, NDN, 4WARD ….
C
C
• Routers need to be upgraded
• Routing needs to be content based
6
Motivation for this work
•
•
•
•
Gains
Lower latency
Reduced congestion
Support for mobility
Intrinsic security
Can we get ICN gains without the pains?
e.g., existing technologies?
e.g., incrementally deployable?
Pains
•
•
Routers need to be upgraded with caches
Routing needs to be content based
7
Approach: Attribute gains to tenets
Qualitative
Quantitative
•
•
•
•
•
•
•
•
Lower latency
Reduced congestion
Support for mobility
Intrinsic security
Decouple “what” from “where”
Bind content names to intent
Equip network with content caches
Route based on content names
8
Heavy Tailed Workload
The simulated logs followZipf
distribution
• Size of the rth occurance is
inversely proportinalto its rank
• In other words, y ∝ r−b
• But why does it matter?
Key Takeaways
• To achieve quantitative benefits:
Just cache at the “edge”
With Zipf-like workloads, pervasive caching and
nearest-replica routing don’t add much
• To achieve qualitative benefits:
Build on HTTP
Basis for incrementally deployable ICN
10
Outline
• Background and Approach
• Analyzing quantitative benefits
• Qualitative benefits  Incrementally deployable ICN
• Discussion
11
Design space of caching
• Quantiative benefits are largely due to caching
Two key dimensions to this design space:
– Cache placement c
E.g., everywhere? Edge?
12
• Request routing
E.g., shortest path, nearest replica?
13
Representative points in design space
Cache Placement
Request Routing
ICN-SP
Everywhere
Shortest path to origin
ICN-NR
Everywhere
Nearest replica
Edge
Only at edge nodes
Shortest path to origin
Edge-Coop Only at edge nodes
Shortest path to origin
Edge neighbors alone
14
Simulation setup
Edge
Real CDN
request logs
Cache provisioning
~ 5% of objects
Uniform or Proportional
LRU replacement
PoP-level topologies (Rocketfuel) augmented with access trees
Assume name-based routing, lookup incurs zero cost
15
Request latency
%
improvement
over
“no-cache”
Telstra
Sprint
Level3
AT&T
Gap between architectures is small (< 10%)
Similar results for congestion + server load
16
Sensitivity Analysis
% gap
ICN-NR
- Edge
Baseline
Best case Normalize Double
Even in best case, ICN-NR is only 17% better
Gap can be easily reduced
17
Implications of Edge Caching
• Incrementally deployable
– Domains get benefits without relying on others
• Incentive deployable
– Domains’ users get benefits if domain deploys caches
18
Outline
• Background and motivation
• Approach
• Quantitative benefits of ICN
• Qualitative benefits  Incrementally deployable ICN
• Discussion
19
Revisiting Qualitative Aspects
1. Decouple names from locations
Build on HTTP
– Can be viewed as providing “get-by-name” abstraction
– Can reuse existing web protocols (e.g., proxy discovery)
2. Binding names to intents
Use self-certifying names
e.g., “Magnet” URI schemes
Extend HTTP for “crypto” and other metadata
20
idICN: Content Delivery
Name Resolution System
2. Name
resolution
Proxy
Edge
Cache
1. Rqst
L.P.idicn.org
Try it out:
www.idicn.org
3. Rqst by address
5. Response + Metadata
6. Response
Client
Reverse
Proxy
4. Fetch
Origin Server
21
idICN: Client Configuration
Name Resolution System
Proxy
Edge
Cache
Reverse
Proxy
Automatic Proxy Discovery
e.g., WPAD
Client
Origin Server
22
idICN: Content Registration
Name Resolution System
Register
L.P.idicn.org
P = Hash of public key
L = content label
Reverse
Proxy
Publish
content
e.g., http://en.5671….fda627b.idicn.org/wiki/
Origin Server
23
Conclusions
• Motivation: Gains of ICN with less pain
– Latency, congestion, security
– Without changes to routers or routing!
• End-to-end argument applied to ICN design space
• Can get most quantitative benefits with “edge” solutions
– Pervasive caching, nearest-replica routing not needed
• Can get qualitative benefits with existing techniques
– With existing HTTP + HTTP-based extensions
– Incrementally deployable + backwards compatible
• idICN design: one possible feasible realization
– Open issues: economics, other benefits, future workloads ..
24
Things we didn’t understand!
• Percentage don’t speak much
– Eg. Performance gap of 9% ?
• Future devices will have “long tail”. Why?
25
References
[1]Seyed Fayazbakhsh, Amin Tootoonchian, Yin Lin, Ali Ghodsi, KC Ng,
Bruce Maggs, Vyas Sekar, Scott Shenker. Less Pain, Most of the Gain:
Incrementally Deployable ICN. in SIGCOMM 2013.
[2]Dirk Trossen and Alexandros Kostopoulos. Techno-Economic Aspects
of Information-Centric Networking in Journal of Information Policy.
[3]Bengt Ahlgren Information-centric networking and relaton to legal and
regulatory issues by SAIL.
Thank you
Questions?
27