## 4 Evaluation of the Mechanism
### Results  
For each of the tested scenarios, 4.66 \(\pm\) 0.12 GB of UDP traffic data were generated. As can be seen in Table 1, each of the implemented scenarios has a gain compared to the baseline solution (that is, a network without the implemented mechanism). In the linear scenario, we observed the maximum amount of data transferred and achieved the highest network throughput. This result can be caused by the unique characteristics of this scenario, where, even under lower loads, the link weights experience the most substantial increase compared to all the other cases under consideration. For every examined scenario, the average delay ('Avg delay') for all flows exhibits a slight increase compared to the baseline ('pure' OpenFlow) solution. This phenomenon stems from the nature of the proposed mechanism, which actively seeks out new paths with lower levels of congestion, but these paths are longer. Consequently, the slightly extended transmission delays are a trade-off for the system's effort to identify less congested routes. The values obtained for the reduction in the number of entries (_maxFRI_) for all solutions are at a very similar level (Figure 7). It indicates a very high degree of reduction in the number of flow entries in the network core nodes P compared to the edge nodes PE. This conclusion can also be notified by observing the number of flow entries (Figure 4) in the edge nodes in relation to the average and maximum number of entries in the network core nodes (Figure 5 and Figure 6, respectively). \begin{table}
\begin{tabular}{c c c c c c} \hline \hline  & **Discrete Scenario** & **Linear Scenario** & **M/M/1 Scenario** & **M/G/1 Scenario** & **Without the Mechanism** \\ \hline Rx [GB] & \(2.22\pm 0.47\) & \(2.80\pm 0.45\) & \(2.44\pm 0.42\) & \(2.70\pm 0.41\) & \(1.79\pm 0.35\) \\ \hline Avg tput [Mb/s] & \(872.54\pm 5.6\) & \(1197.3\pm 7.7\) & \(992.7\pm 10.3\) & \(1103.2\pm 8.5\) & \(771.9\pm 8.3\) \\ \hline Avg delay [ms] & \(26.15\pm 1.01\) & \(20.76\pm 0.67\) & \(21.78\pm 1.23\) & \(19.52\pm 0.95\) & \(18.16\pm 0.60\) \\ \hline \(Rx_{\text{Gain}}\) [\%] & \(22.7\pm 0.8\) & \(58.8\pm 1.4\) & \(38.4\pm 0.9\) & \(51.8\pm 0.8\) & N/A \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Simulation results. The summarized reductions in flow entries within the core nodes, as defined by Equation (3), for all the considered scenarios are presented in Figure 8. Regardless of the simulated scenario for the link weight scheme, _CFRI_ consistently exceeds 94%. Our mechanism leverages multipath transmission. Specific applications, such as video streaming, may require strict latency limits and minimal data rate constraints. Our simulation results confirm the capability of our approach to successfully meet these criteria. In situations of link congestion, the proposed mechanism seeks out alternative paths for the smooth transmission of data. The collected results lead to the following conclusions. Our analysis was conducted with the aim of maximizing throughput while minimizing the number of entries in the flow tables. In addition, we examined the impact of selected scenarios on transmission delay. Table 1 shows that the best throughput is achieved using the linear scenario. The highest number of table entries was reached using the M/M/1 scenario. At the same time, this scenario resulted in the fewest table entries in the edge nodes (PE). The discrete scenario achieved the lowest throughput among the proposed scenarios and the highest delay. Despite the large number of flow entries, applying the discrete scenario to our mechanism allows significant flow reduction and aggregation (Figures 7 and 8). The collected results also show that the choice of the M/G/1 scenario is the best option taking into account all considered metrics. These results confirm the flexibility of the M/G/1 scenario. Using this scenario resulted in the lowest delays, very good throughput (only slightly lower than the throughput achieved with the linear scenario), and good reduction in the number of flow entries.