A Data Oriented Network Architecture

Teemu Koponen, Mohit Chawla, Byung-Gon Chun, Andrey Ermolinskiy, Kye Hyun Kim, Scott Shenker, Ion Stoica

Presented by: Tony Z.C Huang, Adapted from slides by Teemu Koponen and Scott Shenker

1

Focus Of The Paper

• “Clean-slate” look at naming and name resolution

• Focus on “the shift from host-centric to data-centric applications”.

2

Difference Between Yesterday and Today

• Previous applications focus on host-to-host communication

• file-transfer, remote-login,

• The internet therefore is well-suited for communication between pairs of stationary hosts

• Today, majority of internet usage is data retrieval and service access

• Fetching videos from Youtube or oneline-banking

3

Three User-relevant Issues

• Persistence: once a name is give for some data or service, users would like that name to remain valid as long as the data or service is available.

• Availability: data and services should be highly available in terms of both reliability and low-latency.

• Authenticity: data come from appropriate source, rather from adversary.

4

Basic Design• Strict separation between naming and name resolution

• persistence and authenticity is handled by naming.

• availability is handled by name resolution.

• Naming: Flat, self-certifying names.

• Name Resolution: route-by-name paradigm.

• What’s being left: trustworthiness!

• user wants to know whether they’re getting information from trusted sources.

• the author believes thaat it should be handled by external architecture.

5

Summary

Handled By Provided by

Persistence

Authenticity

Availability

Names Flat Names

Names Self-certifying names

Name Resolution Route-by-name Paradigms

6

Naming

• Names are organized as principals

• Each principal is associated with a public-private key pair

• Each named entity is associated with a principal

• Names are of the form P:L

• P: cryptographic hash of he principal’s public key

• L: a unique label chosen by the principal, ensuring uniqueness of name.

• Naming granularity left up to principals.

7

Self-certifying Names

• A piece of data comes with a public key and a signature;

• i.e, when client asks for a piece of data with Names P:L, it receives the triplet <data, public key, signature>

• Verify the authenticity of the data by:

• Checking the public key hashes into P

• Validating that the signature corresponds to the public key

• The fact that a name does not refer to location guarantees persistance.

8

Name Resolution

• Goal: achieve high availability by finding close-by copies and avoiding failures.

• Resolution infrastructure consists of Resolution Handlers (RH)

• Replacing the DNS services, to which user sends their fetch requests.

• Two primitives, FIND(P:L) and REGISTER(P:L).

• Find (P:L) locates the object named P:L.

• REGISTER set up the state necessary for the RHs to route FINDs.

9

Register CommandsRH

RHRH

RH RH

RH

Original

Copy 1 Copy 2

RH RH RH

• REGISTERs are forwarded according according to interdomain policies

• REGISTERs from customers to both peers and providers

• REGISTERs from peers optionally to provider/peers.

10

Forwarding FIND(P:L)

• When FIND(P:L) arrives to a RH:

• If there’s an entry in the registration table, the FIND is send to the next-hop RH.

• Otherwise, the RH forwards the FIND towards its provider.

• In case of multiple equal choices, the RH uses its local policy to choose among them.

11

Forwarding of FINDRH

RHRH

RH RH

RH

Original

Copy 1 Copy 2

RH RH RH

Client

12

Challenges

Concerns Approaches

Usability

Security

Scalability

Names are long and hard to remember

External Mechanisms

Private Key Compromise Key revocation

Huge namespace More shortly...

13

Bottleneck of Architecture

• RH needs only keep routing state for data that lie below or equal to it in the AS hierarchy.

• The toughest requirement will be on Tier-1 providers.

• Only support for FIND/REGISTER load is critical.

• Other functionalities are optional.

14

Requirement

• Registration processing requirements for a single Tier-1 ISP:

• 1011 names, 42 bytes per entry = routing table about 4TB.

• lifetime of registration 2 weeks = handle 83k registrations/second.

• each registration is 1KB = 680Mbps, which is small for an AS.

• Forwarding requirements:

• 20k FINDs/sec, from rate of HTTP requests, from a fully-loaded Gbps link.

15

Hardware Requirement• Routing Table

• In RAM, 50 PCs wach with 8GB of TAM.

• On disk, 50 disks/ 1Gbps link.

• Which approach to take dpends on an ASs aggregate load and other factors

• CPU requirement:

• 40 CPUs running at 3GHz for crypto operations.

• Can be lower if ASs trust each other

• Reasonable Requirements

16

Points Lefted Out...

• Application viewpoints

• Using DONA’s functionality for other tasks

• especially its named-based anycast

• Extending RH functionality

• Caching, subscriptions, etc.

• Architecture implication

17