## 1 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 s). 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 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 a highly unstable network environment. Although the aforementioned problem can easily be solved by simply reducing the segment duration (e.g., 1 s 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 request's 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 research 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 [3; 4], unnecessary RTTs [3; 14], power consumption [13; 15] 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].