Active Networks

1. Active Networks Introduction (What and Why) Active Network Design (How) Applications Experience Preemptive Defense

2. Traditional Networks • Header causes one of small sets of operations to be performed • Data is forwarded/dropped according to those rules Header Data Trailer

3. Active Networks • Switches/routers perform small set of ops on packets • Users can inject programs into the network • User/application specific processing

4. Capsules • Code + data • Similar to Postscript for printing Code Data

5. Motivations • User Pull • Automatically adaptive streaming • Data aggregation • Placing computation closer to user reduces latency • Industry push • Ad-hoc collection of firewalls, Web proxies, multicast routers, mobile proxies, video gateways, etc. • Replace app-specific hardware with generic, multipurpose active nodes. • If we are not careful, the network may be “activated” without providing a systematic way of upgrading services across the Internet.

6. Main high-level advantages • Adaptivity, leading to support for richer interactions than fixed protocols • Targeting of operations at specific locations within the network • Faster deployment of new services

7. Biggest AN challenges • Safety, security and resource allocation • Efficiency

8. AN Overview • Approaches • Discrete • Integrated

9. Discrete Active Networking • Processing of messages and injecting programs into network are distinct • Essentially programmable routers • Impl: program ID much like protocol ID

10. Integrated Active Networking • Capsules carry both data and programs (every message is a program) • Transient and non-transient environment • Programs may: • modify capsule • have access to external API • modify the transient and parts of non-transient environment (e.g., routing table) • schedule zero or more packets for transmission

11. Active Networks in Action

12. Programming with Capsules • Foundation Components • Active Storage • Extensibility • Interoperable Programming Model

13. Foundation Components • Serves as the API of the network • Provides access to node-specific info and services (e.g., link state info, average Qing delay, types of programs supported)

14. Active Storage (Non-transient) • Allows “soft” flows: flow states that are caches and may be disposed of if necessary • Aggregation • Pruning of multicast trees • Network management functions (e.g., SNMP)

15. Extensibility • Reduces size of programs in capsules • Enables demand-loading/caching of programs

16. Interoperable Programming Model • Must enable safe, efficient operation of mobile code • Traditional packet networks do this by standardizing syntax and semantics of packets • For AN, standardize the computation model • Instruction set • Available resources • Resource safety

17. Interoperable Programming Model(Instruction Set) • Primitives: interpreted source, intermediate language, binary (spectrum of safety vs. efficiency and portability) • For safety/protection, namespace of capsule is restricted to transient environment. • Java-like bytecode is preferred • Any number of tricks to improve performance… optimistically use source-code rep, encode multiple formats, convert to binary adaptively, demand loading (see page 12) • For portability, allow multiple models to compete, AN will support the best ones. (Common in the industry)

18. Interoperable Programming Model(Available resources) • interoperability and resource management • requires a shared view of what resources are and how they are named • Simple set of resources: BW, CPU, RAM • CPU: default allocation or trade BW for cycles • Transient storage: bound allocation for each packet, allow period garbage collection • Active Storage: soft state subject to rules of any cache • Logical resources: topology discovery, routing and network management – must have some standard class specification

19. Interoperable Programming Model(Resource Safety) • Requires authentication, delegation of authorization • Big open problem

20. Applications • Routing • Capsules can dynamically enumerate and evaluate paths at each node • Aggregation • Multicasting • Caching dynamic Web content (not as good for DB-related stuff) • Mobile computing  context aware networking • Allows for adaptive bandwidth controls (e.g., automatic caching and compression at bottlenecks, TCP snooping to improve TCP performance)

21. Experience • Caching programs and demand-loading them to reduce capsule size • Foundation Components can implement existing Internet functions to ease transition. • ANTS

22. Experience: ANTS • Capsule code tends to be “glue” for composing capabilities exposed by Active Nodes • Small set of ops: query node environment, manipulate soft store, route capsules toward other nodes • Biggest drawback: code must be signed by authority to ensure safe code • Even with central authority, Internet can evolve much faster with ANTS • Can devote small %age of node resources to uncertified packets for experimentation • No “killer app” because the best part of this is extensibility. Any killer app would be built into the base system • Breaking the cycle of requiring backward compatibility.

23. Preemptive Defense • Leon smells funny.

24. Active Networks are too slow and are not scalable. • Processing power is cheap and always increasing in speed • Recent trends in processing architecture (multi-core, highly parallel) is perfect for this environment. • Storage is cheap and ANs are not required to maintain reliable storage. • Due to AN architecture, AN performance can scale linearly with processing and storage capacity.

25. Modifying non-transient state is inherently unsafe and therefore we should not allow it. • Existing Internet infrastructure allows packets to cause state to modified (e.g., ARP, Link-state and DV routing algos, SNMP)

26. Bah! How are you going to achieve interoperability? • Hourglass approach. • Same guiding principles of IP networks

27. What about trends toward less functionality in the network? • There is no such trend. The “intelligence” has moved toward the edges, but there is still a great deal of computation in the network (e.g., firewalls, routers, proxies, caches).

28. I’m an OSI fanatic. How will this impact the OSI Reference Model poster taped to the ceiling above my bed? • ANs will preempt the layered model and replace it with a component model. • This type of transition is nothing new and has been ubiquitously performed in operating systems. • The OSI model sounded great, but had plenty of problems when applied to real-world networking.

29. Doesn’t this violate the end-to-end argument? • The end-to-end argument focuses on reliability • Teaches us that designers should not “over-engineer” intermediaries. • Concerns the placement of functions in a network, not whether the functions can be application-specific. • ANs still allow the end user to select levels of service and allow users to partition functionality between end systems and intermediaries.

30. Active networks will always be susceptible to devastating attacks. • The current Internet is far from secure from such attacks. • If you already deal with DoS attacks in the current Internet, why are you afraid of challenges in AN security?

31. This idea was proposed almost a decade ago and all you have to show for it are some research systems. Are you suggesting I buy stock in cold fusion, too? • Although cold fusion may someday become reality, Federal law prohibits me from providing investment advice without having passed the Series 7. • Absence of a widespread implementation does not negate the potential utility of the proposed concept.

32. This idea was proposed almost a decade ago and all you have to show for it are some research systems. Are you suggesting I buy stock in cold fusion, too? • Industry is resistant to change. • Biggest challenge is the wide-scale implementation and availability of safe and efficient code mobility.

33. Well, that’s one heck of a challenge—one with few good answers and no complete solutions. Tell me something that will make me believe that ANs will ever be deployed. • Only impediment to ANs is security, a ubiquitous problem • Similar problems already exist in the current infrastructure will never go away • This barrier to adoption will erode much like the shores of California: quickly in the midst of a cataclysmic event. • Soon we will run out of IPv4 addresses, and tricks like NAT will not last long. At some point, most of the existing Internet infrastructure will have to be uprooted. Why not begin the move to ANs then?