Internet Indirection Infrastructure

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” Multicast Anycast Mobility Service Composition An indirection layer based on overlay network decoupling sending and receiving DHT IP Layer

4. send(R, data) send(ID, data) trigger ID R 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). Sender Receiver (R)

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

6. Receiver (R1) id id R1 R2 Receiver (R2) Mobility Sender Efficiency concern --- later

7. Multicast • 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).

8. Large Scale Multicast • Replication possible at any i3-server in the infrastructure. • Tree construction can be done internally (g, data) g x g R1 g R2 R2 x R3 x R4 R1 R3 R4

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

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

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

12. send((ID_MPEG/JPEG,ID), data) send(R, data) send(ID, data) 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 S_MPEG/JPEG Receiver R (JPEG) Sender (MPEG) ID R S_MPEG/JPEG ID_MPEG/JPEG

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

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

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

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

17. 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. • DoS happens anyway • Flooding attacks: Drop public triggers in face of attack.

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

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

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

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