1. Internet Indirection Infrastructure Ion Stoica et. al. SIGCOMM 2002 Presented in CIS700 by Yun Mao 02/24/04

2. Motivation What is old in the Internet? End-to-end communication + IP packet routing substrate Multicast, Anycast, Mobility, Service Composition on top What is new? Peer-to-peer, Overlay networks, DHTs. So, what should be built on top of them?? E.g. Overcast = Multicast+Overlay

3. “One Ring to rule them all” An indirection layer based on overlay network decoupling sending and receiving MulticastAnycastMobility Service Composition IP Layer DHT

4. 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.

5. Rendezvous 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)

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

7. Mobility Sender Receiver (R1) Receiver (R2) idR1 idR2 Efficiency concern --- later

8. 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).

9. 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

10. Extensions Inexact matching (k-prefixed) Have to be on the same node Anycast and load balancing Stack of IDs Service composition Public/private Triggers Security / Efficiency

11. Anycast Generalized matching: First k-bits have to match, longest prefix match among rest. ID of server now includes some location hint as well (say, zipcode) Client sends data address to (id-server, his location) Zipcode != network distance prefixed encoding is hard Used for load-balancing as well: second part of trigger is randomized.

12. Identifiers Stack Stack of identifiers: source routing 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.

13. 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)

14. Requirements for substrate Robustness Scalability Efficiency Stability Chord chosen for implementation, CAN, Tapestry, Pastry also possible.

15. Robustness Routing --- depends on DHT Soft state --- no state management pain Lost trigger Reinserted b/c soft state Backup trigger (id_backup, R) + trigger stack(id, id_backup) Successor replica

16. Routing Efficiency Latency -- It’s DHT, you know cache i3 server’s IP Failure doesn’t matter Triangle routing Private trigger Sample the whole ID space offline

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

18. 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 in fact the inserter Fair Queuing suggested to ensure other triggers are not affected Anonymity: IP address unknown to end-hosts, precludes IP- level flooding attacks. DoS happens anyway Flooding attacks: Drop public triggers in face of attack.

19. Public and Private Triggers The discovery problem Servers publish their public ids: dns, Web 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.

20. 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.

21. Latency Topology (INET, GT-ITM), delays assigned and 16384 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

22. 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)

23. Winding up …. I3 is a toned-down version of active networks that allows packet replication,re-direction, and a few other operations. Indirection + a number of patches Indirection can be implemented using today’s DHTs (note: environment is relatively static). Tradeoff to specific approaches