Internet Indirection Infrastructure Presented in by Jayanthkumar Kannan On 09/17/03

Motivation Current Internet based on point-to-point abstraction: routing built around it. Good for unicast, but not for multicast, anycast, mobility etc. IP based solutions have made it nowhere. Overlay based solutions: each overlay has attempted to provide one of these services

Indirection Indirection: the only primitive needed to provide these services. Move away from end-point to name-based communication: exactly the thing DHTs do efficiently. Soln: Add an indirection layer on top of IP, implemented using overlay networks.

Rendevzous Communication Packets addressed to identifiers (“names”). Trigger: (Identifier, IP address): inserted by receiver and then used by sender. Triggers basically mappings set up by end-hosts, and stored in DHTs (can point to other triggers too). SenderReceiver (R) IDR trigger send(ID, data) send(R, data)

Service Model API sendPacket( p ); insertTrigger( t ); removeTrigger( t ); // optional Best-effort service model (like IP) Triggers are periodically refreshed by end- hosts Reliability, congestion control, and flow- control implemented at end-hosts

Public and Private Triggers The discovery problem Servers publish their public ids: dns etc. Clients contact server using public ids, and negotiate private ids used thereafter. Works well for efficiency: private ids chosen on “close-by” i3-servers. Private ids are shared-secrets, and comm. cannot be disrupted by other end-hosts.

Mobility and Multicast Mobility supported naturally End-host inserts trigger with new IP address, and everything transparent to sender Robust, and supports location privacy Multicast Simplest case: All receivers insert triggers under same ID, and sender uses that ID for sending. Infrastructure can optimize tree construction (optionally) (pursued in later work).

Anycast ID of server now includes some location hint as well (say, pincode) Generalized matching: First k-bits have to match, longest prefix match among rest. Client sends data address to (id-server,his location) Requirement: All such triggers have to reside on same I3-server. Used for load-balancing as well: second part of trigger is randomized.

Identifiers Stack Stack of identifiers: source routing-like Trigger inserter can specify source-routing: RHS of trigger contains a stack I3 routes packet through these identifiers Sender can specify id-stack in packet: first id used to match trigger: rest added to the RHS of trigger and processed as before.

Service Composition Transcoding example. Receiver mediated: R sets up chain and passed id_mpeg/jpeg to sender: sender oblivious Sender-mediated: S can include (id_mpeg/jpeg, ID) in his packet: receiver oblivious Sender (MPEG) Receiver R (JPEG) ID_ MPEG/JPEG S_ MPEG/JPEG ID R send((ID_ MPEG/JPEG,ID), data) S_ MPEG/JPEG send(ID, data) send(R, data)

Replication possible at any i3-server in the infrastructure. Tree construction can be done internally R2R2 R1R1 R4R4 R3R3 g R 2 g R 1 gxgx x R 4 x R 3 (g, data) Large Scale Multicast

Requirements for substrate Robustness, Scalability, Efficiency, Stability. Chord chosen for implementation, CAN, Tapestry, Pastry also possible. Robustness: soft-state, back-up triggers, trigger replication Efficiency: When first packet is sent, ip address of responsible i3-server cached. Suggested method to alleviate triangle routing: choose private triggers by experimentation

Other refinements Avoiding hot spots: Some triggers transferred to predeccessor: caching. Scalability: O ( n = # of flows + # of end- hosts):each server load=O(n/N). Acceptable? Incremental deployment possible. Legacy applications can be supported by proxy which inserts triggers on behalf of client.

Security Properties Eavesdropping by inserting (id,E) Private triggers are secret anyway, not possible to eavesdrop Comm. on public keys encrypted by public key of server: not so feasible? Dos Attacks possible Simple attack: A tree of triggers whose leaves point to the victim end- host Challenges issued to ensure RHS of trigger is infact the inserter Fair Queuing suggested to ensure other triggers are not affected Anonymity: IP address unknown to end-hosts, precludes IP- level flooding attacks. Flooding attacks: Drop public triggers in face of attack.

Security Enhancement A more complete solution proposed in later work to fix loopholes in I3. Basic idea: constrain RHS = hash(LHS) for id- id triggers Cannot setup loops within i3-servers: involves inverting a hash function Cannot create confluences: requires finding collisions.

Latency Topology (INET, GT-ITM), delays assigned and i3-servers allocated(randomly,stub nodes). Latency per packet = sender to i3 server+i3 server to receiver (assuming ip addr is cached) K = number of samples probed to find closeby server

Performance Numbers Latency suffered by first packet = time taken to route through Chord Two heuristics: Closest finger replica: use r successors of each finger for routing Closest finger set: choose closest log(N)/log(2) fingers out of log(N)/log(b) (b<2) fingers Other per-machine benchmarks: Handle 2.4 x 10^6 triggers. 25 micro-secs for 1 Kb pkt Throughput: 200 Mbps (1Kb pkt)

Winding up …. I3 is a toned-down version of active networks that allows packet replication,re-direction, and a few other operations. Indirection used as a simple abstraction to provide variety of services. Indirection can be implemented efficiently using today’s DHTs (note: environment is relatively static). Efficiency: Not fully addressed.