Network Services in the Next Generation Internet Tilman

  • Slides: 36
Download presentation
Network Services in the Next. Generation Internet Tilman Wolf Department of Electrical and Computer

Network Services in the Next. Generation Internet Tilman Wolf Department of Electrical and Computer Engineering University of Massachusetts Amherst Department of Electrical and Computer Engineering

Need for Clean-Slate Network Architecture § Limitations of current architecture • Fixed TCP/IP stack

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 2

Network Virtualization § Virtualization of router system • Common hardware (“substrate”) • Coexistence of

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 3

Outline § Introduction § Network Services • Architecture • Routing with network services §

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

Flexibility vs. Manageability § Customization in network architecture • What is the right level

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 5

Network Service Architecture § New communication abstraction • Custom composition of functions along end-to-end

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 6

Related Work § Protocol stack composition on end-system (“vertical”) • Configurable protocol stacks [Bhatti

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: Open. Flow (Stanford), Po. MO (Univ. of Kentucky) § Our focus: abstractions for horizontal composition Tilman Wolf 7

Network Service Architecture § Hierarchical inter-network and intra-network design • Autonomous System abstraction •

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 8

Connection Setup § Interface to applications • API similar to Berkeley sockets • Service

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 9

Multiparty Interests § Connection setup can be influenced by multiple parties: • Sender (connection

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 10

Service Routing Problem § Interesting problem at connection setup • Determine path and select

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 11

Distributed Service Matrix Routing § Similar to Distance Vector routing • Each neighbor announces

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 12

Approximate DSMR § Use information from single service only • Matrix lists node where

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 13

Prototype Implementation § Emulab prototype • 12 Autonomous Systems • 60 nodes § Service

Prototype Implementation § Emulab prototype • 12 Autonomous Systems • 60 nodes § Service routing • Centralized within AS • Approximate DSMR between ASs § 149, 760 connections • All possible sourcedestination pairs • All possible service combinations Tilman Wolf 14

Evaluation of DSMR § Correctness • 6 of 149, 760 connections failed § Convergence

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 15

Evaluation of DSMR § Connection setup time with Distributed Service Routing Protocol (DSRP) •

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 16

Example Scenario: IPTV Distribution § Heterogeneous receivers present challenge with live IPTV • Current

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

Example Scenario: IPTV Distribution § Transcoding in network when using network service Tilman Wolf

Example Scenario: IPTV Distribution § Transcoding in network when using network service Tilman Wolf 18

Example Scenario: IPTV Distribution § Prototype implementation • Emulab simulation § Service request •

Example Scenario: IPTV Distribution § Prototype implementation • Emulab simulation § Service request • *: *>>monitor(bandwidth) >>multicast(192. 168. 1. 1, videotranscode(1080 p, 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 19

Outline § Introduction § Network Services • Architecture • Routing with network services §

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

Programmable Router § Flexibility through programmability • General-purpose processing capability in data path •

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 21

Programming of Packet Processors § Programming is challenging • Distribution of processing onto multiple

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 MPSo. C 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 22

Runtime System for Packet Processors § Adaptation of task allocation to processing resources •

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 23

Workload Representation § Granularity of representation is important • Too coarse: not easily distributed

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 implementation Tilman Wolf 24

Task Mapping Problem § Which Click element (“task”) should run on which processor? §

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 25

Task Replication § Profiling provides runtime information • Task utilization • Task processing time

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 26

Task Replication § Example: Click configuration with 23 tasks • IP forwarding and IPSec

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

Task Mapping § Simple greedy algorithm • Co-locate tasks with maximum utilization edges •

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 28

System Evaluation § Our runtime system vs. SMP Click on 4 -core Xeon •

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

What’s Next? § Trends continue • Trend towards more programmability in networks • Trend

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

What’s Next? § Question: is there a better packet processor design? • High overhead

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 31

Outline § Introduction § Network Services • Architecture • Routing with network services §

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

Conclusions § Next-generation Internet needs to meet many demands • Flexibility is key to

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 33

Acknowledgements § Graduate students • • Xin Huang Sivakumar Ganapathy Shashank Shanbhag Qiang Wu

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

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

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

Publications § Network service architecture • • § Runtime management of packet processors •

Publications § Network service architecture • • § 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 • § 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 datapath services, ” in Proc. of 16 th 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 (Co. NEXT), Madrid, Spain, Dec. 2008. 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 nextgeneration networks, ” in Proc. of The International Workshop on Next Generation Network Architecture (NGNA), Montreal, Canada, June 2009. Tilman Wolf 36