Towards an Active Network Architecture

David L. Tennenhouse and David J. Wetherall

Notes by Walter Bell, April 1998. Previous notes by Mao

Introduction

Presents the concept of an "active" network, where computation happens inside the network in addition to at the two endpoints of the communication.  Discusses some of the issues involved in how one would design and develop an active network, such as safety of the execution environment, portability of code between vastly different hardware, as well as maintaining code efficiency.

Motivation

The recent spur of interest in agent technologies (client to server code transfer), and web applets (server to client code transfer) shows that the networking community is ready for a model that bridges this dichotomy.

Lead applications are already out there that could benefit from active networks:

Advantages of an Active Network

Overview of the Network

Programmable switches

Switches perform computation on particular packets

Capsules

Every message is a program that executes in it's own transient execution environment.

Format of capsules

Capsules need to provide safe and efficient execution, as well as interoperability between many different switches

Possible program encoding techniques

Source Code - portable, safe, but size and efficiency suffer
Intermediate Code (Java style)- portable, safe, and faster than source
Binary Code- non-portable, unsafe without operating system style protection, fast, could be very small

Resource Sharing

Need to place limits on the amount of resources that a particular capsule can use (memory, transmission bandwidth, cpu, transient / active storage, logical resources)

Preserving resource safety is important, need good ways to dynamically assign resources to capsules, authentication of capsules, etc.

Discussions
"The active network approach opens a Pandora's box of safety, security, and resource allocation issues."

  1. Aren't we going a bit overboard here?
  2. Isn't the network a bottleneck in systems? Should we really be pushing more functionality into it and making the bottleneck worse?
  3. If you give people a programming language, people will use it. Postscript is a good language, but all kinds of people write horrible postscript programs that tie up printers for hours. Do we really want this happening on our switches?
  4. Resource accountability?
  5. Why not just disperse a whole bunch of computers in the network that can do this work for us? Why make a $10,000 switch into a $100,000 switch when you could just buy a whole bunch of full-fledged computers to do the work?