A Scalable High-Performance Active Network Node

A Scalable High-Performance Active Network Node

Paper Critique by:

San-Chu Han

Yan Xiao

Jin Zhang

Abstract

In this critique report for paper 19[1], we introduce a particular design of active network node, specifically its hardware and software architecture. After analyzing the implementation of this design, we make some comments on its major features or advantages and finally we raise some very coarse and probably immature questions on this paper’s design.

I. Introduction:

This paper critique is based upon the paper “A Scalable High-Performance Active Network Node” by Dan S. Decasper, et al. [1]. The concept of active networking emerged from discussions within the DARPA research community around 1994 and 1995 on the future directions of networking systems to address several problems plagued with today’s networks [2]. Basically, there are two approaches to realize active networks: “programmable switches” and “capsules”. The essential difference between these two approaches relies on how program code is injected into network nodes, and programmable switches are considered to be out-of-band whereas capsules are considered in-band. The programmable switch approach maintains the existing packet format, and provides a discrete mechanism that supports the downloading of programs. In contrast, the capsule approach encapsulates active miniature programs into the packets and those programs are executed at each node along their path. However recently convergence between the pure “programmable switch” and pure “capsule” approach becomes appealing and visible. The main reason and motivation for this convergence trend intuitively goes to the fact that some sort of code caching makes a lot of sense so that potential code is more application-specific than user-specific. Another important consideration to take the convergence of programmable switch and capsules approaches is due to the fact that users usually do not write their own applications but use off-the-shelf software, which allows for various optimizations in the form of caching. The authors of this paper take the convergence approach and call code blocks implementing application-specific network functions as active plugins. It describes the design of a high-performance active network node (ANN) that supports network traffic at gigabit rates and provides the required flexibility of active networking technology for automatic, rapid protocol deployment and application-specific data processing and forwarding. The research of this paper is basically based upon the their previous work of Router Plugins research platform [3] and Distributed Code Caching for Active Networks (DAN) [4]. Based upon the Router Plugins platform [3], they came up with “NoseOS”, which is an optimized version of NetBSD derived from Router Plugins architecture. As for Distributed Code Caching for Active Networks (DAN), since it became known in 1998 [4] it has matured significantly. NodeOS and DAN essentially form the software infrastructure of ANN, with DAN built on NodeOS. This paper describes the design of high-performance of ANN hardware first, and then elaborate on the software architecture of ANN, which utilized the hardware architecture and is optimized to a similar extent for high performance, especially, on how DAN is embedded into the NodeOS.

II. The ANN Hardware

The ANN hardware consists of a set of active network processing elements (ANPEs). The core of ANPE is the processing engine, which is the combination of CPU and FPGA. In this architecture, the CPU takes care of the majority of active functions applied to a packet, while the FPGA implement functions that are particularly performance-critical in hardware. Both can be programmed on the fly. The scalability and high-performance of ANN can be achieved by three techniques: a high number of processing elements compared to the number of router ports; Tight coupling between a processing engine and the network (specifically, switch backplane); Scalable processing power. What is the worthiest noting is the realization of scalability. Scalability is guaranteed through the combination of three parts: ability to configure any number of ANPEs that can be added to the ANN; a scalable switch backplane; a load-sharing algorithm that dynamically distributes active flows over the ANPEs.

Basically, more than one ANPEs can be physically placed on one ANPE card to take the advantage of load-sharing mechanism that can save switch backplane bandwidth by distributing the active flows to processing engines on the same card. Basically there are three different modes of operation of an ANPE card: process and cut-through; cut-through and diverted to other lightly-load processing engine on the same card; cut-through and diverted to another ANPE card. Usage of these different modes of operation of the individual ANPE cards leads to optimal performance and scalability of the ANN as a whole.

III. The ANN Software Infrastruture

The main design goal of the ANN software infrastructure is to provide a highly efficient data path and a flexible control path. The ANN software architecture is divided into two related parts: kernel and user space. Basically, all high-bandwith data path components are implemented in the system’s kernel, whereas all management components are implemented in the user space. Based on this principle, we partition the ANN software architecture into two layers: NodeOS and “Execution Environments” (EEs). The NodeOS represents the operating system components implementing services such as packet scheduling, resource management, and packet classification, which are independent of a specific active networking implementation. The NodeOS offers these services to the EEs running on top of it. An EE implements active networking protocol-specific processing. The author’s architecture supports two EEs, namely the ANTS EE and DAN EE. IP can be considered as another EE. In this architecture, active plugins contain code that is downloaded and installed on the node and active plugins create instances. The downloading is triggered by the occurrence of a reference in a datagram. The NodeOS components consist of the following components: Device Drivers (DD)/Layer 2 Processing, Packet Classifier (PC), Selector Dispatcher (SD), Packet Scheduler (PS), Resource Controller (RC), Plugin Control Unit (PCU) and Plugin Manager (PM).

Distributed Code Caching:

Distributed Code Caching features the following important properties: Active Plugins in Object Code; Security Addressed by User of Well-known Cryptography Techniques; Minimization of Code Download Time; Policies; Integration with Existing Network Protocols. The Dan EE consists of following components: Active Function Dispatcher (AFD); Active Plugin Loader (APL); Policy Controller (PC); Security Gateway (SG); Plugin Database Controller (PDC); Plugin Requester (PR)

IV. The Code Server and Plugin Packages

Code servers feature a database of active plugins for different software and hardware architectures. Basically, code servers are network nodes running a version of the DPMgmt. Since most of today’s router hardware lacks large mass storage, end systems similar to database servers are better suited to be configured as code servers. The code for multiple active functions can be wrapped together into one active plugin package. A download of such a package would install multiple active functions on the ANN. This is useful for strongly correlated active functions such as the four options for Ipv6 mobility support. This mechanism requires only one download cycle and one application of related functions such as security checks for the whole package. Basically, a package contains the following components: One or more active functions; Developer’s digital signature; Code server’s authentication information; Configuration information for the ANN.

V. Conclusion and Future Work

Three key components in the ANN in a gigabit environment are designed correlatively to allow scalable and high-performance active networking in a high-bandwidth environment. This system is still being implemented and several promising applications including automatic protocol deployment and application specific processing are being considered.

VI. Comments

Major features/advantages:

General and Hardware Side:

• Convergence of “Programmable Switch” and “Capsule”--Code Caching: Realization that potential capsules code is more application-specific than user-specific and the fact that users usually do not write their own application but use a set of code modules (called off-the-shelf software) written by specialists.

• High-performance of hardware considerations: High number of processing engines (elements) to keep up with link speed in a gigabit environment; tightly coupling the processing engine to the link; load-sharing to dynamically distribute active flows.

• Cut-through: The majority of non-active packets (regular IP traffic) are cut-through routed directly through the switch backplane without CPU intervention to save the valuable processing power and memory bandwidth.

• Multiple ANPEs placed on one ANPE card: load-sharing saves switch backplane bandwidth by distributing the active flows to processing engines on the same ANPE card.

• Flexible usage of different modes of operations on an ANPE card: Utilization of cut-through and load-sharing algorithm closely to evenly distribute the load among ANPEs leads to scalability and high-performance of the ANN as a whole.

Software Side:

• Highly modular and layered router software architecture could be implemented without any significant performance penalties in a way which all high-bandwidth data path components are implemented in the system’s kernel (NodeOS), whereas all management components are implemented in user space (EEs).

• Device Drivers (DDs) are modified not to implement packet queues on their own and the routines of queuing are moved to the dedicated Packet Scheduler (PS), where packet scheduling can be programmed through the PS API, thereby allowing plugins as well as the administrator to reserve resources.

• Packet Scheduler (PS)-DRR vs. FQ: a modified version of a Deficit Round Robin (DRR) scheduler which allows bandwidth reservations using filters in addition to fair queuing. A naïve fair queue would require O(log(m)), where m is the number of packets in the router, and the simulating bit-by-bit round robin (BR) requires O(log(n)) time where n is the number of flows; whereas the work complexity of DRR is only O(1).

• Active Plugins in Object Code vs. Interpretation: Using some sort of code caching techniques and active plugins in machine code promises to deliver a significant performance improvement over traditional interpretation-based capsules.

• Instance Chaining and Labeling—Selector Usage: Tag-switching type selector is used to classify the flow. Certain amount of overhead but dramatic payoff for subsequent packets for flow-oriented network traffic; other than the selector, no de-multiplexing has to be performed; soft-state nature of flow-specific information. A comment worth pointing out is that although the selector is similar to tag switching it is has only local meaning, which has no global reference.

• Caching Policing--two mechanisms: Besides developers’ setting timeouts for active plugins, the ANN administrator can also set timeouts for active plugins. The advantage of this type of settings is that they force a periodic re-fetch of specified plugins independent of a developer’s settings and such a re-fetch can be set to happen out-of-band to provide the node with the most recent plugin version independent of references in data packet.

• Active networking support can be integrated with the existing network protocols at different layers such as data link layer, network layer and transport layer. In particular the flexible and arbitrary number of Ipv6 options could be conveniently configured to integrate DAN function identifiers in the form of, say, hop-by-hop or destination option.

• Due to less overhead of UDP, instead of using TCP protocol, Plugin Requester uses UDP/IP protocol to ensure stable operation under heavy load considering the fact that bandwidth is more important than reliability.

• Taking the well-known cryptography techniques to implement security checking, specifically using MD5 one-way hashing function for generating message digest digitally signed with RSA using the developer’s private key.

• Desirable options for minimizing downloading time: probe packet, optimal code server arrangement and minimizing the distance between the ANN and the code server.

• Optimizing consideration of code servers and plugins: separating ANN NodeOS-dependent layers from the rest of the DPMgmt to port the DPMgmt to a wide range of platforms; end systems similar to database servers are configured as code servers; plugin packages downloading to minimize the number of security checks, etc.

Some questions(?):

Code Servers: In this paper code servers are dedicated, and it does not mention what and how it going to happen when a code server dies. We could take the “code server replicate approach” to guarantee availability of active plugins.

Flow-oriented application: Longer-lived packet streams (flows) are especially efficient in using the selector design since subsequent packets will benefit a lot from the selector dispatching of first few packets. However, for non-flow-oriented application, say, short-lived packet(s) the overhead introduced by this kind of per-flow instance creation and management could become comparable to the payoff.

Caching and Time out policy: One possible scenario with the current caching policy is as follows: after a particular active plugin is downloaded to the ANN, a new version of the same function would bestored in the code server database.So, when another flow comes in andANN finds a previouslyknown function identifier which points to the active plugin stored in its local cache, ANN would not fetch the updated active plugin in code server.Therefore, there is kind of mismatch for active plugins.How to deal with this problem? Maybe we could use some mechanism, say, “call back with priority”, to help the system to always fetch the updated versions of active plugins. A related problem is although the paper mentioned two settings of time out it did not indicate how long a time out would be like.

Security: Basically, the digital signature and authentication implemented in this paper is one-way checking, i.e., the clients (essentially ANNs) check the developer’s signature andthe code server’s authentication. This way, security problem is reduced to the simple policy implementation. But does the code server need to authenticate a downloading from an unknown ANN? How would the code server make sure a request of downloading active plugins is from a trusty ANN party?Probably we need to consider a two-way authentication protocol for security checking. If we take into account the two-way authenticating, the problem may becomepretty complex.

Deployment: The paper mentioned the several possibilities to integrate the active networking into the existing network protocols; however, the planned automatic protocol deployment does have some difficulties such as how cope with recompiling, etc.

References:

[1] D. S. Decasper et al., “A Scalable High-performance Active Network Node,”IEEE Network, January/February 1999

[2] D. Tennenhouse et al., “A Survey of Active Network Research,” IEEE Commun. Mag., Jan. 1997

[3]D. S. Decasper et al.,“Router Plugins – A software Architecture for Next Generation Routers,” Proc. SIGCOMM’98, Sept. 1998

[4] D. Desasper and B. Plattner, “DAN: Distributed Code Caching for Active Networks,” Proc. INFOCOM ’98, Apr. 1998