## 3 The FAURAS Framework
### Request Overwrite
#### 3.2.2 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 [15; 38]. Figure 3 depicts examples of this procedure in HAS; Figure 3 describes a typical scenario that the proxy only forwards the client's segment request, while rewriting it into different bitrate in Figure 3. 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_{i}^{n}\). The client first checks its push cache and finds that \(S_{i}^{n}\) hasn't been downloaded. Therefore, it sends the request to the video server, which traverses via a proxy. In Figure 3a, the proxy keeps the request unmodified and forwards it to the server. The server sends the requested segment \(S_{i}^{n}\) to the client's buffer via an HTTP response and pushes segment \(S_{i+1}^{n}\) to the push cache via a PUSH_PROMISE frame [8]. 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_{i+1}^{n}\), 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 Figure 3b, the proxy rewrites the bitrate of \(S_{i}^{n}\) into \(R^{n^{\prime}}\). Therefore, \(S_{i}^{n^{\prime}}\) and \(S_{i+1}^{n^{\prime}}\) 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_{i+1}^{n}\) as the server pushed \(S_{i+1}^{n^{\prime}}\) instead. As a result, the client discards \(S_{i+1}^{n^{\prime}}\) and sends request for \(S_{i+1}^{n}\), 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. On the client side, a simple algorithm is deployed that 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 (\(PP\)) captured on the client's device, in comparison with the cases when the overwrite function is not activated. Figure 3: Example requests/responses flows in adaptive streaming over HTTP/2 with server push when (**a**) proxy only forwards the client’s request and (**b**) proxy overwrites the client’s request. 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 two 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, which 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.