Review: Internet Indirection Infrastructure

Solutions for mobility, multicast and anycast all require indirection.
This paper proposes a an overlay-based Internet Indirection
Infrastructure (i3) that unifies these solutions. The current
point-to-point communication abstraction is augmented with a
rendezvous-based communication abstraction. Instead of explicitly
sending a packet to a destination, each packet is associated with an
identifier, which is used by the receiver to obtain delivery of the
packet. The receiver sends an i3 server a trigger (id, addr) so that any
packets (id, data) with the given id should be sent to the provided
address. This level of indirection decouples the act of sending from the
act of receiving, and allows i3 to efficiently support a wide variety of
fundamental communication services. The authors designed and built a
prototype i3 based on the Chord lookup protocol. To show that i3 can
support sophisticated application requiring mobility, anycast and
multicast, the authors also implemented a simple heterogeneous multicast
application in which MPEG video traffic is sent to an MPEG receiver as
well as transcoded on the fly to H.263 format for another receiver. They
also developed transparent mobility to legacy applications and a large
scale reliable multicast protocol, however, they did not provide much
detail about these in this paper.
The paper provides a comprehensive overview of i3 along with some
example uses for it, as mentioned above, heterogeneous multicast, large
scale multicast as well as service composition and server selection.
The authors then discuss design and performance issues highlighting the
importance of robust, scalable, efficient and stable overlays.
Furthermore, i3 must itself be robust, self-organizing so that it can be
maintained without human intervention when it grows large. It is
necessary for the routing to be efficient. The authors acknowledge that
i3 routing cannot be as efficient as IP routing, but they provide
methods to improve the routing such as server IP caching so as to bypass
i3 routing. They provide simulations of the end-to-end latency and the
improvement in this latency by using proximity routing (that is sending
trigger to geographically close servers). Based on their prototype, the
authors also provide simulations for the trigger insertion, data packet
forwarding, and throughput. They find that as packet size increases,
memory copy operations and pushing bits through the network dominate
processing time, and that user throughput increases as packet payload
increases since the overhead for headers and processing is small
relative to the payload. However, as packet payload increases,
throughput in packets decreases.
The paper mentions that since i3 end-hosts are responsible for
maintaining the routing information through triggers, this poses
security threats since users can eavesdrop, isolate a host by removing
its trigger and also DoS a server of another host. The authors outline
some solutions to these problems, such as, public and private triggers,
so as to make i3 at least as secure as IP.
Finally, An important advantage of i3 is that it is incrementally
deployable.
The paper is very interesting and puts forth a valuable idea. The
authors explain the idea very well too. One point I did not like as much
was that although they mention i3 is compatible with legacy
applications, these applications now require an i3 proxy to intercept
packets etc. This seems like despite being incrementally deployable, i3
involved quite a bit of effort to deploy it and be able to use current
applications.
Received on Wed Nov 22 2006 - 23:56:50 EST