Middleboxes and NFV: Challenges and Consolidation of Network Functions

1. 15-744: Computer Networking L-11 Middleboxes and NFV

2. Middleboxes and NFV • Overview of NFV • Challenge of middleboxes • Middlebox consolidation • Outsourcing middlebox functionality • Readings: • Network Functions Virtualization White Paper • Design and Implementation of a Consolidated Middlebox Architecture • Optional reading • Making Middleboxes Someone Else’s Problem

3. Outline • NFV Motivation • NFV challenges

4. Network “101” vs. Reality Traditional view: “Dumb” network Reality: Lots of in-network processing Appliances or Middleboxes:IDS, Firewall, Proxies, Load balancers….

5. Need for Network Evolution New applications Policy constraints Evolving threats Performance, Security, Compliance New devices

6. Middleboxes Galore! Data from a large enterprise Survey across 57 network operators APLOMB (SIGCOMM’13)

7. Key “pain points” Narrow interfaces Management Management Management Specialized boxes Increases capital expenses & sprawl Increases operating expenses Limits extensibility and flexibility “Point” solutions! 

8. Middlebox management is hard! Critical for security, performance, compliance But expensive, complex and difficult to manage

9. Vision • Why cant networking get same benefits as IT and cloud world? • Commodity hardware? • Virtualization? • Consolidation

10. Network Functions Virtualisation

11. Key idea: Consolidation Two levels corresponding to two sources of inefficiency 2. Consolidate Management Network-wide Controller 1. Consolidate Platform

12. What are the grand challenges? • High performance virtual appliances? • Isolation/coexistence • Management solutions • Fault tolerance • Vendor independence/multi-vendor

13. What’s missing? • What functions yield most benefits? • Can it really replace hardware acceleration? • Is virtualization necessary? • What novel services can be developed? • How much benefit is “enough” to motivate adoption?

14. Consolidation at Platform-Level Today: Independent, specialized boxes AppFilter Proxy Firewall IDS/IPS Decouple Hardware and Software Commodity hardware: e.g., PacketShader, RouteBricks, ServerSwitch, SwitchBlade Consolidation reduces capital expenses and sprawl

15. Consolidation reduces CapEx Multiplexing benefit = Max_of_TotalUtilization / Sum_of_MaxUtilizations

16. Consolidation Enables Extensibility VPN Web Mail IDS Proxy Firewall Protocol Parsers Session Management Contribution of reusable modules: 30 – 80 %

17. Management consolidation enables flexible resource allocation Today: All processing at logical “ingress” Process (P) Process (0.4 P) Process (0.3 P) Process (0.3 P) N3 N1 P: N1 N3 Overload! N2 Network-wide distribution reduces load imbalance

18. Can NFV/SDN help middlebox management? Web Firewall IDS Proxy Centralized Controller OpenFlow Proxy IDS … Necessity and an Opportunity: Incorporate functions markets views as important

19. SDN vs NFV • Complementary • SDN is all about “control” plane • NFV can happen w/o SDN • Natural allies • SDN enables orchestration, routing • NFV can be the “substrate” over which SDN runs

20. CoMb System Overview Logically centralized e.g., NOX, 4D Network-wide Controller General-purpose hardware: e.g., PacketShader, RouteBricks, ServerSwitch, Middleboxes: complex, heterogeneous, new opportunities

21. CoMb Management Layer Goal: Balance load across network. Leveragemultiplexing, reuse, distribution Resource Requirements Policy Constraints Routing, Traffic Network-wide Controller Processing responsibilities

22. Capturing Reuse with HyperApps HyperApp: find the union of apps to run HTTP: 1+2 unit of CPU 1+3 units of mem UDP: IDS IDS Proxy HTTP: IDS & Proxy NFS: Proxy common 3 4 HTTP UDP HTTP NFS Memory CPU 2 3 3 1 1 1 Memory CPU Memory CPU 4 1 Memory CPU Footprint on resource Need per-packet policy dependencies! Policy dependency are implicit

23. Modeling Processing Coverage HTTP: Run IDS  Proxy IDS  Proxy 0.4 IDS  Proxy 0.3 IDS  Proxy 0.3 HTTP N1  N3 N3 N1 N2 What fraction of traffic of class HTTP from N1 to N3 should each node process?

24. Network-wide Optimization Minimize Maximum Load, Subject to Processing coverage for each class of traffic  Fraction of processed traffic adds up to 1 No explicit Dependency Policy Load on each node  sum over HyperApp responsibilities per-path

25. Network-wide Optimization A simple, tractable linear program Very close (< 0.1%) to theoretical optimal

26. CoMb Platform Applications Challenges: Performance Parallelize Isolation IDS Proxy … Core1 … Core4 Challenges: Lightweight Parallelize Policy Enforcer Policy Shim (Pshim) IDS Proxy NIC Challenges: No contention Fast classification Classification: HTTP Traffic

27. Parallelizing Application Instances M1 M2 M3 M2 ✔ App-per-core HyperApp-per-core M2 M3 M1 Core1 Core2 Core3 Core2 Core1 PShim PShim PShim PShim + Keeps structures core-local + Better for reuse - But incurs context-switch • Inter-core communication • More work for PShim + No in-core context switch HyperApp-per-core is better or comparable Contention does not seem to matter!

28. Discussion • Changes traditional vendor business • Already happening (e.g., “virtual appliances”) • Benefits imply someone will do it! • May already have extensible stacks internally! • Isolation • Current: rely on process-level isolation • Get reuse-despite-isolation?

29. Conclusions • Network evolution occurs via middleboxes • Today: Narrow “point” solutions • High CapEx, OpEx, and device sprawl • Inflexible, difficult to extend • Our proposal: Consolidated architecture • Reduces CapEx, OpEx, and device sprawl • Extensible, general-purpose • More opportunities • Isolation • APIs (H/W—Apps, Management—Apps, App Stack)

30. Can we outsource all middleboxes? ✔ ✔ ✔ ✔ ✗ Bandwidth? ✗ Compression?

31. Next Lecture • Data Center Networks 1 • Readings: • Portland: Read in full • VL2: Read intro