SDN Capacity
Calculate flow table and controller capacity requirements for a software-defined network.
About SDN Capacity
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
Worked example
With the default values below, SDN Capacity returns Controller Flow-Setup Rate of 500.0. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Flow Table Sizeminimum 1
- 32,000
- Average Flow Setup Timeminimum 0.01 ms
- 2 ms
- Flow Idle Timeoutminimum 1 sec
- 30 sec
Results
- 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
Step by step
- 1Values used
- 2Controller throughput
- 3Table churn limit
- 4Controller Flow-Setup Rate= 500.0 flows/sec
- 5Max Flow Table Capacity= 32,000 flows
- 6Max Sustained New-Flow Rate (table churn limit)= 1,066.7 flows/sec
Assumptions and limits
- The result is derived only from the 3 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 1 decimal place, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
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.