# SDN-OpenFlow Topology Discovery: An Overview of Performance Issues
## 3 Recent SDN Topology Discovery Performance Studies
### Flow Table Management Algorithms  
As we mentioned earlier in the section of switches discovery in SDN technology, the adoption of switch discovery depends mainly on the data and instructions of those flow tables. Each OpenFlow in each switch contains at least one flow table and a set of flow entries within that table. These flow entries contain matching fields, counters, and instructions to apply to matched packages. Typically, it will have more than one flow table, so it is important to note that matching starts from the first flow table and may continue with additional pipeline flow tables. The packet will first start in Table 5 and check these entries based on priority. It will match the highest priority first (e.g., 200, then 100, then 1). If the stream needs to continue to another table, the go-to instruction tells the package to go to the table specified in the instruction. Therefore, improving the technique of dealing with tables will improve the performance of the entire network. The researchers attempted to improve the mechanism of flow tables in the process of topology discovery. Whereas SD-OpenFlow uses TCAM memory to store flow tables, it is very expensive and has a limited size. Thus, the number of flow entries that can be accommodated is limited, therefore, the researchers tried to optimize the flow schedule to take full advantage of it. Moreover, a comparison of these proposals is provided in Table 5 as well. \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**Proposal** & **Methodology** & \begin{tabular}{c} **Controller Placement** \\ **Mode** \\ \end{tabular} & **Operation Mode** & **Goals** \\ \hline [PERSON] et al. [89] & \begin{tabular}{c} Flow entry \\ compression \\ \end{tabular} & Reactive & Traffic engineering & \begin{tabular}{c} Maximize the utility of \\ flow tables \\ \end{tabular} \\ \hline [PERSON] et al. [90] & \begin{tabular}{c} Dynamic hard timeout \\ allocation \\ \end{tabular} & Reactive & LRU & \begin{tabular}{c} Maintain unpredictable \\ flow for a limited \\ period \\ \end{tabular} \\ \hline [PERSON] et al. [91] & \
\begin{tabular}{c} Dynamic idle and hard \\ timeout based on traffic \\ pattern to reduce \\ overhead \\ \end{tabular} & Reactive and Proactive & LRU &
\begin{tabular}{c} Improved the restricted \\ flow table \\ \end{tabular} \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Comparison of flow table management to improve OpenFlow performance. Timeout mechanism is one of the techniques used by the SDN-Controller to calculate the lifespan of the forwarding entry in the switch flow table. When no packet matches an item during its timeout period, the entry is ejected from the flow table, making room for fresh arriving packets [89]. There are now two methods for installing the timeout mechanism in the OpenFlow SDN-Controller: idle and hard timeout. Typically, the OpenFlow SDN-Controller configures each stream's flow entry with a preset idle timeout value in seconds. However, when it comes to packet inter-arrival time, the flow table has enough room to accommodate all flows, such a timeout number may provide superior performance. In [90], the authors consider a dynamic allocation of hard timeout for identified and unidentified flows. The goal is to maintain unidentified flow for a limited period while also maintain the identified flows. This is accomplished by studying packet traces to determine the nature of each packet's arrival and then modifying the hard timeout accordingly. When a flow table's load is exceeded, expires Least Recently Used (LRU) is utilized to remove an entry with a maximum timeout. Even when the strategy has succeeded in maintaining identified flows, the challenge of a bad entrance removal scheme remains. LRU is not an ideal eviction method for SDN since it is a packet-driven method that can only be executed in theory but may not be suitable with OpenFlow in action.