Cross-Protocol Unfairness between Adaptive Streaming Clients over HTTP/3 and HTTP/2: A Root-Cause Analysis

: With the introduction of HTTP/3, whose transport is no longer the traditional TCP protocol but the novel QUIC protocol, research for solutions to the unfairness of Adaptive Streaming over HTTP (HAS) has become more challenging. In other words, because of different transport layers, the HTTP/3 may not be available for some networks and the clients have to use HTTP/2 for their HAS applications instead. Therefore, the scenario in which HAS over HTTP/3 (HAS/3) competes against HTTP/2 (HAS/2) must be considered seriously. However, there has been a shortage of investigations on the performance and the origin of the unfairness in such a cross-protocol scenario in order to produce proper solutions. Therefore, this paper provides a performance evaluation and root-cause analysis of the cross-protocol unfairness between HAS/3 and HAS/2. It is concluded that, due to differences in the congestion control mechanisms of QUIC and TCP, HAS/3 clients obtain larger congestion windows, thus requesting higher video bitrates than HAS/2. As the problem lies in the transport layer, existing client-side ABR-based solutions for the unfairness from the application layer may perform suboptimally for the cross-protocol case.


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 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 the others [4][5][6]. Such a phenomenon is defined as the unfairness problem, which causes QoE deterioration and 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 within the recent years that complicates the efforts of solving the unfairness of HAS. In fact, the HTTP/3 protocol [11] was proposed and is expected to be standardized in 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. That is, 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. solution to the cross-protocol unfairness could not be conducted. 10 Realizing the aforementioned drawbacks, this paper presents an up-to-date perfor-11 mance evaluation and a comprehensive root-cause investigation on the cross-protocol 12 unfairness of HAS/3 against its successors HAS/2 and HAS/1.1. In fact, the HTTP/2 13 nowadays accounts for 64% of HTTP requests over the internet and is expected to continue 14 growing linearly [17]. Such usage growth, in addition to the more advanced features the 15 HTTP/2 provides [12], it is believed that HTTP/1.1 will become deprecated in near future 16 time. Therefore, this work focuses mainly on the competition of HAS/3 and HAS/2 clients. 17 Our analysis demonstrates that, with the newest documentation and implementation, 18 HTTP/3 clients tend to experience higher video qualities than HTTP/2 clients when they 19 compete under the same bottleneck network. Taking an in-depth look at their transport -20 QUIC for HTTP/3 versus TCP for HTTP/2, it is found that, despite both implementations 21 running the same congestion control algorithm, QUIC is able to acquire a larger congestion 22 window than TCP. Such a behavior actually originates from the different mechanisms of 23 the congestion control and the characteristics of QUIC and TCP [18]. In detail, we argue 24 that the differences in loss epoch life cycle, acknowledgement (ACK) ranges and minimum 25 congestion window size, as well as the unreliable nature of the UDP (QUIC's based pro-26 tocol), allow QUIC to receive ACK frames more frequently than TCP. As a consequence, 27 QUIC updates its congestion window more aggressively than TCP, resulting in a higher 28 occupation of the bandwidth. Moreover, since such an underperformance is transparent 29 to the application layer, it has been proven that the existing unfairness solutions utilizing 30 the client-side ABR-based approach on the application layer may fail to achieve desirable 31 effectiveness. Instead, follow-up research should focus on either examining server-or 32 network-based approaches on the transport layer, or tweaking the functionalities and 33 parameters of the transport QUIC. In summary, the distinguished contributions of this 34 work are as follows: 35 • An up-to-date investigation of the cross-protocol unfairness between HAS/3 and 36 HAS/2 is provided, showing that HAS/3 clients unfairly experience higher video 37 quality.

38
• A comprehensive analysis of such an unfairness problem is conducted, which con-39 cludes that its origin lies in the differences in congestion control mechanisms and the 40 characteristics of the transport layer -QUIC for HTTP/3 and TCP.

41
• Based on the root-cause analysis, we provide suggestions for proper solutions to the 42 cross-protocol unfairness between HAS/3 and HAS/2.

43
The remainder of this paper is organized as follows: Section 2 reviews the existing

49
As explained in the previous section, the differences in the transport protocol between 50 HTTP/3 and HTTP/2 or HTTP/1.1 urges the need for tackling the cross-protocol unfairness 51 of these traffics. However, research about such a problem for HAS is surprisingly limited.

52
The work in [19]  among the clients running HTTP-over-QUIC, they also observed that such a kind of client 64 also starved out the HTTP-over-TCP clients. Such an observation was contradictory to their 65 own previous work in [19]. On the other hand, a performance investigation similar to that 66 of [19] was conducted in [22] with the Google QUIC server v39. The finding in [22] showed 67 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 69 cases.

70
It can be noticed that the findings in those existing works were contradictory to one 71 another and were actually outdated as the Google QUIC is now deprecated to make way for 72 the IETF QUIC [23]. Moreover, their works only provided observation and lack of in-depth 73 analysis on the origin of the problem. Thus, to the best of our knowledge, there have been 74 no solution proposed for the cross-protocol fairness between HAS/3 and HAS/2 clients 75 due to such a serious drawback. In order to set light for clarifying the root-cause of the cross-76 protocol unfairness, in the following sections, we present our hypothesis, experimental 77 methodology and performance analysis with the latest version of the HTTP/3 and QUIC.
where r c,t denotes the bitrate r selected by the client c at time t. A larger value of 132 F indicates a more severe unfairness. Additionally, the average bitrate r of each client 133 throughout its streaming session will be measured in order to judge whether higher bitrates 134 are only available at a specific type of client.  In this subsection, the description of the experimental settings for investigating the 142 cross-protocol unfairness between HAS/3 and HAS/2 is provided. Figure 2     In this subsection, the results collected for the general ABR are analyzed.   it was obvious that the HAS/3 clients ended up requesting higher bitrates than the HAS/2 183 clients. Particularly, the bitrates selected by the HAS/3 clients were 42.05% higher than 184 those of the HAS/2 clients on average. This led to the results of the unfairness index F 185 in Table 3. Although such an unfairness performance was actually predictable because 186 the general ABR wasn't tuned for solving such a problem, the fact that the high bitrates

209
Similar to the previous subsection, Table 4 shows the measured F, Table 5 summarizes

241
Based on the analysis in Section 4, it is found that the transport QUIC was able to get 242 higher cwnd for its HAS/3 clients than TCP for HAS/2, leading to an unfair distribution of to transmit data packets much faster than TCP. In addition, QUIC runs atop UDP, which is 248 naturally faster than TCP due to the unreliable characteristics [16]. As for those reasons,

249
QUIC is able to receive ACK frames faster than TCP, so that QUIC updates its cwnd more 250 aggressively and occupies more than the fair share of bandwidth. In order to confirm this 251 explanation, Table 6 Table 6 and 7, the HAS/3 clients updated the cwnd much more 256 frequently than the HAS/2 clients. The illustration on Figure 7 also supports this conclusion.

257
It can be noticed that the number of cwnd updates of all clients running the general ABR 258 were higher than those running the fairness ABR across all scenarios and bandwidth limits.

259
This was simply because the clients running the general ABR often abruptly requested 260 bitrates too higher than the fair portion of the total bandwidth limit, leading to higher  or about deployment feasibility as they require additional network entities [34,35]. The

279
cost benefit regarding these matters should be carefully considered before applying such 280 solutions in real life.

281
On the other hand, the transport QUIC is actually implemented on the user space 282 of both endpoints [36]. Therefore, modifications of the protocol's functionalities and 283 parameters become more feasible as they don't experience the ossification problem caused 284 by conservative network blocks on-the-fly [37,38]. For this reason, future research can 285 also consider tweaking the functionalities and parameters of QUIC for obtaining a fairer 286 bandwidth for the HAS/3 clients against HAS/2 and/or HAS/1.1.