## 5 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 compared 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 on 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 the advantages of the above methods well. The bitrate degradation amplitude was significantly reduced comparing to the Proactive method. Despite the fact 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 Section 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  
Figure 8: The sum of HTTP Responses and PUSH_PROMISE frames the client \(a_{1}\) received per segment. illustrated on Figures 9 and 10, respectively, to discuss the consequence of this drawback. In addition, 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 (Figures 9a and 10a) and the FAURAS (Figures 9c and 10c) varied within a low stable range. In contrast, for the case of the Proactive method (Figures 9b and 10b), the RTT drastically increased for a consecutive number of segments (nine segments for subscenario 2-A and 12 segments for subscenario 2-B) after the new clients joined at the 100 th segment. 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. Compared with the Reactive method, the proposal showed minor deterioration as the trade-off for preventing the buffer from underflow.