## 6 Results
### Scenario-1  
In test Scenario-1, the links connecting servers to the switch are configured with packet-loss percentages as given in Table 2. These packet losses are emulated using Linux's Traffic Control which can drop packets at a selected rate before they can reach the IP network stack. In this scenario, server \(s_{3}\) is the fastest one. However, if too many requests are sent to this server, it will increase the response times and making other links appropriate, i.e., server \(s_{1}\). Figure 4a,b depict the performance of the forwarding algorithms while handling HTTP GET and POST requests sent from the client to the back servers. The average delay (i.e., the response time) in serving files is reported. Average delays with both learning algorithms are \(\approx\)80% lower than those achieved with RR with GET requests and \(\approx\)60% lower with POST requests. The requests-loss ratios are depicted in Figure 4c,d. The request-loss is the ratio of requests not serviced by the system to the total number of requests sent by the client/(s). The request loss ratio is \(\approx\)90% better with both learning algorithms compared to RR with both GET and POST requests. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**s1** & **s2** & **s3** & **s4** \\ \hline
2 & 20 & 1 & 40 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Emulated packet-loss percentages for Scenario-1. Figure 3: Emulated HTS system with VNF providing reinforcement learning-based routing. Figure 5a,b show an increase in the average delays with SLA as a function of the load \(\lambda\) compared to Q-Learning since the SLA algorithm selects servers using a probability distribution. It takes a certain amount of time for the SLA to adjust the policy and find the best link after a change in the packet-loss configuration. However, the Q-Learning performed better than both RR and SLA. With HSLA, the learning occurred faster as each agent was limited to decide between two choices, which translates into improved performance for both the average delay and the request loss ratios in serving HTTP GET requests. With GET requests, the average delays of HSLA, Q-Learning, and SLA were \(\approx\)20%-50%, \(\approx\)20%-40%, and \(\approx\)15%-35% better than RR. HSLA was \(\approx\)10%-40% better than Q-learning, and Q-Learning was \(\approx\)2%-20% better than SLA. With POST requests, the average delays of HSLA and Q-Learning were \(\approx\)60% better than RR, whereas SLA was \(\approx\)50% better than RR. Q-learning was \(\approx\)5%-20% better than HSLA, and \(\approx\)20%-40% better than SLA. Figure 5c,d show that the request loss ratio percentages were better with all three learning algorithms than with RR. The request-loss ratios of HSLA, Q-Learning, and SLA were \(\approx\) 80%, \(\approx\)90%, and \(\approx\)60% better than RR, and Q-Learning was \(\approx\)75% and \(\approx\)55% better than SLA and HSLA when serving HTTP GET requests. The request-loss ratios of HSLA, Q-Learning, SLA were \(\approx\)80%, \(\approx\)90%, and \(\approx\)40%-75% better than RR, and Q-Learning was \(\approx\) 50%-80% and \(\approx\)10%-80% better than SLA and HSLA when serving POST requests. Figure 5: Performance measurements—Scenario-2. \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**Packet-Loss \%** & **s1** & **s2** & **s3** & **s4** \\ \hline
**First \(5\) min** & 20 & 40 & 1 & 40 \\
**second \(5\) min** & 1 & 50 & 20 & 50 \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Emulated packet-loss percentages for Scenario-2. Tables 6 and 7 show the number of times each server is selected by the algorithms while serving GET and POST requests in Scenario-2. All of the learning algorithms selected the non-optimal servers \(s_{2}\) and \(s_{4}\) a lower number of times. Q-Learning and HSLA used them a lower number of times than SLA, whereas RR used all of the servers equally. The learning algorithms chose the servers \(s_{1}\) and \(s_{3}\) almost an equal number of times since the quality of the links connecting them alternates between good and worse every 5 min.