## 4 Evaluation  
We evaluated the proposed strategy in a network constructed by the Docker network ([[https://www.docker.com](https://www.docker.com)]([https://www.docker.com](https://www.docker.com))), which has a topology that is the same as that of the Abilene network, as shown in Figure 2. We created real Docker networks as subnets, and imported Docker containers from image shtsai7/server as routers. Three different real-life Abilene backbone network traffic datasets were used as input traffic data. The baseline routing protocol was OSPF, which is the dominant intra-domain routing protocol. The network was simulated with Docker. Eleven Docker containers were created to simulate the eleven routers in the Abilene network. For each of the Docker containers, one Docker network was created for the Internet connection with the subnet name of 170.*.0.0/16. Fourteen Docker networks were created to simulate the connections between routers in the Abilene network, and they belonged to subnet 10.1*.0/24. In each Docker container, Quagga [[https://www.quagga.net](https://www.quagga.net)]([https://www.quagga.net](https://www.quagga.net)) was used to configure OSPF in each router in the network. The goal of this evaluation experiment is to attempt answering the following questions:  
* _Is the proposed PSI able to predict when one path's situation is steadily better than the other (in terms of latency), in different extreme situations? In other words, how often is path_ i's congestion situation indeed worse or better than path_ j (_i.e._, \(L_{i}(\Delta t_{n})>/<L_{j}(\Delta t_{n})\)) when their indicators are 1 and 0, respectively, and to what extent was the channel situation improved by the PSI indicator. * _How consistent is the predication, or in other words, what is the frequency of path swaps, or in yet another way to put it, how long does it last between the indicator swaps in extremely congested situations when the latency difference between paths oscillate._ To answer these two questions, the following metrics were used:
* **True/False rate**, which means the rate when the PSI has correctly predicted the congestion situation between the current path and the backup path, including, when the PSI is 1, the latency of the current path is indeed larger than the backup one, and when PSI is 0, the latency of the current path is smaller than the backup one. * **Latency difference**, defined by the difference between the latency of the path selected by OSPF and the latency of the backup path \(=L_{i}(\Delta t_{n})-L_{j}(\Delta t_{n})\), used as an indicator of the congestion comparison of the two paths. There are two main approaches to measure the latency: RTT, which is the time overhead for a packet to travel from source node to the destination and back, and Time for The First Byte (TTFB), which is the time overhead from the source to the destination node. In this paper, RTT is used like in most other works. As the latency testing tool, _ping_ is used in this paper. Although there are some limitations of _ping_, (for example, _ping_ works on ICMP packets but not TCP/UDP packets, and the former might have lower priority than the later in real-life backbone networks, and thus experience different latencies, which in turn results in inaccurate measurement), but in our experiment that was run on a Docker network simulated on one laptop, the ICMP and TCP/UDP packets shared the same priority; thus we argue that the latency difference is not an issue for the results demonstrated. \begin{table}
\begin{tabular}{c c} \hline \hline
**Parameter** & **Value** \\ \hline \(\theta\) & 0 ms \\ \hline \(\Delta t\) & 5 s \\ \hline \(T\) & 15 s \\ \hline \(\theta_{s+}\) & 2 \\ \hline \(T_{s+}\) & 3 \\ \hline \(\theta_{s-}\) & 2 \\ \hline \(T_{s-}\) & 3 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Parameters used in Experiment 2. Accuracy improvement**, which denotes when the PSI turns to 1, the increment in percentage of the times when the latency of the current path is indeed larger than that of the backup one.