Post on 12-Apr-2020
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