1. Introduction
Adaptive streaming over HTTP (HAS) has become the de facto standard for most of the online video services on the internet nowadays, thanks to its ability to instantaneously adapt the video quality with the network condition [
1]. In HAS, a video at the streaming server is encoded into multiple quality versions (in terms of bitrates), each of which is split into multiple small segments with the same duration. Then, every streaming client is equipped with an Adaptive Bitrate Algorithm (ABR) in its video player to continuously monitor the network condition, therefore requesting the suitable bitrate for every video segment. Accordingly, undesirable incidents such as playback stalls and quality variation can be reduced, thus maintaining a high quality of experience (QoE) for the users.
Nevertheless, in order to cope with the constantly increasing number of online video users [
2], as well as their daily usage time of the service [
3], the performance of the HAS services against multiple competing clients still requires further optimization. In multi-client scenarios, it has been proven that due to the mismatch of the clients’ downloading states originating from their ABRs on the application layer, some clients may overestimate their bandwidths and request higher video bitrates than others [
4,
5,
6]. Such a phenomenon is defined as the unfairness problem, which causes QoE deterioration and a negative impact on the user retention rate. Therefore, over the years, various research has been conducted and various solutions to the unfairness have been proposed [
7,
8,
9,
10].
On the other hand, the protocol stacks have seen some significant changes in recent years that complicate the efforts to solve the unfairness of HAS. In fact, the HTTP/3 protocol [
11] was proposed and is expected to be standardized in the near future. While HTTP/2 differs from HTTP/1.1 by the novel features on the application layer [
12], the major difference between HTTP/3 and its successors lies in the transport protocol. In other words, while HTTP/1.1 and HTTP/2 have been running on top of the well-tuned TCP protocol for decades, the HTTP/3 utilizes the novel QUIC protocol [
13] for its transport. QUIC actually runs atop the UDP protocol, which is often blocked or limited by network entities due to known security risks [
14,
15,
16]. This means that, as QUIC relies on UDP, there are realistic scenarios that a client fails to use HTTP/3 because of configurations of its network system and has to use HTTP/2 or HTTP/1.1 instead (
Figure 1). Thus, streaming providers must support both HTTP/3 and the former HTTP versions at the same time to ensure service availability. This raises the need for the performance investigation of the unfairness with regard to the cross-protocol scenario, where streaming clients using HTTP/3 concurrently compete against ones using HTTP/2 or HTTP/1.1.
In this manner, research about the cross-protocol unfairness between HAS over HTTP/3 (HAS/3) and over HTTP/2 (HAS/2) or HTTP/1.1 (HAS/1.1) should attract more attention. However, to the best of our knowledge, only a few works have attempted to investigate the unfairness in such a case for HAS and no solution has ever been proposed due to the following limitations. Firstly, as HTTP/3 and QUIC are still under standardization, their features and characteristics vary upon drafted versions and their implementations vary upon releases. Consequently, performance conclusions in the existing works are contradictory against one another. Secondly, those works only provide observations and lack root-cause analysis. Without such crucial information, research for an effective solution to the cross-protocol unfairness could not be conducted.
Realizing the aforementioned drawbacks, this paper presents an up-to-date performance evaluation and a comprehensive root-cause investigation on the cross-protocol unfairness of HAS/3 against its successors HAS/2 and HAS/1.1. In fact, the HTTP/2 nowadays accounts for 64% of HTTP requests over the internet and is expected to continue growing linearly [
17]. With such usage growth, in addition to the more advanced features that the HTTP/2 provides [
12], it is believed that HTTP/1.1 will become degraded in the near future. Therefore, this work focuses mainly on the competition of HAS/3 and HAS/2 clients. Our analysis demonstrates that, with the newest documentation and implementation, HTTP/3 clients tend to experience higher video quality than HTTP/2 clients when they compete under the same bottleneck network. Taking an in-depth look at their transport—QUIC for HTTP/3 versus TCP for HTTP/2—it is found that, despite both implementations running the same congestion control algorithm, QUIC is able to acquire a larger congestion window than TCP. Such a behavior actually originates from the different mechanisms of the congestion control and the characteristics of QUIC and TCP [
18]. In detail, we argue that the differences in loss epoch life cycle, acknowledgement (ACK) ranges and minimum congestion window size, as well as the unreliable nature of the UDP (QUIC’s based protocol), allow QUIC to receive ACK frames more frequently than TCP. As a consequence, QUIC updates its congestion window more aggressively than TCP, resulting in a higher occupation of the bandwidth. Moreover, since such an underperformance is transparent to the application layer, it has been proven that the existing unfairness solutions utilizing the client-side ABR-based approach on the application layer may fail to achieve desirable effectiveness. Instead, follow-up research should focus on either examining server- or network-based approaches on the transport layer, or tweaking the functionalities and parameters of the transport QUIC. In summary, the distinguished contributions of this work are as follows:
An up-to-date investigation of the cross-protocol unfairness between HAS/3 and HAS/2 is provided, showing that HAS/3 clients unfairly experience higher video quality.
A comprehensive analysis of such an unfairness problem is conducted, which concludes that its origin lies in the differences in congestion control mechanisms and the characteristics of the transport layer QUIC for HTTP/3 and TCP.
Based on the root-cause analysis, we provide suggestions for proper solutions to the cross-protocol unfairness between HAS/3 and HAS/2.
The remainder of this paper is organized as follows:
Section 2 reviews the existing research about the cross-protocol unfairness between HAS/3 and HAS/2. The hypothesis on the cause of the cross-protocol unfairness and the methodology and experimental setup for validation are presented in
Section 3. The experimental results are analyzed and discussed in
Section 4 and
Section 5, respectively. Finally,
Section 6 concludes this paper.
2. Related Work
Ever since the proposal of the QUIC transport protocol and the HTTP/3, a dedicated track of research has focused on evaluating its influences on the performance of the HAS. To name a few, in [
19], the authors showed that HTTP-over-QUIC, which was the former name of HTTP/3 before November 2018 [
20], helped the client start the video quicker, reduced the rebuffering ratio and improved the average bitrate compared to HTTP-over-TCP in WiFi, LTE and 3G networks. Moreover, for the situation when the client switched between network interfaces, the results also expressed the outperformance of HTTP-over-QUIC in those metrics. The work in [
21] combined a traditional video streaming approach and a retransmission technique for Scalable High Efficiency Video Coding streaming over HTTP/3. Compared with HTTP/2, the proposed approach provided higher average video quality and more stable bitrate switches when packet loss and retransmission occurred. Meanwhile, the paper [
22] discussed and provided suitable settings of the QUIC’s parameters for better performance of the HAS. On the other hand, [
23] investigated the impact of HTTP/3 and QUIC on 360° HAS and argued that they could effectively reduce rebuffering counts and duration. Despite the fact that these works provided promising performances of the HTTP/3 and QUIC on HAS, they did not consider the multi-client scenario, where the unfairness problem requires more attention.
As explained in the previous section, the differences in the transport protocol between HTTP/3 and HTTP/2 or HTTP/1.1 highlight the need for tackling the cross-protocol unfairness of the clients requesting these traffics. However, research about such a problem for HAS is surprisingly limited. The work in [
24] provided a performance study of several ABRs under the HTTP-over-QUIC. The author did not state which version of QUIC had been tested in their work. However, they did mention the Google QUIC, which is the very first variant of today’s IETF QUIC. Based on their evaluation results, it was shown that the streaming clients using HTTP-over-QUIC failed to experience a video bitrate as high as that of the HTTP-over-TCP clients. The author argued that such an underperformance of the HTTP-over-QUIC clients was because most ABRs were tuned to work well with TCP so they did not utilize the features of QUIC effectively. In their later work [
25], the QUIC retransmission scheme was employed with Google QUIC version Q043, showing promising improvements in video quality and bitrate stability. Interestingly, while they noted that their solution might result in unfairness among the clients running HTTP-over-QUIC, they also observed that such a client also starved out the HTTP-over-TCP clients. Such an observation was contradictory to their own previous work in [
24]. On the other hand, a performance investigation similar to that of [
24] was conducted in [
26] with the Google QUIC server v39. The finding in [
26] showed that, while the HAS clients running over QUIC could perform fairly against one another, they provided 37% higher bitrate than the HAS over TCP clients in most cross-protocol cases.
It can be noticed that the findings in these existing works were contradictory to one another and were actually outdated as the Google QUIC is now deprecated to make way for the IETF QUIC [
27]. Moreover, their works only provided observation and lacked in-depth analysis on the origin of the problem. Thus, to the best of our knowledge, there have been no solutions proposed for the cross-protocol unfairness between HAS/3 and HAS/2 clients due to such a serious drawback. In order to clarify the root cause of the cross-protocol unfairness, in the following sections, we present our hypothesis, experimental methodology and performance analysis with the latest version of the HTTP/3 and QUIC.
5. Discussion
Based on the analysis in
Section 4, it is found that the transport QUIC was able to achieve higher
for its HAS/3 clients than TCP for HAS/2, leading to an unfair distribution of the shared bandwidth. For this reason, even the referenced fairness ABR could not perform optimally to provide similar bitrates for both types of HAS client. Such a phenomenon is actually explainable by examining the enhancements of QUIC’s congestion control in comparison with TCP’s, as described in
Section 3.2. These enhancements actually empower QUIC to transmit data packets much faster than TCP. In addition, QUIC runs atop UDP, which is naturally faster than TCP due to the unreliable characteristics [
16]. For these reasons, QUIC is able to receive ACK frames faster than TCP, so that QUIC updates its
more aggressively and occupies more than the fair share of bandwidth. In order to confirm this explanation,
Table 6 and
Table 7 show the average number of
updates of the clients using the general and the fairness ABR, respectively, in the previous experiment; meanwhile,
Figure 7 illustrates an example of the zoomed-in time-varying
of the clients using the fairness ABR under the scenario
with
(mbps).
Obviously, from
Table 6 and
Table 7, the HAS/3 clients updated the
much more frequently than the HAS/2 clients. The illustration in
Figure 7 also supports this conclusion. It can be noticed that the number of
updates of all clients running the general ABR was higher than those running the fairness ABR across all scenarios and bandwidth limits. This was simply because the clients running the general ABR often abruptly requested bitrates much higher than the fair portion of the total bandwidth limit, leading to higher packet loss due to insufficient bandwidth and increasing the frequency of
updates.
In conclusion, our hypothesis on the root cause of the cross-protocol unfairness of HAS/3 and HAS/2 was verified; in other words, the dissimilarities in congestion control of QUIC and TCP led to unfair bandwidth allocation and, finally, unfair bitrate selections. As the the problem arises from the transport layer, follow-up research on the cross-protocol unfairness can investigate existing methods working on this layer, such as server- or network-based solutions. For example, [
10,
37] utilized a bandwidth allocation module that assigned an equal and separate bandwidth slice for each client.
Figure 8 visualizes the bitrate selection performance of the scenario
with
(mbps) when applying such a method.
The time-varying bitrate selection clearly demonstrates superior fairness performance compared with the client-side fairness ABR tested in
Section 4.2. This is because, as explained in [
10,
37], when every client had its own specific bandwidth, they ultimately did not compete with one another and only maximized the bitrates based on the assigned bandwidth. Consequently, since all clients were given an equal bandwidth, their bitrate selections ended up being fair regardless of their HTTP versions or transport protocols. Nevertheless, the server- and network-based solutions have been questioned regarding their consistent efficiency in large-scale networks due to the extra computational complexity and overhead, or regarding the deployment feasibility as they require additional network entities [
38,
39]. The cost benefit regarding these matters should be carefully considered before applying such solutions in real life.
On the other hand, the transport QUIC is actually implemented on the user space of both endpoints [
40]. Therefore, modifications of the protocol’s functionalities and parameters become more feasible as they do not experience the ossification problem caused by conservative network blocks on-the-fly [
41,
42]. For this reason, future research can also consider tweaking the functionalities and parameters of QUIC for obtaining a fairer bandwidth for the HAS/3 clients against HAS/2 and/or HAS/1.1.