Data Oriented Network Architecture (DONA) Andrey Ermolinskiy Mohit Chawla CS 262 A Project Poster December 14

DONA Overview Data REGsFINDs DONA explores a clean-slate approach to Internet Architecture Main idea: data-centric routing:  Client requests a piece of data by its name rather than the owner’s address  Names are flat, self- certifying Dissemination Handlers (DH) are DONA “routers”  Combine forwarding, name resolution, and data caching functions

DONA Overview (cont.) Data REGsFINDs DONA exposes three operational primitives:  FIND -- discovers an entity or a data item by its name Long-lived FINDs (ttl > 0) are subscriptions, which set up forwarding state  REGISTER -- advertises ownership of a data item  PUSH -- disseminates new content to all current subscribers DHes propagate REGISTER requests and route FINDs to nearby copies of data

Load Shedding and Congestion Control Snapshot of Routing Table at DH D Snapshot of Congestion Table at DH D

Optimality of Load Distribution OPT_LS(S k, C n ): “Given a set of clients and servers with specific query rates and capacities respectively, find an optimal mapping between clients and servers to minimize the total latency incurred by queries in the system”. We can show that OPT_LS is NP-complete (reduction from the k-partition problem) c1c1 c2c2 c 3..c n-1 S1S1 cncn S2S2 S3S3 Cap(S 1 )=Cap(S 2 )=Cap(S 3 )=D L(S1)=L(S2)=L(S3)=1 Sample construction for an instance of a 3- partition problem C={ a 1,a 2,a 3 ….a N };

Simulation Studies Event-driven simulator written in Java Observes average latency and CDFs of latency Simulation parameters:  A 10 node topology using GT-ITM and manually generated topologies  Latency between links: Pre-Assigned (GT-ITM/manual)

DONA Administrative Policies Goal: ability to selectively deny incoming FIND and REGISTER requests based on fields in request header. Example: DENY (type == REGISTER) OR (ttl != 0) OR (appHeader != HTTP) type == REGISTERttl != 0 appHeader != HTTPOR policy action Parse the expression, convert it to a tree DH sends a DENY message to inform the client of its decision

Client Access Control DONA provides a framework for implementing user access control mechanisms (authentication and authorization). AUTHENTICATE policy action instructs a DH to request and verify client’s credentials prior to granting its request. AUTHENTICATE group1 Certif (type == FIND) policy action authentication domain credentials format DONA Authentication Agent Application Client node First-hop DH data request 2 1 FIND Verifier 1 DONA Verifier 2 PasswdCertif Policy Module 3 4 AUTHENTICATE DENY AUTH 5 6 credentials request 7 FIND 8 Packet contain authToken 9 authToken ACCEPT 10

Services and Applications RSS content dissemination on top of DONA:  Server-side proxy registers with a DH on behalf of content source.  Client-side proxies convert RSS refresh requests into long-lived FINDs (subscriptions), which set up forwarding state in the topology.  PUSH operation propagates content updates through the dissemination tree PUSH FIND (ttl > 0) Reverse-path forwarding entry RSS Client 1 RSS Client 2 DH 1Client Proxy 1 DH 2 DH 3 DH 4 RSS Source Server ProxyClient Proxy 2 DONA REGISTER

Services and Applications (cont.) DONA rendezvous capabilities simplify design of Overlay Multicast:  Global multicast routing state = shared undirected tree  New group members use DONA to discover a nearby member and attach themselves to the tree  To transmit a packet to the group: Sender locates a nearby member (M), forwards the packet to M Each member forwards the packet to its neighbors on the tree DONA M1M1 M2M2 REGISTER M4M4 M5M5 M6M6 FIND S1S1 ATTACH FIND SEND sender  DONA routing ensures that resulting trees are geographically efficient