Active network vision and reality: lessons from a capsule-based system

[paper]

In an active network, packets carry code that is executed by the routers that handle the packet while it is in transmission. Nodes in an active network need to be able to understand and execute packet code, but it is possible to mix and match active and normal routers. Packets can therefore react to changing network conditions and choose new routing paths for themsleves. This is very much the opposite of the "dumb core" from the end-to-end argument.

ANTS is the active network system developed by the author. A "capsule" is an extended packet that has code associated with it. In their design, capsules do not actually carry code. Rather, each active node has a set list of forwarding functions that it will execute, and each capsule says which forwarding function should be used for the packet. New forwarding functions can be provided for new services; these functions can query the router about network state. They suggest that code should be certified by an overseeing authority. Code is always executed in a sandbox.

- They do not actually want to load all possible functions in all active nodes (memory constraints), nor do they want packets to actually carry the executable code (certifying the code every time would be slow). Instead, they cache the most recently seen functions. Since they expect a small number of functions to be very popular, this would be good for those popular functions. For less-popular functions, the code is requested from the last active node that the packet was at, which (hopefully?) will still have the code.

- Forwarding functions are identified by their MD5 hash. This is an old paper, so this was probably OK at the time. However, MD5 shouldn't be used anymore. Also -- at first I was concerned because a hash function alone will only provide integrity but say nothing about authenticity -- you need an HMAC if you want both. However, after thinking about it, authenticity doesn't really matter in this scenario, we really do just care about integrity.

- They duly note that active networks won't work very well when you have end-to-end encryption and your function depends on packet contents. Seems like this will be an increasingly big problem.

They do an evaluation. Their use of Java is a significant cause of poor performance; they compare a Java relay to a C relay and the C relay has a lot more throughput (4x) and much lower latency (~5x). However, processing forwarding functions doesn't add much on top of that, although it does seem like a poorly-written forwarding function could do much worse than their example forwarding function. Use of C would make it harder to sandbox the code but it is certainly still possible.

Comment: I don't think the paper explained the concept of an "active network" well. I was confused about whether the point was to use the network for arbitrary computation or to change the way routing works. I ended up reading the Wikipedia article and this GE page. I think the authors should have defined "capsule" in the introduction so that I didn't have to read the third section to understand the intro. Sections 3 and onwards are quite good, but I found the intro & background less than helpful for someone who didn't know anything about active networks.

--------------

Class Notes

- Things you might want to do in a network: app-relevant metrics; DOS prevention with capabilities; NAT address translation; media transcoders; compression/decompression.
- Many of those apps can be done with a box on either end rather than in every router.
- No killer app! However, this does sort of happen near the edges, but at the application layer.
- PROS of active networks vs application-layer services: common way of implementing services; potentially more efficient since packets stay in their "natural path"
- CONS of active networks vs application-layer services: performance (esp latency), security, isolation (if one crashes, do they all?), state