Challenges in Implementing an ESP Service

Abstract

Abstract. Although active network services have been widely studied, the task of mapping these services and algorithms onto actual network hardware presents an additional set of challenges. For example, high-end routers and switches are designed to handle as many interfaces delivering packets at wire speed as possible; in such an environment decentralized processing, pipelining, and efficient synchronization are crucial for good performance. At the low end (e.g. small routers/firewalls for the home), cost and flexibility are paramount; such systems are often structured as a general-purpose processor running modular software. Thus, the two environments are different and have different goals and objectives. We present a case study based on a representative active service called Ephemeral State Processing (ESP) that highlights many of the issues that arise when mapping services to real hardware. We discuss engineering considerations for ESP in both low-end uniprocessor and higher-end network processor scenarios, and present performance measurements from both implementations.

A practical bytecode interpreter for programmable routers on IXP network processors

“…Most of the research activities to run active code on network processors so far have focused on building custom services by chaining pre-installed and operator-approved modules [1,2,3]. In [4], the authors present a prototype of the Ephemeral State Processing (ESP) router on IXP1200 network processors, where end-systems may only use a restricted number of operations that are performed on the router state store. Our work is clearly a derivative of this work where we replace pre-defined operations by a bytecode interpreter.…”

“…In [4] the authors illustrate this principle on an IXP1200 network processor. With at most 10 5 packets per second, each allowed to create 2 ESS entries that last for 10 seconds, a 46MB ephemeral store never gets full.…”

“…Given that routers export a hint on the depth of output queues, we can program packets that drop themselves if the router appears congested, making room for "more important" data in the same flow 4 . WASP also offers the flexibility to detect losses between any successive WASP routers and to prepare state so that such losses are reported back to the source by e.g.…”

“…The initial implementation of ESS on IXP was borrowed from [4] and was accessed through two opcodes (lookup and insert) that mimics statements val = get(key) and put(val, key) found in the pseudo-code of ESP functions. In previous work on x86 architecture [17], we explored various ways to optimise ESS accesses to compete with the performance of ESP.…”