CoNext HotMiddlebox: FlowOS: A Flow-based Platform for Middleboxes

Mehdi Bezahaf, Abdul Alim, Laurent Mathy

Presenter: Laurent Mathy

We have middleboxes everywhere. Many of them of proprietary and difficult to upgrade. The problem of focus is here can we just expose substreams of flows and get a high level abstraction of traffic for programming and management purposes. 

bytestreams are IP bytes, a TCP byestream is just IP payload and similarly app streams only include tcp part. the goal is to get these abstraction and simplify building of middlebox functionalities. We should do so without copying data, deal with packet reordering and packet loss and duplicate packets. The module should be processing a flow sequentially and concurrently We need support flow migration and support for inter process communication. A stream is a sequence of bytes such as application data of a connection. The architecture deploys a processing routine for each NIC. In input processing we would like to handle packet reordering effects. After decoding packets we will have virtual byte streams. FlowOS packets encapsulate protocol effects. Stream Pointer APIs enables us not to deal with details of sk_buff and be agnostic to that. 

Middleboxes are run as a thread of a kernel module. Only read-only processig modules are allowed to process a flow concurrently. This makes synchronization simple and low cost. The last-stage processing modules release data to the TX handler. An example of a peice of code on top of FlowOS that simplifies programming. Early results show promising throughput on a small number of sessions.

Q) What does the first data structure achive?

A) identifies level. 

Q) Where was this implemented?

A) Linux kernel. Processing modules are just threads.

Q) Is this a static module chain in the compile time?

A) For now, yes. 

Q) Can we just focus on the problem of difficulty of accounting? 

A) You could have a simple TCP solution. But the problem is with intricacies of TCP such as sequence number etc. 

Q) Regarding end pointer, why should they be fixed at the end of packets?

A) Because we are processing packets in the buffer. The painter helps identify the boundaries in sk_buff.