## 3 System Overview
### Bandwidth Allocation Framework Based on Congestion Control  
When multiple video streams are in the same bottleneck link, the available capacity of the bottleneck link cannot be changed by any other methods. The QoE fairness between videos can only be improved by adjusting the proportion of video streams in the throughput of the bottleneck link. In this paper, we attempt to predict the reasonable weight of bandwidth allocation \(W_{k}^{i}\) for each video stream through the deep reinforcement learning algorithm and then use the congestion control protocol to allocate the bandwidth matching the weight for each video stream in the bottleneck link. Figure 2 depicts the basic flow of a distributed active bandwidth allocation framework based on congestion control. Firstly, the ABR algorithm of the client \(i\) makes bitrate decisions based on the local observation value \(S_{i}^{2}\) of the player. Meanwhile, the QoE of each video block is calculated according to Equation (1) and sent to the video server. The server can generate the parameter \(S_{i}^{1}\) containing global characteristics according to the QoE information of all clients currently connected to it. Then, the DRL algorithm on the client predicts the weight of bandwidth allocation \(W_{k}^{i}\) of the current video stream according to \(S_{i}^{1}\) and \(S_{i}^{2}\). The server needs to continuously monitor the QoE information of each client to generate global parameters, and reconfigure the relevant parameters of congestion control for the video stream \(i\) to allocate bandwidth according to the weight \(W_{k}^{i}\) predicted by the client. It is worth noting that FBAC attaches the parameters (QoE, weight, etc.) that need to be passed between the client and the server to the header of the HTTP request in order to reduce the communication overhead of the system:  
1. The client \(s\) sends a GET request for the \(k\)-\(th\) video block to the server, and the request header is accompanied by the bandwidth allocation weight \(W_{k}^{i}\) of the \(k\)-\(th\) block and the QoE score \(QoE_{(k-1)^{i}}\) of the \(k-1\)-\(th\) block;
2. The server receives and parses the information \(W_{k}^{i}\), \(QoE_{(k-1)^{i}}\) attached to the header in the request;
3. The server updates the congestion control parameters of the video stream and generates global state parameters \(S_{k}^{1}\) according to \(QoE_{(k-1)^{i}}\) at the same time;
4. The server returns the \(k\)-\(th\) video block to the client with the global status parameter \(S_{k}^{1}\) in the response header;
5. The client plays the video block \(k\)-\(th\) and calculates the \(QoE_{k^{i}}\) that can be obtained by playing the video block, and the weight prediction module predicts the band  
Figure 2: Active bandwidth allocation framework based on congestion control. width allocation weight \(W_{k+1}^{i}\) during the download of the \(k+1\)-\(th\) block according to the parameters, including the parameter \(S_{k^{\prime}}^{1}\);
6. The client issues a GET request for the \(k+1\)-\(th\) block. For the fairness algorithm to work, FBAC must also use the existing congestion control algorithm to convert the weight value wi of each video stream into the available bandwidth proportional. Here, we discuss how to use packet loss-based CUBIC [12] and delay-based FAST [13], two types of congestion control, to allocate user bandwidth shares. In this paper, the cube implemented in the QUIC protocol is used as the underlying congestion control for algorithm deployability. Cubic will reduce the size of the sending window after detecting packet loss, and the magnitude of the reduction is related to the multiplicative subtraction factor \(\beta\) of Cubic. Therefore, by adjusting the multiplicative subtraction factor \(\beta_{i}\) corresponding to each stream, the video in the bottleneck link can be obtained. This is the percentage of available bandwidth for the stream allocation.