internet indirection infrastructure ion stoica et. al. sigcomm 2002 presented in cis700 by yun mao...
TRANSCRIPT
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
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)