this part struck me as not quite right:
> Active Networking reduces the chances that your packets (and if
> there's
> shared code, someone else's packets) actually reach their destination.
> When a packet's path is affected by some code carried in the packet,
> the chances that the packet will reach the destination is reduced
> considerably. Programs are buggy, and there is still no effective way
> to prove the correctness of a program.
This seems to assume away the possibility that active networks could
actually *increase* the odds that your important data makes it to the
destination by making intelligent decisions about what to drop, what to
keep, what to re-packetize, what to transcode, what to add FEC to, etc. It
seems like making these decisions intelligently could decrease buffer
occupancy, decreasing loss rates, and actually help your flow *and*
everyone else's get their data to the destination.
And it seems that the gains from doing this (maybe decreasing loss rates
by a few %?) could outweigh the costs of reduced reliability (increasing
IP forwarding outages). At least in theory... ;-)
Of course one could argue that a few well-chosen differentiated service
bits might get you most of what you want here, without sacrificing much
reliability at all...
neal
---------- Forwarded message ----------
Date: Mon, 23 Mar 1998 16:03:58 -0800
From: savage@cs.washington.edu
To: tom@cs.washington.edu
Cc: cardwell@cs.washington.edu, vahdat@cs.washington.edu
Subject: FW: Active Nets and the E2E Argument
> -----Original Message-----
> From: Craig Partridge [SMTP:craig@aland.bbn.com]
> Sent: Monday, March 23, 1998 8:55 AM
> To: end2end-interest@ISI.EDU
> Subject: Active Nets and the E2E Argument
>
>
> Bob Braden suggested I forward this to E2E.
>
> It's an editorial that we're putting together for IEEE Network's
> special
> issue on Active Networks (to go with a Georgia Tech editorial on the
> same topic).
>
> Craig
>
> *********************************************************************
> *********************************************************************
>
> Active Networking and the End-To-End Argument
>
> C. Partridge, T. Strayer, B. Schwartz and A. Jackson
>
> Active Networking is a new communications paradigm for data networks.
> While some uses of active networking have shown promise, the general
> utility of Active Networking is still (widely) questioned. In this
> essay,
> we seek to evaluate Active Networking in the context of the End-To-End
> Argument. In particular, in what parts of the networking stack does
> the End-To-End Argument tell us that Active Networking is useful,
> and where does the End-To-End Argument say that Active Networking is
> a bad idea? We argue that Active Networking could have a place in
> every network layer, except the internet layer, where the End-To-End
> Argument strongly suggests Active Networking is a bad idea.
>
> The End-To-End Argument is a system design principle, intended to help
> determine where to place services in a subsystem. The argument states
> that a function or service should be implemented in a subsystem only
> if the service can be completely implemented in that subsystem, or if
> by
> partially implementing the service in the subsystem, the subsystem
> substantially improves the performance of other parts of the system.
> The classic example of such a tradeoff is checksums for data transfer.
> If an application is to ensure that a data transfer successfully took
> place,
> it must checksum the data at both ends and check the result. However,
> we
> can use a less expensive checksum if lower layers, especially the
> media
> access layer, does a CRC to protect against layer-specific errors.
>
> The End-To-End Argument has often been generalized to a layered
> environment: a
> communications layer should not try to offer services that only a
> higher
> layer can implement completely, unless the incompletely offered
> service is
> a clearly useful performance enhancement.
>
> Active Networking is a research program that seeks to place programs
> in
> packets and then have those programs executed at some or all of the
> network
> nodes that the packets traverse. The exact function of the program
> varies depending on which Active Networking researcher one talks to.
> For example, the program may be run at each node to determine how the
> packet should be routed (i.e., the packet and program are
> indistinguishable).
> Or the program may be used to augment the packet service, for example
> by
> setting up a special forwarding service that subsequent packets may
> use.
>
> Both practices can be used to implement the same service. For
> instance,
> consider flow setup. Each packet in the flow could carry a program
> (presumably the same in all cases) which implements the flow's
> forwarding
> choices for its packet. Or, the first packet in the flow could
> deposit
> a program in each router in the flow's path, and subsequent packets
> could
> simply call the program to be forwarded according to the flow's
> choices.
>
>
> User Operator
> +----------------------+ +--------------+
> | Application |-| Management |
> +----------------------+ | |
> | Transport |-| Subsystem |
> +----------------------+ | |
> | Internet |-| |
> +----------------------+ | |
> | SubNetwork |-| |
> +----------------------+ | |
> | Data Link |-| |
> +----------------------+ +--------------+
>
> Figure 1: Internet Stack
>
> The evaluation is done in pieces. We separate the data processing
> stack (the five layers on the left) from the management subsystem and
> examine each in turn, asking the following two questions:
>
> 1. Does adding a programmable environment at layer N (or to the
> management
> subsystem) enhance performance of the layers above N (or the
> management
> subsystem and layers it manages)?
>
> 2. Does adding a programmable environment at layer N allow us to
> eliminate
> the need to support functions at layers above N? (I.e., taking the
> End-To-End Argument in reverse, can we show the function is now
> implementable without the higher layers' involvement?).
>
> The easiest layer is the application layer. Active Networking has
> been
> a feature of the application layer for several years. The most
> notable
> example is Java, where applets and their data are exported to a remote
> machine, which runs the applet until it is completed or terminated by
> the user. But other work, such as CORBA, Linda,
> and Remote Evaluation, has also demonstrated the tremendous value of
> integrating programs with application data at the application layer.
> Fundamentally, the triumph of moving programs make it possible to move
> the program to its data, rather than the other way around. In response
> to the two thought questions, we can comfortably say that Active
> Networking
> enhances performance for higher layers (in this case, the user), and
> may
> relieve the user of some burdens like trying to figure out which
> system
> supports the graphics routines needed to display their data (since we
> can now export those routines to the user's system).
>
> The transport layer is a more confusing case. The transport layer
> would
> clearly benefit from programmability. Programmers often bemoan the
> limited set of communications paradigms that current transport
> protocols
> offer. And there is a design theory, known as Application Layer
> Framing (ALF),
> that argues that applications are better placed than transport
> protocols
> to determine how their data should be packetized and transmitted over
> the network. So Active Networking could allow the transport layer
> to enhance the performance of the application layer.
>
> However, as we better understand the problems of sharing a
> network's capacity fairly among transport protocol users, it has
> become
> clear that we need to constrain transport protocol behavior to certain
> behavioral norms. In particular, transport protocols' reactions to
> congestion
> need to meet certain constraints. How to impose behavioral norms on a
> program is an open question, and until it is solved, adding
> programmability
> to the transport protocol potentially violates the End-To-End
> Argument.
> In particular, a programmable transport layer could enhance
> higher-layer
> performance, but could also require new functionality at higher and
> lower
> layers to ensure that buggy or malicious transport layer programs do
> not violate transmission rules. In short, while we answered yes to
> our first thought question, we must ruefully answer no to the second.
>
> The most serious conflict between the End-To-End Argument and Active
> Networking comes in the internet layer. The purpose of the internet
> layer
> is to achieve universal connectivity and communication between an
> arbitrary
> number of heterogeneous devices. The difficulty is that it is hard
> to find a way that Active Networking could enhance this service, while
> very
> easy to find ways that Active Networking harms this service.
>
> Active Networking reduces the chances that your packets (and if
> there's
> shared code, someone else's packets) actually reach their destination.
> When a packet's path is affected by some code carried in the packet,
> the chances that the packet will reach the destination is reduced
> considerably. Programs are buggy, and there is still no effective way
> to prove the correctness of a program. When the delivery of a packet
> depends
> on code execution at each node in the route, the packet is at the
> mercy of
> poorly implemented, damaged, or out-of-version execution environments.
> Since
> the code can use any of thousands of variables as conditionals in
> determining a delivery path, every communications path is therefore
> unique. If your packet's program doesn't work, then only you have the
> necessary knowledge to debug your mix of programs and data to figure
> out why. At the same time, the damage that a buggy program,
> say one that copies packets at each node, can inflict has been
> magnified
> and made harder for network operators to stop.
>
> Adding programmability to routing and forwarding is potentially very
> powerful,
> but to what end? So far, no one has identified a performance
> enhancement (e.g.,
> custom routing) that could not be achieved via other means. So no
> unique
> new functionality is being added. So no unique new functionality is
> being
> added, while considerable complexity is being introduced that other
> layers will have to be modified to manage.
>
> Oddly enough, as we go further down the networking stack, to to the
> lowest
> two layers, the subnet and link layers, Active Networking looks like a
> winner again. Especially packets that deliver programs for later
> execution
> and we can use
> programs to reconfigure our communications devices. For example,
> suppose
> that when a modem dialed into a modem bank, the first step was to
> download
> the code to run the appropriate signaling protocol. No need to figure
> out if the modem and modem bank both ran the same type of 56Kbps
> signaling,
> the modem would automatically run whichever type the modem bank used.
> The modem industry already operates in this fashion, albeit more
> crudely,
> by shipping code to update modems to new standards.
>
> One can envisage even more sophisticated systems in which a PCMCIA
> card
> with a 4-wire connector can plug in, download the appropriate MAC
> layer
> protocol, such as 100 Mb/s Ethernet (either BaseT or AnyLAN), a modem
> protocol, or FDDI, and proceed to transmit and receive packets. The
> interface could effectively shield higher software from worrying about
> what network it is running over, and effectively eliminate the need
> for
> much configuration software. (Note that putting code in every packet
> doesn't work well here - we do not want devices booting a new MAC
> layer
> to receive each packet). Looking to our two questions, adding
> programmability
> to the subnet and link layers has the potential to both enhance
> performance
> (reducing the user's need to update hardware) and eliminate some
> higher
> layer functions.
>
> Finally, there is the network management system. Here programmability
> is also a tremendous win. In today's network management systems,
> management
> centers frequently poll devices for data, and then examine the data to
> detect
> problems. This practice is very inefficient; in most cases, the
> polled data indicates there are no problems, indeed usually not even a
> change
> in conditions, and we have used valuable network bandwidth to learn
> that
> nothing has changed. A better approach is to occasionally send a
> program
> to each device, and only have it return information about changes. An
> even better approach might be to download a program in the device that
> watches for certain misbehaviors, and reports back if it sees them.
> Today's network management system was chosen because of fears in the
> late
> 1980s that programmable systems would be too complex. Now that we
> better
> understand programmable systems, there seems no good reason not to
> make
> network management programmable. Programmability enhances performance
> and allows us to eliminate needless work by sending the program to the
> data it needs to observe.
>
> One of the interesting results of this exercise is that it indicates,
> yet
> again, that the internet layer is special. All other layers could
> benefit,
> at least somewhat, from putting programs in packets. But the
> simplicity
> that ensures interconnectivity, the fundamental feature of the
> internet layer,
> resists the complexity that programmability brings.