Towards an Active Network Architecture
David L. Tennenhouse and David J. Wetherall, MIT Telemedia, Networks &
ACM SIGCOMM 96?, (Computer Communication Review)
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
- 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.
Programming model issues:
- 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.
- 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.
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
- 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
- "...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