Review of "Internet Indirection Infrastructure"

Deploying new network services such as anycast, multicast, and mobility
requires significant changes to the routing nodes of the Internet.
Implementations of these technologies currently lie dormant within routers,
partly because of fears of complications arising from fundamental changes to
the network architecture, uncertainty about the value of a partial
deployment, and the additional processing overhead of adding stateful
services to routers. This paper presents the Internet Indirection
Infrastructure (i3), a rendez-vous based communication model that shifts the
risk and the cost of deploying such services to the end-hosts. The
prototype i3 system is implemented as an overlay network based around the
Chord lookup protocol. As such, it provides a unified means for developing
a variety of new network services that are troublesome to implement on a
large scale at the IP layer.

I3 is based around the idea of decoupling senders and receivers without
resorting to modifications to the IP layers of the routing nodes. For
example, in an i3 implementation of multicast, the sender uses an identifier
(ID) instead of an IP address to indicate the destination nodes of its
packets. When the multicast sender dispatches the message consisting of an
{ID, data} pair, it is routed using the underlying IP network to the holder
of the group state -- one of a set of i3 servers that store "triggers" and
forward packets. The receivers send in their {ID, IP address} pairs to the
same server to register "triggers" (forwarding rules). This will result in
copies of packets addressed to the ID to be forwarded to the receivers' IP
addresses. This approach allows the receivers to control the routing of the
message and it allows the infrastructure to shift the burden of constructing
distribution trees to the end nodes. One variation of this algorithm allows
for inexact matching: a match occurs if the destination ID and trigger ID
share at least k of their bits and there is no other trigger which matches a
greater number of bits. This variation can be used to implement anycast.
Identifier stacks are another powerful variation; based on ID nesting, it
allows for service layering, heterogeneous multicast and increased
robustness.

The authors chose to implement their system around Chord because it exhibits
the required properties of robustness, scalability, efficiency, and
stability. The paper presents several methods for maintaining these
properties during adverse conditions. For example, i3 servers can push
triggers to other servers if they find themselves becoming overloaded. In
addition to these properties, i3 is self-organizing and allows for
incremental deployment. The paper also provides an adequate discussion of
defenses against security attacks such as eavesdropping, impersonation and
DoS attacks.

Overall, reading this paper was satisfying. The authors presented the paper
in a logical fashion and did a good job of addressing issues such as
security, latency and efficiency.
Received on Thu Nov 23 2006 - 04:45:51 EST