SDN Capacity Calculator
Estimate SDN flow table capacity and controller flow-setup throughput.
Inputs
Maximum number of flow entries the switch's flow table can hold (from datasheet, e.g. TCAM size)
Time for the controller to compute and install a new flow rule
How long an inactive flow entry remains before being evicted
Controller Flow-Setup Rate
500.0flows/sec
Max Flow Table Capacity
32,000flows
Max Sustained New-Flow Rate (table churn limit)
1,066.7flows/sec
Step by step
Values used
Flow Table Size = 32,000; Average Flow Setup Time = 2 ms; Flow Idle Timeout = 30 sec
Controller throughput
controller_flows_per_sec = 1000 / flow_setup_time_ms
Table churn limit
max_sustained_new_flows = flow_table_size / idle_timeout_sec
Controller Flow-Setup Rate
= 500.0 flows/sec
Max Flow Table Capacity
= 32,000 flows
Max Sustained New-Flow Rate (table churn limit)
= 1,066.7 flows/sec
How it works
An SDN switch's flow table has a fixed capacity (often TCAM-limited to tens of thousands of entries), which caps how many concurrent flows it can enforce rules for. Separately, the SDN controller has a flow-setup throughput determined by how long it takes to compute a path and push a new rule — dividing 1000ms by the per-flow setup time gives flows/sec. Whichever of these two is lower becomes the effective bottleneck: a huge flow table is wasted if the controller can't populate it fast enough during a traffic surge, and a fast controller is wasted if the table fills up and starts evicting active flows.
Formulas
Controller throughput
controller_flows_per_sec = 1000 / flow_setup_time_ms
Table churn limit
max_sustained_new_flows = flow_table_size / idle_timeout_sec
Frequently Asked Questions
Why does flow idle timeout affect the maximum sustained new-flow rate?
Flow table entries are evicted after a period of inactivity (the idle timeout), so at steady state the table can only accept new flows as fast as old ones expire and free up space — a shorter idle timeout churns the table faster, allowing more new flows per second before hitting a capacity wall, while a longer timeout holds entries longer and lowers the sustainable new-flow rate.
What happens when the controller is the bottleneck, not the flow table?
New flows queue waiting for the controller to compute and install their rules, adding latency to the first packet of each new flow (the classic SDN 'first-packet penalty') — under a sudden burst of new connections (e.g. a DDoS or flash crowd), this can cause visible delay or packet loss even though the flow table itself has free capacity.
How can I increase effective SDN capacity?
Reduce controller-side flow-setup latency (proactive rule installation, wildcard/aggregate rules instead of exact-match per-flow rules, distributed or hardware-accelerated controllers), or reduce flow table pressure by shortening idle timeouts for short-lived flows and using longer timeouts only for genuinely long-lived flows.