Internet Indirection Infrastructure April 16, 2009

This seems to do the same as SSH reverse tunneling in terms of its mobility.

Indirection — this allows for portability in that the end user does not need to know the exact location of the other end and the system can more easily do “creative” rerouting (e.g. multicast).

Distributed routing “tables” — instead of having one central domain name server as a single point of failure, this allows for some reliability through multiplexing and redundancy.

I see an issue with the routing efficiency. The paper gives the example of having the sender and receiver in Berkeley, but the i3 node storing the triggers in London. The claim is that the data can avoid the trip from Berkeley to London and back by way of a private trigger on a closer server, but does not account for the case where there is no closer server.

Internet Indirection Infrastructure April 16, 2009

Three Important Things:

• The motivating observation by the authors is that the demand for additional internet abstractions is out there, and the current IP layer cannot provide things such as multicast, anycast, and mobility in a scalable way. Taking the overlay network approach to this problem is a crucial decision, and it has the advantage of working with the infrastructure in place instead of trying to replace it. Such a network could be easily deployed in today’s internet, and based on the evaluation of its merit could someday become the dominant protocol.
• By decoupling the sender from the receiver i3 is able to implement a variety of services. Using indirection is a key design point that enables flexible communication between hosts. This transition to rendezvous-based communication  is a marked improvement over the point to point model.
• As the way that we use the internet has evolved, security has become a primary concern because of the services that are delivered over the internet. The problem is that the protocols in use today were not designed with security in mind. Any new idea for internet architecture should make sure to address security concerns. The paper comments on issues that are particularly relevant such as eavesdropping and DoS attacks.  The ability to have private triggers, enforcing that only a host can insert triggers on its own behalf, and fair queuing are all important extensions.

Glaring Problem:
A major concern with i3 is that the end hosts are responsible for inserting triggers, which means that it would be hard to enforce order and structure in the resulting overlay network. I would have liked to see the paper address this more fully, and maybe elaborate on how a large scale network could evolve out of an ad hoc, approach. This is discussed in the context of preventing attacks, but not in terms of how the network should be structured.

Future Work:
The i3 overlay is presented to us as a general mechanism for implementing communication abstractions. It would be interesting to see what other abstractions could be implemented with i3 in its current form or with extensions.

Internet Indirection Infrastructure April 16, 2009

(i) The three most important things the paper says:

1. The author suggests adding more robustness and flexibility to the IP protocol with the introduction of i3 as an overlay on top of IP. The defining feature of this new protocol is that it is designed to be support more than peer to peer communication as the original IP protocol first envisioned. i3 is aimed at easily adapting multicast, anycast and host mobility while still efficiently handling unicast.

2. The protocol uses packet ids and triggers to route packets instead of source and destination adresses. This means that the sender does not need to know exactly who he is sending his data to, and multicast is attained by having multiple hosts subscribe (by creating triggers) for that packet id. This means that no extra protocol or overhead is needed to attain other types of communication which is needed with IP alone.

3. This protocol has gone to great lengths to take design ideas from what has shown it was adaptable by users in the past. The author emphasizes that the protocol can be incrementally distributed and will work even when a low percentage of the machines support i3. This will greatly help a transitional phase to adapt this protocol. The protocol also limits itself in adapting IP’s best effort delivery model and not adding overhead by adding checks when not all applications would find then useful. This has been proven to be a key when designing a flexible enough system to enable widespread support.

(ii) The most glaring problem with the paper:

A contradiction that this paper suggests but does not offer a solution or recommendation for is that for many of the security and large scale multicast problems they recommend adding a trigger hierarchy to decouple the sender from the receiver, but for performance they recommend caching the receiver so the messages can be sent directly.

(iii) The future research directions of the work:

The paper offers many suggestions for possible future research on i3.  The state that parameters, algorithms and protocol should be experimented with for optimal performance, so the benefits for i3 can be fully assessed. The many security risks pointed out by the paper should also be considered and a balance of security versus performance should also be found before this technology could be deployed. After limited or full deployment there would be many measurements to compile and evaluate to gain further insight on the uses of i3.

Internet Indirection Infrastructure April 16, 2009

The paper proposes an overlay network introducing a level of indirection which allows an easy implementation of the multicast, anycast and host mobility. The i3 overlay provides a rendezvous-based communication abstraction which decouples senders from receivers.

In i3 packets are represented by pairs of message identifier (id) and data. Receivers wanting to an id class attach their addresses with that id to form triggers. The packet identifiers are distributed among the available i3-nodes that are connected in a loop. The packet id is matched until it researches the node whose id matches and from that node, the packet is sent to the destination basing the receiver-address. Further the authors propose that packets and triggers may contain a stack of identifiers to allow service composition, eliminating the clients’ need to know the identity of service provider. The authors point the key differences between the existing rendezvous based overlays like the distributed-event system and i3 and describe their event-dispatching architectures. In a conventional event-based systems, a set of hosts subscribe to a set of events and notify them to a distributed dispatcher routes them as per the subscription. Similar to this model triggers distributed in i3. Also, the traditional system use overlay for routing even notifications whereas i3 uses the IP address of the receiver (a part from some inter-i3-nodes transmissions).

The paper mentions that since i3 end-hosts are responsible for maintaining the routing information through triggers, this poses security threats since users can eavesdrop, isolate a host by removing its trigger and also adversely affect a server of another host. To overcome the authors propose the use of public and private triggers, so as to make i3 at least as secure as IP. The authors then propose ways to make the system robust to i3-node failures: one based on backup triggers, and the other on trigger replication. A possible problem in the i3 could stem from the fact that the final i3-node can be far apart from the sender and the receiver although the two are physically close and this may introduce unnecessary latency. The authors alleviate this problem by proposing that the server selection should be made on the basis of the last m-k bits, which should contain the location information and for private triggers, they make an assumption which states that receivers will check identifier space to find ranges located on nearby i3-nodes. Further the latency arising from sender-to-server network distance is addressed by caching the server IP-address on the sender. They present a performance evaluation by providing simulations of the end-to-end latency and the improvement in this latency by using proximity routing.

The authors also provide simulations for the trigger insertion, data packet forwarding, and throughput. They find that as packet size increases, memory copy operations and pushing bits through the network dominate processing time, and that user throughput increases as packet payload increases since the overhead for headers and processing is small relative to the payload. Since i3 is incrementally deployed as an overlay at the same time giving the security of ip, it can be evaluated and deployed to augment the existing point-to-point links in networks which may benefit from multicast and anycast. And like the authors mention in the paper, third party providers can seamlessly provide i3 service and dependence on major ISPs can be decreased.

Internet Indirection Infrastructure April 16, 2009

(i) the three most important things the paper says:

1. The Internet Indirection Infrastructure (i3) is an overlay-based network infrastructure which provides a level of indirection that is convenient for implementing such services as mobility, multicast and anycast. i3 provides this indirection by decoupling the act of sending from that of receiving via the use of packets and triggers. Senders and receivers use an address, id, to send and receive messages. In particular, senders send a message addressed to id (by sending a packet consisting of id and their message), while receivers express their interest in receiving a packet destined to id by registering a trigger consisting of id and their own IP address/port.
2. i3 addresses various security issues by using techniques such as private and public triggers (with private triggers encrypted and shared via a public trigger), an additional level of indirection in the trigger to protect against trigger hijacking, and use of random nonces and resource capping to avoid denial of service attacks.
3. An implementation of i3 was built using the Chord overlay protocol, which was chosen due to its robustness, scalability, efficiency and stability. Caching is used to avoid hot-spots (i.e. if a flood of clients all try to contact a particular trigger) — specifically, the S which keeps the trigger will send a copy to another server (and more if necessary) to offload some of the traffic. Backup triggers and replication of triggers in the servers is used to protect against failure.

(ii) the most glaring problem with the paper:

Adding extra indirection and particularly pushing storage and translation of rendezvous identifiers into the network seems to be a violation of the end-to-end principle.

(iii) the future research directions of the work:

A more fleshed-out implementation of the overlay network as well as stronger benchmarking results (perhaps helped by re-implementing the finger table with a more efficient data structure) would help bolster the author’s arguments. Further applications that could capitalize on the properties provided by the infrastructure (mobility, multicast, anycast) could be built and compared to current implementations that do not use the infrastructure. Additional experiments to verify some of the properties that the authors describe in their system (such as incremental deployment and protection against failure) would be interesting.

Internet Indirection Infrastructure April 16, 2009

The main contributions of this paper are:

1. Indirection: the authors discuss how decoupling of the sender and receivers helps to generalize point-to-point communication. i3 provides better mobility, multicast, and anycast through this indirection. i3 identifiers and triggers serve to achieve this level of indirection.
2. The paper proves the flexibility of overlay networks. It further provides valuable techniques to build security, scalability, availability, fault tolerance, and improved performance on top of the overlay. Overlay also allows for incremental deployment of i3 in a network.
3. The authors provide many novel ideas such as using a stack of i3 identifiers to achieve service composition on top of i3, heterogeneous multicast (where receivers choose to receive different flavors of the multicast data), and fault tolerance (if one identifier fails, try the next identifier).

Glaring problems: The paper is well written and many scenarios are well thought of, however, the authors provide no experimental results for the applications of i3 most discussed in the paper: multicast, anycast, mobility. The paper goes at length to describe how i3 eases multicast, but does not provide evidence about i3’s efficiency when dealing with these. Additionally, it is my understanding that i3 would make unicast quite slow, so it would not be a suitable replacement for existing network infrastructue.

Future research: it would be interesting to implement a hybrid approach where packets are not required to go through an i3 node. Also implement i3 servers as modified switches. That is, modify a network switch to work with i3 triggers and identifiers instead of IP packets. If a switch can be made like this, a lot of the overhead from processing the triggers in software is taken away.

Internet Indirection Infrastructure April 16, 2009

Single overlay capable of achieving multiple communication services over a P2P network
The paper comes up with a single infrastructure capable of supporting several services such as multicast, broadcast, anycast, mobility etc over the Internet architecture with was built to be P2P. It achieves this by introducing a level of indirection in the form of nodes that act as i3 servers. Senders direct outgoing messages to identifiers instead of a particular destination node address. Receiving nodes can then subscribe to these identifiers if they wish to the message. Hence, more than one receiver can subscribe to an identifier, thereby allowing for the above mentioned services to be achieved over a P2P network. This method suggested by them provides for a lot of flexibility in the terms of the types of services that can be provided, nodes that can add or drop themselves to a service, etc. Other than providing for these services, their structure achieves security (in some aspects, while giving rise to different set of security concerns that they consider in detail and provide methods to counteract) which couldn’t have been achieved in a P2P system.

Methods to add new nodes, handle failure of old ones and provide efficient routing
In addition to suggesting the basic infrastructure, the paper also talks of efficient methods implementation of the idea. The first question that comes to mind when the i3 structure is suggested is, the overhead it would add. The paper provides for a method of packet forwarding that seems to add minimal overhead. In the method suggested, the senders cache the address of the server that is responsible for routing packets to the identifier the sender wishes to send packets to. This reduces the time to find the server for subsequent sends. The receivers reduce the time to receive packets from the servers by choosing servers close to themselves. Similarly, the paper also suggests efficient methods to deal with node failures, node additions and packet forwarding.

Methods to handle security threats
The nature of how the i3 system works exposes it to several security threads. The paper makes a detailed analysis of all possible threats and suggests methods to counteract them.

PROBLEMS

The paper claims that it handles the triangle problem by getting the receiving nodes to choose a server close to themselves to store the trigger containing their id. However, this solution only works if the system has a large number of i3 servers. If there exist only a few servers for a large number of nodes, it is likely that two nodes, adjacent to one another, might have to communicate with a far away server node to be able to reach one another.

Several of the methods they suggest to handle the issue of security work by inhibiting free and flexible use of i3 by the servers. For eg, one of the methods limit the number of triggers a node can have. Also, the innate structure of i3 introduces far too many means of intrusion to be able to detect and counter every one of them.

In spite of several methods to reduce overhead, the structure still introduces them at various stages and steps. There is the overhead introduced by in the security methods suggested, enabling caching by the appropriate server sending out the, “it is me you want to send future messages to” message, etc.

FUTURE WORK

It seems like i3 would provide a workable and efficient platform for a network of rapidly moving nodes. it seems to have the mechanisms in place to provide support for such a system. Work could be done to explore possibilities in the area.

Internet Indirection Infrastructure April 16, 2009

i)

1. There are many applications that implement their own versions of multicast, anycast, or address mobility since trying to deploy a level 3 protocol to solve these is infeasible. Building up a generic infrastructure that can service any of these types of services would be a much better solution. The author propose a generic, incrementally deployable solution to this problem by adding servers that use their own specialized level 7 protocol.

2. Decoupling the act of sending and receiving allows for a very generic design than can support any type of packet routing that is currently used. The authors introduce the idea of using a publish/subscribe type framework where senders can send a packet with and id# and anyone interested in receiving that packet can do so by adding a trigger to indicate they want to receive the packet.

3. The ability to quickly route a packet to the server that has a longest matching trigger is important since it greatly impacts the efficiency of the system. The authors use the  chord lookup protocol to allow them to route packets to the correct server in O(log # of servers) hops.

ii) While the authors did address security of the end users, I felt they failed to adequetly address the security of the actual infrastructure. For instance an attacker could mount a denial of service attack on i3 (i.e. disrupt i3 so anyone trying to use i3 can’t) by creating a large number of i3 servers on perhaps a small number of physical machines by using virtualization. The attacker will then be responsible for a large portion of the id space and they can correctly reply to requests to register triggers or send a packet to an id, but refuse to actually send the packet to end users who have registered a trigger for that id.

iii) A clear area of future research would be into the feasibility of deploying such a system. This would require gauging peoples interest of having such a system and determining the best economic model for deployment (i.e. single provider, multi-provider, for profit, not for profit).

Internet Indirection Infrastructure April 16, 2009

In this paper the authors present a single new overlay network that serves as a general purpose Internet Indirection Infrastructure (i3) based on rendezvous. This network would expand functionalities offered by the IP network without requiring a widespread consensus and commitment from the network community. The two main entities are the sender and the receiver that locate each other through i3 nodes. The senders sends into the i3 network a packet (id, data), where id is an identifier of the communication/service/flow that the sender is providing. At every point in time, in the i3 network there is only one i3 node that is responsible to manage that particular id. On the other side, the receiver registers itself at the i3 node responsible for the specific id the receiver is interested in receiving. From that moment on, the i3 node forwards all the incoming packets with that specific id to all the registered receivers.
The three most important features of this approach are:
1. Modularity & scalability. The new layer can be created in an incremental way, starting with even only one i3 node. It does not require any particular modification to the existing Internet protocol nor infrastructure. The i3 nodes can be pc-based and they communicate through IP. The required number of i3 nodes depends only on the traffic that this new network has to manage and on the locality of the users. The fact that it is so modular can potentially be a key success factor for this approach since it does not require a huge investment to start.
2. Adds functionalities to already existing services. The i3 network allows multicast, anycast etc, combining them with also mobility. A receiver can move from a network to another one and in order to remain connected it has only to send another trigger packet to register itself with the new location. This can be easily be implemented in a seamless way for the application and hence for the user. I3 network can also add security to the communication with the use of public and private triggers that allow the i3 node and the end-host to exchange their private ids.
3. Dynamic service composition & Heterogeneous multicast. A receiver can specify that the data that it wants to receive must be first processed by another server (in the paper there is the example of the H.263 transcoder). This chain of execution/elaboration can be built dynamically by the receiver by sending different triggers to the i3 node. In the same way, a intermediate processing node can exploit the capabilities of another server by forwarding the data to it in a completely transparent way for the receiver. Heterogeneous multicast instead allows the same flow of data to the elaborated in different ways by adding different triggers for a particular id.

Potential problems:
Security. Even if the authors try to address this part in section 4.10, their solution does not sound very strong to me. In particular they address all the security related problems with the use of private triggers. While they can potentially work, they could also add a lot of overhead and complexity to the system, as well as modifying the real nature of the multicast idea.

Possible future research:
The authors do not compare the performance of their implementation with already existing technologies. That would definitely be an interesting avenue of research, also to prove the quality of the i3 infrastructure. Another branch of research could be to try to quantify their proposed solutions to the security related problems.

Internet Indirection Infrastructure April 16, 2009

The authors introduce a design for separating network senders from receivers by introducing a layer of indirection. The system is called i3. The basic structure involves receivers registering a trigger containing an id and the receiver’s address which signals willingness to receive data labeled with the id. Correspondingly, senders send data with an id. The i3 system ensures that data sent with an id is routed to receivers interested in data with that id. The decoupling is intended to improve connectivity in the face of end host mobility as well as provide scalable multicast and anycast solutions.

The greatest contribution is the idea of decoupling the sender from the receiver. This is also the source of the greatest hit to performance, as will be discussed later. Because the sender does not know who will be receiving its transmissions, it is free to simply publish the data however is easiest. The infrastructure can handle routing the data to the appropriate hosts, whether there exists just one or multiple hosts.

Another feature of the i3 design is that it allows ids to be composite ordered stacks. This means that an end host can express a route that the data should take before being delivered. This feature can be used to compose services, such as transforming data into a specific format before being received by the end host. By allowing this kind of id based routing, end hosts can push processing into the network instead of orchestrating such compositions directly (as might be done in a traditional IP network). Of course this freedom is not without consequences. Being able to direct a route is a powerful feature and can cause problems with efficiency and loops if not used carefully.

The authors take steps to avoid the obvious misuses of this type of design. Security and robustness are directly addressed with seemingly adequate solutions. Although they also implement numerous optimizations to achieve low overhead and low latency, they are ultimately tied to the extra processing and hops necessitated by the level of indirection. The simulations in the paper show that at best, packet latency is twice as long as direct IP delivery — and this is after caching addresses and sampling servers to find the closest intermediary. Interestingly, one of the example applications proposed in the paper is transmission of MPEG data that is distributed to multiple end hosts. One of the hosts makes use of i3 composition to transcode the MPEG data into H.264 data en route. Clearly, this was not meant to be an example of a realtime video stream.

Despite the glaringly high latency issues, I find the approach to be interesting and possibly useful in specialized environments. It’s not clear how i3 can be used on the Internet, in practice, however. Further exploration into specific applications where mobility is an extremely common and problematic issue might yield enough demand to consider using i3.

Internet Indirection Infrastructure April 16, 2009

This paper was about I3, a proposed rendezvous-based packet delivery system that would overlay the current Internet. The authors hope that this method will provide greater flexibility than the IP based system in current use can provide. The three main points of this paper were:

1. I3 decouples the sender from the receiver by creating a two part packet, an ID and a Payload, that is transmitted by the sender without any knowledge of the recipients. The nodes wishing to receive the packets, express interest in that particular ID and receive it without speaking to the sender node directly. This provides for greater flexibility in the way that packets are handled by the network.

2. The decoupled nature of such a network provides robustness, scalability, efficiency, stability and incremental deployability. The designers of this system are familiar with the modern Internet and have planned for challenges in a way that the original creators could not have imagined. This gives them a considerable advantage in that not only do they know the challenges associated with designing such a protocol, they are also familiar with the growth trends that we likely must plan for in order for the protocol to be acceptable for a long time into the future.

3. This type of network mitigates some security concerns common in todays Internet but introduces several new ones. This solution is not necessarily designed to be a more secure network, but one that provides for greater flexibility in packet delivery and an alternative to the IP based system that we now use. The authors do a good job of pointing out the security concerns and make no claims to be completely secure.

The most glaring weakness that I saw with this paper was that while the authors did show a solid proof of concept for a different method of packet delivery, I do not know that I am convinced that this kind of network would be able to withstand the amount of traffic present on todays Internet with the performance that people are used to receiving. While they do do a solid performance evaluation, I was still left with some questions about its potential due to the small size of the implemented network and the controlled nature of the experiments.

The research in this paper is in the same vein as the active network, a new way of dealing with packets. This is an ongoing research project and one that is likely to continue for some time as few people believe that our current Internet structure is perfect and strive to find a more effective alternative. Also, further research into performance optimization and security should greatly improve the chances of a protocol such as this being adopted by the mainstream public.