Internet Indirection Infrastructure

Ion Stoica et. al. SIGCOMM 2002

Presented in CIS700 by Yun Mao02/24/04

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

“One Ring to rule them all”

An indirection layer based on overlay networkdecoupling sending and receiving

Multicast Anycast MobilityService

Composition

IP Layer

DHT

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)

ID R

trigger

send(ID, data)send(R, data)

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

Mobility

Sender

Receiver(R1)

Receiver(R2)

id R1id R2

Efficiency concern --- later

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

Replication possible at any i3-server in the infrastructure.

Tree construction can be done internally

R2

R1

R4R3

g R2

g R1

gx

x R4

x R3

(g, data)

Large Scale Multicast

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

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.

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.

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/JPEGID R

send((ID_MPEG/JPEG,ID), data)

S_MPEG/JPEG

send(ID, data) send(R, data)

Requirements for substrate

Robustness Scalability Efficiency Stability Chord chosen for implementation, CAN,

Tapestry, Pastry also possible.

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

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

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.

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.

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

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 + a number of patches Indirection can be implemented using

today’s DHTs (note: environment is relatively static).

Tradeoff to specific approaches