## 4 Performance Evaluation
### Evaluation Scenarios and Metrics  
Table 4 shows the experimental scenarios for assessing the performance of the proposed FAURAS and reference methods. In this experiment, each client streams a total of 200 segments from the server. Similar to existing research, a common scenario that multiple clients join together is considered, denoted as scenario #1. Specifically, the mentioned methods are tested on three subscenarios _1-A_, _1-B_ and _1-C_ with the number of clients ranging from 2 to 4, respectively. In addition, we also evaluate those methods with scenario #2 when new clients join in the middle of an existing client's session, causing the change of the fair bandwidth. A single client \(a_{1}\) firstly plays the video alone in the network, utilizing the whole fixed bandwidth for itself. After it finishes the download of the \(100^{th}\) segment, the client \(a_{2}\) joins and introduces a bandwidth gap \(\Delta C\) of 1.5 Mbps observing from the original client. This is denoted as \begin{table}
\begin{tabular}{c c c} \hline \hline
**Scenario** & **Subscenario** & **Description** \\ \hline \multirow{3}{*}{Scenario \#1} & 1-A & 2 clients join together \\  & 1-B & 3 clients join together \\  & 1-C & 4 clients join together \\ \hline \multirow{2}{*}{Scenario \#2} & 2-A & 1 client \(a_{1}\) joins first, then 1 more client \(a_{2}\) joins later \\  & 2-B & 1 client \(a_{1}\) joins first, then 2 clients \(a_{2}\) and \(a_{3}\) join together later \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Experimental scenarios. subscenario _2-A_. Another subscenario, denoted as _2-B_, is that two clients \(a_{2}\) and \(a_{3}\) join together at the same moment as above, which causes the bandwidth gap to increase to 2 Mbps. The proposal and aforementioned methods are evaluated in various aspects. The following metrics are considered in both scenarios #1 and #2:  
* Unfairness Index (_F_): Solving the unfairness problem is the main focus of this paper. The unfairness index \(F\) across all clients is calculated based on the Jain Fairness index [45] as in Equation 5. A lower value of \(F\) indicates a better performance. The unfairness performance in scenario #1 is determined by averaging \(F\) from the beginning to the end of the streaming session. On the other hand, in scenario #2, it is averaged from the time when the new clients \(a_{2}\) and \(a_{3}\) join to the network to the time when \(a_{1}\) finishes the video: \[F=\sqrt{1-\frac{\left(\sum_{x=1}^{X_{t}}{r_{x,t}}\right)^{2}}{X_{t}*\sum_{x=1} ^{X_{t}}{r_{x,t}}^{2}}}\] (5)
* Number of Rebuffering Events (_Rebuff_): Rebuffering event should be eliminated since it is the most serious video impairment that degrades the user's QoE [46]. In this evaluation, the total number of rebuffering events of all clients is collected. In scenario #2, the performances of all network-assisted methods are investigated further. Specifically, the explicit performance of client \(a_{1}\) is assessed based on the following metrics:  
* Adaptation Delay (\(\Delta t\)): As discussed in Section 3, a large adaptation delay can lead to rebuffering events. Therefore, it is necessary to reduce such delay to ensure a smooth streaming playback. \(\Delta t\) is calculated from the time when the new clients \(a_{2}\) and \(a_{3}\) join to the time when the client \(a_{1}\) achieves the fair bitrate. * Bitrate Degradation Amplitude (\(\Delta r\)): Existing research have found that viewers often react negatively to abruptl and large degradation in visual quality [36]. For this reason, the amplitude of bitrate down-switching should be minimized. In this evaluation, \(\Delta r\) accounts for the gap between the bitrate at the first time it reaches the fair value with the one right before it. * Number of HTTP Responses (_Res_) and number PUSH_PROMISE frames (_PP_): These metrics are to evaluate the ability of FAURAS and referenced methods in ensuring the HTTP/2 server push mechanism.