Towards an Active Network Architecture

David L. Tennenhouse and David J. Wetherall, MIT Telemedia, Networks & Systems Group
ACM SIGCOMM 96?, (Computer Communication Review)

One-line summary

Return path noise in CATV networks is dominated by "noise funneling" (addition at cascade amps) and noise sources inside subcriber homes that can be only partially attenuated, and will be reduced if <500 subscribers are on one segment. Return path characteristics suggest that FDMA or FDMA/TDMA hybrid will be better choice than CDMA or pure TDMA for MAC on this shared backchannel.

Main ideas

Replace passive data packets with active "capsules" encoding programs and data. This is generalization of user-injected programs to its logical extreme.
Architectural effect is to raise the level at which network ineroperability is realized, from IP to application level.
This is a good time for large-scale investigation of this approach, because traditional OSI layering is showing cracks due to obsolete SW/HW assumptions/limitations. E.g. OSI underemphasizes upper-layer interoperability, network tunneling, and app-specific behavior at the network layer or below, all of which are flourishing in popularity now.

Requirements:

Foundation Components: executable format, API for capsule's runtime.
Active storage: capsules can leave persistent state at each node they visit, for use by subsequent capsules.
Extensibility: capsules can extend the programming environment on a visited node, leaving methods for use by subsequent capsules.

Programming model issues:

Mobility/portability: use high-level scripting language, intermediate bytecode, or "fat" capsule binaries. Expect that all three will occur in practice.
Safety, security, accountability/authentication: weak arguments given, primarily based on safe-Tcl and Java and some handwaving abou crypto.
Resource allocation at nodes: garbage collection, CPU limiting, bandwidth limiting, naming constraints. References to some existing language-based work and promise to leverage IETF namespace work, but nothing concrete.

Comments/Flaws

Good example of taking an idea to its logical extreme; some convincing arguments that some kind of investigation is warranted, but several things are glossed over:

Many routers already have their hands full. Do we have to put compute farms at every router to accommodate capsules?
"Most capsules will not require sophisticated resource models": maybe so, but requires careful API for specifying minimum necessary resources. Compare Java: "require awt" even when only 1 or 2 classes ar needed.
"...ability to trade computation against bandwidth may be useful to encourage, for example, compression prior to transmission on low bandwidth links." Not a single citation is provided for this even though a lot of work has been done.
"...our use of active technologies within the network is novel": same criticism. Lots of proxies out there at multiple levels, including ours, anonymizer, Zenel, etc.

Back to index