Calculate flow table and controller capacity requirements for a software-defined network.
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.
Controller throughput
controller_flows_per_sec = 1000 / flow_setup_time_ms
Table churn limit
max_sustained_new_flows = flow_table_size / idle_timeout_sec
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.
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.
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.