Internet Indirection Infrastructure
by Ion Stoica, Daniel Adkins, Shelley Zhuang, Scott Shenker, Sonesh Surana
url show details
Details
| address: | New York | | journal: | IEEE/ACM Trans. Netw | | editor: | Peter Druschel and M. Frans Kaashoek and Antony I. T. Rowstron | | abstract: | Attempts to generalize the Internet's point-to-point communication abstraction to provide services like multicast, anycast, and mobility have faced challenging technical problems and deployment barriers. To ease the deployment of such services, this paper proposes an overlay-based Internet Indirection Infrastructure (i3) that offers a rendezvous-based communication abstraction. Instead of explicitly sending a packet to a destination, each packet is associated with an identifier; this identifier is then used by the receiver to obtain delivery of the packet. This level of indirection decouples the act of sending from the act of receiving, and allows i3 to efficiently support a wide variety of fundamental communication services. To demonstrate the feasibility of this approach, we have designed and built a prototype based on the Chord lookup protocol. | | volume: | 12 | | series: | Computer Communication Review | | number: | 2 | | month: | mar # "~14 | | annote: | Ion Stoica (University of California , Berkeley; {\textbraceleft}istoica); Daniel Adkins (University of California , Berkeley; {\textbraceleft}istoica); Shelley Zhuang (University of California , Berkeley; {\textbraceleft}istoica); Scott Shenker (University of California , Berkeley; {\textbraceleft}istoica); Sonesh Surana (University of California , Berkeley; {\textbraceleft}istoica); | | type: | misc | | pages: | 205--218 | | year: | 2002 | | publisher: | ACM | | booktitle: | SIGCOMM |
|
|
You need to log in to add tags and post comments.
i3 seems to offer an effective generalization to communication abstractions such as multicast, anycast, and mobility. However, it's a little difficult for me to assess the overhead in the performance section because I don't have much intuition about how bad the latency stretches and packet forwarding/routing overheads are (i.e., how bad is a 20 usec delay in practice?) I did like the fact that they try to give a sense of the entire distribution of delays in their graphs by showing the values for the 10, 25, 50, 75, and 90th percentiles rather than just showing the 50th percentile: I found it interesting that the distribution of packet forwarding overheads of i3 was skewed to the left while that of packet routing overhead was strongly skewed to the right.
i3 offers an expressiveness power suitable for composition of services, as well as multicast and unicast. i3 could, for example, be used at the core of many internet services since it seems easy to deploy.
Its performance is not that bad but the authors mention that this implementation is a proof of concept and some improvements still need to be made in terms of efficiency.
Regarding security, their strategy of relying in random ids that are hard to guess is probably enough in most situations.However, a solution similar to the one used in DOA (as mentioned by Kaushik) could and should be used, since i3 security depends on extra intermediate ids that could add more latency (but it really seems they were not concerned with these details).
Just want to point you folks towards another recent paper on naming (I'm a bit biased in referring this paper to you). It has to do with using self-certifying addressing to solve some of the accountability problems of spoofing, DDoS prevention, etc.
Holding the Internet Accountable in HOTNETS07.
I thought this was a good idea that unified support for multicast, anycast, mobility, and service composition.
I also liked how the authors thought through the security issues--my first thought was how this infrastructure could be used to support DoS attacks, which the authors discussed.
I would have liked to see more done in the evaluation with actual measurements rather than simulation. Has there been any follow-up work in a real environment?
This paper states a very interesting idea. The rendezvous part acts like a naming system to keep the mapping from a "id" to one or multiple real IPs.
Given the trigger in i3 system, the data transfer is more like a "pull" by the receiver instead "push" by the sender. I am not sure what may happen between the i3 overlay and its underlay, say TCP or UDP throughput. Maybe there will be different in congestion control part.
I enjoyed reading this paper. The proposed ideas were presented clearly and concisely and I felt that most of my initial concerns about i3 were covered by the authors’ thorough analysis. The existence of realistic scenarios, such as the heterogeneous multicast video streaming example, made the ideas more convincing. I liked that the authors touched on the areas of security and proximity mapping, because I believe that they are very important in the context of overlay networks. Finally, I think that the Chord overlay network is ideal for achieving the goals of i3. One interesting issue is the deployment strategy and even more so the economic model of i3, which is left as future work by the authors.
In subsection 4.10.2 (Trigger hijacking) the authors state “One possibility to guard against this attack is to add another level of indirection”, which reminded me of David Wheeler’s aphorism: “All problems in computer science can be solved by another level of indirection”. :D
This is a really interesting idea, and I think it can be applied for commercial streaming services. However, simple security measures provided in the paper don't seem to be sufficient for commercial purposes. Actually, I didn't have time to look at the optional reading that Vijay suggested. But, is there any following work with a commercial purpose?
According to Wikipedia, Wheeler's full quote is "Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem." :)
#12: If I'm not mistaken, this doesn't necessarily change the way we find data. We still use off-band mechanisms to locate the id of who we want the data from. For example, you'll still use Google to search for the source code location of some software, and for multicast you register your intention to be part of the same multicast group by registering a trigger for that multicast id, but you don't register data items.
In contrast, the SFR paper (by the same guy who did DOA) talks about how to find data by essentially registering triggers for data (in a way), so theoretically i3 and SFR can coexist.
This last point also brings up the idea of 'data-oriented networking,' which we will get into in a few lectures. While we won't cover this in class, Van Jacobson recently started a new project at PARC looking at 'data dissemination' architectures. He has a very interesting and fun talk here: http://video.google.com/videoplay?docid=-6972678839686672840&q=Van+Jacobson+data+dissemination&subtitle=on&pr=goog-sl
A general framework for mobility, multicast, and anycast is interesting. I think the section giving several examples of how i3 can be used is very useful to understand what i3 would look like in reality. Also, the authors did a good job in discussing many aspects of issues on design and performance- e.g. robustness, routing efficiency, and especially on security.
i3 provides a flexible solution for communication abstraction. Similar as DOA, it is based on flat names, which is not deployed commercially today. Under the rendezvous-based scheme, name resolving is at the packet level, as Kaushik pointed out. I think it would be interesting to see a paper with results on the cost this level of indirection by introducing i3 on a real network.
One interesting thing that I didn't see mentioned in the paper was the economics of multicast. If you're sending a datastream to n people, then, in general, eventually n copies of that datastream need to be sent out onto the existing public Internet. Who's going to the pay for the bandwidth needed to send those n copies?
I suppose that if an individual host uses multicast for only a small fraction, but during that time he would not have enough upstream bandwidth to send n unicast datastreams, then it might be reasonable to pay to belong to an overlay network that provides multicast capability.
Also, I thought it was nifty that this design was built on top of Chord. I had thought of Chord as being mainly used to support FTP-like bulk data transfer like today's p2p networks, but it's interesting to see it being use to support real-time multicast (e.g., multi-party video conference) as well.
I like how their main idea was simple and intuitive, with possible incremental deployment. They do say that they don't understand what the economic model that make sense for it is though.
Does anyone know what the current status of i3 is? Is it still an active project/has it been deployed? I'm curious, because the authors mention a fair bit about future work and issues with deployment.
With regards to the use of Chord, as the authors mention, it isn't as if the other P2P schemes can't be used. It was probably just easier to design their protocol over Chord, because they'd developed it(they have the same first author). Just thought I'd mention it.
This seems like a nice routing overlay which could handle a variety of services in a reasonable way.