Summary:
This paper introduces Internet Indirection Infrastructure (i3), which is an overlay network supporting a rendezvous-based communication abstraction between senders and receivers. in i3 overlay network, sender transmits the packet to an identifier rather than receiver within the i3 server cluster which is forwarded to interested receivers according to already registered triggers (some kind of callback). i3 is built on top of Chord overlay network which supports scalable and balanced lookups of the identifiers. I3 can efficiently support multicast, anycast and mobility simultaneously and without the involvement of the transmitter and this is the major contribution of this paper.
Using a stack of identifiers instead of simple scalars give an special flexibility to i3 network. Transmitters send a stack of identifiers along with the packet which can be used for example to backup triggers improving the robustness of the system. Using a stack of identifiers also enables heterogeneous multicast since receivers can specify the set of services/servers the packet need to visit before arriving at the receiver and (therefore enable different kind of processing on the packet).
An important technique in i3 design is the usage of public and private triggers. The public trigger is known by everyone and can be used by everyone to for example access a web-server. Private triggers on the other hand are usually short lived triggers which are used for individual data transmission among the nodes. This feature is used to improve routing efficiency by locating the i3 server closest to the receiver in order to alleviate the triangle problem. The length and also private-ness of the private triggers also helps with security issues such as eavesdropping.
Critique:
The authors use simulations and limited experiments to show the feasibility and performance of i3 system. An interesting result is that a receiver can improve the end-to-end latency by only obtaining 16-32 samples from the i3 servers (in order to identify the closer ones). I wonder what happens when the multicast group is geographically widespread? A comparison of this case with IP multicast would have been interesting.
This paper introduces a very nice communication abstraction layer and I vote for keeping it in the syllabus.
This paper introduces Internet Indirection Infrastructure (i3), which is an overlay network supporting a rendezvous-based communication abstraction between senders and receivers. in i3 overlay network, sender transmits the packet to an identifier rather than receiver within the i3 server cluster which is forwarded to interested receivers according to already registered triggers (some kind of callback). i3 is built on top of Chord overlay network which supports scalable and balanced lookups of the identifiers. I3 can efficiently support multicast, anycast and mobility simultaneously and without the involvement of the transmitter and this is the major contribution of this paper.
Using a stack of identifiers instead of simple scalars give an special flexibility to i3 network. Transmitters send a stack of identifiers along with the packet which can be used for example to backup triggers improving the robustness of the system. Using a stack of identifiers also enables heterogeneous multicast since receivers can specify the set of services/servers the packet need to visit before arriving at the receiver and (therefore enable different kind of processing on the packet).
An important technique in i3 design is the usage of public and private triggers. The public trigger is known by everyone and can be used by everyone to for example access a web-server. Private triggers on the other hand are usually short lived triggers which are used for individual data transmission among the nodes. This feature is used to improve routing efficiency by locating the i3 server closest to the receiver in order to alleviate the triangle problem. The length and also private-ness of the private triggers also helps with security issues such as eavesdropping.
Critique:
The authors use simulations and limited experiments to show the feasibility and performance of i3 system. An interesting result is that a receiver can improve the end-to-end latency by only obtaining 16-32 samples from the i3 servers (in order to identify the closer ones). I wonder what happens when the multicast group is geographically widespread? A comparison of this case with IP multicast would have been interesting.
This paper introduces a very nice communication abstraction layer and I vote for keeping it in the syllabus.
I3 was actually used as the foundation for CORAL, a CDN that at least at one point had 10s of millions of fetches per day. The implementation of i3 is pretty robust at this point. I think Stoica introduced sufficient extra mechanisms like the hierarchical decomposition of the trigger tree.
ReplyDeleteThat is a sweat story! Seeing a great innovation get adapted instead of resisted (similar to XCP-like proposals).
ReplyDelete