Upload
gino
View
115
Download
1
Tags:
Embed Size (px)
DESCRIPTION
Incrementally Deployable Information Centric Networking. Seyed K. Fayazbakhsh , Yin Lin, Amin Tootoonchian , Ali Ghodsi , Teemu Koponen , Bruce Maggs , KC Ng, Vyas Sekar, Scott Shenker. Internet Service Model. - PowerPoint PPT Presentation
Citation preview
1
Incrementally Deployable Information Centric Networking
Seyed K. Fayazbakhsh, Yin Lin, Amin Tootoonchian, Ali Ghodsi, Teemu Koponen, Bruce Maggs,
KC Ng, Vyas Sekar, Scott Shenker
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
4
• Equip network with content caches
ICN decouples “what” from “where”C
S1
S2
• Bind content names to intent
• Route based on content namese.g., find nearest replica
C C
e.g., CCN, DONA, NDN, 4WARD ….
Today: 1) Ask search engine for name of server holding object 2) Resolve name to network address of server 3) Send request for object to server
This talk is not anti-ICN
I am not an opponent of ICN
5
Benefits of deploying ICN
6
C
C
• Lower latency• Reduced congestion• Support for mobility• Intrinsic security
e.g., CCN, DONA, NDN, 4WARD ….
7
Difficulties deploying ICN
C
C
Routers need to be replaced to support content-based routing and to incorporate caches
e.g., CCN, DONA, NDN, 4WARD ….
8
Motivation for this work• 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?
Benefits
DifficultiesRouters need to be replaced to support content-based routing and to incorporate caches
Approach: Attribute gains to tenets
9
• 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
Quantitative Qualitative
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
10
Basis for incrementally deployable ICN
• Background and Approach
• Analyzing quantitative benefits
• Qualitative benefits Incrementally deployable ICN
• Discussion
11
Outline
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
13
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 originEdge neighbors alone
Cache Placement Request Routing
Object Popularities have Zipf Distribution
14
ith most popular item occurs with frequency proportional to 1/iα
Simulation setup
15
PoP-level topologies (Rocketfuel) augmented with access trees
Real CDNrequest logs
LRU replacement
Assume name-based routing, lookup incurs zero cost
Cache provisioning~ 5% of objects per nodeUniform or Proportional
Edge
Request latency (hops) - Asia trace
16
Gap between all architectures is small (< 10%)Nearest-replica routing provides almost no benefit
Improvement in network congestion
17
Improvement in origin server load
18
Sensitivity Analysis
19
Baseline
Even in best case, ICN-NR is only 17% better
% gap ICN-NR - Edge
Best case Normalize Double
Vary Zipf parameter, cache size, popularity skew, access tree degree
Edge cache deployment
• Incentives are alignedUsers benefit if they deploy caches
• Incremental deployment is facilitatedBenefits come immediately and don’t depend on router upgrades or other cache deployments
20
• Background and motivation
• Approach
• Quantitative benefits of ICN
• Qualitative benefits Incrementally deployable ICN
• Discussion
21
Outline
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?
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
2012 Data (Source: Bloomberg BusinessWeek)
Revisiting Qualitative Aspects
2. Binding names to intents
24
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)
Use self-certifying namese.g., “Magnet” URI schemes
Extend HTTP for “crypto” and other metadata
Name Resolution System
Reverse Proxy
Origin Server
Publishcontent
Register L.P.idicn.org
idICN: Content Registration
L = content label
P = Hash of public key
25
e.g., http://en.5671….fda627b.idicn.org/wiki/
Name Resolution System
ProxyEdge Cache Reverse
Proxy
Automatic Proxy Discoverye.g., WPAD
Origin Server
idICN: Client Configuration
Client 26
Name Resolution System
ProxyEdge
Cache
Reverse Proxy
1. Rqst L.P.idicn.org
Origin Server
2. Name resolution
6. Response
3. Rqst by address
5. Response + Metadata
idICN: Content Delivery
Client
4. Fetch
Try it out: www.idicn.org
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