Summary: Active Networks

The authors address the concerns about efficiency and security that have been associated with the active network argument from its inception, and do a fairly good job of demonstrating that a careful implementation (not the current one ;) ) can perform reasonably and provide an acceptable level of safety.  Protection issues are addressed through code signing and type fingerprinting: users are prevented from running arbitrary code by using a call-by-reference approach where the pointer is an MD5 hash of the registered code chunk, and the connection between different code chunks that must share soft state is indicated via signatures.   Resource management issues are addressed much as they are in the internet of today: a combination of restrictive APIs, TTLs and general optimism about user cooperation is employed.  The performance analysis is not particularly rigorous: the prototype is slow, presumable because 1.) java is slow, 2.) copying the network stack into userland is slow 3.) their capsule approach is generally slow, and the authors attempt to separate the latencies associated with each component in order to speculate about how a kernel-mode c implementation might perform.

 What the authors fail to do, at least in my opinion, is demonstrate convincingly that there are really compelling applications for the technology, or even that it would be easy to build existing technology using this approach: I agree with Ari.  This was a fun paper to read because in spite of the argument in the introduction, it's  a good example of pure research that will never be realized in the field.  If safe, proven and on-board technologies like RED are almost universally left disabled by conservative network admins because a suboptimal equilibrium is preferable to any risk or uncertainty, it is safe to say that technology like this will never be adopted.