Incrementally Deployable
Information Centric Networking
Seyed K. Fayazbakhsh, Yin Lin, Amin Tootoonchian,
Ali Ghodsi, Teemu Koponen, Bruce Maggs,
KC Ng, Vyas Sekar, Scott Shenker
1
Internet Service Model
The network makes its best effort to deliver
every datagram to the destination address
specified in its header
Example address: 128.2.205.42
“the narrow waist of IP”
2
ICN Service Model
Given a request for named content, the network
attempts to locate and retrieve the content
Example request: retrieve DSAK832NSKAWKW282
Names may be bound to content cryptographically
3
Content Retrieval
S1
e.g., CCN, DONA, NDN, 4WARD ….
C
S2 C
C
ICN decouples “what” from “where”
•
Bind
content
names
to
intent
Today: 1) Ask search engine for name of server holding object
2) Resolve
name network
to networkwith
address
of server
• Equip
content
caches
3) Send request for object to server
• Route based on content names
e.g., find nearest replica
4
This talk is not anti-ICN
I am not an opponent of ICN
5
Benefits of deploying ICN
e.g., CCN, DONA, NDN, 4WARD ….
C
C
•
•
•
•
Lower latency
Reduced congestion
Support for mobility
Intrinsic security
6
Difficulties deploying ICN
e.g., CCN, DONA, NDN, 4WARD ….
C
C
Routers need to be replaced to support
content-based routing and to incorporate
caches
7
Motivation for this work
Benefits
•
•
•
•
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?
Difficulties
Routers need to be replaced to
support content-based routing and
to incorporate caches
8
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
9
Key Takeaways
• To achieve quantitative benefits:
Just cache at the “edge”
With Zipf-like object popularities, 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
• Quantitative benefits are largely due to
caching
• Two key dimensions in this design space:
– Cache placement
• E.g., everywhere? Edge?
– Request routing
• E.g., shortest path, nearest replica?
12
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
13
Object Popularities have Zipf Distribution
ith most popular item occurs with frequency proportional to 1/iα
14
Simulation setup
Edge
Real CDN
request logs
Cache provisioning
~ 5% of objects per node
Uniform or Proportional
LRU replacement
PoP-level topologies (Rocketfuel) augmented with access trees
Assume name-based routing, lookup incurs zero cost
15
Request latency (hops) - Asia trace
Gap between all architectures is small (< 10%)
Nearest-replica routing provides almost no benefit
16
Improvement in network congestion
17
Improvement in origin server load
18
Sensitivity Analysis
% gap
ICN-NR
- Edge
Baseline
Best case Normalize Double
Vary Zipf parameter, cache size, popularity skew,
access tree degree
Even in best case, ICN-NR is only 17% better
19
Edge cache deployment
• Incentives are aligned
Users benefit if they deploy caches
• Incremental deployment is facilitated
Benefits come immediately and don’t depend on
router upgrades or other cache deployments
20
Outline
• Background and motivation
• Approach
• Quantitative benefits of ICN
• Qualitative benefits  Incrementally deployable ICN
• Discussion
21
Design Rationale
• Parties that benefit should bear the costs
– Consumers deploy ICN-aware proxies/caches
– Content providers register names of objects
• ISPs leverage their existing investments in
infrastructure
22
How Big is the CDN Market?
2012 Data (Source: Bloomberg BusinessWeek)
Revenues
Earnings
Akamai
1.374B
204M
Chinanet
46.6M
3.0M
Limelight
180.2M
(30M)
Level 3
6.376B
(422M)
Netflix
3.6B
17.2M
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
24
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
25
idICN: Client Configuration
Name Resolution System
Proxy
Edge
Cache
Reverse
Proxy
Automatic Proxy Discovery
e.g., WPAD
Client
Origin Server
26
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
27
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 ..
28