10/31/2007cs6221 Internet Indirection Infrastructure ( i3 ) Paper By Ion Stoica, Daniel Adkins, Shelley Zhuang, Scott Shenker, Sonesh Sharma Sonesh Sharma Presented By Kunal Bele

10/31/2007cs6222 The Purpose Point-to-Point communications easy to handle in original Internet communication. Point-to-Point communications easy to handle in original Internet communication. For more beneficial & general applications involving Multicast, Anycast & Host Mobility rely on layer of indirection. For more beneficial & general applications involving Multicast, Anycast & Host Mobility rely on layer of indirection. Difficult to implement scalably & poses technical problems and major deployment barriers at IP layer. Difficult to implement scalably & poses technical problems and major deployment barriers at IP layer. Hence, turned to application layer solutions. Hence, turned to application layer solutions.

10/31/2007cs6223 Introducing i3 Associates packets with an identifier which is used by receiver for delivery of packets. Associates packets with an identifier which is used by receiver for delivery of packets. i3 offers powerful and flexible rendezvous based communication. i3 offers powerful and flexible rendezvous based communication. This approach provides general overlay service that avoids both the technical problems & deployment challenges inherent in IP layer. This approach provides general overlay service that avoids both the technical problems & deployment challenges inherent in IP layer. Combines generality of IP-layer solutions with the deployment of overlay solutions. Combines generality of IP-layer solutions with the deployment of overlay solutions.

10/31/2007cs6224 i3 Overview - Service Model (provides indirection) - Rendezvous-Based Communication (communicates using identifiers & triggers) - Design - Communication Primitives - Stack of Identifiers

10/31/2007cs6225 Service Model - Sources send packets to a logical identifier. - Receivers express interest in packets sent to an identifier. - i3 equivalent of IP multicast join more flexible & advantageous than IP multicast join. - By inserting a trigger, the operation is more flexible than an IP multicast join as it allows receivers to control the routing the packet. - Advantageous wrt that it allows end-hosts to create different services at application level out of this basic service model.

10/31/2007cs6226 Rendezvous-Based Communication Senders send packets which are (id,data) pair Senders send packets which are (id,data) pair - id is m-bit identifier - data is payload (IP packet payload) Receivers use triggers which are (id,addr) pair Receivers use triggers which are (id,addr) pair - id is trigger identifier - addr is node’s address (IP & Port no) Trigger (id,addr) indicates all packets with an identifier id should be forwarded (by i3) to the node identified by addr. Trigger (id,addr) indicates all packets with an identifier id should be forwarded (by i3) to the node identified by addr.

10/31/2007cs6227 i3’s API 3 Basic Primitives exported by RBC p – (id, data), t – (id,addr)

10/31/2007cs6228 Rendezvous-Based Communication (Basic) Communication between two nodes

10/31/2007cs6229 Rendezvous-Based Communication (Generalized) There is exact-match threshold k with k<m. There is exact-match threshold k with k<m. - identifiers being m-bit long(256 in experiment) id Matching in i3 : id Matching in i3 : Identifier id t in a trigger matches identifier id in a packet iff - - id & id t have a prefix match of at least k bits. - there is no trigger with an identifier that has a longer prefix match with id.

10/31/2007cs62210Design i3 is an overlay network consisting of set of servers. i3 is an overlay network consisting of set of servers. These servers store the triggers & forward the packets between i3 nodes & end-hosts. These servers store the triggers & forward the packets between i3 nodes & end-hosts. Matching of identifiers in packets to those in triggers is done by mapping each identifier to a unique i3 node. Matching of identifiers in packets to those in triggers is done by mapping each identifier to a unique i3 node. At a given time, only one server ( i3 node) is responsible for given id. At a given time, only one server ( i3 node) is responsible for given id. Packets are not stored in i3 nodes, but only forwarded. Packets are not stored in i3 nodes, but only forwarded.

10/31/2007cs62211 Communication Primitives by i3 - Mobility

10/31/2007cs62212 Communication Primitives by i3 - Multicast

10/31/2007cs62213 Communication Primitives by i3 -Anycast

10/31/2007cs62214 Stack of Identifiers Replaces identifiers with identifier stacks. Replaces identifiers with identifier stacks. Identifier stack is a list of identifiers that take the form ( id 1, id 2, id 3, ….., id k ) Identifier stack is a list of identifiers that take the form ( id 1, id 2, id 3, ….., id k ) where id i is either an identifier or an address. - packet p = (id stack, data) - trigger t = (id, id stack ) This allows the node to forward the packet to another identifier rather than to an address. This allows the node to forward the packet to another identifier rather than to an address.

10/31/2007cs62215 i3_recv() & i3_forward() Pseudocode Pseudocode of the receiving and forward operations executed by an i3 server.

10/31/2007cs62216 i3 Service Composition WML – Wireless Markup Language

10/31/2007cs62217 i3 Heterogeneous Multicast

10/31/2007cs62218 i3 Server Selection Good support for basic server selection through use of last m-k bits of the identifiers to encode application preferences. Good support for basic server selection through use of last m-k bits of the identifiers to encode application preferences. Ex1 : Assume there are several web servers & the goal is to balance the client requests among these servers. This can be achieved by setting the last m-k LSB of trigger & packet identifiers to random values. Ex1 : Assume there are several web servers & the goal is to balance the client requests among these servers. This can be achieved by setting the last m-k LSB of trigger & packet identifiers to random values. Ex2: Consider a goal of selecting a server that is close to client. To achieve this goal, each server can use the last m-k bits of it’s trigger identifiers to encode it’s location & the client can use the last m- k bits in packets’ identifier to encode it’s own location. Ex2: Consider a goal of selecting a server that is close to client. To achieve this goal, each server can use the last m-k bits of it’s trigger identifiers to encode it’s location & the client can use the last m- k bits in packets’ identifier to encode it’s own location.

10/31/2007cs62219 i3 Large Scale Multicast - Hierarchy of triggers

10/31/2007cs62220 Design & Performance Issues 1. Properties of the Overlay - Robustness - Scalability - Efficiency - Stability - Hence, authors chooses Chord Lookup Protocol

10/31/2007cs62221 Chord Lookup Protocol Routing Information maintained by the Chord nodes. The i th entry in routing table of server n contains the first server that follows n + 2 i-1 This server is the i th finger of n.

10/31/2007cs62222 Other Issues 2. Public & Private Triggers 3. Robustness 4. Self-Organizing 5.Routing Efficiency 6. Avoiding Hot Spots 7. Scalability 8. Incremental Deployment

10/31/2007cs62223 Other Issues 9. Security - Constrained Triggers - Pushback - Trigger Challenges 10. Anonymity

10/31/2007cs62224 Implementation & Experiments Implemented i3 using the Chord Protocol Implemented i3 using the Chord Protocol Uses 256 bit identifiers (m=256) & assumes matching procedure requires exact matching on 128 bits (k=128) Uses 256 bit identifiers (m=256) & assumes matching procedure requires exact matching on 128 bits (k=128) Insert trigger requests & data packets share a common header of 48 bytes Insert trigger requests & data packets share a common header of 48 bytes Triggers are updated every 30 s Triggers are updated every 30 s

10/31/2007cs62225 Implementation & Experiments (Testbed) Used cluster of Pentium III 700-MHz m/c’s running Linux Used cluster of Pentium III 700-MHz m/c’s running Linux Tests ran on systems of up to 32 nodes, with each node running on its own processor Tests ran on systems of up to 32 nodes, with each node running on its own processor Nodes communicated over a shared 1- Gb/s Ethernet. Nodes communicated over a shared 1- Gb/s Ethernet. For time measurements, Pentium time- stamp counter was used For time measurements, Pentium time- stamp counter was used

10/31/2007cs62226 Performance Trigger Insertion - Triggers maintained in Hash Table - Inserting a trigger involves just a hash table lookup & memory allocation - The average & standard deviation of trigger insertion operation over 10,000 insertions are 12.5 & 7.12 µs - Memory Allocation time is 0.25 µs - Trigger updated every 30 s - A server able to maintain up to 30 * = 2.4 * 10 6 triggers 30 * = 2.4 * 10 6 triggers

10/31/2007cs62227 Data Packet Forwarding

10/31/2007cs62228 i3 Routing

10/31/2007cs62229 Throughput

10/31/2007cs62230 Future Work Using & deploying new applications on top of i3 other than Mobility solution & scalable reliable Multicast protocol. Using & deploying new applications on top of i3 other than Mobility solution & scalable reliable Multicast protocol. Have used longest-prefix match for inexact matching. Which inexact matching procedure will best allow applications to choose among several candidate choices? Have used longest-prefix match for inexact matching. Which inexact matching procedure will best allow applications to choose among several candidate choices? Efficiency can be increased by embedding location semantics into the node identifiers. Efficiency can be increased by embedding location semantics into the node identifiers. Implementing i3 on top of other lookup protocols to explore more benefits from them. Implementing i3 on top of other lookup protocols to explore more benefits from them.