1. Jennifer Rexford Fall 2010 (TTh 1:30-2:50 in COS 302) COS 561: Advanced Computer Networks http://www.cs.princeton.edu/courses/archive/fall10/cos561/ Programmable Networks

2. Today’s Passive Networks Dumb store-and-forward network –Smart end hosts implement key functions –Simple routers store and forward packets –Limited network processing (e.g., routing, forwarding, buffering, and packet scheduling) Packet header used in a simple way –Common, standardized format –Causes one of a small set of operations to occur –Packet forwarded or dropped based on those rules –Network (largely) ignores higher-layer headers Enable experimentation and innovation inside the networks?

3. Active Networks 3

4. Proposed Active Networks Packet == data + code –Smart hosts, as before –Active nodes that can execute code on the data –Active packets that carry code to active nodes Postscript analogy –Contains both your data, and the program the printer runs to print your data Active networks –allow an individual user, or groups of users, –to inject customized programs –into the nodes of the network.

5. Motivation for Active Networks High-level goal –Leverage computation in the network User pull –Automatically adaptive streaming –Data aggregation to reduce data volumes –Computation closer to users to reduce latency Industry push –Ad-hoc collection of middleboxes emerging –Replace with generic, multi-purpose active nodes –Otherwise, proliferation of active components will happen anyway, without any common framework

6. Motivation for Active Networks Big mismatch in rates of innovation –Applications change quickly (e.g., Web, P2P, IM) –The network changes slowly Deploying new network technology is hard –Delay for standardization (at the IETF) –Additional delays for vendors to implement and service providers to deploy the new technology Better to decouple services from hardware –Minimize the amount of global agreement –Load new services on demand

7. Motivating Examples Customized packet-drop policy –User watching video stream (MPEG) –Congestion leads to bandwidth limits –Drop selectively the B frames –Requires application-specific intelligence Other examples –Forward error correction: adapt to loss rate. –TCP-SYN filtering –Web caching –Reliable multicast (or any multicast) –Support for mobility

8. Enabling Technologies for Active Networks Component-based software engineering –Building blocks for composing software Code mobility (e.g,. Java) –Previously between end hosts, not network nodes –Innovation in safe and efficient code mobility Field-programmable gate arrays (FPGAs) –Enabling higher speed of packet processing Research in programming languages –And PL folks’ interest in networking

9. Two Models of Active Networks Active networks are active in two ways –Switches run code on data flowing through them –Individuals can inject programs into the network Programmable switches: discrete ANs –Separation of program loading and execution –E.g. program loading only by network operator –Packet is demultiplexed to the right program Capsules: integrated ANs –Every packet is a program, and carries its code –Perhaps in a restricted programming language

10. Three Parts to an Active Network Execution environment –Virtual machine with access to node resources –General, Turing-complete vs. restricted models Active applications –Provide an end-to-end, customized service –Load code on to the routers to program the VM Node operating system –Support multiple execution environments at once –Provide safety between execution environments

11. Example: Capsules Capsule = code + data –Extension of IP packet format Type identifies which code handles the capsule –E.g., may indicate a Java class Code runs in transient execution environment –Destroyed when the capsule evaluation ends Active storage –Capsules can leave information behind in a node’s non- transient storage for subsequent capsules External methods cached on the node

12. Security, Safety, and Performance Protection –Can my service damage yours? –Need to run code in a sandbox Resource management –Can my service consume arbitrary resources? –Need careful control over resource allocation Performance –Can my program complete quickly enough to avoid introducing excessive latency? –Need to limit the complexity of the programs –… or run them only on lower-speed links

13. Efficiency and Performance Running programs on packets –Questionable on higher-speed links –E.g., where you have just a few nsec per packet Feasible at the edge (e.g., 100 Mbps, 1 Gbps) –Firewall, NAT, shaper, proxy, intrusion detection Feasible for control plane in the core –Running routing protocols Computer architecture advances help –Faster conventional processors –Network processors and FPGAs –Multi-processor cores

14. Stepping Back Was active networks a success or failure? –General idea of computation/services in the network? –Need for a principled approach to middleboxes, and a blurring of router vs. general network node? –Specific mechanism of packets carrying code? Devil in the details –What granularity: packets vs. flows –When is code loaded: on demand vs. in advance –Who programs: user vs. network operator –What programming environment: specialized secure languages/OSes vs. commodity Linux platforms

15. Network Virtualization 15

16. Rethinking the Network Architecture The Internet is showing signs of age –Security, mobility, availability, manageability, … Challenges rooted in early design decisions –Weak notion of identity, tying address & location –Not just a matter of redesigning a single protocol Revisit definition and placement of function –What are the types of nodes in the system? –What are their powers and limitations? –What information do they exchange?

17. Hurdle #1: Deployment Dilemma An unfortunate catch-22 –Must deploy an idea to demonstrate feasibility –Can’t get an undemonstrated idea deployed A corollary: the testbed dilemma –Production network: real users, but can’t change –Research testbed: easy changes, but no users Bad for the research community –Good ideas sit on the shelf –Promising ideas do not grow up into good ones

18. Hurdle #2: Too Many Design Goals Many different system-engineering goals –Scalability, reliability, security, privacy, robustness, performance guarantees, … –Perhaps we cannot satisfy all of them at once Applications have different priorities –Online banking: security –Web surfing: privacy, high throughput –Voice and gaming: low delay and loss Compromise solution isn’t good for anyone

19. Hurdle #3: Coordination Constraint Difficult to deploy end-to-end services –Benefits only when most networks deploy –No single network wants to deploy first Many deployment failures –QoS, IP multicast, secure routing, IPv6,… –Despite solving real, pressing problems Increasing commoditization of ISPs senderreceiver 123

20. Virtualization to the Rescue Multiple customized architectures in parallel –Multiple logical routers on a single platform –Isolation of resources, like CPU and bandwidth –Programmability for customizing each “slice”

21. Overcoming the Hurdles Deployment Dilemma –Run multiple experimental networks in parallel –Some are mature, offering services to users –Isolated from others that are works in progress Too Many Design Goals –Run multiple operational networks in parallel –Customized to certain applications and users Coordination Constraint –Run multiple end-to-end services in parallel –Over equipment owned by different parties

22. Economic Refactoring Infrastructure providers: Maintain routers, links, data centers, and other physical infrastructure Service providers: Offer end-to-end services (e.g., layer 3 VPNs, SLAs, etc.) to users Infrastructure ProvidersService Providers Today: ISPs try to play both roles, and cannot offer end-to-end services

23. Enabling End-to-End Services Secure routing protocols Multi-provider Virtual Private Networks Paths with end-to-end performance guarantees Today Virtualized Network Competing ISPs with different goals must coordinate Single service provider controls end-to-end path

24. Discussion: Internet vs. Pluralism Internet architecture –End-to-end argument –Best-effort packet-delivery service –Narrow waist of IP –Separation of intradomain from interdomain Virtualized programmable networks –Complete control within a virtual network –Programmable functionality inside the network –Different (virtual) networks for different services –No “interdomain,” except for instantiating topologies