Presentation on theme: "Department of Electrical and Computer Engineering Tilman Wolf Department of Electrical and Computer Engineering University of Massachusetts Amherst Network."— Presentation transcript:
Department of Electrical and Computer Engineering Tilman Wolf Department of Electrical and Computer Engineering University of Massachusetts Amherst Network Services in the Next- Generation Internet
Tilman Wolf 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
Tilman Wolf 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?
Tilman Wolf 4 Outline Introduction Network Services Architecture Routing with network services Packet processing systems Runtime management Conclusions
Tilman Wolf 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
Tilman Wolf 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
Tilman Wolf 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
Tilman Wolf 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
Tilman Wolf 9 Connection Setup Interface to applications API similar to Berkeley sockets Service specification determines sequence 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)
Tilman Wolf 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
Tilman Wolf 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
Tilman Wolf 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
Tilman Wolf 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-last service to that node Repeat for all services Upper bound on path
Tilman Wolf 14 Prototype Implementation Emulab prototype 12 Autonomous Systems 60 nodes Service routing Centralized within AS Approximate DSMR between ASs 149,760 connections All possible source- destination pairs All possible service combinations
Tilman Wolf 15 Evaluation of DSMR Correctness 6 of 149,760 connections failed Convergence time Service matrices converge Time increases with network size Approximate DSMR Works well for small number of services Inefficiency grows with number of service path length of approximation over optimal route
Tilman Wolf 16 Evaluation of DSMR Connection setup time with Distributed Service Routing Protocol (DSRP) Compared to TCP Setup time less than 2× longer Evaluation summary Routing with service constraints can be solved efficiently Distributed algorithm is scalable when using approximation
Tilman Wolf 17 Example Scenario: IPTV Distribution Heterogeneous receivers present challenge with live IPTV Current solution: overlay with transcoding on end-systems
Tilman Wolf 18 Example Scenario: IPTV Distribution Transcoding in network when using network service
Tilman Wolf 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?
Tilman Wolf 20 Outline Introduction Network Services Architecture Routing with network services Packet processing systems Runtime management Conclusions
Tilman Wolf 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 high level of parallelism Network services on packet processor
Tilman Wolf 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.
Tilman Wolf 23 Runtime System for Packet Processors Adaptation of task allocation to processing resources Runtime profiling to obtains usage statistics Task mapping to adapt to current requirements Current focus: processing (not memory)
Tilman Wolf 24 Workload Representation Granularity of representation is important Too coarse: not easily distributed Too fine-grained: scalability problem Good balance: Click modular router Directly translatable into imple- mentation
Tilman Wolf 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 of inter-processor transfers Leads to packing problem Computationally hard to solve Our approach Simplify problem by creating tasks of equal size
Tilman Wolf 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
Tilman Wolf 27 Task Replication Example: Click configuration with 23 tasks IP forwarding and IPSec as network services
Tilman Wolf 28 Task Mapping Simple greedy algorithm Co-locate tasks with maximum utilization edges When processor “full” then switch to next Runtime adaptation Update profiling information Update replication Update mapping Update NP configuration
Tilman Wolf 29 System Evaluation Our runtime system vs. SMP Click on 4-core Xeon For various scenarios we observe up to 1.32x higher throughput
Tilman Wolf 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?
Tilman Wolf 31 What’s Next? Question: is there a better packet processor design? High overhead for managing packet processing context Hardware support for context management Processor core sees simple instruction and memory address space Question: correct service composition semantics? How can service specifications be verified or composed automatically? Can enumeration of all service properties be avoided?
Tilman Wolf 32 Outline Introduction Network Services Architecture Routing with network services Packet processing systems Runtime management Conclusions
Tilman Wolf 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
Tilman Wolf 34 Acknowledgements Graduate students Xin Huang Sivakumar Ganapathy Shashank Shanbhag Qiang Wu Sponsors National Science Foundation Intel Research Council
Tilman Wolf 35 email@example.com http://www.ecs.umass.edu/ece/wolf/
Tilman 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.Service-centric end-to-end abstractions in next-generation networks 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.Design of a network service architecture 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.A scalable distributed routing protocol for networks with data- path services 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.Run-time support for multi-core packet processing systems 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.Evaluating dynamic task mapping in network processor runtime systems 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.On runtime management in multi-core packet processing systems 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.