From: Jonas Lindberg (jonaslin@kth.se)
Date: Sun Nov 14 2004 - 16:49:20 PST
"Internet Indirection Infrastructure" by Ion Stoica et al.
Reviewed by Jonas Lindberg
In this paper Stoica et al. proposes an overlay-based communication
abstraction called Internet Indirection Infrastructure (i3). The purpose of
this infrastructure is to provide a level of indirection that applications
can use to easily implement services such as mobility, anycast and
multicast.
The i3 network consists of a number of i3 servers, or rendezvous points,
each responsible for its own i3 address interval. The model is receiver
initiated in the following sense: end-hosts that want to receive traffic
sent to a certain i3 address need to registers this in the i3 server
responsible for the interval the particular i3 address is in. When an i3
server receives a packet, it sends it out to everyone that is registered as
a receiver for the i3 address of the packet. This indirect infrastructure
makes it possible for a sender to continue sending traffic to the same i3
network address even when the number of receivers is changing or when a
receiver is switching IP address as a consequence of switching between
different wireless networks (mobility).
Among other things, the paper presents an i3 feature called identifier
stack, which gives receivers the possibility to control the traffic to be
sent to other locations before it is sent to the receiver. This feature is
cool, but I am wondering if this is the right place for it. I am also
skeptical to weather protecting yourself by using this technique to force
all data to go through a firewall (as mentioned in the end of 3.2
Hetrogenous Multicast) is a good idea.
One downside of using an indirect infrastructure like this is increased
packet delay as a consequence of packets being sent via the rendezvous point
that might not be on the shortest path between the sender and the receiver.
Some small amount of time will also be spilled during the lookup that is
needed to find what IP addresses the receivers have. There is also a risk
that the i3 servers, or the paths leading to them, become overloaded by all
traffic that needs to pass through it.
This paper provides an infrastructure that seems useful and also possible to
deploy in an incremental manner. However, before i3 can be deployed, more
details need to be worked out and additional testing is also necessary (e.g.
multicast was never tested). I find it a little bit unclear how the ISP's
will profit from deploying it. Overall it was an interesting paper that I
enjoyed reading.
This archive was generated by hypermail 2.1.6 : Mon Nov 15 2004 - 01:50:02 PST