2. Content distribution
• CDNs
• Peer-to-peer
– User driven
– Service provider
driven
• Making use of
storage for caching
– In one way or another
2011-09-02 2 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
3. Evolution of networking
Information-centric
Today’s Internet network
Focuses on Focuses on
Conversations between Hosts Dissemination of Information
objects
Host-centric abstraction Evolution
Who to communicate with Information-centric abstraction
Web CDN P2P What to communicate
In today’s Internet,
accessing information is
the dominating use case!
2011-09-02 3 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
4. Host-centric networking
Trusted
Connect to Server
Server X and
get object B
Server X
B
Secure
Connection
2011-09-02 4 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
5. Information-centric networking
A
Trustable D
copy of
object B
B C
E
Get object B
D
B B B
E E
A A
A A
C D
Untrusted Untrusted
2011-09-02 5 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
connection host
6. ICN main components
Name resolution/routing Security
Security
Name resolution/routing - - tied to the information
tied to the information
- - scalability main concern
scalability main concern
- - and the names
and the names
Naming scheme for objects
Naming scheme for objects
- - flat or hierarchical
flat or hierarchical
Forwarding/transport
Forwarding/transport
- - with in-network caching
with in-network caching
2011-09-02 6 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
7. ICN naming
• Naming today:
– Hierarchical (aggregatable) IP addresses
– Hierarchical DNS names
– URL/URIs name “stuff”, but includes one of the above!
• So names are largely tied to hosts, that is, name the
container, not the actual content
• New: names for information objects themselves
– Names for the information independent of the container
– Need security directly tied to the name and object
– Hierarchical or flat namespace?
• I.e., aggregatable or non-aggregatable
• Consequences for resolution/routing
2011-09-02 7 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
8. NetInf naming scheme
Type A = Hash(PKIO) L = {identifier attr.}
Structure:
– Type: Defines the format
• e.g. Hash algorithm used (SHA1, MD5, …)
– Authenticator (A): Binds the ID of the IO to a public key PK
• Hash function used to compress length of PK
– Label (L): Identifying individual object published by Authenticator
• contains a number of identifier attributes associated with an IO
– (A, L) combination needs to be globally unique
Supporting the combination of:
– name persistence, self-certification, and owner authentication
– for objects that change content, location, or owner
– without need to trust the delivering host
Internet-draft: draft-farrell-ni
2011-09-02 8 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
9. CCN naming scheme
• Hierarchical names rooted in publisher prefixes
– Includes segmentation (packets!) and versioning
• Makes (some) routing aggregation possible
• Need to establish trust in signing key to verify integrity
• (drawing from “Networking Named Data” paper at CoNEXT 2009 by Van Jacobson et al)
2011-09-02 9 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
10. Name resolution / routing –
scalability
• Main scalability issue:
– Number of information objects
• bookkeeping needed to keep track of them
– Cf. Internet: IP network prefixes in backbone & BGP convergence
• How many information objects?
• Some numbers to compare with:
– One trillion (1,000,000,000,000) unique web URLs (Google 2008)
– 26 billion web pages (http://www.worldwidewebsize.com/)
– 119 million second-level domain names in the DNS (Dec 2010)
• Applicable if we can aggregate information objects on the publisher
level
– 60.000 AS numbers, of which 34.000 announced in BGP
2011-09-02 10 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
11. Name resolution / routing
• Two main options:
– Name resolution translating into another, routable,
namespace
• e.g., IP
– Routing directly on information object names
• sometimes called “name-based routing”
– (Possible with hybrid schemes)
• Scalability depends on namespace
– Flat or hierarchical
2011-09-02 11 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
12. ICN application service
(“socket API”)
sender receiver
publish()
retrieve(object ID)
object
• “Publish/subscribe-like”
• Most approaches defines a synchronous
“retrieve” instead of asynchronous “subscribe”
2011-09-02 12 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
13. ICN vs current networks
• Caches integrated in the network infrastructure
– Combines today's CDNs and user caching (p2p) in
the basic network service
• Network service in terms of named data objects
– No direct host addressing
2011-09-02 13 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
14. Legal implications of caching
(a layman view)
2011-09-02 14 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
15. Copyright
• Copyright and distribution agreements currently do not seem to
allow for general in-network caching
– Distribution agreements need to change? Is this likely?
• What exactly differs packet buffering from caching?
– Both stores content in a memory
• Can some mechanism in the network support the copyright
agreements?
– I.e., mechanisms that have legal meaning
– (I do not believe in enforcing mechanisms – it has to be combined with contracts
and/or legislation)
• Example mechanisms:
– Access counting, distribution constraints, time-to-live
• Or, is the only solution to encrypt copyrighted material and replace
the problem with key distribution
– as is done for satellite TV
2011-09-02 15 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
16. Responsibility for illegal content
• To what extent is the cache owner responsible
for the cached content?
– e.g., if it is illegal for some reason?
• Dependent on the time in the cache?
• (Anonymity and content control later...)
2011-09-02 16 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
17. Business issues
• Some current ISP business models work against
in-network caching
– Need to pay for delivering data to someone else
– Delivering data from your own cache to others incurs
a cost!
• Shouldn't there instead be value in providing
content that users want?
2011-09-02 17 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
19. Problems in host-centric
networks
No common persistent naming scheme for information
– URLs and IPs overloaded with locator and identifier functionality
• Moving information = changing it‘s name („404 file not found“ errors)
=> Use flat namespace for persistent and secure identification
Information dissemination is inefficient
– Can‘t benefit from existing copies (e.g. local copy on client)
• Also true for Content Delivery Networks (e.g. Akamai)
– No “anycast”: e.g., get “nearest” copy
– Problems like Flash-Crowd effect, Denial of Service, …
=> Add storage for caching as part of the infrastructure
Security is host-centric
– Mainly based on securing channels (encryption) and trusting servers
(authentication)
– Can’t trust a copy received from an untrusted server
Problems can be solved in a consistent manner
via an information-centric architecture
2011-09-02 19 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
20. Flat namespace
• Name resolution:
– Distributed hashtables (DHTs) only known technology
that scales
– Make use of publisher prefixes to increase scalability
• Routing:
– Hard!
– DHTs can be used here too (?)
– “Routing hints” proposed as optimisation
• ~ source route or topological address
• Can be tied to publisher prefixes
• Can be retrieved from a name resolution service
2011-09-02 20 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
21. Hierarchical namespace
• Name resolution:
– DNS type design scales well (?)
• Routing:
– Problem similar to BGP, but harder
2011-09-02 21 SCALABLE & ADAPTIVE INTERNET SOLUTIONS