1 / 27

Design and Implementation of a Consolidated Middlebox Architecture

Design and Implementation of a Consolidated Middlebox Architecture. Vyas Sekar. Sylvia Ratnasamy. Michael Reiter. Norbert Egi Guangyu Shi. Need for Network Evolution. New applications. Evolving threats. Policy constraints. Performance, Security, Compliance. New devices.

sadie
Download Presentation

Design and Implementation of a Consolidated Middlebox Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Design and Implementation of aConsolidated MiddleboxArchitecture Vyas Sekar Sylvia Ratnasamy Michael Reiter Norbert EgiGuangyu Shi

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

  3. Network Evolution today: Middleboxes! Data from a large enterprise: >80K users across tens of sites Just network security $10 billion

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

  5. Outline • Motivation • High-level idea: Consolidation • System design • Implementation and Evaluation

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

  7. 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

  8. Consolidation reduces CapEx Multiplexing benefit = Max_of_TotalUtilization / Sum_of_MaxUtilizations

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

  10. 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 distributionreduces load imbalance

  11. Outline • Motivation • High-level idea: Consolidation • CoMb: System design • Implementation and Evaluation

  12. CoMb System Overview Logically centralized e.g., NOX, 4D General-purpose hardware: e.g., PacketShader, RouteBricks, ServerSwitch, Network-wide Controller Existing work: simple, homogeneous routing-likeworkload Middleboxes: complex, heterogeneous, new opportunities

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

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

  15. 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 N3 should each node process?

  16. 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 A simple, tractable linear program Very close (< 0.1%) to theoretical optimal

  17. CoMb System Overview Logically centralized e.g., NOX, 4D General-purpose hardware: e.g., PacketShader, RouteBricks, ServerSwitch, Network-wide Controller Existing work: simple, homogeneous routing-likeworkload Middleboxes: complex, heterogeneous, new opportunities

  18. 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

  19. 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 - Need replicas • 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!

  20. CoMb Platform Design M1 M1 M2 M4 M4 M3 Core-local processing Workload balancing Core 2 Core 3 Core 1 M1 M5 Hyper App1 Hyper App2 Hyper App4 Hyper App3 Hyper App3 PShim PShim PShim PShim PShim Q1 Q2 Q4 Q5 Q3 NIC hardware Parallel, core-local Contention-free network I/O

  21. Outline • Motivation • High-level idea: Consolidation • System design: Making Consolidation Practical • Implementation and Evaluation

  22. Implementation using CPLEX Policy Shim Kernel mode Click Extensible apps Standalone apps Network-wide Management Memory mapped Or Virtual interfaces Ported logic From Bro  Click Protocol Session 8-core Intel Xeon with Intel 82599 NIC

  23. Consolidation is Practical • Low overhead for existing applications • Controller takes < 1.6s for 52-node topology • 5x better than VM-based consolidation

  24. Benefits: Reduction in Maximum Load MaxLoadToday /MaxLoadConsolidated Consolidation reduces maximum load by 2.5-25X

  25. Benefits: Reduction in Provisioning Cost ProvisioningToday /ProvisioningConsolidated Consolidation reduces provisioning cost 1.8-2.5X

  26. 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?

  27. 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)

More Related