1. Design and Implementation of a Consolidated Middlebox Architecture (CoMb) Vyas Sekar, Norbert Egi, Sylvia Ratnasamy Michael K. Reiter, Guangyu Shi Intel Labs, UC Berkeley, UNC Capel Hill, Huawei Presenter: Giyoung Nam Some slides are brought from the author’s presentation EE807 – Software-defined Networked Computing

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

3. Era of Middleboxes Exponentially growth middlebox market Reaching the number of middleboxes to number of L3 network devices Type of applianceNumber Firewalls166 NIDS127 Media gateways110 Load balancers67 Proxies66 VPN gateways45 WAN Optimizers44 Voice gateways11 Total Middleboxes636 Total routers~900 3

4. Messy Middlebox Infrastructure Developed uncoordinated manner Acquired from independent vendors Closed system Specialized boxes One device, one functionality No unified interfaces Hard to manage No unified view or management middleboxes across the network Increases CapEx Increases OpEx 4

5. CoMb: Consolidate Middleboxes CoMb consolidates at two levels Platform – decuples the hardware and software Network management Network-wide Controller 5 Multiplexing & reusability Load distribution

6. Consolidation at Platform-Level Reduces CapEx Enables extensibility 6 ProxyFirewallIDS/IPS AppFilter Decouple Hardware and Software

7. Application Multiplexing 7 Different peak time shows a possibility of multiplexing’s benefit

8. Reusing Software Elements Low-level modules can be shared each other Enables extensibility 8 Session Management Protocol Parsers VPN Web Mail IDS Proxy Firewall

9. CoMb: Consolidate Middleboxes CoMb consolidates at two levels Platform – decuples the hardware and software Network management Network-wide Controller 9 Multiplexing & reusability Load distribution

10. Spatial Distribution Management consolidation enables flexible resource allocation 10 N1 N3 N2 Path: N1  N3 Network-wide Controller ‘s Capacity: 100 unit Incoming 150 unit Overload! Distribute loads

11. Outline Motivation Overview of CoMb Design Management layer Platform layer Evaluation & Conclusion xOMB Discussion 11

12. CoMb Management Layer Goal: balance load across network, exploit multiplexing, reuse, distribution Require three inputs AppSpec: Policy constraints for middlebox application NetworkSpec: Routing path, middleboxes’ location, traffic classification information BoxSpec: Resource requirements for each application 12 Network-wide Controller Policy Constraints Resource Requirements Routing, Traffic

13. Constrains of Management Layer Processing coverage Each middlebox application should define interested sessions Policy dependences Respect the policy ordering constraints across middlebox applications Reuse dependences Model the potential for reusing common actions 13

14. Constrains of Management Layer All applications pertaining to a given session run on the same node for a practical reason 14 IDSProxy common Footprint on resource HTTP UDP HTTP NFS 2 3 11 Memory CPU HTTP For HTTP session, IDS and Proxy must locate on a same node Need to Identify the exact sequence of applications for each session: HyperApp

15. Capturing Reuse with HyperApps 15 IDSProxy common Footprint on resource HTTP UDP HTTP NFS 2 3 11 Memory CPU HTTP = IDS & Proxy 43 Memory UDP = IDS NFS = Proxy 13 4 1 CPU Memory CPU HyperApp: find the union of apps to run HTTP HTTP: 1+2 unit of CPU 1+3 units of mem

16. Network-wide Optimization 16 Minimize Maximum Load, Subject to Processing coverage for each class of traffic  Fraction of processed traffic adds up to 1 Load on each node  Sum over HyperApp responsibilities per-path HTTP N1  N3 N1 N2 N3 IDS < Proxy 0.4 IDS < Proxy 0.3 IDS < Proxy 0.3 CPU HTTP = IDS & Proxy 43 Memory 1.2 CPU, 1.6 Mem 0.9 CPU, 1.2 Mem 0.9 CPU, 1.2 Mem 10 CPU 10 Mem load = 12% CPU, 16% Mem 9% CPU, 12% Mem 9% CPU, 12% Mem Max{Load} = 12% CPU, 16% Mem

17. CoMb Platform Layer 17 NIC Policy Shim (Pshim) Core1 Core4 IDS … … Proxy Traffic Applications Policy Enforcer Classification: HTTP IDS -> Proxy Performance Parallelize Isolation Lightweight Parallelize Fast classification

18. Parallelizing Application Instances 18 M1 M2 PShim App-per-core Core3 M3 PShim Core1Core2 HyperApp-per-core M2M3 PShim M1M2 PShim Core1 Core2 - Inter-core communication + No in-core context switch + Keeps structures core-local + Better for reuse - But incurs context-switch - Need replicas

19. CoMb Platform Design 19 Hyper App1 Hyper App2 Hyper App4 Hyper App3 Hyper App3 PShim M1M4M1M4M2M3 Q1 Q3 Q2Q4Q5 M1M5 Core 1Core 3Core 2 NIC hardware Contention-free network I/O Core-local processing Parallel, core-local Workload balancing

20. Outline Motivation Overview of CoMb Design Management layer Platform layer Evaluation & Conclusion xOMB Discussion 20

21. Implementation CoMb Controller Use CPLEX (mathematical solver for liner programming) CoMb box prototype Classification is done by NIC Policy enforcer is implemented in kernel-mode Click CoMb application Session reconstruction & protocol parser Port these logic from Bro to Click For standalone applications Enable DMA or virtual network interfaces 21

22. Reduction in Provisioning Cost 22 Consolidation reduces provisioning cost 1.8-2.5X Relative savings = Provisioning Today /Provisioning Consolidated

23. Reduction in Maximum Load 23 Consolidation reduces maximum load by 2.5-25X Relative savings = MaxLoad Today /MaxLoad Consolidated

24. Conclusion Most network evolution occurs via middleboxes Current middleboxes is inflexible and difficult to extend High CapEx, OpEx CoMb: Consolidated Middlebox Decouple software and hardware Application multiplexing Spatial load distribution Resource reuse 24

25. xOMB: Extensible Open Middleboxes with Commodity Servers James Anderson, Ryan Braud, Rishi Kapoor, George Porter and Amin Vahdat

26. xOMB: eXtensible Open Middlebox Framework for programmable middleboxes using commodity servers Focused on programmability and extensibility Provides a programmable pipeline CoMb: Per-packet processing xOMB allows byte stream level Provides low-level functionality necessary for high performance processing User defined functionality on top of basic xOMB blocks It currently working for TCP only 26

27. xOMB Architecture 27

28. Design of xOMB Server 28 Socket I/O Control Plane Connection Manager Message Reorder Buffer Client TCP Buffer Manager Backend TCP User or xOMB defined modules Pipeline Basic Functionality

29. Example of Pipeline: HTTP 29

30. Discussion Missing explanation about “reusable modules” in design Hyperapp only identifying application sequence and resource footprint Shows an opportunity of reusable modules in evaluation only How to classify traffic which has already processed from other middlebox? Identifying hyperapp requires huge pre-processing time “handful of applications” does not fit on future network Tradeoff of batching Batching packet on each hyperapp can reduce overhead of context switching Pshim (or some layer between app and pshim) needs additional buffer to store mid-stage 30

31. Load Balancing Switches Although xOMB design is for general middlebox, we will examine it with load balancing switch scenario LBS with xOMB Packet-payload granularity Additional functionalities: Re-writing HTTP 1.0 requests as 1.1 Connection collapsing 31