Internet Indirection Infrastructure

1
Internet Indirection Infrastructure

• Presented in 294-4 by
• Jayanthkumar Kannan
• On 09/17/03

2
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

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

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

Sender
Receiver (R)
5
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

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

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

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

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

10
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
ID_MPEG/JPEG
S_MPEG/JPEG
11
Large Scale Multicast

• Replication possible at any i3-server in the
  infrastructure.
• Tree construction can be done internally

(g, data)
g R2
g R1
g x
R2
x R4
x R3
R1
R3
R4
12
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

13
Other refinements

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

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

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

16
Latency

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

17
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) (blt2) fingers
• Other per-machine benchmarks
• Handle 2.4 x 106 triggers.
• 25 micro-secs for 1 Kb pkt
• Throughput 200 Mbps (1Kb pkt)

18
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
  todays DHTs (note environment is relatively
  static).
• Efficiency Not fully addressed.