Review - Internet Indirection Infrastructure

From: Ivan Hernandez <ivanxx_at_gmail.com>
Date: Thu, 23 Nov 2006 10:45:54 -0500

 Review of Internet Indirection Infrastructure
by Ivan Hernández

The paper propose to augment the current point-to-point communication
abstraction with a rendezvous-based communication abstraction. In the
paper, this abstraction, called Internet Indirection Infrastructure
(i3), is based on an overlay network. By using i3 a sender does not
send a packet explicitly to a receiver, instead it tags each packet
with an identifier and sends the packet to a server associated with
this id. On the other hand, if a receiver wants to get a certain
packet flow id, it must register a trigger in each server associated
with the desired id packet flow. The server in charge of that id
forwards the packets from the sender to the receiver. This basic model
is improved through the paper to provide better scalability, security,
privacy and routing performance.

I find the main idea of the paper good, to decouple the sender and the
receiver behaviors, this allows provide a good support for mobility,
multicast and anycast. In addition, the paper provides a good
discussion of ideas to improve several features of i3 that can be
applied in general to overlay networks, such as routing efficiency.

On the other hand, I think that the paper has some issues. First, In
the implementation and experiments section, the authors provide
results of the implementation of the overlay network that i3 uses, but
they do not provide an implementation or evaluation from i3 for any of
the three proposed delivery scenarios multicast, mobility,
anycast. Second, For a TCP communication there is no clear how the
sender and receivers are going to initiate a TCP session, i.e., the
ids that a sender set in an i3 server are for a particular packet
flow. Third, for the mobility solution, the authors assume that the
server in charge of the id used by the sender and receiver is always
available, i.e., the server cannot be mobile, leave the overlay, and
it has no crashes. Next, in the Large Scale Multicast, it looks that
they have an idea to solve this particular problem, but they have not
implemented it, and therefore i3 only is able to work with the
non-scalable approach where the server in charge of a multicast id is
the only one that will forward each multicast packets to every member
of the multicast group. Another problem with the paper is in the
Routing Efficiency section. To achieve routing efficiency, the authors
cache in the sender the IP address of the Server, and the Sender sends
directly using IP packets to the receiver. When the sender notices
that the server has failed, it informs the receiver to reinsert the
trigger immediately; nevertheless, this solution totally breaks with
the main objective of the solution: to decouple the sender and the
receiver behaviors! because the sender must always know the IP address
of the mobile device or the IP addresses of all the multicast devices!
Finally, I think that one weakness of the solution is that uses an
overlay network, and therefore the authors have to deal with some of
the weaknesses of overlays that, if it is true that overlays have been
studied for some time, to my best knowledge there is no implementation
of a particular in-production resilient solution that uses overlay
networks.
Received on Thu Nov 23 2006 - 10:46:02 EST

This archive was generated by hypermail 2.2.0 : Thu Nov 23 2006 - 10:55:03 EST