# Blockchain-Assisted QoS-Aware Routing for Software-Defined Wide Area Network
## 5 Evaluation  
One of the key challenges in Software-Defined Networking (SDN) is efficiently routing flows through the underlying network and, in this research, the performance of the proposed routing algorithm (QRS) was evaluated against an already existing QoS-aware routing algorithm using the Mininet emulator [30] and the RYU controller [31]. The Mininet emulator allows to simulate a network of virtual switches, hosts, controllers, and links and the RYU SDN Controller provides application program interfaces (APIs) for creating new controls for data flows. Generally, the underlying network is represented as a directed graph G = (V, E), where V is the set of nodes/switches and E is the set of links. Each link (u, v) in E is associated with a link cost C(u,v), based on the obtained link-state information. The primary difference among the algorithms is in how they determine C(u,v). For a QoS-aware routing algorithm, widest-shortest path routing (WSR) [5,32] is considered a state-of-the-art routing algorithm that first selects the widest path group that matches the bandwidth availability constraint, and then, from this group, it picks the path that offers the shortest path (Algorithm 4). The algorithm iteratively selects the next router in the path with the maximum available bandwidth and maintains a record of predecessors for each router to enable path reconstruction. Once the destination is reached, the final shortest path is reconstructed by tracing backward from the destination to the source using the predecessor information and reversing the traced sequence to form the complete path. In fact, WSR can be considered as an OSPF extension [16] to network flow routing considering bandwidth and number of hops. The goal was to measure the performance of the existing routing algorithm in the context of SDN-based networks and compare it with QRS. Here, three important network QoS performance metrics, i.e., throughput, packet loss, and path computation time, were considered to compare the performance of the algorithms. Throughput is the total data transfer rate of the accepted flows of the considered application and this is the sum of the demands of the accepted flows. Packet loss measures the percentage of packets lost relative to the packets sent by the accepted flows. Path computation time is the total time taken by the routing algorithm to find the path from the source to the destination. To measure the performance, an experiment was conducted for a specific case scenario and with a few key QoS factors (namely, bandwidth, delay, and data loss) relating to data traffic preferences of an application. A network topology based on the Internet2 Abilene backbone network topology [34] (as shown in Figure 4) was also considered for the evaluation. The customized topology consists of 11 ISPs and each of the ISPs is also assumed to act as an SDN domain controller (i.e., connected with the SDN root controller and connected with the blockchain framework). The bidirectional connection between the ISPs was considered to have a capacity of 10 Mbps with a random delay between 1 ms and 5 ms, and with a random packet loss expressed as a percentage between 1 and 5 (as summarized in Table 2). The scenario included three cloud-based servers (providing VoIP services) connected with corresponding ISPs--S3, S4, and S5--and the three different clients were also connected through the ISPs--S0, S1, and S2. For each of the routing algorithms, network performance was monitored to effectively find a path for the flows between the randomly chosen client and server. The Iperf [35] tool was used to generate the VoIP workload between the client and server in this experiment and the average performance information of multiple runs was measured accordingly. VoIP applications are very much sensitive to delay, jitter, and packet loss [36], and this type of application requires more weights on them to reduce the delay and loss during the routing of its flow.