Active Networking and End-To-End Arguments*

Abstract

design space, rather than solving the design problem. This structure provides a basis for discussion and analysis of trade-offs, and suggests a strong rationale to justify design choices. This note comments on a current design controversy that can be framed partly in terms of end-to-end arguments. One form of active networking[2], a novel category of communication network architectures, comprises attaching programs to data packets, with the intent that those programs be executed at points within the network. The purpose is to better match the behavior of the network to the requirements of the application. The question being raised is whether or not this idea directly violates an end-to-end argument. On the one hand, programmability appears to contradict the end-to-end principle that a function or service should be carried out within a network layer only if it is needed by all clients of that layer, and it can be completely implemented in that layer. 2 On the other hand, programmability may allow a network client to implement precisely the service it needs, an outcome that is consonant with end-to-end arguments. Contradiction and consonance aside, because programmability enables such a wide range of possibilities, applying end-to-end arguments in a general, yet definitive, way may be impossible. Instead, the specifics of each particular active networking idea would benefit from evaluation in light of the end-to-end principle. Programmability's Effect on Design-time Function Placement End-to-end arguments address design more than implementation and implementation more than execution—that is, they suggest who should provide the code, not which box it should run on. Moving functions and services upward in a layered design, closer to the application(s) that use them, increases the flexibility and autonomy of the application designer to apply those functions and services to the specific needs of the application. With that view, programmability in a lower layer can be seen as a means to defer design choices upwards in the layering, closer to the application, and later in time, even though the resulting functions may actually take place deep inside the network. At the same time, one can raise a concern that a general programming interface can lead to complex and unpredictable interactions among independently designed applications and independently acting users. Part of the