Thursday, November 6, 2008

i3

Internet Indirection Infrastructure (i3) is a neat idea that presents a communication abstraction based on an overlay. The key notion is the decoupling the act of sending from receiving. The paper is motivated by the fact that while IP has served the Internet pretty well in its original form, adding more services to it like multicast, mobility has been a problem with inelegant solutions.

In comes i3! In i3, nodes interested in receiving packets insert a trigger in the i3 overlay node. Packets are sent to identifiers and appropriately forwarded to interested receivers – delivery is best-effort as the Internet. The overlay consists of a set of i3 nodes with each of them responsible for a chunk of identifiers. Mapping of the identifiers to the nodes is through Chord. Every packet is routed to the i3 node responsible for the packet’s identifier which in turn forwards it to the interested receivers.

I would have liked a little bit of a discussion on what naming service is required for i3 – mapping servers to identifiers – but I guess it shouldn’t be too different than DNS. Routing inefficiency is a major problem with this overlay and if this were to be deployed at a large scale, can potentially be a show-stopper. The solution for it sort of hand-wavy and I didn’t like that.

Given that now the i3 nodes are crucial to the communication, the churn in the overlay can potentially leave TCP extremely confused! Handling the dynamics already present is hard enough – i3 just added a lot more using overlay nodes that can come and go, and possibly be overloaded causing more dynamicity.

I liked the security analysis. The anonymity argument made me uncomfortable. Contrary to their argument, tracing back attackers is a much more important problem than hiding your own identity. In the earlier Internet, attackers at least had to spoof their addresses (and fight against techniques that prevent that) to avoid being traced back – with i3 they wouldn’t even have to do that. I think this is a fairly serious concern. On the other hand, the fact that the receiver can remove a trigger at will makes it less vulnerable to DoS attacks.

All these neat ideas make me wonder what exactly is the E2E principle relevant for and why is it such a big deal in the networking world?! Fine paper, a keeper!

No comments: