FAURAS: A Proxy-based Framework for Ensuring the Fairness of Adaptive Video Streaming over HTTP/2 Server Push

HTTP/2 video streaming has caught a lot of attentions in the development of multimedia technologies over the last few years. In HTTP/2, the server push mechanism allows the server to deliver more video segments to the client within a single request in order to deal with the requests explosion problem. As a result, recent research efforts have been focusing on utilizing such a feature to enhance the streaming experience while reducing the request-related overhead. However, current works only optimize the performance of a single client, without necessary concerns of possible influences on other clients in the same network. When multiple streaming clients compete for a shared bandwidth in HTTP/1.1, they are likely to suffer from unfairness, which is defined as the inequality in their bitrate selections. For HTTP/1.1, existing works have proven that the network-assisted solutions are effective in solving the unfairness problem. However, the feasibility of utilizing such an approach for the HTTP/2 server push has not been investigated. Therefore, in this paper, a novel proxy-based framework is proposed to overcome the unfairness problem in adaptive streaming over HTTP/2 with the server push. Experimental results confirm the outperformance of the proposed framework in ensuring the fairness, assisting the clients to avoid rebuffering events and lower bitrate degradation amplitude, while maintaining the mechanism of the server push feature.


Introduction
Online video streaming and downloads have been consuming a dramatic share of the global network over the last decade and are estimated to reach 82% of all consumer Internet traffic by 2022 [1]. Such a tremendous growth has put the pressure on the streaming providers to enhance their services in order to serve the viewers with the best quality that corresponds well with the network availability. To this manner, the HTTP Adaptive Streaming (HAS) has been introduced. In HAS, each video is encoded in multiple qualities in terms of bitrates; the encoded video with each quality is then chunked into multiple segments with fixed duration (usually 2 to 10 seconds). At the client side, an adaptive bitrate selection algorithm (ABR) is deployed to continuously measure the current network state (e.g., available bandwidth). Based on the measuring state, the video segments with the suitable quality versions will be fetched and stored into its play-out buffer. The video starts playing once the buffer is stored at a specified level. This procedure is arXiv:2003.08619v1 [cs.MM] 19 Mar 2020 repeated throughout the whole streaming session. The main advantage of this heuristic is that it promotes the client's ability to adapt the video quality to the change of network condition. As a result, video impairments such as rebuffering events and quality variation can be avoided, thus maintaining a high quality of experience (QoE) for each user.
However, current implementations of HAS mainly utilize the HTTP/1.1 protocol, whose limitations have been exploited in recent studies [2,3]. As the client usually measures the network condition and decides the quality version once a segment is successfully downloaded, a large segment duration obviously decreases the measurement frequency, resulting in slow adaptability that may eventually lead to video impairments in highly unstable network environment. Although the aforementioned problem can easily be solved by simply reducing the segment duration (e.g., 1 second or milliseconds), this negatively correlates with the number of segments that need to be delivered (e.g., reducing the segment duration by half means that the number of segments is doubled). Due to the pull-based characteristic of HTTP/1.1 -the client has to send a request for every single segment, such an attempt causes the requests explosion that introduces huge overheads to the network infrastructure [4,5]. Moreover, the number of round-trip time (RTTs) for each request-response pair is also increased, which may degrade the link utilization in critical network conditions [6,7].
Recently, the HTTP/2 protocol has been standardized [8] and is now supported by major internet browsers [9]. The HTTP/2 presents a new feature called server push, which allows a server to push responses without having to wait for explicit requests from the client. As a result, current researches have focused on leveraging the server push feature of HTTP/2 for adaptive streaming technology [10,11]. Specifically, the so-called k-push strategy has been adopted, where the client receives k video segments with one request [4]. Prior studies have confirmed the promising performance with short segment duration of such a strategy in reducing request-related overheads [5,12,13], startup and delivering delay [4,3], unnecessary RTTs [3,14], power consumption [15,13] and in improving the QoE [16,17]. However, those existing works only focused on optimizing the performance of one client without considering the impact on other clients sharing the same bandwidth. Little attention has been paid to such a mechanism under the multi-clients scenario where the bandwidth competition occurs.
When multiple clients stream a video under a shared bandwidth, the unfairness in bitrate selection among the clients can happen in both HTTP/1.1 [18,19] and HTTP/2 server push [20]. In HTTP/1.1, various research efforts have been made to deal with the unfairness problem, whose deployments varied across different network entities, that is, client-based [21,22,23,24,25], server-based [26,27,28,29], or network-assisted (e.g., controller, base station, proxy, etc.) [30,31,32,33,34]. It has been proven that network-assisted solutions perform best in guiding the clients to select bitrates with respect to fairness, thanks to the ability of in-network entities to globally observe the condition of every client in under its management [10,11]. Although such studies are crucial, to the best of our knowledge, no existing work has aimed at solving the unfairness issue of HAS when employing the HTTP/2 with the server push.
In this paper, we investigate the feasibility of utilizing a network-assisted approach to adaptive streaming over HTTP/2 server push. A novel framework for FAir and pUsh-enabled pRoxy-based Adaptive Streaming over HTTP/2 -the FAURAS framework -is proposed to tackle the unfairness problem when multiple clients compete for a shared bandwidth. Specifically, by fairly allocating an explicit bandwidth for every client, FAURAS can effectively eliminate the bandwidth competition, thus avoiding the unfairness problem. Furthermore, previous studies usually do not consider the situation that clients start the streaming sessions at different time instants, causing abrupt changes of the fair bandwidth that can negatively influence the streaming experience of on-playing clients. The proposed FAURAS successfully overcomes this drawback by proactively rewrites the clients' bitrate requests on-the-fly, considering a QoE-aware strategy to harmonize the needs of uninterrupted playback and low bitrate degradation amplitude. On the other hand, we also found that existing network-assisted solutions in HTTP/1.1 fail to apply in HTTP/2 server push as they tend to drop the pushed segments when bitrate requests are overwritten, thus inefficiently making use of the feature's advantages. Meanwhile, our proposed framework is able to maintain the mechanism of the HTTP/2 server push by informing the client of the bitrate modification in advance via HTTP headers. Finally, the experimental results strongly demonstrate that the proposed FAURAS outperforms the existing works in many different criteria. The distinguished contributions of this paper are as follows: • A novel FAURAS framework is proposed which is the first ever network-assisted approach in adaptive streaming over HTTP/2 with server push. The FAURAS successfully solves the unfairness problem in bitrate selection among the clients, while also assisting the clients to avoid rebuffering events and to minimize bitrate degradation amplitude.
• The use of the pushed segments are strictly guaranteed, therefore maintaining the mechanism and fully embracing the advantages of the HTTP/2 server push.
• A detailed experimental evaluation is conducted to confirm the superior performance of FAURAS over the existing methods across various aspects.
The remainder of the paper is organized as follows: Section 2 provides an overview of existing investigations and solutions to the unfairness issue in HTTP/1.1. The proposed FAURAS framework for solving the unfairness in HTTP/2 server push is presented in details and evaluated in Section 3 and 4, respectively. Section 5 discusses the effectiveness of the proposed framework. Finally, Section 6 concludes this paper.

Related Work
The behavior of multiple clients sharing a fixed bottleneck bandwidth in adaptive streaming over HTTP/1.1 was first investigated in [19]. A performance evaluation of major commercial and open source adaptive streaming players with two competing clients was conducted, showing that the unfairness in bitrate selection occurred. The authors argued that the issue was not related to the well-known congestion control mechanism of TCP but to the mismatch of bandwidth estimations among the clients. This finding was confirmed and investigated further in [18]. It was discovered that, due to the temporal overlap of the clients' segment download states, which were called the ON-OFF periods, a client might overestimate its available bandwidth, thus selecting a too high bitrate version and unfairly occupying the utilization for other clients. As a result, several attempts have been carried out to solve the unfairness in adaptive streaming over HTTP/1.1.
Existing solutions to the unfairness of HAS in HTTP/1.1 can be categorized into client-based, server-based and networkassisted methods [11]. Client-based adaptation schemes [21,22,24,25,23] make use of the computational power of clients' devices to adapt the video bitrate based on measurements of different adaptation metrics, such as available bandwidth, playback buffer, instantaneous QoE, etc. Although benefiting the system deployment and scalability, such methods usually perform suboptimally due to insufficient information regarding the entire network conditions [35]. On the other hand, server-based solutions [26,27,28,29] utilize the advantages of centralized video servers to perform overall bitrate optimization and exchange insights about the clients' statuses. However, these solutions either limit the system scalability when the number of clients increases or introduce high overhead and complexity that may harm the network efficiency [11,10]. Meanwhile, network-assisted approaches [30,31,32,33,34] employ in-network entities (e.g., network edges, controllers, proxies, etc.) to assist the clients' bitrate decisions. Thanks to the general observation of the network, such approaches have shown a high performance in both small and large networks. A bandwidth shaping mechanism was deployed at the residential gateway in [30,31] to assign fair bandwidth slices to the clients. As such, the bandwidth competition was avoided and the bitrate difference among the clients were minimized. In [32], the authors discussed the use of a network proxy in overwriting the client's bitrate request to meet with the calculated fair share. The work in [33] compared the performance of different Software-Defined Network based (SDN-based) methods, including bandwidth shaping, bitrate guidance and hybrid method, found out that all methods provided remarkable improvement of fairness. Likewise, several proxy-based methods were evaluated in [34] considering the fairness in terms of user's QoE under the Long-Term Evolution (LTE) network. The aforementioned researches are crucial for the mass adoption of the adaptive streaming technology. However, to the best of our knowledge, no existing work has ever considered the unfairness problem when utilizing the HTTP/2 server push.
The existence of the unfairness in adaptive streaming over HTTP/2 server push has been confirmed in our previous work [20]. Therefore, in this paper, we set light for solving such a problem with a network-assisted approach by proposing the FAURAS framework. Figure 1 depicts the block diagram of the proposed FAURAS framework. In this framework, requests from multiple clients to the video server are routed through a proxy which is located in-between (e.g., at network edges). At the proxy, as soon as a client joins and starts its streaming session, a fair bandwidth is calculated and assigned separately to each client presenting in the network. This corresponds with the function of the Bandwidth Allocation module. The Request Overwrite module, on the other hand, is responsible for rewriting the segment's request into one with the bitrate matching the fair share. The overwriting decision of this module is based on a QoE-aware strategy that takes into account the QoE-related metrics, that is, rebuffering event and bitrate degradation amplitude. In addition, when the Request Overwrite module modifies a bitrate request, a notification message is signaled to the corresponding client via HTTP headers so that the client will not discard the upcoming pushed segments. The whole procedure of FAURAS is kept transparent so that it does not require significant modifications for both the server and client side. In the following subsections, the function of each module is presented and discussed in details. Some notations and definitions used in this paper are summarized in table 1.

Determining the Fair Share
A client starts its streaming session in the buffering state where it aggressively downloads video segments to fill the play-out buffer. Once the buffer reaches its maximum at B max seconds, the client switches to the steady state when it plays out and downloads segments simultaneously to maintain the buffer stable at B max . Suppose that at time t in the steady state, client a x initiates a new push cycle with the bitrate r x,t = R n and sends request for the next k segments {S n i , S n i+1 ...S n i+k−1 }, where the first segment S n i is called the lead segment. As the video keeps playing during the download of the segments, the buffer will lose an amount corresponding to the downloading time, which can be approximated as k * L * rx,t cx,t . After that, k * L seconds more will be added to the buffer. Therefore, when the client finishes the push cycle, the estimated buffer condition at time t can be determined by the Eq. (1): Since the proxy has a global view of all HAS traffics under its management, it is designated for dividing a suitable bandwidth slice for every of its client. Such an approach, as discussed in Section 2, can effectively eliminate the bandwidth competition. The Bandwidth Allocation module calculates the fair share by dividing the available bandwidth by the number of currently-streaming clients, which is described by the Eq. (2): where C f t demonstrate the fair share at time t. At the client side, the deployed ABR decides the bitrate to be requested based on the bandwidth c x,t it observes. In general, a bitrate decision should always satisfy: where R f t is the fair bitrate version corresponding with the fair bandwidth C f t at time t. Inferring from Eq. (1), a bitrate higher than R f t will probably harm the play-out buffer as the buffer has to spend more time to download the segments than the duration it is added. Due to the fact that maximizing the QoE is among the crucial goals of every ABR [11,36,10], it obviously tends to decide the bitrate that is equal to R f t for its client since this is the best possible video quality under the bandwidth C f t . Consequently, as all clients are assigned with the same bandwidth C f t by the Bandwidth Allocation module, they are likely to select similar video bitrates, thus achieving fairness. It should be noted that, we assume every client shares the same characteristics (e.g., screen size, device type, subscription plan, etc.) in this paper.

Problem when New Clients Join
Every time existing clients stop or new clients start their streaming sessions, the module recalculates and assigns the new fair share C f t for all active clients. Figure 2 illustrates an example experiment of the two cases. In this experiment, one client is tested by streaming 200 segments from a video server via a proxy. The detailed settings will be presented later in Section 4. To simulate the start/stop of clients, we set the proxy to allocate different bandwidth at different periods for the client as described in Table 2. The client starts with the initial bandwidth of 1 Mbps at time t 1 . After downloading segment 60 th at time t 2 , the bandwidth increases to 3 Mbps. This simulates the case when existing clients finish their streaming sessions and leave the network. As the number of clients has decreased (X t2 < X t1 ), the bandwidth assigned for each client is increased . Such a situation deals no negative impact but, instead, can increase the user's satisfaction.
On the other hand, from segment 121 th at time t 3 , the bandwidth is shaped to only 1 Mbps, resembling that new clients have joined to the network (X t3 > X t2 ). At this time, the current client will experience a drop of bandwidth (C f t3 < C f t2 ), which is the main consideration in the development of HAS. As a result, it has to decrease its bitrate to match with the new fair bitrate (R f t3 ≤ R f t2 ). Given the fact that most ABRs often decrease the bitrate step-by-step to maintain the user's QoE [37,12], the client usually needs ∆t seconds to adapt to the new condition and the buffer is likely to degrade during the time. As a consequence, a large gap ∆C between C f t3 and C f t2 will doubtlessly result in a large adaptation delay ∆t. Despite that such a large ∆t can help the client experience the high bitrate longer, it is likely to increase the risk of buffer underflow. This is illustrated clearly in Fig. 2: the client's buffer depletes 3 times during this period. This has shown that, under such a situation, the Bandwidth Allocation module itself cannot efficiently help the client react in time to bandwidth degradation. To overcome this disadvantage, in the next subsection, a Request Overwrite module, which is the most important component of our system, is presented to assist clients shifting to the fair bitrate before draining out their buffers.

Overwriting Strategy
The Request Overwrite module is responsible for proactively rewriting the bitrate of the segment request to the one matching with the fair bandwidth if it detects that the client is demanding a higher value. The operation is performed on-the-fly and no additional communication link is required for both the server and the client side. A safe and aggressive strategy is to immediately overwrite the client's request once the bitrate exceeds the fair video rate. This effectively reduces the adaptation delay, hence maintaining the buffer at a high level and definitely preventing the rebuffering from happening. However, such an approach results in a large down-switching amplitude ∆r (i.e., the bitrate difference between the current bitrate decision and one right before it), which has been proven to have negative impact on the user's QoE [36]. Therefore, it is necessary to develop an overwriting strategy that can minimize the bitrate difference while ensuring a smooth video playback.
In the FAURAS framework, we propose a QoE-aware strategy for overwriting the bitrate request. The video will not be rebuffered if there is at least one segment in the buffer [25]. Considering the case of the HTTP/2 server push, during a push cycle, the client fetches k segments with the same bitrate which cannot be changed in-between. To this manner, for the k-push strategy, it is optimal to maintain k segments in the buffer at all time. Thus, the Request Overwrite module will correct the client's bitrate decision once the following condition is met: When the client sends a request for segment S n i , it will notify the proxy of its current buffer condition B t . Such information is delivered via an explicit HTTP header included to the request so that no extra connection is created, thus limiting unnecessary overheads [35]. If the requested bitrate r x,t exceeds the fair value, the proxy extracts the buffer information from the request headers to estimate the buffer B e t after finishing the download of the push cycle. Once B e t is expected to drop under the duration of k segments, the proxy will overwrite the bitrate decision to R f t .

Handling the Server Push Mechanism
In the HTTP/2 server push, the pushed resources are stored in the browser's push cache of the client for later use [38,15]. Figure 3 depicts examples of this procedure in HAS; Fig. 3a describes a typical scenario that the proxy only forwards the client's segment request, while rewriting it into different bitrate in Fig. 3b. Assuming that in a 2-push mechanism (i.e., for 1 request, 2 segments are delivered), at time t, a client a x decides the bitrate r x,t = R n for the next push cycle and prepares to send the request for segment S n i . The client first checks its push cache and finds that S n i hasn't been downloaded. Therefore, it sends the request to the video server, which traverses via a proxy. In Fig. 3a, the proxy keeps the request unmodified and forwards it to the server. The server sends the requested segment S n i to the client's buffer via an HTTP response and pushes segment S n i+1 to the push cache via a PUSH_PROMISE frame. Then, as the client is still in the push cycle, its bitrate decision remains unchanged at R n . However, before sending the request for S n i+1 , the client sees that such a segment is already in the push cache (whole or partly). Accordingly, the client only needs to take this segment out and directly add into the play-out buffer. This procedure is repeated until the end of the streaming session.
In the case of Fig. 3b, the proxy rewrites the bitrate of S n i into R n . Therefore, S n i and S n i+1 are delivered into the client's buffer and push cache, respectively. Due to the fact that the client is not aware of its bitrate decision being modified, we speculate that it still expects the bitrate R n for the next segment. Thus, when checking the push cache, the client cannot see S n i+1 as the server pushed S n i+1 instead. As a result, the client discards S n i+1 and sends request for S n i+1 , which completely compromises the mechanism of the server push. Hence, not only does the client fail to make use of the advantages discussed in Section 2, but also it wastes the server's network resources utilized for the push segment [39].
An experiment has been conducted in order to prove the hypothesized phenomenon. We set up one single client streaming 100 video segments from the server via a proxy, under an unlimited bandwidth and with the 2-push strategy. At the client side, a simple algorithm is deployed that it only selects the lowest bitrate R 0 for the whole session. In this experiment, the proxy overwrites all segment requests from the client to ones with the second-lowest bitrate R 1 . The detailed settings will be presented in Section 4. Table 3 summarizes the total number of responses (Res) and PUSH_PROMISE frames (P P ) captured on the client's device, in comparison with the cases when the overwrite function is not activated.
As for HTTP/1.1, it is obvious that the client had to send requests for all 100 segments due to the pull-based characteristic. For the case of the 2-push strategy, the client received 2 segments for each request sent (i.e., 1 in the response to the request and 1 delivered via the PUSH_PROMISE frame). Thus, the number of requests was reduced to half that corresponds to the increase of PUSH_PROMISE frames. However, when rewriting the requests, not only did the number of requests remain similar as in HTTP/1.1, but also the number of PUSH_PROMISE frames was double. This confirms the above hypothesis: the pushed segments will be discarded if the overwritten bitrate does not meet the client's desire. To overcome this issue, an essential notification function is proposed in the Request Overwrite module. Everytime a bitrate request is modified, the module explicitly informs its client by simply adding an HTTP header to the response of the lead segment. Once the client receives such an information, it is forced to select the bitrate for the remaining segments in the push cycle as one the proxy requires. Therefore, although the overwrite function can work with any ABR, clients do need a minor modification to support extracting the information in the headers and modifying its bitrate decision to match with the proxy's demand. 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 Fig. 4. The settings of the server and clients are similar to that of [20]. The server is run on a Windows 10 Core i7 physical machine with 8GB of RAM and is implemented based on Jetty [40], while each client is a Core i5 physical machine with 4GB of RAM. On the server, the DASH.js streaming player [41] is packaged as a web application, which will be run at the client side via Chrome web browser. At 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 3GB of RAM and 3 cores of CPU is installed to implement the proxy and its modules. A virtual QoS Router 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. =  {99, 192, 285, 470, 656, 838, 1118, 1401, 1855, 2324, 2791} (Kbps) as in [20]. Each version is chunked into segments of 1 second. The maximum bandwidth 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. At the client side, the maximum buffer level B max is set to 10 seconds. 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. Table 4 shows the experimental scenarios for assessing the performance of the proposed FAURAS and reference methods. 1 client a 1 joins first, then 2 clients a 2 and a 3 join together later

Evaluation Scenarios and Metrics
In this experiment, each client streams a total of 200 segments from the server. Similar to existing researches, a common scenario that multiple clients join together is considered, denoted as scenario #1. Specifically, the mentioned methods are tested on 3 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 ∆C of 1.5 Mbps observing from the original client. This is denoted as subscenario 2-A. Another subscenario, denoted as 2-B, is that 2 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 scenario #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 Eq. 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.
• Number of Rebuffering Events (Rebuf f ): 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 (∆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. ∆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 (∆r): Existing researches 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, ∆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 (P P ): These metrics are to evaluate the ability of FAURAS and referenced methods in ensuring the HTTP/2 server push mechanism. For streaming 200 segments from the server with the 2-push strategy, baseline values of 100 HTTP responses and 100 PUSH_PROMISE frames must be precisely achieved.
A summary of the above evaluation metrics is shown in Table 5. In the following subsection, the experimental results in each scenario are presented in details.

Detailed Results
The experiment of each subscenario in the scenarios provided in the previous subsection was conducted 5 times. The average results are summarized as below.  Table 6 shows the achieved unfairness index of all methods as well as the total number of rebuffering events occurring in scenario #1. It should be noted that, for the number of rebuffering events, the results show an accumulated value of all running times instead of an average value. In general, all network-assisted methods provided relatively identical unfairness performances that significantly outperformed the No-Proxy method. Particularly, the fairness is improved by 4.29 times on average. The results of number of rebuffering events express the similar trend. While the proxy-based methods successfully eliminated such an impairment, the No-Proxy method performed more poorly when the number of clients increases. This is because the more clients there were in the network, the more fiercely they competed for the bandwidth. In Fig. 5, the time-varying performance of each method is illustrated. Due to similar behaviors, only the subscenario 1-B is shown. It can be observed from Fig. 5a that client a 2 usually selected a bitrate higher than the fair share (1 Mbps) and consumed the bandwidth of other clients. For this reason, not only that client a 1 and a 3 failed to reach the fair bitrate but their play-out buffers also became highly unstable and eventually depleted (as for client a 3 ). Meanwhile, under assistance of the proxies in the Reactive, Proactive and proposed FAURAS method (Fig. 5b, 5c and 5d), all clients were able to select similar bitrates and maintained the buffers stable. In the next part, the performance of the network-assisted solutions are investigated further, with respect to the ability to assist the client to adapt to the changes of the fair bandwidth.

Scenario #2
The results of unfairness and the number of rebuffering events in Scenario #2 are summarized in Table 7. Meanwhile, Fig. 6 and 7 illustrate the time-varying performances of the methods in subscenarios 2-A and 2-B, respectively.
The unfairness performances of the evaluated methods show the similar tendency as in Scenario #1. The solutions with proxy improved the fairness by 1.72 times on average comparing to the No-Proxy method. It is noticeable that the improvement was less than that in Scenario #1. Actually, this is understandable due to the characteristics of the client's   Fig. 6 and 7, the new clients a 2 and a 3 had to select their bitrate step-by-step from the lowest version when they started their streaming session, while a 1 was already at high levels. As such, the unfairness index performed worse during this period and recovered once all clients achieved the fair bitrate (1401 Kbps for subscenario 2-A and 838 Kbps for subscenario 2-B).
Likewise, the No-Proxy method still underwent rebuffering events, while the proposed FAURAS and the Proactive method showed consistent efficiency in avoiding them. However, despite the same performance was achieved in subscenario 2-A, the Reactive method failed to prevent rebuffering events in subscenario 2-B when the number of newly-join clients increased. In addition, all rebuffering events when using this method only occurred on client a 1 , who started the streaming session earlier and experienced the bandwidth change when other clients joined. The numerical statistics of the adaptation delay, along with bitrate degradation amplitude, of the network-assisted methods are shown in Table 8 in order to explain this underperformance.  The Reactive method only allocated the bandwidth for the client and respected the gradual quality deterioration of the ABR. As shown in Fig. 6b and 7b, the video bitrate only dropped by 1 level at a time. For this reason, this method provided the lowest ∆r among the evaluated methods in both subscenarios. However, it resulted in the highest ∆t that might cause the client to fail to maintain enough buffer. For the subscenario 2-A, the fair bandwidth dropped from 3 Mbps to 1.5 Mbps and the fair bitrate had to decrease by 3 levels from 2791 Kbps to 1401 Kbps. In this case, the client a 1 still managed adapt to the new fair share before the buffer ran out (Fig. 6b). However, in subscenario 2-B, the fair bandwidth dropped from 3 Mbps to 1 Mbps that decreased the fair bitrate by 5 levels from 2791 Kbps to 838 Kbps. Thus, ∆t of the client a 1 increased by 1.9 times and caused its buffer to deplete (Fig. 7b).
On the other hand, the Proactive method immediately rewrote the client's request to match with the fair bitrate. Observing from Fig. 6c and Fig. 7c, the client a 1 decreased its bitrate straight away instead of switching the bitrate steadily via intermediate levels.
Obviously, the ∆t was reduced to the lowest, hence effectively avoiding the rebuffering events. As a consequence, this method induced the largest ∆r.
Meanwhile, it is shown that the proposed FAURAS framework harmonized the performance of the other two methods. For subscenario 2-A, the FAURAS and the Reactive method performed equally in terms of ∆r, which were approximately 2.24 times lower than the Proactive method. This is visualized by Fig. 6d, the bitrate of client a 1 also decreased gradually as when using the Reactive method. Therefore, they required similar ∆t values that did not harm the playout buffers. In the case of subscenario 2-B, the ∆r of the FAURAS was slightly higher than the Reactive method (1.8 times) but was still significantly lower than the Proactive method (3.5 times). Inferring from Fig. 7d, at 86s, the client decided to switch from 1401 Kbps to 838 Kbps and skipped the value at 1118 Kbps. As a result, the ∆t was reduced comparing to the Reactive method and the buffer was able to recover before fully depleted, thus avoiding rebuffering events.
Additionally, Table 9 shows the number of HTTP responses and the number of PUSH_PROMISE frames client a 1 received throughout the whole session, while Fig. 8 illustrates the sum of those metrics for each video segment specifically.   Table 9, the FAURAS and Reactive method show consistently identical statistics with the baseline as described in 4.2. The behavior of those methods is represented in Fig. 8a. It is obvious that the client alternately received either a single HTTP response or a single PUSH_PROMISE frame for every segment throughout the streaming session. The Proactive method, however, failed to achieve such a performance, the Res and P P values exceeded the baseline in both cases. Referring to Fig. 8b (subscenario 2-A) and 8c (subscenario 2-B), after segment 100 th which was the moment that the new clients joined, the client a 1 consecutively received both an HTTP responses and a PUSH_PROMISE frame for 6 and 10 segments, respectively. This indicates that, although those segments had been pushed by the server, the client still requested and used those in the HTTP responses instead of fetching from its push cache. As result, those pushed segments were wasted and the client switched back to the pull-based mechanism of HTTP/1.1 during this period.

Discussion
Based on the evaluation results assessed in Section 4, it has been proven that the proposed FAURAS significantly improved the fairness of the adaptive streaming over HTTP/2 server push comparing with the No-Proxy method. Such a performance was identical with the referenced Reactive and Proactive method. However, although ensuring the fairness, the Reactive method failed to assist the client to react quickly to large changes of the fair bandwidth. This was because the Reactive method only allocated the bandwidth and did not interfere with the bitrate adaptation of the ABR at the client side. As a result, even though the gradual quality transition strategy of the ABR was fully respected and the bitrate degradation amplitude was minimized to the smallest, the client failed to maintain its buffer, leading to rebuffering events in subscenario 2-B. On the other hand, the Proactive method rewrote the bitrate immediately when it exceeded the fair value, thus effectively keeping the buffer undepleted. Nevertheless, the Proactive method ended up with the highest down-switching amplitude that harmed the user's QoE [36]. Meanwhile, the FAURAS not only solved the unfairness problem but also harmonized well the advantages of the above methods. The bitrate degradation amplitude was significantly reduced comparing to the Proactive method. Despite that such a bitrate gap was still higher than the Reactive method in subscenario 2-B, the rebuffering events were effectively eliminated. Moreover, the Proactive method failed to maintain the mechanism of the HTTP/2 server push when it had to overwrite the client's bitrate. As shown in 4.3.2, the client discarded the pushed segments with bitrate different from its decision and switched back to the pull-based mechanism of HTTP/1.1. The per-segment bitrate and RTT of the client a 1 in scenario 2-A and 2-B are illustrated on Fig. 9 and Fig. 10, respectively, to discussed the consequence of this drawback. Also, Table 10 summarizes the average bitrate of the client a 1 from the time when the new clients joined and caused the fair bandwidth to decrease (segment 100 th ) to the time when the streaming session ended (segment 200 th ). In both subscenarios, the RTT of the Reactive method ( Fig. 9a and 10a) and the FAURAS (Fig. 9c and 10c) varied within a low stable range. In contrast, for the case of the Proactive method ( Fig. 9b and 10b), the RTT drastically increased for a consecutive number of segments (9 segments for subscenario 2-A and 12 segments for subscenario 2-B) after the new clients joined at segment 100 th . We speculate that this was because of the deliveries of the wasted PUSH_PROMISE frames that caused the server to delay the downloads of the responses for those segments [39]. Since the client performed similar to the HTTP/1.1 during this period, such large RTTs were unavoidable and resulted in bandwidth underutilization [6,7]. Therefore, the client had to lower its bitrate more than the others; the lowest bitrate of the client running the Proactive method was 838 Kbps in subscenario 2-A and 480 Kbps in subscenario 2-B, while those of both the Reactive method and the proposed FAURAS were 1118 Kbps and 656 Kbps. As a result, the Proactive method provided the lowest average bitrate for the client a 1 in the last 100 segments in both subscenarios as shown in Table 10. This underperformance was also because of the overwriting strategy; the bitrate was immediately overwritten once it exceeded the new fair share, thus shortening the time for the client to experience high bitrate levels.
Meanwhile, the Reactive method and our FAURAS were able to achieve high and relatively similar results. Comparing with the Reactive method, the proposal showed minor deterioration as the trade-off for preventing the buffer from underflow.
In summary, it is confirmed that our proposed FAURAS succeeded in improving the fairness in bitrate selection of the clients in adaptive streaming over HTTP/2 server push. In addition, comparing to the reference methods, the proposal effectively assisted the client to balance the needs of uninterrupted playback and low bitrate degradation amplitude. Finally, the mechanism of the server push feature was strictly guaranteed that no pushed segment was wastefully discarded. For those reason, it is fair to conclude that the proposed FAURAS outperformed other existing methods.

Conclusion and Future Work
In this paper, a novel proxy-based method is proposed to solve the unfairness in adaptive streaming over HTTP/2 with server push, the FAURAS. The proposed method allocates an explicit bandwidth slice for each streaming client and proactively overwrites the bitrate request to ensure the smooth playback. Through experiments, it has been proven that our proposal not only effectively deals with the unfairness problem but also succeeds in assisting the client to completely avoid rebuffering events and to lower the bitrate degradation amplitude. Moreover, our method strictly obeys the mechanism of the server push feature, therefore leaving no pushed segment wasted. For future work, the performance of the FAURAS will be assessed with multiple bitrate adaptation algorithm. In addition, the client-oriented characteristics (e.g., subscription plan, device specifications, content preference, etc.) will be considered to investigate the efficiency of the proposed framework in broader scenarios.