Microboxes: High Performance NFV with Customizable, Asynchronous TCP Stacks and Dynamic Subscriptions

Group meeting presentation of CANLAB in NTHU

Transcript

1. 1 Communications and Networking Lab, NTHU 1 Guyue Liu, Yuxin Ren, Mykola Yurchenko 2018 SIGCOMM Microboxes: High Performance NFV with Customizable, Asynchronous TCP Stacks and Dynamic Subscriptions Speaker: Chun-Fu Kuo Date: 2020.10.22 簡報連結 https://docs.google.com/presentation/d/15yOfBvY2iQ8EC4dXrGOH2yWTbmC7Y1GghB88xFB2r78/edit?usp=sharing
2. Communications and Networking Lab, NTHU Outline ▪ Introduction ▪ Problem Formulation ▪ System Model ▪ Proposed Method ▪ Implementation ▪ Evaluation ▪ Conclusion ▪ Pros and Cons 2
3. Communications and Networking Lab, NTHU Introduction ▪ A kinds of performance-enhancing proxy ▪ Improve end-to-end performance ▪ Pretends to be the opposite endpoint of the connection in each direction ▪ Typical system used in satellite system ▪ High latency ▪ Different protocol 3 TCP Split Proxy
4. Communications and Networking Lab, NTHU Introduction ▪ A technique to reconstruct TCP byte stream ▪ For those who needs to know complete information which scatter in many packets ▪ Often used in middlebox, like web proxy ▪ Analysis, compress, forward, etc. 4 TCP Splicing
5. Communications and Networking Lab, NTHU Introduction ▪ LSO is a technology used in NIC ▪ To offload the processing of TCP/IP stack from OS to NIC ▪ E.g., checksum calculation, IP fragmentation, TCP segmentation ▪ Similar concept ▪ Large receive offload (LRO) ▪ Generic segmentation offload (GSO) ▪ TCP Offload Engine (TOE), TCP segmentation offload (TSO) 5 Large Send Offload (LSO)
6. Communications and Networking Lab, NTHU Introduction ▪ A technology used in NIC ▪ Distribute received packet processing across multiple CPU cores ▪ Use hash mechanism (like 5-tuple) ▪ Increase cache hit ratio 6 Receive Side Scaling (RSS)
7. Communications and Networking Lab, NTHU Introduction ▪ A messaging pattern in software architecture ▪ Includes publisher, subscriber, broker ▪ Famous project ▪ Apache Kafka ▪ RabbitMQ 7 BTW, famous NFV project Open Source MANO also uses Kafka Publish–Subscribe Pattern
8. Communications and Networking Lab, NTHU Introduction
9. Communications and Networking Lab, NTHU Introduction Monolithic Pipeline ▪ Pros: ▪ Low latency (since only func call) ▪ Cons: ▪ Not easy to accelerate specific NF ▪ Security, privacy issue ▪ Example: ▪ BESS, mOS ▪ Pros: ▪ Each NF runs in single process or container ▪ NFs of different provider can chain together easily ▪ Cons: ▪ High latency with long chain ▪ Example: ▪ Microboxes, OpenNetVM, ClickOS Focus on packet forwarding, not higher level protocol stack
10. Communications and Networking Lab, NTHU Problem Formulation duplicated stack processing Pipeline Architecture
11. Communications and Networking Lab, NTHU Problem Formulation ▪ Layer-2/3 ▪ Require no TCP state ▪ Need R/W packet header ▪ TCP Splicer ▪ Need R/W TCP header (for forwarding) ▪ E.g., L7 LB needs to analyze HTTP request after 3-way handshake ▪ TCP Split Proxy ▪ Need byte stream R/W (for compress) 1 1 Common NF TCP Processing Type ▪ TCP Monitor ▪ Need TCP reconstruction, flow state
12. Communications and Networking Lab, NTHU Problem Formulation ▪ Standard pipeline processing ▪ Each NF is bound on a dedicated core 1 2 Consistency Challenges - 1 P1 = Packet 1 P2 = Packet 2 P3 = Packet 3
13. Communications and Networking Lab, NTHU Problem Formulation ▪ Single consolidated stack (instead of on each NF) ▪ Secure method 1 3 Consistency Challenges - 2 P1 = Packet 1 P2 = Packet 2 P3 = Packet 3
14. Communications and Networking Lab, NTHU Problem Formulation ▪ High efficiency ▪ But may have consistency problem (later packet overwrite stack state) ▪ Workaround: state snapshot 14 Consistency Challenges - 3 P1 = Packet 1 P2 = Packet 2 P3 = Packet 3
15. Communications and Networking Lab, NTHU Problem Formulation ▪ Ideal model ▪ But may have consistency problem (later packet overwrite stack state) ▪ And may have race condition ▪ Solution: lock, transaction 15 Consistency Challenges - 4 P1 = Packet 1 P2 = Packet 2 P3 = Packet 3
16. Communications and Networking Lab, NTHU System Model 16 μStack
17. Communications and Networking Lab, NTHU System Model 17 μEvents
18. Communications and Networking Lab, NTHU Proposed Method ▪ Generated by protocol stack or NF ▪ To trigger needed protocol, application layer to process packets ▪ Transmitted by Microboxes event management system ▪ Microboxes Controller is in charge of publish, subscribe ▪ Can be categorized by flow ▪ Each Event is based on another event (apart from the base: EVENT) 18 μEvents
19. Communications and Networking Lab, NTHU Proposed Method ▪ Hierarchy message format accelerates communication ▪ Event/PKT inherits the data structure of EVENT ▪ Event/FLOW is for those who only need to be notified the start/end of a flow (don’t care about other packet) ▪ Each event has an unique event ID 19 μEvents - Base Event Types
20. Communications and Networking Lab, NTHU Proposed Method ▪ When NF starts, it subscribe needed event and provides callback function ▪ If NF subscribe X, it can also parse the information of X/Y (Subscription/load balancing flexibility) 20 μEvents - Base Event Types
21. Communications and Networking Lab, NTHU Proposed Method ▪ We know… ▪ Cache needs full TCP endpoint termination (It could be the full cache record is finish) ▪ IDS doesn’t need any TCP processing 21 μStacks - Base Event Types
22. Communications and Networking Lab, NTHU Proposed Method ▪ Even with modular design, μStack must be built upon existing μStack (To prevent duplicated operation) ▪ When NF finishes processing, it sends corresponding message back to μStack 22 μStacks vs μEvents
23. Communications and Networking Lab, NTHU Proposed Method ▪ Maintain a registry of NFs and the event types ▪ High level logic specifying how publishers and subscribers are interconnected (like SDN controller) ▪ Each NF, μStack module register its message type to controller ▪ When NF modifies the packet or μStack state, it specifies the change in publication ▪ This enables controller to determine which NF can run in parallel 23 Controller
24. Communications and Networking Lab, NTHU Proposed Method ▪ Composed of 1 or more μStack modules & multiple NFs ▪ 2 Examples are in speaker’s notes 24 Application
25. Communications and Networking Lab, NTHU Proposed Method ▪ Asynchronous stack snapshot ▪ Add snapshot of stack in event message ▪ Almost each header in snapshot, but byte stream uses pointer with append-only ▪ Parallel Events ▪ Controller links several NF’s subscription to splitter like NF ▪ After splitter collects all the response and merge them, it propagates result to next stage ▪ Modifying Packets and Stack State ▪ Event-based API for NF to modify (via μStack), which prevents race condition ▪ Parallel Stacks 25 Asynchronous, Parallel Processing
26. Communications and Networking Lab, NTHU Proposed Method ▪ Different flows need different μStack ▪ Some stacks allow to be adjusted on each flow ▪ μStacks build on each other to provide progressively more complex processing ▪ The Microboxes TCP stack is broken into the following μStack: ▪ Network Layer ▪ Layer 2/3 determine what flow the arriving packets are, where to go ▪ Maintains minimal state flow stats (e.g., packet count, flow status tracking) ▪ Publish PKT, FLOW event 26 Customizing μStack Modules
27. Communications and Networking Lab, NTHU Proposed Method ▪ TCP Monitor ▪ Seek to track the TCP state at both client & server side ▪ Allow monitor NF to 1. Reconstruct a bidirectional bytestream 2. Observe TCP state transitions ▪ Ex: stateful firewall doesn’t allow full termination or arbitrary transformation ▪ Subscribe to PKT event from the Network Layer ▪ Produce events including DATA_RDY (when TCP state change) 27 Customizing μStack Modules
28. Communications and Networking Lab, NTHU Proposed Method ▪ TCP Splicer ▪ For proxy-type middlebox ▪ Redirect a TCP connection after handshake has been established ▪ Ex: HTTP proxy might observe the contents of a GET request ▪ before selecting a server and forwarding the request ▪ By extending the TCP Monitor stack, without requiring full TCP endpoint ▪ Subscribe to PKT/TCP of TCP Monitor to know connection initialization ▪ Splicer responds with a SYN-ACK to finish 3-way handshake with client ▪ Then publish FLOW_REQ event to NF ▪ NF responds with FLOW_DEST contains new destination IP ▪ Splicer initiates a new TCP connection with destination IP 28 Customizing μStack Modules
29. Communications and Networking Lab, NTHU Proposed Method ▪ TCP Endpoint ▪ Export events similar to a socket API ▪ By extending TCP Monitor to contain full TCP logic ▪ E.g., congestion control, retransmission ▪ It’s a new opportunity to deploy many types of NF ▪ E.g, cache server, IoT analysis server at edge cloud 29 Customizing μStack Modules
30. Communications and Networking Lab, NTHU Proposed Method ▪ TCP Split Proxy and Bytestream NFs： ▪ Most complex NF types perform transformations on the bytestreams ▪ The author calls this Bytestream NF ▪ Requires 2 TCP connection (for client, server) ▪ Allow redirection (like TCP Splicer stack), and byte stream transformation ▪ By extending 2 TCP Endpoint stack ▪ DATA_RDY message type is used when incoming or outgoing data ready ▪ Used by Proxy μStack and Bytestream NF 30 Customizing μStack Modules
31. Communications and Networking Lab, NTHU Implementation ▪ Based on OpenNetVM ▪ Provide shared-memory based communication ▪ NFs run as separate process or container ▪ An IO management layer for starting/stopping NFs ▪ Use RSS (Receive Side Scaling) ▪ To prevent any concurrent updates to shared cache lines 31
32. Communications and Networking Lab, NTHU Implementation 32 Microboxes Architecture
33. Communications and Networking Lab, NTHU Implementation 33 Middlebox App Implementation
34. Communications and Networking Lab, NTHU Evaluation ▪ E5-2660 v3 @ 2.6GHz CPUs (2 * 10 cores) ▪ RAM: 160 GB ▪ NIC: Dual-port Intel X520 10Gb ▪ Ubuntu 14.04, kernel 3.13.0-117-generic ▪ DPDK v16.11 ▪ Web server: Nginx 1.4.6, Benchmark: Apache Bench 2.3 34 Environment
35. Communications and Networking Lab, NTHU Evaluation 35 Throughput
36. Communications and Networking Lab, NTHU Evaluation 36 Scalability CPU Cores
37. Communications and Networking Lab, NTHU Evaluation 37 Sequential Latency
38. Communications and Networking Lab, NTHU Evaluation 38 Sequential vs. Parallel Processing
39. Communications and Networking Lab, NTHU Conclusion ▪ Goal ▪ Eliminate redundant processing across service function chain ▪ Make management more flexible ▪ Method ▪ Use publish/subscribe-based API for NFs ▪ Result ▪ Improve latency, throughput, flexibility ▪ Get at least 30% improvement against HAProxy ▪ Compare to mOS, Microboxes has better performance isolation and security level 39
40. Communications and Networking Lab, NTHU ▪ Pros ▪ Novel μStack consolidation stack processing ▪ Event hierarchy benefit different NF to share state ▪ Bytestream append-only saves memory usage ▪ Cons ▪ Modify existing NFs to Bytestream NF could need lots of work Pros & Cons 40 Similar works: 1. OpenBox (SIGCOMM 2016) 2. mOS (OSDI 2017) 3. SpeedyBox (ICDCS 2019) 4. Performance Contracts (NSDI 2019)