From: Pravin Bhat (pravinb@u.washington.edu)
Date: Sun Nov 14 2004 - 22:37:17 PST
Paper summary: The paper proposes a new way to think about internet routing.
In traditional routing the ends of a flow are tied to the hosts involved. i3
unties a flow from the end-hosts thus allowing flows to take any desired shape.
The shape of a flow can then be modified dynamically to best suite the needs of
a specific application. Flows can be shaped as trees to support multicasting, or
as dynamically updating chords to support anycast/mobile hosts. Flows can be
deliberately made circuitous to increase anonymity and so on.
Paper Strengths:
The i3 paper is simply outstanding. The ideas presented in the paper are great.
The paper is well written, explaining the technical details of the infrastructure
with much clarity. The paper has great breadth in its analysis of the proposed
infrastructure across various domains ranging from scalability to security. The
authors also clarify how i3 compares to the existing body of research conducted
in the field.
Decoupling flow from end-hosts is a great idea. It adds much greater expressivity
and flexibility to internet routing available on the current unicast based
architecture. The number of new features that be built using this system far
exceed the ones presented in the paper which as its stand is an impressive
list - multicast, anycast, mobility, anonymity, self organization, load balancing,
and heterogeneous multicast. Considering the incredible number of features that
have been already built using the current architecture one can only expect such
added expressivity to increase the feature set and application diversity by
several orders.
Limitations and further improvements:
The authors claim that the end-hosts can minimize path inflation due to i3
indirection by ensuring that the triggers are inserted in i3 nodes that are in
close proximity. The end-host are required to find these close proximity i3 nodes
by probing the network hence the system works under the assumptions that the
proximity measure remains static over long periods of time. However this assumption
does not hold for mobile hosts which could result in increased latency for such hosts.
It is also not clear how end-hosts probe the network for close proximity i3 nodes.
The authors suggest probing the network with trigger ids constructed using
local zip codes or by probing a range of ids. The problem with the former is
that end-hosts may not always know their zipcodes/physical-locations. The latter
raises the question of how a end-host selects a range of ids to probe the network
without sacrificing precision and at the same keeping redundant traffic to a minimum.
Security is a concern with the i3 architecture. Consider a multicast based
pay-per-view movie broadcast system. Using the i3 architecture a single host can
"rent" the private id for a movie's multicast session and then share the id with
everyone on the internet. In the existing architecture at least when a malicious user
decides to share copyrighted content, the user has to do the broadcasting himself
thus limiting the damage that can be done by a single user. However by sharing private
ids a single user can effectively leverage the i3 architecture to broadcast copyrighted media.
The paper falls short in the simulation section. Its surprising to see that the
authors did not implement multicast in their i3 implementation. Also some of the number
presented in the simulation results seem to be misrepresented: for example the authors
claim that a server is able to maintain 2.4 * 10^6 triggers at any given time however this
number is valid assuming the server is doing nothing but updating trigger ids.
Deployment is also bound to be an issue with i3. i3 can be deployed as an
overlay network on top of IP however considerable changes will have to be made in the
end-host applications. Application that plan to work with the i3 infrastructure will have to
use i3's publish-and-subscribe model in additional to the traditional socket model.
Relevance and future work:
The i3 infrastructure provides a solution for applications like P2P and media broadcasting
that are gaining prominence in the internet today but their continued growth is unfeasible
in the current unicast based architecture. This infrastructure will also enable new
applications like heterogenous multicast to emerge which might have been previously next
to impossible to implement.
For future work, the authors need to strengthen their experimental implementation of i3 -
implement multicast, fix the performance issues with the data structures and prove that
their proposed architecture behaves as predicted in diverse simulations.
This archive was generated by hypermail 2.1.6 : Sun Nov 14 2004 - 22:37:22 PST