A purely functional approach to packet processing

Nicola Bonelli

Nicola Bonelli, Stefano Giordano, Gregorio Procissi University of Pisa

Luca Abeni University of Trento

2

Facts on Linux ●  Linux is a general purpose operating system often used

to create middleboxes o  large amount of open source software o  a feature-rich subsystem of networking

●  The kernel provides o  network stack supports a large amount of protocols o  traffic control (tc), firewall (netfilter) o  routing (iproute2), bridging o  monitoring facilities (AF_PACKET and BPF filters)

●  Open-source kernel modules o  PF_RING-DNA / Netmap (accelerated drivers) o  PFQ framework for multi-core architectures

3

Motivation ●  What’s wrong with Linux as a middlebox?

o  Components are designed to be configurable !  programmability is not fully addressed

●  only low level libraries enable tools to communicate to the kernel

o  Interoperability among heterogeneous components? !  components are statically linked to each other !  what about bridging packets that satisfy a given BPF ?

o  With no virtual machines, the configuration is system-wide !  Multiple applications can concurrently manage the networking for different

purposes?

4

Objective ●  Design a new language for programmable middleboxes

that: o  at high level enables reusability and interoperability among kernel components

!  interfaces, kernel and sockets are end-points o  is multi-thread oriented by design

!  allows concurrent execution of networking applications o  as much close as possible to NICs

●  But where to implement it? o  Use PFQ as underlying architecture

5

Why PFQ? ●  Multi-language framework

o  C, C++11-14, Haskell o  compliant with a plethora of device drivers o  line-speed with Intel vanilla drivers (14.8Mpps)

●  Flexible parallelism o  decouple software from hardware parallelism

●  Address multi-core architectures o  scale almost linearly in any possible configuration

●  Best practices of concurrent programming o  no mutexes, no spinlocks in fast data-path o  amortized atomic operations

6

PFQ/lang overview ●  PFQ/lang as a functional language

!  DLS describing networking application as a sequence of elementary operations (functions)

!  simple firewall, bridge, load balancer, etc. !  early stage of monitoring applications (dispatcher)

●  A PFQ/lang program consists of a functional composition o  takes a packet and return a packet enriched with a context

!  information about the distribution (Fanout) !  state, annotation (State) etc. !  possible side effect (IO)

7

PFQ/lang features ●  strongly typed language ●  high-order functions

o  functions that take functions as argument (i.e. conditional expressions) ●  currying

o  Used to bind arguments in user-space "  string, vectors, trivially copyable objects in C++ "  storable types, storable tuples, list in Haskell

●  immutability of data o  COW (copy-on-write)

●  deterministic garbage collector (GC) o  Value semantic with no impact on performance

8

PFQ/lang principles ●  PFQ/lang computations are defined in user-space

o  C++11/Haskell eDSL ●  AST is transferred to kernel module for a group of

endpoints o  runtime strict type-checking (to avoid kernel panic)

●  Converted into an executable data structure by a runtime linker o  structure with data and pointers to functions

●  … and executed on top of network device drivers

9

PFQ/lang current state ●  In-kernel functions are implemented in C language

o  reusability of Linux kernel functions o  about a hundred of functions ready to use o  functional library eases the implementation

●  The runtime linker is extensible o  users can add custom functions and make them available

in the DLS

●  What is missing... o  grammar parser for computations from text o  PFQ/lang native compiler

10

PFQ/lang theory (in short) ●  Fanout, State and IO can be seen as mathematical abstractions

called monads (category theory) ●  Monads are data structures that represent computations

o  extend pure functions with side effect ●  PFQ/Lang elementary operations are monadic functions

o  Action: fanout monad, IO monad and state monad.

●  Functional composition of monadic functions with the Kleisli operator

11

Monads: fanout and state ●  Fanout monad is designed to model packet dispatching

o  fanout values can be: Drop,  Pass,  Broadcast,  Steer,  Deliver  and  Dispatch  

Drop => drop the packet Pass => pass this packet to the next function Broadcast => broadcast this packet to all the endpoints of this group Deliver => send the packet to the endpoints of the given class Steer => send the packet to an endpoint by means of a hash (random) Dispatch => combination of Deliver + Steer

●  State monad is designed to model a mutable state o  the state is associated with the computation

simple state, used to mark packets o  persistent state assiciated with flows

12

IO monad ●  IO monad (+GC) is used to implement packet

forwarding o  lazy implementation

carried out after the computation is evaluated

●  Lazy means faster! o  A shallow copy per packet forwarding o  The last forward can be done without the copy o  A posteriori with lazy forwarding we can save

the last skb_clone  

13

PFQ/lang simple functions ●  Simple functions are divided into the following categories:

o  predicates: !  is_ip,  is_udp,  is_tcp,  is_icmp,  is_ip6,  is_udp6,  is_tcp6,  is_flow,  

is_frag,  is_first_frag,  is_more_frag,  has_port,  has_src_port,  has_dst_port,  has_vlan,  has_vid,  bloom  etc...  

o  combinators: !  ||,  &&,  ^^  (binary),  not  (unary)  

o  properties: !  ip_tos,  ip_tot_len,  ip_id,  ip_frag,  ip_ttl,  tcp_src,  tcp_dst,  

tcp_hdrlen,  udp_src,  udp_dst,  udp_len,  icmp_type,  icmp_code...  

o  comparators: !  >,  >=,  <,  <=,  ==,  /=,  any_bit,  all_bit  

14

PFQ/lang monadic functions ●  Monadic functions are divided into the following categories:

o  filters: !  ip,  ip6,  udp,  tcp,  udp6,  tcp6,  icmp,  icmp6,  flow,  rtp,  no_frag,  

no_more_frag,  vlan_filter,  bloom_filter,  etc.  

o  steering functions: !  steer_link,  steer_vlan,  steer_ip,  steer_ip6,  steer_flow,  steer_rtp,  

steer_net,  steer_field  

o  conditionals: !  when,  unless,  conditional  

o  others: !  kernel,  forward,  bridge,  tee,  tap,  inv,  par,  log_msg,  

log_packet,etc.  

15

PFQ/lang example Haskell: comp  =  ip  >-­‐>  forward  "eth1"  >-­‐>  log_msg  "IP  packet"  >-­‐>    

               addr  "192.168.0.0"  16    >-­‐>                                          (when’  is_icmp  log_packet)  >-­‐>  kernel  

C++11: auto  comp  =  ip  >>  forward  ("eth1")  >>  log_msg  ("IP  packet")  >>    

               addr  ("192.168.0.0",16)  >>                                            when(is_icmp,  log_packet)  >>  kernel;  

16

PFQ/lang use cases Port mirroring

forward  "eth1"  >-­‐>  kernel  

Smart Bridging        (when  is_udp  (forward  "eth1"))  >-­‐>  kernel  

       tap  "eth2"  is_rtp  >-­‐>  kernel    

Load Balancer steer_flow  

ip  >-­‐>  steer_link  

17

PFQ/lang use cases Stateless Firewall

(when  has_port  22  &&  !address("131.114.0.0",  16)  drop)  >-­‐>  kernel  

when  (bloom  16  ["192.168.0.1",  "192.168.0.2"  ...])  kernel  

Monitoring (early stage application)

conditional  is_rtp  (class  0  >-­‐>  steer_flow)  class  1    

18

Performance Speed test: 10Gb link, 64B packets, Xeon 6 cores x5650 (Nehalem) @2.67Ghz, 16G Ram + Intel

82599 10G (Debian Wheezy)

19

Performance Conditional: (when is_tcp steer_flow) bridge: tap is_udp “eth2”

20

Performance speed test: comparisons of different computations

21

PFQ wiki and download

http://www.pfq.io

https://github.com/pfq/PFQ/wiki