Network Services in the Next-Generation Internet

1. Network Services in the Next-Generation Internet

2. Need for Clean-Slate Network Architecture • Limitations of current architecture • Fixed TCP/IP stack • Hardware implementation of forwarding • Extensions are “hacks” • Firewalls, intrusion detection systems,network address translation • Need for new network architecture • Support for more heterogeneity • End systems: cell phones, PDAs, RFID tags, sensors • Routers: wireless infrastructure, ad-hoc networks • Support for new networking paradigms • Data access: content distribution, content addressable networks • Protocols: multipath routing, network coding

3. Network Virtualization • Virtualization of router system • Common hardware (“substrate”) • Coexistence of multiple virtual networks • Specialized networks deployed as separate protocol stacks (“slices”) • Programmability in data plane • Deployment of new protocols through software • Questions • How to deploy new functionality in empty slice? • Per-connection functionality and network-wide functionality • How to manage processing resources in substrate?

4. Outline • Introduction • Network Services • Architecture • Routing with network services • Packet processing systems • Runtime management • Conclusions

5. Flexibility vs. Manageability • Customization in network architecture • What is the right level of flexibility? • Two extremes • ASIC implementation of IP router • All packets are handled the same way • No flexibility • Active networks • Packet processing can be programmed • Too much flexibility – very difficult to manage • Our approach: balanced combination • Set of well-defined protocol processing features (“network services”) • E.g., reliability, security, scheduling, … • Custom combination of services provides flexibility

6. Network Service Architecture • New communication abstraction • Custom composition of functions along end-to-end path • expressed as sequence of “network services” • Benefits • End-system application can choose most suitable features • Network can control placement of services • Programmable routers implement network services

7. Related Work • Protocol stack composition on end-system (“vertical”) • Configurable protocol stacks [Bhatti & Schlichting, SIGCOMM 1995] • Configurable protocol heaps [Braden, Faber & Handley, CCR 2003] • NCSU SILO project [Dutta et al., ICC 2007] • Custom network processing (“horizontal”) • Active networks [Tennenhouse & Wetherall, SIGCOMM 1996] • Modular routers: Click [Kohler et al., TOCS 2000] • Programmable routers and network processors • Substrate systems • Router virtualization: VINI (Princeton), SPP (Washington University) • Forwarding substrate: OpenFlow (Stanford), PoMO (Univ. of Kentucky) • Our focus: abstractions for horizontal composition

8. Network Service Architecture • Hierarchical inter-network and intra-network design • Autonomous System abstraction • Match with administrative boundaries of Internet • Control plane • Connection setup • Routing algorithm • Data plane • Forwarding • Packet processing

9. Connection Setup • Interface to applications • API similar to Berkeley sockets • Service specification determinessequence of requested services • Example: *:*>>compression(LZ)>>decompression(LZ)>>192.168.1.1:80 • Connection to 192.168.1.1 port 80 • Compression (Lempel Ziv) on path • Options • Parameters necessary for service (e.g., LZ) • Constraints service placement (e.g., sending LAN, receiving LAN)

10. Multiparty Interests • Connection setup can be influenced by multiple parties: • Sender (connection to destination) • Receiver (e.g., use of proxy) • Network service provider (e.g., monitoring) • Explicit addition of services

11. Service Routing Problem • Interesting problem at connection setup • Determine path and select nodes to perform service • How can a node decide best path? • Better to perform service locally? • Better to defer to downstream node? • Which direction to route connection? • Assumption: single cost metric • Otherwise NP complete • Centralized solution • Global view necessary • Limited scalability • Distributed solution • Dynamic programming

12. Distributed Service Matrix Routing • Similar to Distance Vector routing • Each neighbor announces cost of best path to each destination • Each node adds cost to neighbor and picks best router (Bellman-Ford) • Distributed Service Matrix Routing (DSMR) • Expand vector to include service: “service matrix” • Periodic service matrix exchange • Service matrices stabilize eventually • Each node can determine best path • Handle service locally OR • Send to neighbor with lowest cost • Challenge: each service combination requires columns in matrix • Exponential growth of matrix with number of services

13. Approximate DSMR • Use information from single service only • Matrix lists node where service is performed • Routing of multiple services • Allocate best node for last service • Find best path for second-to-lastservice to that node • Repeat forall services • Upper boundon path

14. Prototype Implementation • Emulab prototype • 12 Autonomous Systems • 60 nodes • Service routing • Centralized within AS • Approximate DSMRbetween ASs • 149,760 connections • All possible source-destination pairs • All possible servicecombinations

15. path length of approximation over optimal route Evaluation of DSMR • Correctness • 6 of 149,760 connections failed • Convergence time • Service matrices converge • Time increases with networksize • Approximate DSMR • Works well for small numberof services • Inefficiency grows with number of service

16. Evaluation of DSMR • Connection setup time withDistributed Service RoutingProtocol (DSRP) • Compared to TCP • Setup time less than 2× longer • Evaluation summary • Routing with service constraints can be solved efficiently • Distributed algorithm is scalablewhen using approximation

17. Example Scenario: IPTV Distribution • Heterogeneous receivers present challenge with live IPTV • Current solution: overlay with transcoding on end-systems

18. Example Scenario: IPTV Distribution • Transcoding in network when using network service

19. Example Scenario: IPTV Distribution • Prototype implementation • Emulab simulation • Service request • *:*>>monitor(bandwidth)>>multicast(192.168.1.1,videotranscode(1080p,H.264)>>monitor(bandwidth)>>192.168.2.17)>>*:5000 • Also prototyped on real router system • Cisco ISR with AXP • Single core processor insufficient • How to design a good packet processing system?

20. Outline • Introduction • Network Services • Architecture • Routing with network services • Packet processing systems • Runtime management • Conclusions

21. Programmable Router • Flexibility through programmability • General-purpose processing capability in data path • Packet processing in software • High-performance processing hardware • E.g., network processors • Scalability through highlevel of parallelism Network services on packet processor

22. Programming of Packet Processors • Programming is challenging • Distribution of processing onto multiple processors • Run-to-completion model often not feasible • Limited instruction store on embedded packet processors • Contention for shared data structures • System components on MPSoC are tightly coupled • Simple code, but repetitiveness amplifies small problems • Typical solution: offline optimization • Simulation to identify performance bottlenecks • Manual adjustment • Code, thread and processor allocation, memory management • Repeat • Offline optimization cannot handle dynamic environment • Change in network traffic, network services, slice allocation, etc.

23. Runtime System for Packet Processors • Adaptation of task allocationto processing resources • Runtime profiling to obtainsusage statistics • Task mapping to adapt tocurrent requirements • Current focus: processing (not memory)

24. Workload Representation • Granularity of representationis important • Too coarse: not easily distributed • Too fine-grained: scalability problem • Good balance: Click modular router • Directly translatable into imple-mentation

25. Task Mapping Problem • Which Click element (“task”) should run on which processor? • Challenges • Different task “sizes” (in terms of processing requirements) • Different task utilization • Communication cost ofinter-processor transfers • Leads to packing problem • Computationally hard to solve • Our approach • Simplify problem by creatingtasks of equal size

26. Task Replication • Profiling provides runtime information • Task utilization • Task processing time • Compute: “work” per task • work = (utilization) × (processing time) • Replicate tasks with highest work • Replication reduces utilization • Reduced utilization reduces work • Benefits or replication • Task work more balanced • Simplifies mapping problem • Larger number of tasks • Allows scaling to large number of processors

27. Task Replication • Example: Click configuration with 23 tasks • IP forwarding and IPSec as network services

28. Task Mapping • Simple greedy algorithm • Co-locate tasks withmaximum utilizationedges • When processor “full” then switch to next • Runtime adaptation • Update profiling information • Update replication • Update mapping • Update NP configuration

29. System Evaluation • Our runtime system vs. SMP Click on 4-core Xeon • For various scenarios we observe up to 1.32x higher throughput

30. What’s Next? • Trends continue • Trend towards more programmability in networks • Trend toward more embedded cores per chip • Trends towards system usability • Cisco QuantumFlow (40 cores, 4 threads) programmable in ANSI-C • Question: homogeneous or heterogeneous MPSoC? • Homogeneity simplifies programmability • Hardware accelerators perform better • How to find balance in next-generation Internet?

31. What’s Next? • Question: is there a better packet processor design? • High overhead for managingpacket processing context • Hardware support for contextmanagement • Processor core sees simpleinstruction and memoryaddress space • Question: correct service composition semantics? • How can service specifications be verified or composed automatically? • Can enumeration of all service properties be avoided?

32. Outline • Introduction • Network Services • Architecture • Routing with network services • Packet processing systems • Runtime management • Conclusions

33. Conclusions • Next-generation Internet needs to meet many demands • Flexibility is key to avoid ossification • Network services implement new features • Routing with services is important control-plane problem • Distributed Service Matrix Routing provide effective solution • Programmable routers provide packet processing platform • Runtime system for network processors necessary for adaptation • Mapping of processing tasks to hardware resources • Exciting time for networking research • New network architecture and applications • “Clean slate” designs allow for creative contributions

34. Acknowledgements • Graduate students • Xin Huang • Sivakumar Ganapathy • Shashank Shanbhag • Qiang Wu • Sponsors • National Science Foundation • Intel Research Council

35. wolf@ecs.umass.edu http://www.ecs.umass.edu/ece/wolf/

36. Publications • Network service architecture • Tilman Wolf, “Service-centric end-to-end abstractions in next-generation networks,” in Proc. of Fifteenth IEEE International Conference on Computer Communications and Networks (ICCCN), Arlington, VA, Oct. 2006, pp. 79-86. • Sivakumar Ganapathy and Tilman Wolf, “Design of a network service architecture,” in Proc. of Sixteenth IEEE International Conference on Computer Communications and Networks (ICCCN), Honolulu, HI, Aug. 2007. • Xin Huang, Sivakumar Ganapathy, and Tilman Wolf, “A scalable distributed routing protocol for networks with data-path services,” in Proc. of 16th IEEE International Conference on Network Protocols (ICNP), Orlando, FL, Oct. 2008. • Shashank Shanbhag and Tilman Wolf, “Implementation of end-to-end abstractions in a network service architecture,” In Proc. of Fourth Conference on emerging Networking EXperiments and Technologies (CoNEXT), Madrid, Spain, Dec. 2008. • Runtime management of packet processors • Tilman Wolf, Ning Weng, and Chia-Hui Tai, "Run-time support for multi-core packet processing systems,"IEEE Network, vol. 21, no. 4, pp. 29-37, July 2007. • Qiang Wu and Tilman Wolf, “Dynamic workload profiling and task allocation in packet processing Systems,” in Proc. of IEEE Workshop on High Performance Switching and Routing (HPSR), Shanghai, China, May 2008. • Xin Huang and Tilman Wolf, "Evaluating dynamic task mapping in network processor runtime systems," IEEE Transactions on Parallel and Distributed Systems, vol. 19, no. 8, pp. 1086–1098, Aug. 2008. • Qiang Wu and Tilman Wolf, “On runtime management in multi-core packet processing systems,” in Proc. of ACM/IEEE Symposium on Architectures for Networking and Communication Systems (ANCS), San Jose, CA, Nov. 2008. • Qiang Wu and Tilman Wolf, “Runtime resource allocation in multi-core packet processing systems,” in Proc. of IEEE Workshop on High Performance Switching and Routing (HPSR), Paris, France, June 2009. • Service processor design • Qiang Wu and Tilman Wolf, “Design of a network service processing platform for data path customization,” In Proc. of The Second ACM SIGCOMM Workshop on Programmable Routers for Extensible Services of TOmorrow (PRESTO), Barcelona, Spain, August 2009. • Verification of service composition • Shashank Shanbhag, Xin Huang, Santosh Proddatoori, and Tilman Wolf, “Automated service composition in next-generation networks,” in Proc. of The International Workshop on Next Generation Network Architecture (NGNA), Montreal, Canada, June 2009.