Incrementally Deployable ICN 1 Seyed K Fayazbakhsh Yin Lin Amin Tootoonchian Ali Ghodsi Teemu Koponen Bruce Maggs KC Ng Vyas Sekar Scott Shenker A highlevel view of ICN ID: 315557
Download Presentation The PPT/PDF document "Less Pain, Most of the Gain:" 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
Less Pain, Most of the Gain:Incrementally Deployable ICN
1
Seyed K. Fayazbakhsh, Yin Lin, Amin Tootoonchian, Ali Ghodsi, Teemu Koponen, Bruce Maggs, KC Ng, Vyas Sekar, Scott ShenkerSlide2
A high-level view of ICN2
Equip network with content caches
Decouple “what” from “where”
C
S1
S2
Bind content names to intent
Route based on content names
e.g., find nearest replica
C
C
e.g., CCN, DONA, NDN, 4WARD ….
Today: Fetch from server IPSlide3
Gains of deploying ICN3
C
C
Lower latency
Reduced congestion
Support for mobility
Intrinsic security
e.g., CCN, DONA, NDN, 4WARD ….Slide4
4
Pains of deploying ICN
C
C
Routers need to be upgraded
Routing needs to be content based
e.g., CCN, DONA, NDN, 4WARD ….Slide5
5
Motivation for this work
Lower latencyReduced congestionSupport for mobilityIntrinsic security
Routers need to be upgraded with cachesRouting needs to be content based
Can we get ICN gains without the pains?
e.g., existing technologies? e.g., incrementally deployable?
Gains
PainsSlide6
Approach: Attribute gains to tenets
6
Lower latencyReduced congestionSupport for mobilityIntrinsic security
Decouple “what” from “where”Bind content names to intent
Equip network with content cachesRoute based on content
names
Quantitative
QualitativeSlide7
Key TakeawaysTo achieve quantitative benefits:
Just cache at the “edge”With Zipf
-like workloads, pervasive caching and nearest-replica routing don’t add muchTo achieve qualitative benefits:Build on HTTP7Basis for incrementally
deployable ICNSlide8
Background and Approach
Analyzing quantitative benefits
Qualitative benefits Incrementally deployable ICNDiscussion8OutlineSlide9
Design space of caching Quantiative benefits are largely due to caching
Two key dimensions to this design space:Cache placement E.g., everywhere? Edge?
Request routingE.g., shortest path, nearest replica?9Slide10
Representative points in design space10
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
Cache Placement
Request RoutingSlide11
Simulation setup11
PoP
-level topologies (Rocketfuel) augmented with access trees
Real CDN
r
equest logs
LRU replacement
Assume name-based routing, lookup incurs zero cost
Cache provisioning
~ 5% of objects
Uniform or Proportional
EdgeSlide12
Request latency
12
Gap between architectures is small (< 10%) Similar results for congestion + server load
Telstra Sprint Level3 AT&T
%
improvement
over
“no-cache”Slide13
Sensitivity Analysis
13
BaselineEven in best case, ICN-NR is only 17% better% gap
ICN-NR - Edge
Best caseNormalize
Double
Gap can be easily reducedSlide14
Implications of Edge CachingIncrementally deployableDomains get benefits without relying on others
Incentive deployableDomains’ users get benefits if domain deploys caches
14Slide15
Background and motivation
Approach
Quantitative benefits of ICNQualitative benefits Incrementally deployable ICNDiscussion15
OutlineSlide16
Revisiting Qualitative Aspects2. Binding names to intents
16
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 names
e.g., “Magnet” URI schemes
Extend HTTP for “crypto”
and other
metadataSlide17
Name Resolution System
Reverse Proxy
Origin Server
Publish
content
Register
L.P.idicn.org
idICN
: Content Registration
L = content label
P
= Hash of public key
17
e.g., http://en.
5671….fda627b.idicn.org
/
wiki
/Slide18
Name Resolution System
Proxy
Edge CacheReverse Proxy
Automatic Proxy Discoverye.g., WPAD
Origin Server
idICN
: Client Configuration
Client
18Slide19
Name Resolution System
Proxy
EdgeCacheReverse 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
19Slide20
ConclusionsMotivation: 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” solutionsPervasive caching, nearest-replica routing not neededCan get qualitative benefits with existing techniquesWith existing HTTP + HTTP-based extensionsIncrementally deployable + backwards compatibleidICN design: one possible feasible realizationOpen issues: economics, other benefits, future workloads ..
20