Review: Internet Indirection Infrastructure

Internet’s original point-to-point communication mechanism based on IP
address scales very well for uni-cast communication. However due to
changing requirement of application and usage patterns there has been
increasing demand for communication mechanisms that support multicast,
anycast and mobility, at the same time general enough to scale and support
multiple applications. In order to support these requirements, author in
this paper has purposed a general purpose overlay network infrastructure
based on the idea of indirection that enables applications to implement a
variety of communication services, such as multicast, anycast and
mobility.

Internet Indirection Infrastructure (i3) offers a rendezvous-based
communication infrastructure that decouples the sender from receiver and
uses Chord as a lookup protocol to achieve robustness, scalability and
efficiency. In i3 each packet is associated with an identifier instead of
IP address and the receiver uses this identifier to receive the packet.
Triggers are used by receiver to indicate their interest for packets with
particular identifiers. In order to support this abstraction the overlay
network consists of servers that store the triggers and forward the
packets using IP between i3 node and end hosts.

i3 decouples sender from receiver which make it possible to support the
mobility of both sender and receiver. As the communication is based on
identifier so as the client moves it just has to update the trigger to
reflect its new IP address so the i3 server can now forward the packets
accordingly. Multicast can also be supported easily by having multiple
receiver register trigger with the same identifier. Another abstraction in
i3 is use of stack of identifier instead of a single identifier. This
enables the i3 to support feature such as service composition, server
selection and heterogeneous multicast.

The idea of i3 is simple and using the simulations author has shown that
this could be implemented by using simple heuristics to achieve the decent
performance. Though the author has mentioned the design as preliminary and
has discussed issues such as security, routing efficiency, scalability and
robustness, but I still believe more attentions is needed to handle server
failures so that applications do not suffer from delay, avoiding replay
attacks and impersonation. Similarly in the current scenario mobility is
not being handled gracefully meaning when the client moves the packets are
being still forwarded to old IP, which could have been issued to another
client, unless the client updates the trigger with new IP. Also the client
loses packets during the mobility that can be undesirable for some
applications. But overall the idea presented in this paper is good and it
could be used to support the indirection efficiently.
Received on Thu Nov 23 2006 - 10:55:00 EST