Internet Indirection Infrastructure (i3)

This paper shows how overlay networks can be used to build a simple indirection infrastructure, i3, that solves service problems in the Internet such as multicast, mobility, and anycast. I really liked this paper. The i3 design uses three simple ideas to achieve its goal: communicating through an intermediary with publish-subscribe, longest prefix matching for choosing between servers, and identifier stacks to compose services and scale up multicast. It's very promising that these basic primitives let you implement a lot of things that are otherwise difficult in the Internet, and the primitives are also general enough that you might imagine doing other things with them. In other words, if we ever deploy any kind of widely used overlay network to provide a richer service model than IP, it would be nice if its service model was as general and clean as i3's. Anyone interested in Internet architecture should also read this paper. There are many papers that focus on fixing a particular problem in some complicated way, but it's rare to see one where you think "yeah, this service model is actually something I'd like to have for the whole Internet".

The big challenge with i3 is of course its implementation, and especially the performance aspect of it. The authors suggest using a Chord DHT to implement i3. While Chord is designed to continue working under an insanely adverse fault model, this comes at a cost in efficiency, which shows in the results. It is possible to optimize Chord for latency, as the authors mention. However, I think the work would also have benefitted from an analysis of how well you could provide the service with dedicated servers if you were a commercial entity. The implementation might then look radically different, but the design problem would be easier (less need to worry about security, faults, etc), and the benefits of a fast i3 are so compelling that it might get application developers to use the system. In a similar vein, it would be interesting to talk about how i3 might be monetized - how much would you have to charge for it in order to be able to support servers at some given scale? I think that at the time this paper was written, the networking community was very focused on DHTs and overlay networks, and missed the chance to argue about how feasible this might be to actually build.

One last thought is that i3 might also be useful on much smaller scales than the Internet, and a fast implementation for those settings would also be good. One example is in an enterprise network, to provide the same features as the Intentional Naming System (e.g. find my closest printer). Another would be in a data center, to provide anycast.