CS6390 Advanced Network

PLANET: An Active Internetwork

A Dream Come True

Author: Liang, Zhiyan

Chen, Boqian
Summer 2000
The following document serves as a report after reviewing paper “PLANet: an Active Internetwork”(Michael Hicks et al., 1999). We would summarized the essential information about PLANet implementation of active network model in this paper, focusing on the advantage and disadvantage of this approach, as well as suggest some of the limitations in their studies. We divide this report into four parts. Section I gives general introduction to active network and PLANet. Section II highlights PLANet architecture. Section III describes their performance testing results. Section IV ends the document with brief discussion on strength and limitation of this paper.
I. Introduction

During the past decade, the world has witnessed the massive explosion of internet development. But unfortunately, the rapid developing lead user applications that the internet must carry out and underlying technologies position internet itself to an evolution bottleneck:

  1. Difficulty of deploying new technologies and standards in the existing network infrastructure.
  2. Poor performance due to redundant protocol stack.
  3. Difficulty to implement new services in the existing architectural model.

Active network is an emerging approach to address these issues, where the switches of the network is capable of performing customized computations on datagrams passing by. Among all kinds of proposed active network models so far, such as Active Network Transport System (ANTS), Netscript, Smart Packets etc, PLANet is the best performing system in the literature to date. This paper further contributes to our understanding of the capability and performance of PLANet implementation by their prototype.

II PLANet Architecture

PLANet Makeup

PLANet is indeed a pure internetwork, because it implements network layer services directly on top of line layer technologies without relying on the existing IP infrastructure. PLANet is pure active at two different levels:

  1. All packets contain programs written in a special purpose language called PLAN. PLAN is a small language that has common elements with Haskell(refer to Michael Hicks et al., 1998). In addition, it includes primitives for evaluating an expression at a remote node, invoking such primitives generates newly spawned packets. PLAN has resource-limited semantics that ensures PLAN programs always terminates after visiting a fixed number of nodes. PLAN programs provides control of how packets operate inside the network by calling router resident service routines.
  2. PLANet nodes may be programmed by dynamically loading active extensions written in Ocaml, a dialect of the ML. The choice of Ocaml is due to the following reasons: Ocaml is a type-safe, garbage-collected language, suitable for safe mobile code; Ocaml provides machine independency and code-downloadability, which is needed for dynamically loading active extensions to the nodes. These extensions may add to the existing node functionality and provide services to active packets when they are evaluated.

Thus, the PLANet approach allows flexibility along two design space axes which are important for active networking:

  1. Two possible level of activeness, namely active packets and programmable nodes
  2. Possible locations for active evaluation namely PLANet allows evaluation at some of the intermediate hops instead of a fixed point such as destination only in some other projects.

Packet Format

Any form of internetwork requires uniform network layer addressing and packet format to allow interoperation between diverse physical networks. Since the all PLAN packets consists of PLAN programs, so this standardization reduces to defining a standard marshalling scheme for PLAN programs. This greatly simplifies the task of implementation of future new network services, because the only concern will be what kind of information needed to be included in the PLAN programs.

Detailed information about each packet field is depicted in Fig 2 of the paper. Some highlights of this scheme:

  • PLANet uses 48 bit addressing. The author use 32 bit IP address and 16 bit port number as their implementation address, making it easy for them to use UDP/IP as a link layer.
  • Techniques similar to ARP are used for link layer and network layer address transformation. But in PLANet, PLAN program substitute the special packets used in ARP.
  • PLAN programs can manipulated as data so that they can encapsulated in the chuck or fragmented, reassembled by active router resident service routines.

Routing

Obviously, per hop evaluation of the packet to determine the next hop is flexible and easy to do approach, but very expensive in terms of performance. To force a single routing protocol throughout the network would enhance the efficiency for transporting ‘dumb’ packets, but those who want to follow non-standard routes have to suffer. Having a ‘routFun’ in packet field really allows all incoming packets to ‘select’ a service routine at the node to find out the next hop without evaluation of the packet. Since the routFun itself is still lightweight, PLANet approach can be viewed as a hybrid solution while inheriting best of previous ones.

Diagnostics and Error Handling

In the traditional internet, low level diagnostics and errors are reported with ICMP. The fundamental difficulty lies in the limitation of the vocabulary the current standard has. While in PLANet, diagnostics can be crafted on-the-fly, since they are simply PLAN programs. For error handling, the PLAN program itself can take over some of the work- load since the level of abstraction has been reduced to program level as compared to packet level. Furthermore, the packet ‘handler field contains information about the service routine at source node to take care of the errors.

III PLANet Performance

Any novel idea of implementation has to undergo rigorous performance testing before claiming its success. From the very beginning of this arising approach, people have been worried about its inherent high overhead due to the program evaluation. Can PLANet attain reasonable performance, especially for common operations? Their answer is yes, which mainly comes from the following measurements. One of their excellent work is to have C bridge and Ocaml bridges as control for user space application overhead(since their PLANet implementation reside in user space at this stage) and byte-code interpretation(since PLAN needs to be interpreted before execution).

Latency

Using ‘Ping’ as testing program with different payload sizes, a consistent pattern is observed that IP always has the lowest latency and PLANet has the highest, while bridge programs are in between. The majority of the delay in PLANet comes from the PLAN program evaluations showed by the difference between PLANet and bridges. While kernel crossing certainly contributes, which is reflected in the difference between bridges and IP kernel implementation. But the latter overheads can be eliminated in the future by moving the PLANet implementation into the hardware.

Based on the raw latency measurement, they further analyzed the switching cost namely the cost per packet and cost per byte. This is another essence of their work which reveal the fact clearly that although there is not much space for improvement in terms of cost per byte, since the figures for PLANet and IP are similar, there is certainly a lot to be done for minimizing the per packet overheads. Based on the Amdahl’s law, further optimization of the PLAN program evaluation path inside each node will exert significant impact on PLANet performance.

Experiment on intermediate evaluation vs endpoint evaluation cost of PLAN packet has been carried out. Not surprisingly, the intermediate evaluation version adds a lot more overhead, because the program evaluation itself is expensive. This clear evidence leads to the idea that the majority of the active packets should only need to be transported, while only a few of them require evaluation along their path to carry out some special task such as discover new routes, reconfigure the network or dynamically changing router’s functionality etc.

Bandwidth

Throughput has been measured based on UDP like flow with 5000 packets of 1500 bytes. When there are no intermediate hops, the receiver is clearly the bottleneck for PLANect compared to the IP and C bridges which switches at the link rate. Program evaluation is the one to blame. When there are intermediate hops, the performance gets worse in PLANet case, since the switches become the bottleneck now. Interestingly, the author tried to address the overheads of byte-code interpretation by compiling the Ocaml bridge and PLANet routers into native code. Indeed, the performance of both improves, which further indicates that the PLANet switching path should be optimized.

Active Network can do more

So far the advantage of having active network has not been explored. Both levels of ‘activeness’ have been demonstrated by applying their prototype into a well defined scenario. In the first case, they have shown that the active packet can deliver instruction to active router to dynamically change their queuing police from FCFS queue to Round Robin queue, allowing well behaving sender to recover some of its bandwidth from the misbehaving flow. In the second case, network diagnostic packet-scout packet, which is simply a PLAN program performing some non-trivial computation along its path, has been used by the sender when network congestion occurs. The scout packets can return to the source eventually and set up the path for future packet switching based on its flowId, very similar to ATM circuit switching. Here a recurrent theme comes out again that the overall objective for active networks would be to provide switching for most packets with performance comparable to IP routers while achieving better overall performance by selective use of evaluated packets.

IV Strength and Limitation

Their implementation of the PLANet approach of is a concrete demonstration that building highly extensible and non-trivial active network is not only feasible, but also acceptable in terms of performance. Furthermore, it can provide additional interesting active services over legacy internet. Compared to other projects, PLANet presents 3 major advantages, that is, PLANet allows selective evaluation of active packets, which is not restricted to the endpoint; PLANet is a pure active network independent of existing internet infrastructure; PLANet performs the best.

Their studies are well done overall. They adopted very nice controls such as C bridge and Ocaml bridge to dissect the potential sources of PLANet overheads. Compiling to native code also clearly address the issue of byte code interpretation delay. The detailed analysis of per byte and per packet cost also helps pinpoint the future research direction of minimizing the switching cost in active network. The case demonstration of PLANet’s capability of providing active services really shows the bright future of active network idea.

But there are still a lot of questions about PLANet, which have not been explored in this paper, such as the important security issues and how to go for the optimization of PLANet performance except moving it from user space down to kernel, etc. From their performance fine-tuning, there is not much of exciting discoveries. In addition, their performance measurement is based on simple topology lab network, what would it be if we deployed it into the real world and how it cooperates with traditional IP routers. In the demonstration of active services, they have not address the overheads of injecting scout packets and the timing and frequency of applying these packets; and what is the overall strategy to invoke different active services, namely when to use what.

Although from this paper and other resources, PLANet idea is great in many aspects, it seems that there is still a long journey to take to optimize this approach due to its high overheads comparing to existing IP infrastructure. Given the heated racing of network technologies and user applications, whether PLANet will become reality is still in question.

1