# Content Centric Networks

A Brief History of Networking

- Gen 1. The **phone system** (focus on the **wires**)
  - The utility of the system depends on running wires to every home & office.
  - Wires are the dominant cost.
  - A *call* is not the conversation, its the **PATH** between two end-office line cards.
  - A *phone number* is not the name/address of the caller, its a **program** for the end-office switch fabric to build a path to the destination line card.
  - <img src="/lectures/acn/img/k.png" alt="switch board" style="zoom:50%;" />
  - Path building is **non-local** and **encourages centralisation** and **monopoly**.
  - Calls fail is any element in the path fails so reliability goes down exponentially as the system scales up.
  - Data cannot flow until the path is set up so efficiency decreases with setup time.

- Gen 2. The **Internet** (focus on the **endpoints**)
  - Data sent in independent chunks and each chunk contains the name of the final destination.
  - Nodes forward packets onward using routing tables.
  - **ARPAnet** was built on top of the existing phone system.

- Gen 3. **dissemination** (focus on the **data**)

#### TCP/IP

###### Pros

- Adaptive routing lets system **repair failures**
- **Reliability increases exponentially** with **system size**.
- **No call setup** means **high efficiency** at any bandwidth and scale.
- Distributed routing supports any topology and tends to spread load and avoid a hierarchy's hot spots.

###### Cons

- *Connected* is a binary attribute. 
- Becoming part of the internet requires a globally unique, globally know IP address that's topologically stable on routing time scales.
  - Connecting is a heavy weight operation
  - The net struggles with moving nodes

#### Conversation and Dissemination

Acquiring chunks of data (web pages, emails, videos etc) is not a conversation, it's *dissemination*.

In a dissemination **the data matters**, not the supplier.

- Data is request by name.
- Anything that hears the request, and has a valid copy can respond.
- The return data is signed, so integrity and association can be validated.

CCN can run over and be run over anything e.g. IP.

#### CCN Packets

![img](/lectures/acn/img/l.png)

**Interest** - similar to HTTP `GET`

**Data** - similar to HTTP response

#### Content Based Security

Data packets are authenticated with digital signatures.

![img](/lectures/acn/img/m.png)

#### CCN Forwarding

Consumer *broadcasts* and *interest* over all available communication media

- e.g. `get '/parc.com/van/presentation.pdf'`
- response: `heres '/parc.com/van/presentation.pdf/p1' <data>`

##### Names and Meaning

* Like IP, CCN nodes imposes no semantics on names
* Meaning comes from **application**, **institution** and **global conventions** reflected in prefix forwarding rules.
* Globally meaningful name leveraging the DNS global naming structure
  * `/parc.com/van/presentation.pdf`
* Local and context sensitive, it refers to different objects depending on the room you're in.
  * `/thisRoom/projector`

#### Strategy Layer

* When you do not care who you are talking to, you don't care if they change
* When you are not having a conversation, there's no need to migrate conversation state.
* Multi-point gives you multi-interface for free.
* When all communication is locally flow balanced, your stack knows exactly whats working and how well.

In the current Internet, Quality of Service (QoS) Problems are highly localised

* Roughly half the problems are from serial dependencies created by queues
* The other half are caused from a lack of receiver based control over bottle-necked links.

Unlike IP, CCN is **local**, don't have queues and receivers have complete control

![img](/lectures/acn/img/n.png)

Tree serves as transport state