From: Masaharu Kobashi (mkbsh@cs.washington.edu)
Date: Sun Nov 14 2004 - 23:25:57 PST
1. Main result of the paper
The paper proposes a new overlay-based Internet indirection
infrastructure, i3, that is capable of supporting a wide variety of
service types such as mobility, multicast, and anycast without changing
the underlying network architecture. Its features include unique
functionalities such as service composition and heterogeneous multicast,
2. Strengths in this paper
One of the greatest properties of the proposed architecture is it
does not require modification to the underlying network. This makes
it easily deployable in the current Internet.
The key design feature of the proposed architecture is the decoupling
of the act of sending from the act of receiving. By this design, many
favorable characteristics are made possible including the capability to
enable mobility, efficient multicast, good security and even anonymity.
Use of stack of identifiers is a clever idea. It makes interesting
functionalities possible such as service composition and heterogeneous
multicast, which are very unique capabilities.
3. Limitations and suggested improvements
One of the biggest weaknesses of i3 is that routes for delivery of
packets are most likely longer, (can be much longer), than the shortest
paths. The remedy by using private trigger does not completely eliminate
this problem, since there need a lot of i3 servers to make the routes
short to widely distributed hosts in the Internet even by using private
triggers.
Therefore, the authors should investigate this problem in the performance
evaluation thoroughly. Its simulations are very limited in this respect.
Another problem is its provision for transient inconsistency when i3 is
used for mobile hosts. The paper does not provide any such provision for
the cases where moving a host's registered trigger momentarily differs
from its actual location when the hosts are in transit.
4. Relevance today and future
It can be deployed easily on the current Internet, since it does not
require modification to the underlying network. It seems there are
types of applications that fit the proposed architecture. But it is
not a right design for wide-area real-time services since, as I
pointed out above, it will be hard to maintain low and bounded latency
for many hosts distributed over a wide-area due to potentially longer
paths than shortest paths even with the private triggers.
To make the paths shorter by using the private triggers, it requires
a lot of i3 servers distributed all over the Internet.
So this is a good design for some applications and deployable into the
future but not for all types of services.
This archive was generated by hypermail 2.1.6 : Sun Nov 14 2004 - 23:25:57 PST