Logically Centralized? State Distribution Trade-offs in Software Defined Networks

Presentation Overview Overview Problem Description Key Tradeoffs Evaluation Summary References

Problem Physically centralized control is inadequate, it limits o responsiveness o reliability o scalability Need a physically distributed control plane on which logically centralized control plan operates o Causes tradeoffs (solution to problem becomes new problem!)  Consistency models Strongly and Eventually Consistent  how much will performance suffer? Categorize tradeoffs, simulate and measure

Questions How centralized or distributed should the network control plane be? How does distributed SDN state impact the performance of a logically centralized control application? When the underlying distributed control plane state leads to inconsistency or staleness in global network view, how much does network performance suffer?

Key State Exchange Points in SDN Dotted lines are State Exchange Points in SDN Physical Devices are grouped into domains o Ctrl 1, Ctrl 2 State flows up, control flows down NIB is updated from Physical as well as other controllers

Key Tradeoffs Staleness vs Optimality o Cost to achieve consistent state in global network view entails higher rates of control synchronization and communication Application Logic Complexity vs Robustness to Inconsistency o Example of end-to-end argument

Tradeoff #1 - Staleness vs Optimality Each controller maintains a NIB o global view of network NIB is updated by o other controllers o physical network control application performance suffers in presence of inconsistency consistent state requires higher rates of control communication

Tradeoff #2 App Complexity vs Robustness Applications can either be aware of state inconsistencies or not If they are aware, complexity of application increases o more to be aware of If they are not aware, performance suffers o take action on stale data

Evaluation - Example Application Load Balancing o Objective is to minimize the maximum link utilization in network Two Implementations o Link Balancer Controller (LBC) o Separate State Link Balancer Controller (SSLBC)

Example Application - LBC Link Balancer Controller (LBC) o Simpler of two applications o Inspired by “Load Balancing Gone Wild” o Application is presented with a global network view when certain events are triggered, application uses this view to calculate paths, the path with lowest max link utilization is chosen to assign next arriving flow and forwarding state is installed in network

Example Application - SSLBC Separate State Link Balancer Controller (SSLBC) o Application keeps fresh intra-domain physical network state from updates learned through inter- domain controller synchronization events o Potentially stale global network view is used o global network view guides each application instance to redistribute scaled fraction of its local link imbalance on a flow-by-flow arrival basis

Evaluation - Network Architecture Two co-operating controller domains Each domain has single switch Upstream traffic considered negligible Table describes link capacities servers are identical replicas fat interdomain links Load Balancer objective o minimize Root Mean Squared Error (RMSE)

Evaluation - Workloads Deterministic, controlled workload o Flow arrival rate driven by sin function More Realistic Workload o exponentially distributed flow inter-arrival times o modulate mean of exponential distribution by wave function Common o vary time interval between NOS synchronization events

Evaluation Results - How to Read the Graph 32 arrivals per timestep, fixed flow duration of 2 timesteps, total of 64 flows active Vertical line represents sync occurring lower % is better Top graph corresponds to 16 in bottom graph NOS Sync Period is how often state synched Box shows the center half of data with median marked whiskers show 95 percentiles outliers are marked 0 corresponds to balanced loads

Evaluation Results - LBC, SSLBC, Simple Workload As global network view becomes inconsistent, application performance can suffer (left graphs) awareness of underlying distributed state leads to less sensitivity to NOS staleness (right graphs) SSLBC may not perform as well with high rates of NOS synchronization as it is more conservative (0,1 in both graphs)

Evaluation Results - LBC, SSLBC, Realistic Workload SSLBC is still better!

Evaluation Summary Results o View staleness significantly impacts optimality  As global network view becomes inconsistent, application performance can suffer o Application robustness to inconsistency increases when application logic is aware of distribution Other Applications - not covered o Distributed firewalls, IDS, admission enforcement, routing, middle-box application

Questions How centralized or distributed should the network control plane be? How does distributed SDN state impact the performance of a logically centralized control application? When the underlying distributed control plane state leads to inconsistency or staleness in global network view, how much does network performance suffer?

References Logically Centralized? State Distribution Trade-offs in Software Defined Networks; Dan Levin, Andreas Wundsam, Brandon Heller, Nikhil Handigol, Anja Feldmann