# Blockchain-Assisted QoS-Aware Routing for Software-Defined Wide Area Network
## 5 Evaluation
\begin{table}
\begin{tabular}{l l} \hline Number of ISPs & 11 \\ \hline Number of cloud servers & 3 \\ \hline Number of cloud clients & 3 \\ \hline Bandwidth on each link & 10 Mbps (bidirectional) \\ \hline Average delay on each link & Between 1 ms–5 ms \\ \hline Average packet loss each on link & Between 1–5\% \\ \hline Flows for performance measurement & VolP applications (bandwidth, delay, loss) \\ \hline Application 1’s QoS (v1) and weights (w1) & Normalized v1 = [0.5, 0.2, 0.3], w1 = [0.3, 0.5, 0.2] \\ \hline Application 2’s QoS (v2) and weights (w2) & Normalized v2 = [0.3, 0.3, 0.4], w2 = [0.5, 0.3, 0.2] \\ \hline Application 3’s QoS (v3) and weights (w3) & Normalized v3 = [0.7, 0.2, 0.1], w3 = [0.3, 0.4] \\ \hline Application 4’s QoS (v4) and weights (w4) & Normalized v4 = [0.4, 0.4, 0.2], w4 = [0.6, 0.2, 0.2] \\ \hline Application 5’s QoS (v5) and weights (w5) & Normalized v5 = [0.8, 0.1, 0.1], w5 = [0.4, 0.3, 0.3] \\ \hline Controller & Ryu \\ \hline Testing tool & Iperf \\ \hline Performance metrics & Throughput, loss, delay, computation time \\ \hline \end{tabular}
\end{table} 
Table 2: Simulationparameters. Figure 5: Performance comparison of various algorithms. \[P= \begin{bmatrix}p_{1}\\ p_{2}\\ p_{3}\\ p_{4}\\ p_{5}\end{bmatrix} = \begin{bmatrix}0.3&0.5&0.7\\ 0.8&0.2&0.4\\ 0.4&0.3&0.5\\ 0.7&0.6&0.1\\ 0.5&0.3&0.2\end{bmatrix} \]  
Initial experiments indicate that, considering all QoS requirements, application 1 (i.e., VoIP application in this case study) achieves a QoS satisfaction rate of 84% with the selected routing path by the considered router using the proposed strategy, QRS. Among the applications, application 5 attains the highest QoS satisfaction rate at 93%, while the lowest satisfaction rate, measuring 78%, is observed for application 2. The satisfaction rate is significantly influenced by the availability of a routing path with the necessary QoS support, and the amount and type of applications currently supported by the router. A greater number of routing paths with the required QoS support would enable more applications to secure their QoS requirements. But it will require more computation to find the best path if there are more possible path options. In the pursuit of evaluating the feasibility of the approach to compensate Internet Service Providers (ISPs) based on service delivery and user satisfaction, a smart contract using the Solidity programming language was developed. Leveraging the Geth environment (implementation of Ethereum in Go programming language), [37] was used as a blockchain-based solution to automate and transparently execute the payment process. This smart contract utilizes the Ganache local Ethereum [38] to record and validate the amount of services provided by ISPs and automate payment transactions with ensuring a reliable and tamper-proof ledger of transactions. For the considered scenario, the incentives of ISPs were transferred through the developed smart contract, and Figure 6 suggests that the ISPs obtain more incentives when they can satisfy more QoS aspects. In this experiment, a certain monetary reward was provided to the ISP to provide support for the corresponding level of QoS satisfaction. This methodology not only verifies the viability and effectiveness of incentivizing ISPs through user satisfaction metrics, but also helps to enhance the potential benefits of blockchain technology in ensuring transparency and trust within the realm of cloud service access. Future experiments will be conducted to validate the effectiveness of the proposed framework on a larger scale.