## 4 Performance Evaluation  
### Experimental Setup  
In this subsection, we describe our experimental settings for evaluating the proposed FAURAS. Our testbed consists of an HTTP/2 server, a proxy and multiple HTTP/2 streaming clients as shown in Figure 4. The settings of the server and clients are similar to that of [20]. The server is run on a HP Windows 10 Core i7 physical machine with 8 GB of RAM and is implemented based on _Jetty_[40], while each client is a Panasonic Core i5 physical machine with 4 GB of RAM. On the server, the _DASH_js_ streaming player [41] is packaged as a web application, which will be run on the client side via a Chrome web browser. On the client side, the _Wireshark_[42] is deployed to monitor the number of HTTP responses and PUSH_PROMISE frames the clients receive.  
On the same machine as the server, an Ubuntu 18.04 LTS virtual machine with 3 GB of RAM and three cores of CPU are installed to implement the proxy and its modules. A virtual QoS Router  
Figure 4: Experiment topology.  
\begin{table}
\begin{tabular}{c c c c} \hline \hline
**Metric** & **HTTP/1.1** & **HTTP/2 2-Push** & **HTTP/2 2-Push with Overwrite** \\ \hline \(Res\) & 100 & 50 & 100 \\ \(PP\) & 0 & 50 & 99 \\ \hline \hline \end{tabular}
\end{table}
Table 3: Total number of requests and PUSH_PROMISE frames capturing on the client’s device.  
is created with the _RYU SDN_ framework [43] for monitoring and controlling the network flows between the server and clients. All traffic from the clients are transparently routed to the proxy which is deployed based on the _mitmproxy_[44]. Every time a client sends a request for the MPD file to start the streaming session, the proxy recalculates the fair share and signals the QoS Router to assign a bandwidth slice for the new client and adjust the bandwidth given for existing clients. When the proxy judges that the client's bitrate decision would cause rebuffering, it rewrites the URL in the GET request to one matching the fair bitrate and informs the client by adding a header to the response.  
In our experiment, the server provides the _Big Buck Bunny_ video with 11 versions of bitrate, i.e., \(\Re=\{99,192,285,470,656,838,1118,1401,1855,2324,2791\}\) (Kbps) as in [20]. Each version is chunked into segments of 1 s. The maximum bandwidth \(\mathbb{C}\) is fixed at 3 Mbps, which is sufficient for a client to reach the highest bitrate. As recommended in [3], the \(k\)-push value in this experiment is set to 2. On the client side, the maximum buffer level \(B_{max}\) is set to 10 s. The _FESTIVE_[21] algorithm is chosen as the client's ABR, with minor modifications to support the HTTP/2 server push mechanism and communications via HTTP headers. The FESTIVE employs the harmonic mean smoothing technique for bandwidth estimation, gradual bitrate transition, and randomized segment download scheduler for tackling the unfairness from the client side. Please note that the main focus of this paper is the performance of network-assisted solutions in solving the unfairness problem of HAS when using the HTTP/2 server push; a comparison of different ABRs will be left as future work.  
For performance comparison, in addition to the proposed FAURAS, the following methods are considered under the same settings as above:  
* **No-Proxy:** This represents the typical situation when the proxy is not activated and all clients compete fiercely for the bandwidth.
* **Reactive:** The proxy only allocates the fair bandwidth separately for every client and leaves the client's bitrate decision untouched. This corresponds to the work in [30], which is proposed for HTTP/1.1.
* **Proactive:** An implementation of the method proposed in [32], which is also for HTTP/1.1. Each client gets its own fair bandwidth given by the proxy. If a client requests a bitrate that is higher than the calculated fair value, the proxy immediately corrects it and forwards to the server.