1. Content Centric Networking
Uichin Lee KAIST KSE
Based on Van Jacobson’s slide decks

2. Talk Plan A Brief History of Networking (+Motivation) Node Model
Routing
Transport

3. A Brief History of Networking
Generation 1: the phone system (focus on the wires)
Generation 2: the Internet (focus on the endpoints)
Generation 3? dissemination (focus on the data)

4. The Phone System is not about phones, it’s about connecting wires to other wires
The utility of the system depends on running wires to every home & office
The wires are the dominant cost
Revenue comes from dynamically constructing a path from caller to callee

5. A business model built on side effects
For a telco, a call is not the conversation you have with your mom in Phoenix, it’s a PATH between two end-office line cards
A phone number is not the name of your mom’s phone, it’s a program for the end-office switch fabric to build a path to the destination line card

6. Some ways to build paths
Sequential switch sequencing
(Strowger stepper)
Switchboard coordinate
(AT&T Operators, 1959)

7. Structural problems with phone systems
Path building is non-local and encourages centralization and monopoly
Calls fail if any element in path fails so reliability goes down exponentially as the system scales up
Data can’t flow until a path is set up so efficiency decreases when setup time or bandwidth increases or holding time decreases

8. Gen 2: packet switching
Paul Baran, 1964
Change point view to focus on endpoints rather than paths
Data sent in independent chunks and each chunk contains the name of the final destination
(Transitivity) If node gets a chunk for a different destination, tries to forward it using static configuration or distributed routing computation
Don Davies, 1963

9. Packet switching used the existing wires, it just used them differently
In 1964 these ideas were ‘lunatic fringe’ — anyone
who knew anything about communications
knew this could never work

10. ARPAnet September, 1971

11. ARPAnet The ARPAnet was built on top of the existing phone system
It needed cheap, ubiquitous wires
It needed a digital signaling technology (but not anything like the state of the art)
At the outset, the new network looked like an inefficient way to use the old network
The rest of the research community put enormous effort into the details of circuit switched data. In the end it didn’t matter

13. The CATENET and TCP/IP
Bob Kahn, 1973
Packet switching worked so well that by 1973 everyone wanted a network
Each was done as a clean slate so they didn’t interoperate
Since Paul had already abstracted out all the topological details Vint realized that a common encapsulation & addressing structure could glue together arbitrary networks
Vint Cerf, 1973

14. Multinetwork Demonstration 1977

15. TCP/IP wins
Adaptive routing lets system repair failures and hook itself up initially.
Reliability increases exponentially with system size.
No call setup means high efficiency at any bandwidth, holding time or scale.
Distributed routing supports any topology and tends to spread load and avoid a hierarchy’s hot spots.

16. TCP/IP issues
“Connected” is a binary attribute: you’re either part of the internet and can talk to everything or you’re isolated.
Becoming part of the internet requires a globally unique, globally known IP address that’s topologically stable on routing time scales (minutes to hours).
connecting is a heavy weight operation
the net doesn’t like things that move

17. Like the phone system before it, TCP/IP solved the problems it set out to solve so well that even today it’s hard to conceive of an alternative.
TCP/IP’s issues don’t reflect an architectural failing but rather its massive success in creating a world rich in information & communication.
When TCP/IP was invented there were few machines and many users per machine. Today there are many machines and many machines per user, all with vast amounts of data to be synchronized & shared.
And that creates an entirely new class of problem . . .

18. The raison d’être of today’s networking, both circuit switched and TCP/IP is to allow two machines to have a conversation
The overwhelming use (>99% by most measurements) of today’s networks is for a machine to acquire named chunks of data (like web pages, or messages)
Acquiring named chunks of data is not a conversation, it’s a “dissemination” (the computer equivalent of “Does anybody have the time?”)

19. In a dissemination the data matters, not the supplier
It’s possible to disseminate via conversation and get the data as a side effect, But:
Security is an afterthought. Channels are secured, not data, so there’s no way to know if what you got is complete, consistent or even what you asked for.
It’s inefficient (hotspots, poor reliability, poor utilization).
Users have to do the translation between their goal & its realization and manually set up the plumbing to make things happen.

20. Dissemination networking
Data is request by name, using any and all means available (IP, VPN tunnels, multicast, proxies, etc).
Anything that hears the request and has a valid copy of the data can respond.
The returned data is signed, and optionally secured, so its integrity & association with name can be validated (data centric security)

21. Content Centric Networking (CCN): Goals
Create a simple, universal, flexible communication architecture that:
Matches today’s communication problems
Matches today’s application design patterns
Is at least as scalable & efficient as TCP/IP
Is much more secure
Requires far less configuration

22. Universal?
Any architecture that runs over anything is an overlay (IP is an overlay).
IP started as a phone system overlay; today much of the phone system is an IP overlay. System theorists would say ‘IP is universal’.
CCN has the same character: it can run over anything, including IP, and anything can run over CCN, including IP.
And CCN has a simpler, more general relationship with lower layers than IP.

23. There are two ways to view CCN
a ‘universal’ middleware
an IP for content
The difference between these is
deployment time horizon

24. IP to “chunks of named content”
Strategy: exploit multiple simultaneous connectivities for data delivery (e.g., ethernet, 3G, WiFi) due to its simpler relationship with layer 2
Current Internet
CCN

25. Talk Plan A Brief History of Networking (+Motivation) Node Model
Routing
Transport

26. CCN packets There are two CCN packet types:
interest (similar to http “get”) and data
(similar to http response). Both are
encoded in an efficient binary XML.

27. Content-Based Security
Name-content mapping verification via per-data packet signature
Data packet is authenticated with digital signature
CCN trust establishment by associating content namespaces w/ public keys

28. Basic CCN forwarding
Consumer ‘broadcasts’ an ‘interest’ over any & all available communications media:
get ‘/parc.com/van/presentation.pdf’
Interest identifies a collection of data - all data items whose name has the interest as a prefix.
Anything that hears the interest and has an element of the collection can respond with that data:
HereIs ‘/parc.com/van/presentation.pdf/p1’ <data>

29. Basic CCN transport Data that matches an interest ‘consumes’ it.
Interest must be re-expressed to get new data. (Controlling the re-expression allows for traffic management and environmental adaptation.)
Multiple (distinct) interests in same collection may be expressed (similar to TCP window).

30. Internally, CCN names are opaque, structured byte strings
/parc.com/van/cal/417.vcf/v3/s0/0x3fdc96a4... is represented as a component count then, for each component, a byte count followed by that many bytes: … 7
8: parc.com
3: van
3: cal
32: 3FDC96…
The only assumption CCN makes about names is hierarchical structure.
E.g., names or components can be encrypted or contain arbitrary binary data.

31. Using Names
The hierarchical structure is used to do ‘longest match’ lookups (similar to IP prefix lookups) which helps guarantee log(n) state scaling for globally accessible data.
Although CCN names are longer than IP identifiers, their explicit structure allows lookups as efficient as IP’s. (see hashing work by Rasmus Pagh and Martin Dietzfelbinger)

32. Names and meaning
Like IP, a CCN node imposes no semantics on names. Meaning comes from application, institution and global conventions reflected in prefix forwarding rules. For example, /parc.com/people/van/presentations/FISS09 might be the name of a presentation’s data and /thisRoom/projector the name of the projector it should display on.
The former is a globally meaningful name leveraging the DNS global naming structure. The latter is local and context sensitive—it refers to different objects depending on the room you’re in.

33. IP node model

34. CCN node model
Get /parc.com/videos/ WidgetA.mpg/v3/s2

35. Comparison

36. Strategy layer (mobility management)
When you don’t care who you’re talking to, you don’t care if they change.
When you’re not having a conversation, there’s no conversation state to migrate.
Multi-point gives you multi-interface for free.
When all communication is locally flow balanced, your stack knows exactly what’s working and how well.

37. Quality of Service (QoS)
In the current Internet, QoS problems are highly localized.
Roughly half the problems arise from the serial dependencies created by queues.
The other half are caused the lack of receiver based control of bottleneck links.
Unlike IP, CCN is local, doesn’t have queues and receivers have complete, fine-grained control.
But it does aggregate traffic and has face-specific controls on the aggregation.

38. Talk Plan A Brief History of Networking (+Motivation) Node Model
Routing
Transport

39. There are many (emerging) ways to do routing, e. g
There are many (emerging) ways to do routing, e.g., Small Worlds, Geographic Hyperbolic, Pseudo potential Gradient, Epidemic percolation.
In general they’re easier to implement and work better for CCN than for IP:
no looping data ⇒ no convergence issues.
multi-destination ⇒ state can be approximate (false positives ok).
CCN transport model matches routing’s and adds security.

40. I’m only going to talk about embedding CCN in existing Internet routing.
This is an easy evolutionary path (it allows for immediate, incremental deployment).
It offers some intuition on scaling (same scaling as IP routing).
The basics are the same for any routing scheme.

41. Existing link-state routing protocols can be used, unmodified, to construct a CCN FIB
data src advertisement: /parc.com/media/art /parc.com/media
data src advertisement: /parc.com/media/art B A C D F E
E’s FIB
/parc.com/media/art /parc.com/media
A, B B
CCN Router

42. Example: Content Distribution

43. Example: Content Distribution

44. Example: Content Distribution

45. Example: Content Distribution

46. Content goes only where there’s interest.
It takes at most one trip across any link.
Average latency is minimized.
Total bandwidth is minimized.
There’s no routing or control traffic associated with the replicas.

47. Talk Plan A Brief History of Networking (+Motivation) Node Model
Routing
Transport

48. Transport State Conversation transport state is very compact:
One dynamic state variable (tcp sequence / ack number) conveys what ends know.
Additional static variable (tcp window) conveys what they want.

49. Annotated path in CCN name tree serves as transport state
Conventions:
name tree child nodes are lexically ordered
<next> assumed if no relationship specified

50. Annotated path in CCN name tree serves as transport state
Most recent version of slides for this talk:
parc.com/van/talks/mit10-08 <rightmost child>
Conventions:
name tree child nodes are lexically ordered
<next> assumed if no relationship specified

51. Annotated path in CCN name tree serves as transport state
Most recent version of slides for this talk:
parc.com/van/talks/mit10-08 <rightmost child>
Newest version after v2:
parc.com/van/talks/mit10-08/v2 <rightmost sibling> (fails since there is no newer version)
Conventions:
name tree child nodes are lexically ordered
<next> assumed if no relationship specified

52. Annotated path in CCN name tree serves as transport state
Most recent version of slides for this talk:
parc.com/van/talks/mit10-08 <rightmost child>
Newest version after v2:
parc.com/van/talks/mit10-08/v2 <rightmost sibling> (fails since there is no newer version)
Next available chunk after s1: parc.com/van/talks/mit10-08/v2/s1
Conventions:
name tree child nodes are lexically ordered
<next> assumed if no relationship specified

53. Bulk-data transfer performance comparison
TCP
CCN
Throughput (Mbps)
Pipeline size (like TCP window size)

54. Shared-content performance comparison
# of clients
Download delay
CCN
TCP

55. Wrapup CCN node is as simple as an IP node:
same memory requirements
same computational requirements (with option to increase security)
CCN offers simple, robust, secure single-point configuration.
CCN does near optimal content distribution.
Network, applications and users all share the same model of communication.