Skip to Content
MDPIMDPI

Advanced

TelecomTelecom
PDF
  • Feature Paper
  • Article
  • Open Access

4 March 2026

25 Pages

Communication Bicasting for Improving Throughput and Fairness in Multihomed Networks Using QUIC with BBRv3

,
and
1
Department of Electrical Engineering and Computer Science, Graduate School of Engineering, Tokyo University of Agriculture and Technology, Koganei 184-8588, Tokyo, Japan
2
Division of Electrical Engineering and Computer Science, Institute of Engineering, Tokyo University of Agriculture and Technology, Koganei 184-8588, Tokyo, Japan
*
Author to whom correspondence should be addressed.
Telecom2026, 7(2), 29;https://doi.org/10.3390/telecom7020029
Version Notes
Order Reprints

Abstract

When devices equipped with multiple wireless network interfaces access the Internet via Wi-Fi, 4G, and 5G, external factors such as radio interference can increase packet loss rates, resulting in reduced communication speed. To address this issue, two approaches exist: the use of Bottleneck Bandwidth and Round-trip propagation time (BBR), a congestion control algorithm designed to mitigate the impact of packet loss and bicasting in multihomed networks. Bicasting in multihomed networks exploits multiple network paths by transmitting identical packets simultaneously over different networks, thereby reducing effective packet loss and mitigating throughput reduction. In this paper, we introduce a novel network architecture that effectively operates in lossy networks by combining bicasting with BBR. By utilizing QUIC and OpenFlow, the proposed architecture enables the construction of a multihomed network that is independent of the operating system (OS), allowing flexible configuration of congestion control algorithms. Furthermore, the introduction of a QUIC proxy enables the use of existing server-side applications without requiring any modifications. Using the proposed multihomed network, we evaluate communication performance for unicasting and bicasting under varying packet loss rates, and we also analyze fairness with competing Transmission control protocol (TCP) flows. The results indicate that the combination of BBRv3 and bicasting achieves fivefold higher throughput than TCP unicasting at a 1% packet loss rate while preserving fairness with competing TCP flows.

1. Introduction

The number of devices has been increasing significantly, with mobile traffic accounting for more than 60% of global website traffic [1]. These mobile devices generally communicate using wireless networks, such as 4G, 5G, and Wi-Fi. Wireless networks lead to communication instability compared with wired networks. One of the factors causing this instability is packet loss due to external influences, such as radio interference [2]. Packet loss results in a decrease in communication speed. Hence, mitigating the reduction in communication speed due to packet loss in wireless networks is essential.
Transmission control protocol (TCP) uses CUBIC [3], a loss-based congestion control algorithm, as the default in major operating systems, including Linux, Windows, and macOS. However, CUBIC significantly reduces throughput in lossy networks, achieving only one-tenth of its original throughput at a packet loss rate of 0.1% [4]. Since CUBIC is a loss-based congestion control algorithm, it reduces its sending rate whenever packet loss occurs, resulting in significant throughput reduction in wireless environments.
To address this problem, the following methods have been proposed. The first is to use a congestion control algorithm that is less sensitive to packet loss, specifically Bottleneck bandwidth and round-trip propagation time (BBR). BBR estimates the bottleneck bandwidth and round-trip time (RTT) to determine the sending rate. Therefore, packet loss has a smaller impact on throughput than loss-based algorithms. BBR aims to operate near the optimal operating point of Kleinrock [5], where maximum bandwidth utilization and minimal latency are achieved. BBRv1 was proposed by Google in 2016, and its subsequent versions have evolved up to BBRv3. BBRv1 can maintain high throughput even at higher packet loss rates [4]. However, BBRv1 faces fairness issues when competing with other loss-based congestion control algorithms. BBRv3 mitigates these issues, maintaining high throughput while improving fairness in lossy networks.
The second approach is to reduce the packet loss rate, which is achieved by applying bicasting in a multihomed network. Using bicasting, where the same packet is transmitted through multiple paths simultaneously in multihomed networks, can reduce the packet loss rate and stabilize communication in lossy networks. TCP can perform bicasting using Multipath TCP (MPTCP), which is designed to support multihomed networks [6,7].
By employing the two methods described above, it is possible to mitigate the reduction in communication throughput due to packet loss typically observed in wireless networks. However, implementing these methods on all mobile devices and servers is challenging. Since TCP congestion control algorithms are configured at the operating-system level, modifying them requires Operating system (OS) level updates on both the client and server, which is not feasible for real-world deployment. Similarly, the use of MPTCP requires support from both the client and server operating systems, and it is currently available on Linux but not on Windows. Therefore, modifications to TCP congestion control algorithms or the use of multihomed networks require specific operating system support, which may limit their feasibility.
In contrast, QUIC has been attracting attention as a general-purpose transport layer protocol [8]. QUIC is a connection-oriented transport layer protocol like TCP, developed based on User datagram protocol (UDP), and enables flexible control in the application layer, which does not depend on OS specification. Thus, QUIC makes it easy to configure and deploy different congestion control algorithms without OS-level modifications.
To mitigate communication speed reduction in lossy networks, our previous study introduced a novel network architecture that uses BBRv1 and bicasting [9]. The proposed network architecture is realized by leveraging QUIC and OpenFlow. QUIC enables flexible configuration of congestion control algorithms, and OpenFlow controls bicasting of a single QUIC flow in multihomed networks. To enhance deployment flexibility, we introduced a split-connection architecture using two QUIC proxies. The proxies maintain standard TCP connections with the client and server while communicating with each other via QUIC, where the proposed method is applied. This design ensures compatibility with unmodified legacy applications. In this architecture, BBRv1 was previously employed as the congestion control algorithm for QUIC. As a result, the communication speed could be maintained with packet loss rates up to 15% in unicasting and up to 32% in bicasting.
This study extends the previous study by addressing the following points: First, since the previous study focused only on unicasting and server-side bicasting implementations, we investigate the effect of client-side bicasting on communication throughput. Second, although BBRv1 was used as the congestion control algorithm for QUIC, it faced fairness issues with loss-based congestion control algorithms of other competing flows. Therefore, we evaluate BBRv3, which is designed to improve fairness. Finally, we assess the fairness between QUIC traffic using the proposed architecture and competing TCP traffic.
The contributions of this paper include:
  • We propose a QUIC-based OpenFlow bicasting architecture that mitigates throughput degradation under packet loss by leveraging BBR congestion control. The architecture operates entirely in the user space and can be deployed without OS-level modifications while maintaining compatibility with existing applications through a QUIC proxy.
  • We systematically design and analyze three deployment configurations of the proposed bicasting schemes, namely client-side, server-side, and bidirectional bicasting, to clarify their distinct impacts on mitigating ACK and data packet loss. Since each bicasting scheme generates varying amounts of network overhead, we further compare throughput and fairness across the configurations and evaluate the effectiveness of each scheme relative to its increased overhead.
  • We conduct a comprehensive experimental evaluation to compare QUIC BBRv1 and BBRv3 deployed on the proposed bicasting schemes, measuring the impact of packet loss rates on communication speed and fairness with competing TCP flows.
The rest of the paper is organized as follows. Section 2 describes the fundamental technologies and related work. Section 3 proposes and describes the multihomed network with QUIC and OpenFlow in detail. Section 4 presents a performance comparison of the proposed multihomed network under various network conditions. Section 5 presents a discussion on the feasibility of implementing QUIC proxies and OpenFlow, as well as the trade-offs among overhead, communication speed, and fairness in bicasting. Finally, Section 6 concludes the paper.

2. Fundamental Technologies

This section describes QUIC, BBR and OpenFlow, along with the related work.

2.1. QUIC and TCP

QUIC is a secure general-purpose transport protocol built on top of UDP, designed to improve web performance. It addresses many of the limitations of TCP, including reducing latency, enhancing security, and mitigating the head-of-line blocking problem. The notable advantages of QUIC over TCP include:
  • Support for IP address changes: TCP identifies connections using a 5-tuple. As a result, if the IP address changes during a connection, the connection cannot be maintained. In contrast, QUIC uses a Connection ID (CID) to uniquely identify communications. This allows seamless communication continuity even when IP addresses change as long as the CID remains consistent.
  • Encryption and authentication: TCP lacks built-in encryption and authentication, requiring TLS to provide security. QUIC, on the other hand, encrypts communications and provides authentication natively. This enables secure communication to be established in a single QUIC handshake. Additionally, the authentication mechanism can be used to restrict connections to specific users or devices.
  • Application layer implementation: TCP is implemented in the OS, making it difficult to update or extend its functionality. In contrast, QUIC is implemented in the application layer, independent of the OS. This design allows new features to be introduced without modifying the OS and simplifies portability to other devices. Furthermore, QUIC’s application layer implementation makes it versatile, enabling deployment across a wide range of communication devices that support UDP.
QUIC supports both streams and datagrams for data transmission. Streams ensure reliable communication with retransmission and reordering, whereas datagrams provide unreliable but low-latency communication. Both approaches allow encrypted data transmission.
However, QUIC has a lower adoption rate than TCP as it is a relatively new transport layer protocol. This limited adoption is partly due to the need for support in both client and server applications, which have traditionally been optimized for TCP. Consequently, despite its performance and security advantages, QUIC is not yet as widely deployed as TCP in production networks.

2.2. BBR

Loss-based congestion control algorithms, such as New Reno and CUBIC, consider packet loss as an indicator of congestion. When a packet loss event is detected, these algorithms reduce the window size and try to avoid congestion. Therefore, in a network where packet loss is likely to occur, the window size tends to be small, and the communication speed is reduced.
In contrast, BBR is a model-based congestion control algorithm and is deployed in over 40% of TCP flows today [10]. BBR sets the sending rate based on the RTT and bandwidth. BBR is a congestion control algorithm designed to optimize the performance of network connections, particularly in scenarios where there is limited available bandwidth or high latency. BBR focuses on estimating the bandwidth of the bottleneck, which typically refers to the link with the narrowest capacity along the data path. This estimation is achieved through real-time probing of the network to determine the available bandwidth. Additionally, BBR considers the round-trip propagation time, which is estimated as the minimum RTT observed within a specific time window. By actively measuring and factoring in the RTT, BBR dynamically adjusts its sending rate to avoid congestion and minimize queuing delay. The goal of BBR is to adapt its sending rate to maximize link utilization without inducing congestion and excessive queuing at bottlenecks.
BBRv1 can maintain stable communication even at packet loss rates up to approximately 15%. Subsequent developments have improved BBR significantly. BBRv2 introduced major enhancements, addressing several limitations of earlier versions, including fairness issues with Cubic and Reno flows, excessive retransmissions, and RTT fairness concerns. The most recent version, BBRv3, is a minor refinement of BBRv2, preserving its core principles while offering incremental improvements.

2.3. OpenFlow

OpenFlow is a protocol used in SDN to separate the control of network devices from the actual data transmission process. OpenFlow can be implemented as software, independent of the operating system. OpenFlow switches operate by processing incoming packets based on flow tables that dictate packet handling. These flow tables can define how packets are handled based on attributes such as IP and MAC addresses. Furthermore, by using a group table, multiple actions can be applied to a single packet. Consequently, OpenFlow switches provide flexible routing control.

2.4. Related Work

Pavur et al. proposed and implemented QPEP, a QUIC-based performance-enhancing proxy designed for geostationary satellite networks [11]. By splitting end-to-end communication into QUIC segments and optimizing congestion control over the satellite link, QPEP significantly improves throughput while preserving security and compatibility with existing applications. In addition, QPEP has been deployed in real-world environments, where improvements in goodput have been observed [12]. Unlike QPEP, our work focuses on loss-resilient congestion control using BBRv1/BBRv3 and improving communication performance through bicasting. This enables improved robustness under lossy network conditions.
Fairness issues arose as BBRv1 flows tended to consume excessive bandwidth, reducing the performance of other flows sharing the link [13,14]. Piotrowska, A evaluated the performance of TCP BBRv3 in networks with multiple RTTs and demonstrated that BBRv3 achieves more balanced bandwidth sharing with CUBIC than BBRv1 in many scenarios, although fairness issues may still arise under certain buffer and RTT configurations [15]. Jose Gomez et al. evaluated BBRv3 using Mininet and real hardware, and BBRv3 achieved fairness with CUBIC for bottleneck queues ranging from Bandwidth–delay product (BDP) to 10BDP [16]. These studies demonstrate the effectiveness of BBR in network environments where clients use a single path. In this work, we consider a QUIC client employing BBRv3 that simultaneously utilizes multiple paths through bicasting. We also consider competing TCP clients using a single path and evaluate fairness between clients employing different congestion control algorithms.
Bicasting reduces the packet loss rate, thereby mitigating communication speed reduction. In our previous study, stable communication was maintained with packet loss rates up to 15% in unicasting, whereas bicasting enabled stable communication even at packet loss rates up to 35% [9]. While A et al. improved latency for important traffic by selectively bicasting packets using Multipath QUIC (MPQUIC) [17]. They did not account for server-side packet loss or evaluate the approach with BBRv3 congestion control [18].

3. Methodology

TCP, which typically employs CUBIC as its default congestion control algorithm, suffers from severe throughput reduction in lossy networks. Moreover, changing the TCP congestion control algorithm requires OS-level modifications, making it impractical to deploy such changes across all servers. To address this issue, we design and implement a multihomed network that employs BBR and bicasting over QUIC. Since BBR determines its sending rate based on measurements of bottleneck bandwidth and RTT, it can sustain communication throughput even when packet loss occurs. In addition, leveraging QUIC’s flexibility in congestion control, we adopt BBRv3, which provides better fairness than BBRv1. Bicasting is a transmission method in which identical packets are sent simultaneously over multiple paths. In bicasting, a packet is considered lost only if all identical packets are lost on every path. Therefore, bicasting reduces the packet loss rate compared with unicasting and is particularly effective in wireless networks where packet loss is more likely. Thus, using BBRv3 and bicasting reduces communication speed reduction in lossy networks while preserving fairness with competing traffic.

3.1. Proposed Method

We propose a network architecture for data transmission from a server to a client, as illustrated in Figure 1. In Figure 1, the server first sends data to the QUIC proxy over TCP. The QUIC proxy then forwards the received TCP data to the connected QUIC proxy using QUIC via bicasting. Upon receiving the same data from multiple paths via QUIC packets, the QUIC proxy delivers one of the data units to the client over TCP, thereby enabling end-to-end communication between the client and the server. Two QUIC proxies are deployed between the client and the server, and all traffic of the client and the server is relayed through the QUIC proxies. In contrast to TCP, since QUIC is implemented in userland, its congestion control algorithm can be flexibly configured. Therefore, BBRv3 can be used simply through application-level configuration. Furthermore, the QUIC communication segment between the QUIC proxies operates over a wireless network that is prone to packet loss. Thus, bicasting is employed to reduce the packet loss rate.
Figure 1. Proposed network architecture. The architecture employs a QUIC proxy to realize bicasting in a multihomed network and illustrates the packet flow when Data 1 is transmitted from the server to the client. Transmission control protocol (TCP) is used on the server–QUIC proxy 2 and QUIC proxy 1–client links, whereas QUIC is used between QUIC proxy 2 and QUIC proxy 1.
By constructing a multihomed environment using a QUIC proxy, the proposed network architecture can be deployed without requiring any modifications to existing server-side applications using TCP as the transport protocol. For client-side applications, communication must be routed through a local QUIC proxy by configuring the TCP destination port to that of the QUIC proxy since the client initiates the connection. In contrast, server-side applications require no such changes as they use the TCP connection initiated by the QUIC proxy.
Deploying QUIC end-to-end to all servers is generally impractical. However, by placing a QUIC proxy within the network, communication from all TCP applications can be routed through the proxy, enabling QUIC-based transmission without requiring any modifications to server-side applications. Furthermore, in practical networks, middleboxes may discard UDP packets, which implies that QUIC packets running over UDP may also be dropped [19]. Therefore, using a QUIC proxy confines QUIC usage to specific network segments, lowering the risk of packet drops compared with end-to-end QUIC communication.

3.2. Design of QUIC Proxy

Currently, only 37% of HTTP servers support QUIC, and many servers do not support this protocol [20]. To use the proposed network without necessitating modifications to existing server-side applications and existing network middleboxes, we implement a QUIC proxy on a client and a proxy host.
Figure 2a presents a ladder diagram that depicts the flow of the HTTP transaction passing through QUIC proxies. The QUIC proxies maintain standard TCP connections with the client and server while communicating with each other via QUIC, where the proposed method is applied. The transaction proceeds as follows. The client first initiates a TCP connection to QUIC proxy 1. QUIC proxy 1 then initiates a QUIC handshake with QUIC proxy 2, and QUIC proxy 2 subsequently initiates a TCP connection to the server. After the connections are established, each QUIC proxy converts TCP data received from the client or server into QUIC STREAM frames and forwards them to its connected QUIC peer. Likewise, the QUIC proxy converts received QUIC STREAM frames back into TCP segments and delivers them to the client or server. Acknowledgmen (ACK) is exchanged within each connection to confirm successful data delivery.
Figure 2. Operation of a QUIC proxy (PN: packet number). (a) This figure illustrates the operation of a QUIC proxy in an HTTP transaction. The QUIC proxy converts the received TCP data into QUIC stream frames and forwards them to the destination QUIC proxy. Conversely, it converts the received QUIC stream frames back into TCP and delivers them to the client or server. (b) Since the QUIC proxy can perform retransmissions when packet loss occurs between QUIC endpoints, it can retransmit lost packets faster than end-to-end TCP retransmission.
This architecture enables rapid packet retransmission in lossy networks as the segmented QUIC connection manages loss recovery locally, thereby maintaining end-to-end communication quality. In conventional TCP using CUBIC, packet loss is interpreted as a sign of congestion, which significantly reduces the sending rate and leads to throughput reduction. In contrast, BBR is used as the congestion control algorithm for QUIC, which is more robust to packet loss than loss-based algorithms such as CUBIC. Moreover, because retransmissions can be initiated directly by the QUIC proxy, lost packets can be recovered more promptly than end-to-end TCP retransmissions. As a result, QUIC retransmission is generally faster than TCP, improving responsiveness and maintaining stable communication performance. The retransmission process in QUIC is illustrated in Figure 2b.

3.3. Implementation of OpenFlow for Bicasting

We perform bicasting using OpenFlow as the software-based method does not require OS-level modifications. In bicasting, a single packet is replicated and transmitted simultaneously over multiple paths. Bicasting can reduce the packet loss rate because a packet is considered lost only when all replicated packets are dropped. Therefore, compared with unicasting, which relies on a single path, bicasting significantly decreases the packet loss rate. In the proposed network architecture, both the client-side and server-side QUIC proxies can transmit data using either unicasting or bicasting.
When bicasting is employed, the receiver must be able to accept packets arriving via multiple NICs. To achieve this, we deploy an OpenFlow switch on the receiver side and configure it to operate as a router, enabling packet forwarding across multiple interfaces. This allows the receiver to process packets received over multiple NICs and collect data from multiple paths seamlessly.
Three bicasting schemes are implemented in this study:
  • Client-side bicasting: The client primarily transmits ACKs, and reducing ACK loss enables the sender to more accurately estimate network conditions.
  • Server-side bicasting: Throughput is improved because data packet loss is reduced.
  • Bidirectional bicasting: Losses of both ACKs and data packets are mitigated, resulting in further performance improvement.
Figure 3 shows the packet flows of bidirectional bicasting. In this architecture, QUIC packets are transmitted via bicasting by OpenFlow switches on both the client and server sides and are forwarded through two different routes. However, a conventional flow table typically forwards packets through only a single output port. To address this limitation, we implement bicasting by applying a group table action in the flow table. The group table enables the collective definition of multiple output ports, thereby allowing packet delivery over diverse routes. To ensure that packets are sent through all selected ports, we configure the group table with the “all” type. In practice, the group table is invoked by specifying its group ID as the output destination in the flow table instructions so that packets originating from the QUIC proxy are forwarded through all designated ports. Furthermore, when packets match the predefined match fields, their source MAC address and destination MAC address are dynamically rewritten to satisfy the routing requirements. When the OpenFlow switch receives packets destined for the connected QUIC proxy, it forwards the packets to QUIC proxy 1 and QUIC proxy 2. These configurations demonstrate that bicasting can be realized using coordinated flow and group table settings in OpenFlow switches. The flow table configurations deployed on the client and proxy host are summarized in Table 1, while the group table configuration on the client and the proxy host is shown in Table 2.
Figure 3. Packet flow of bidirectional bicasting using OpenFlow. Bicasting is performed between OpenFlow switches, and, after passing through the switches, packets converge to a single path. It is assumed that one Acknowledgment (ACK) is sent for each data packet. The numbers (1–4) in the figure represent the sequence of data and ACK transmissions.
Table 1. Flow table of OpenFlow switches for bidirectional bicasting (Figure 3).
Table 2. Group table of the OpenFlow switches (Figure 3).
Client-side bicasting can be implemented by modifying the flow table of the OpenFlow switch on the proxy host, as shown in Table 3, while server-side bicasting can be implemented by modifying the flow table of the OpenFlow switch on the client side, as shown in Table 4.
Table 3. Flow table of the client OpenFlow switch for unicasting (Figure 3).
Table 4. Flow table of the proxy OpenFlow switch for unicasting (Figure 3).

4. Performance Evaluation

To evaluate the proposed network architecture, we implement it on a real testbed and conduct experiments focusing on two key aspects.
First, we compare the communication performance under typical wireless packet loss conditions by measuring file download time. We use TCP with its default CUBIC congestion control algorithm as the baseline method for comparison, and experiments are conducted both with and without the proposed network architecture. Similarly, QUIC in the proposed network architecture is employed with BBRv1 and BBRv3 as the congestion control algorithm. In all cases, we evaluate unicasting, unidirectional bicasting (client-side or server-side), and bidirectional bicasting.
Second, we evaluate fairness when QUIC shares the bottleneck wireless network with TCP in the proposed network architecture. In this experiment, we measure the fairness of QUIC using BBRv1 and BBRv3 while competing with concurrent TCP flows over the same wireless bottleneck link.

4.1. Experimental Environment

In our experimental network, as shown in Figure 4, we implement the multihomed network using QUIC proxies and OpenFlow switches. Hardware specifications of the client, the OpenFlow switch 2, the QUIC proxy 2, and the server are shown in Table 5, and Raspberry Pi 5 devices are used as routers. The network setup for these experiments consists of the following components and configurations:
Figure 4. Experimental setup with QUIC and OpenFlow. The bandwidth between OpenFlow switches is 100 Mbps, the Round-trip time (RTT) is 10 ms, and the packet loss rates on both the client-side and server-side links are varied. Solid lines represent packets transmitted from the server to the client, while dashed lines represent packets transmitted from the client to the server. (a) Unicasting. (b) Client-side bicasting. (c) Server-side bicasting. (d) Bidirectional bicasting.
Table 5. Hardware specifications of the experimental setup.
  • The client application, QUIC proxy 1 and OpenFlow switch 1 are implemented on a single terminal as the client, and Open vSwitch is used as the OpenFlow switch. In addition, to enable communication within the same host, the client application, QUIC proxy 1, and OpenFlow switch 1 run in different namespaces. Namespace is a mechanism for creating virtual nodes and using virtual NICs to communicate with other nodes.
  • We emulated a wireless network by employing switches and routers and configuring the routers’ NICs.
  • For QUIC, we use picoquic [21] implemented in the C. This is because picoquic supports both BBRv1 and BBRv3 as congestion control algorithms.

4.2. Measurement of the Communication Speed

In this section, we measure the communication speed of the proposed network architecture using BBRv1 and BBRv3, with QUIC transmissions performed in unicasting, client-side bicasting, server-side bicasting, and bidirectional bicasting.

4.2.1. Experimental Conditions for File Download Time Measurement

The download time of the file is measured under the following conditions:
  • As baseline methods, we evaluate TCP with CUBIC and its client-side bicasting extension, namely TCP unicasting and TCP client-side bicasting, respectively. The network topology shown in Figure 5 is used when measuring the file download time for TCP.
  • Using the proposed network architecture (Figure 4), we evaluate QUIC with BBRv1 and BBRv3. For each congestion control algorithm, we measure the file download time in unicasting (BBRv1/BBRv3 unicasting), client-side bicasting (BBRv1/BBRv3 client-side bicasting), server-side bicasting (BBRv1/BBRv3 server-side bicasting), and bidirectional bicasting (BBRv1/BBRv3 bidirectional bicasting).
Figure 5. Experimental setup with TCP and OpenFlow. The bandwidth between OpenFlow switches is 100 Mbps, the RTT is 10 ms, and the packet loss rates on both the client-side and server-side links are varied. Solid lines represent packets transmitted from the server to the client, while dashed lines represent packets transmitted from the client to the server. (a) Unicasting. (b) Client-side bicasting. (c) Server-side bicasting. (d) Bidirectional bicasting.
We set specific network conditions using the Linux Traffic Control (TC) so that we simulate a wireless network between the client and proxy host. We fix RTT between the client and the proxy host to 10 ms to reproduce the actual latency and limit the bandwidth between the client and the proxy host to 100 Mbps. In addition, we set the RTT between the proxy host and the server to 10ms. To assess performance, we measure the time required to download a 100 MB file using Hypertext transfer protocol (HTTP) communication initiated from the client to the server. We emulate the wireless network between the client and the proxy host and vary the packet loss rate as a key parameter for the analysis. The packet loss rate is configured identically on both paths and in both transmission directions (client-to-server and server-to-client).

4.2.2. Results of File Download Time

First, we compare the performance of client-side bicasting with unicasting. Figure 6 shows the average file download time, measured over 50 repetitions, required to transfer a 100 MB file from the server to the client when the packet loss rate between the client and the proxy host was varied from 0% to 15%. In these experiments, the server transmitted data using unicasting, while the client transmitted data using either unicasting or bicasting.
Figure 6. Average file download time for 100 MB data transfer under unicasting and client-side bicasting using TCP and QUIC with Bottleneck Bandwidth and Round-trip propagation time (BBR) v1/v3. The packet loss rate between the client and the proxy is varied from 0% to 15%, while the bottleneck bandwidth is 100 Mbps and the RTT is 10 ms. Results are averaged over 50 repetitions.
From Figure 6, file download times of TCP unicasting and client-side bicasting increase significantly due to excessive packet loss, specifically at 1% and above. In contrast, both in BBRv1 unicasting and client-side bicasting method, the file download time is reduced by approximately 80% at a packet loss rate of 1% and by approximately 90% at 2% compared with both TCP unicasting and TCP client-side bicasting. In addition, BBRv1 unicasting and client-side bicasting maintain stable communication even at packet loss rates up to 15%. Furthermore, in BBRv3 unicasting, the file download time is reduced by 32% at a packet loss rate of 1% and by 56% at 2% compared with TCP unicasting, while, in BBRv3 client-side bicasting, the file download time is reduced by 23% at 1% and 43% at 2% compared with TCP client-side bicasting. Compared with TCP with CUBIC, QUIC with BBRv1 and BBRv3, in both unicasting and client-side bicasting, suffer little throughput reduction due to packet loss and maintain stable throughput even at high loss rates.
Comparing BBRv1 unicasting and BBRv1 client-side bicasting, there is little change in the file download time since the client transmits only ACK packets and packet loss on the client side has minimal impact on the overall communication speed. However, BBRv3 client-side bicasting increases the file download time by approximately 130% compared with BBRv3 unicasting, when the packet loss rate exceeds around 2%. This is because BBRv3 reduces its sending rate in response to packet loss to maintain fairness with competing flows. In client-side bicasting, receiving more ACKs makes loss detection more responsive, which in turn increases the file download time.
Next, we compare the performance of server-side bicasting with bidirectional bicasting. Figure 7 shows the average file download time, measured over 50 repetitions, required to transfer 100 MB of data from the server to the client under the same conditions as Figure 6, except for the following changes: the packet loss rate between the client and the proxy host was varied from 0% to 40%, the server transmitted data using only bicasting, and the client transmitted data using both unicasting and bicasting.
Figure 7. Average file download time for 100 MB data transfer under server-side bicasting and bidirectional bicasting using TCP and QUIC with BBRv1/BBRv3. The packet loss rate between the client and the proxy is varied from 0% to 40%, while the bottleneck bandwidth is 100 Mbps and the RTT is 10 ms. Results are averaged over 50 repetitions.
From Figure 7, the file download times for both BBRv1 server-side and bidirectional bicasting are comparable to those of TCP server-side and bidirectional bicasting at packet loss rates up to 3%. However, at packet loss rates of 5% and 10%, both the download times with BBRv1 server-side and bidirectional bicasting are reduced by approximately 35% and 82%, respectively, compared with both TCP server-side and bidirectional bicasting. In addition, both BBRv1 server-side and bidirectional bicasting maintain high throughput even at a 40% packet loss rate. Moreover, the file download times of BBRv3 server-side and bidirectional bicasting increase relative to those of TCP server-side and bidirectional bicasting for packet loss rates up to 5–6%. In addition, at a 10% packet loss rate, BBRv3 server-side and bidirectional bicasting reduces file download time by 40% and 28%, respectively, compared with TCP server-side and bidirectional bicasting. This is because BBRv3 aims to maintain fairness with loss-based congestion control algorithms, which increases the file download time. However, once the packet loss rate exceeds 7%, BBRv3’s throughput-maintenance mechanisms become effective due to combined congestion estimation with network delay and packet loss, leading to a shorter file download time of BBRv3 server-side and bidirectional bicasting than TCP server-side and bidirectional bicasting, respectively.
By comparing BBRv1 and BBRv3 server-side bicasting and bidirectional bicasting, we evaluate the effect of client-side bicasting. As shown in Figure 7, comparing BBRv1 server-side bicasting and bidirectional bicasting, bicasting the client-side packets has little effect on file the download time for BBRv1 because BBRv1 is not largely affected by ACK loss. However, file download times of BBRv3 bidirectional bicasting increase by approximately 110-200% compared with BBRv3 server-side bicasting when the packet loss rate exceeds 4% because of increased ACK reception, which makes the sender more responsive to packet loss.
By comprehensively analyzing Figure 6 and Figure 7, we clarify the distinct effects of bicasting location and congestion control algorithm on throughput robustness. First, across all communication schemes, BBRv1 consistently maintains stable performance under increasing packet loss regardless of whether unicasting or bicasting is employed. This confirms that BBRv1 is inherently robust to packet loss, and the additional benefit of client-side bicasting is limited because ACK loss has little influence on overall throughput in this configuration.
In contrast, BBRv3 demonstrates more complex behavior. When server-side bicasting is employed, the data packet loss rate is effectively reduced because duplicate data packets are transmitted through multiple paths. As a result, packet loss rate is reduced, the throughput increases and the file download time is reduced. Conversely, when client-side bicasting is applied, the reception of additional ACK packets accelerates loss detection at the sender. Since BBRv3 incorporates packet loss into its congestion control mechanism, earlier loss detection leads to a reduction in the sending rate, leading to lower throughput and longer download times.
Overall, these results demonstrate that the performance gain from bicasting depends not only on the transmission direction in which packet loss is mitigated but also on the characteristics of the congestion control algorithm. In particular, while BBRv1 primarily benefits from reduced data loss, BBRv3 exhibits a trade-off between robustness and fairness, especially when ACK reception is increased through bidirectional transmission.

4.2.3. Analysis of BBRv3 Congestion Window Behavior

From Figure 6 and Figure 7, the file download times of BBRv3 client-side and bidirectional bicasting are increased compared to BBRv3 unicasting and server-side bicasting. To further analyze this behavior, we measure the number of ACKs received by the server and the evolution of the congestion window (cwnd). Figure 8, Figure 9, Figure 10 and Figure 11 show the cwnd evolution for BBRv3 unicasting and client-side at a packet loss rate of 10%, and for BBRv3 server-side and bidirectional bicasting at a packet loss rate of 20%, respectively.
Figure 8. Congestion window (cwnd) evolution in BBRv3 unicasting at a packet loss rate of 10%.
Figure 9. cwnd evolution in BBRv3 client-side bicasting at a packet loss rate of 10%.
Figure 10. cwnd evolution in BBRv3 server-side bicasting at a packet loss rate of 20%.
Figure 11. cwnd evolution in BBRv3 bidirectional bicasting at a packet loss rate of 20%.
At a packet loss rate of 10%, the server receives 12,849 QUIC ACK frames in BBRv3 unicasting and 18,116 in BBRv3 client-side bicasting. Similarly, at a packet loss rate of 20%, the server receives 6775 ACK frames in BBRv3 server-side bicasting, whereas this number increases to 16,163 in BBRv3 bidirectional bicasting. These results indicate that client-side bicasting noticeably increases the number of ACKs received at the server.
Figure 8 and Figure 9 show that the cwnd in BBRv3 client-side bicasting decreases faster than in BBRv3 unicasting. Likewise, as shown in Figure 10 and Figure 11, the cwnd in BBRv3 bidirectional bicasting decreases faster than that in BBRv3 server-side bicasting. This behavior occurs because BBRv3 reduces cwnd upon detecting packet loss, and loss detection relies on ACK reception. By detecting loss through ACKs, BBRv3 enforces fairer and more moderate sending rate control than BBRv1, which results in the increased file download times observed in Figure 6 and Figure 7. In client-side and bidirectional bicasting, where ACKs are also transmitted over multiple paths, fewer ACKs are lost, enabling faster loss detection. Consequently, the sending rate is reduced earlier, leading to increased file download times.

4.2.4. Evaluation of the Amount of Transmitted Data

We measure the amount of data transmitted by both the client and the server under the four communication schemes: unicasting, client-side bicasting, server-side bicasting, and bidirectional bicasting. The data transmitted by the client is calculated as the sum of bytes sent through ports A and B of the client-side OpenFlow switch shown in Figure 4, while the data transmitted by the server is calculated as the sum of bytes sent through ports 1 and 2 of the proxy’s OpenFlow switch. All measurements are averaged over 50 repetitions. Figure 12 illustrates the total transmitted data for both the client and server using BBRv1 and BBRv3.
Figure 12. The amount of transmitted data at both the client and the server when downloading a 100 MB file using the proposed network architecture under the four communication schemes (unicasting, client/server-side bicasting, and bidirectional bicasting) with BBRv1 and BBRv3. The packet loss rate between the client and the proxy is varied from 0% to 15%, while the bottleneck bandwidth is 100 Mbps and the RTT is 10 ms. Results are averaged over 50 repetitions. (a) BBRv1—client: the amount of transmitted data at the client using BBRv1. (b) BBRv1—server: the amount of transmitted data at the server using BBRv1. (c) BBRv3—client: the amount of transmitted data at the client using BBRv3. (d) BBRv3—server: the amount of transmitted data at the server using BBRv3.
From Figure 12, the amount of data transmitted by the client is smaller than that transmitted by the server across all four communication schemes. This is because the client only sends ACK packets. Therefore, even when client-side bicasting schemes (client-side and bidirectional bicasting) are employed to increase the client’s traffic, the resulting increase in transmitted data is minimal.
In contrast, the server’s transmitted data increases with the packet loss rate across all communication schemes due to retransmissions triggered by packet loss. Furthermore, server-side unicasting schemes (unicasting and client-side bicasting) experience higher data packet loss than the server-side bicasting schemes (server-side and bidirectional bicasting). As a result, at a 15% packet loss rate, the transmitted data for server-side unicasting schemes increases by approximately 120% compared to the 0% loss case for both BBRv1 and BBRv3, whereas server-side bicasting schemes only increase by approximately 104%. However, for both BBRv1 and BBRv3, server-side bicasting schemes increase the server’s transmitted data by approximately 170–200% compared with server-side unicasting schemes, indicating a potential increase in overall network load.
These results highlight a trade-off between communication speed and the amount of transmitted data. While server-side and bidirectional bicasting effectively reduce packet loss and thereby improve file download times, this improvement comes at the cost of increased transmitted data, particularly on the server side. In other words, faster data delivery is achieved by sending additional redundant packets to mitigate losses, resulting in higher network load.
For example, as discussed in Section 4.2.2, BBRv1 and BBRv3 both benefit from reduced download times under server-side and bidirectional bicasting. However, the corresponding increase in server-side transmitted data (up to 170–200% compared with unicasting) represents a clear overhead. In contrast, client-side bicasting schemes have minimal impact on the amount of transmitted data because the client only sends small ACK packets, but they provide limited improvement in file download times as they do not reduce data packet loss.
Therefore, the selection of a bicasting scheme requires balancing improvements in communication performance against the additional network resource consumption depending on the specific requirements of the deployment scenario.

4.3. Evaluation of Fairness with TCP

This section evaluates the fairness of the proposed network architecture where QUIC traffic coexists with competing TCP flows over a shared bottleneck link.

4.3.1. Experimental Conditions for Fairness Evaluation

The network configuration used for this experiment is shown in Figure 13. The client, router, OpenFlow switch 2, QUIC proxy 2, and server are the same as those described in Figure 4 and Table 5, while a Raspberry Pi 3 Model B is used as the TCP client and TCP server.
Figure 13. Network configuration for fairness evaluation. In the packet flow using the proposed network architecture, solid lines represent packets transmitted from the server, while dashed lines represent packets transmitted from the client. The bandwidth between OpenFlow switches is 100 Mbps, the RTT is 10 ms, and the packet loss rates on both the client-side and server-side links are varied. (a) Unicasting. (b) Client-side bicasting. (c) Server-side bicasting. (d) Bidirectional bicasting.
TCP traffic is generated using iperf3 between the TCP client and TCP server. The experiments are conducted over a wireless network with a bandwidth of 100 Mbps, which serves as the bottleneck shared by both TCP and QUIC traffic. QUIC employs BBRv1 and BBRv3 as congestion control algorithms, and measurements are performed under unicasting, unidirectional bicasting (client-side or server-side), and bidirectional bicasting.
For each QUIC transmission, a 1GB file is downloaded, and throughput is measured until the download completes. The packet loss rate of the wireless network is varied from 0% to 1% in 0.1% increments.

4.3.2. Results of Fairness Evaluation

Figure 14 shows the throughput comparison between QUIC using BBRv1 and competing TCP flows. Figure 14 indicate that “QUIC” represents the throughput achieved by the proposed network architecture. “TCP1” and “TCP2” represent the throughput of each competing TCP flow, and “TCP unicasting” denotes the average throughput measured over 100 s when a single TCP flow operates alone under the same packet loss conditions. At a 0% packet loss rate, BBRv1 achieves comparable throughput to TCP across all transmission modes, indicating that fairness is maintained under lossless conditions.
Figure 14. Throughput comparison between QUIC with BBRv1 and TCP (CUBIC) under four communication schemes. The packet loss rate between the client and the proxy is varied from 0% to 1%, while the bottleneck bandwidth is 100 Mbps and the RTT is 10 ms. Results show the average throughput, where the throughput was computed using the time required to complete the download of a 1 GB file over QUIC. (a) Unicasting. (b) Client-side bicasting, where TCP1 shares the bottleneck link with client/server-side traffic and TCP2 shares it with client-side traffic. (c) Server-side bicasting, where TCP1 shares the bottleneck link with client/server-side traffic and TCP2 shares it with server-side traffic. (d) Bidirectional bicasting, where TCP1 and TCP2 share the bottleneck link with both client-side and server-side traffic.
We define “throughput utilization” as the ratio of TCP1 or TCP2 throughput to TCP unicasting throughput. Values approaching 100% indicate that the competing TCP flows maintain their expected throughput, reflecting higher fairness. For packet loss rates of 0.1% and above, TCP unicasting throughput falls below 50 Mbps; therefore, we use throughput utilization as the primary fairness index. Table 6 shows the TCP1 and TCP2 throughput utilization at packet loss rates between 0.1% and 1%.
Table 6. Throughput utilization of TCP1 and TCP2 competing for QUIC using BBRv1.
Unicasting: Figure 14a shows the results when QUIC with BBRv1 is transmitted via unicasting. The throughput utilization of TCP1 is 28.6% at a packet loss rate of 0.1%, indicating that BBRv1 occupies most of the available bandwidth. At packet loss rates between 0.2% and 1%, TCP1’s throughput utilization remains below 50%. The throughput of QUIC increases from 78.3 Mbps at 0.1% to 87.2 Mbps at 1% packet loss. This occurs because CUBIC reduces its sending rate upon detecting packet loss, whereas BBRv1 does not. Consequently, BBRv1 utilizes the bandwidth released by CUBIC, causing CUBIC throughput to decrease progressively with each loss event.
Client-side bicasting: Figure 14b shows the results when QUIC with BBRv1 is transmitted via client-side bicasting. The throughput utilization of TCP1, which shares the bottleneck link with QUIC data packets, improves to 74.6% compared to TCP1 with BBRv1 unicasting at a 0.1% packet loss rate. At packet loss rates between 0.2% and 1%, TCP1’s throughput utilization remains above 70%. This improvement is attributed to the increased reception of ACKs in client-side bicasting, which allows BBRv1 to more accurately estimate bottleneck bandwidth and RTT variations. The throughput utilization of TCP2 remains nearly 100% because TCP2 shares the bottleneck only with client-side ACK packets, which are small and have little impact on throughput.
Server-side bicasting: Figure 14c shows the results when QUIC with BBRv1 is transmitted via server-side bicasting. The throughput utilizations of both TCP1 and TCP2 are approximately 65% at a 0.1% packet loss rate, decreasing below 50% at packet loss rates of 0.2% and above. This degradation occurs because both TCP flows share their respective bottleneck links with BBRv1 data traffic. The throughput of QUIC ranges from 73.1 to 86.5 Mbps at packet loss rates between 0.1% and 1%.
Bidirectional bicasting: Figure 14d shows the results when QUIC with BBRv1 is transmitted via bidirectional bicasting. The throughput utilizations of TCP1 and TCP2 are 66.1% at a 0.1% packet loss rate. Compared with server-side bicasting, bidirectional bicasting slightly improves TCP throughput because ACKs are also transmitted via bicasting, enabling BBRv1 to estimate network conditions more accurately. The throughput of QUIC ranges from 69.3 to 84.6 Mbps at packet loss rates between 0.1% and 1%. Consequently, BBRv1 faces significant unfairness toward competing TCP flows under lossy conditions across all transmission modes as it occupies most of the bottleneck bandwidth regardless of whether unicasting or bicasting is employed.
Figure 15 shows the throughput comparison between QUIC using BBRv3 and competing TCP flows, and Table 7 shows the TCP1 and TCP2 throughput utilization at packet loss rates between 0.1% and 1%. The definitions of QUIC, TCP1, TCP2, and throughput utilization are the same as those in Figure 14 and Table 6. At a 0% packet loss rate, BBRv3 maintains fairness with TCP across all transmission modes.
Figure 15. Throughput comparison between QUIC with BBRv3 and TCP (CUBIC) under four communication schemes. The packet loss rate between the client and the proxy is varied from 0% to 1%, while the bottleneck bandwidth is 100 Mbps and the RTT is 10 ms. Results show the average throughput, where the throughput was computed using the time required to complete the download of a 1 GB file over QUIC. (a) Unicasting. (b) Client-side bicasting, where TCP1 shares the bottleneck link with client/server-side traffic and TCP2 shares it with client-side traffic. (c) Server-side bicasting, where TCP1 shares the bottleneck link with client/server-side traffic and TCP2 shares it with server-side traffic. (d) Bidirectional bicasting, where TCP1 and TCP2 share the bottleneck link with both client-side and server-side traffic.
Table 7. Throughput utilization of TCP1 and TCP2 competing for QUIC using BBRv3.
Unicasting: Figure 15a shows the results when QUIC with BBRv3 is transmitted via unicasting. The throughput utilization of TCP1 exceeds 90% at packet loss rates between 0.1% and 1%, demonstrating significantly improved fairness compared with BBRv1. This improvement occurs because BBRv3 reduces its throughput upon detecting packet loss, preventing it from occupying most of the available bandwidth. However, the throughput of QUIC ranges from 23 to 45 Mbps, and the combined throughput of QUIC and TCP is only 76.8 Mbps at 0.1% and 33.6 Mbps at 1% packet loss, indicating that the 100 Mbps bottleneck link is underutilized.
Client-side bicasting: Figure 15b shows the results when QUIC with BBRv3 is transmitted via client-side bicasting. Similar to unicasting, TCP1 maintains high throughput, with utilization exceeding 85% at packet loss rates between 0.1% and 1%. QUIC achieves 25.5 to 46.5 Mbps, slightly higher than in unicasting due to improved ACK reception. However, the bottleneck link remains underutilized.
Server-side bicasting: Figure 15c shows the results when QUIC with BBRv3 is transmitted via server-side bicasting. The throughput utilization of TCP1 is 82% at a 0.1% packet loss rate and 87% at 0.2%, which is lower than in unicasting. This occurs because server-side bicasting reduces BBRv3’s packet loss, thereby increasing its throughput and reducing the bandwidth available to TCP. QUIC throughput increases from 54.8 Mbps at 0.1% to 68.8 Mbps at 1% packet loss. The combined throughput of QUIC and TCP ranges from 77 to 96 Mbps, indicating that the bottleneck bandwidth utilization is improved as compared to unicasting and client-side bicasting.
Bidirectional bicasting: Figure 15d shows the results when QUIC with BBRv3 is transmitted via bidirectional bicasting. The throughput utilizations of TCP1 and TCP2 exceed 90%. The reduced ACK loss enables BBRv3 to estimate network conditions more accurately, preventing excessive bandwidth consumption and improving fairness compared with server-side bicasting. QUIC throughput ranges from 49.4 Mbps at 0.1% to 66.9 Mbps at 1% packet loss. The combined throughput of QUIC and TCP ranges from 75 to 83 Mbps, demonstrating effective utilization of the bottleneck bandwidth while preserving fairness.
Overall, the comparison between BBRv1 and BBRv3 reveals fundamentally different fairness characteristics under lossy conditions. While BBRv1 consistently maintains high throughput across all communication schemes, it occupies a large portion of the bottleneck bandwidth, leading to significant unfairness toward competing TCP flows.
In contrast, BBRv3 achieves significantly better fairness than BBRv1 across all communication schemes. By incorporating packet loss into its congestion control mechanism, BBRv3 reduces its sending rate upon detecting loss, thereby preventing excessive bandwidth occupation and allowing competing TCP flows to maintain high throughput. However, this fairness improvement may result in lower combined throughput of QUIC and TCP and, in some cases, underutilization of the bottleneck link.
Among the four communication schemes, each evaluated with both BBRv1 and BBRv3, bidirectional bicasting using BBRv3 achieves the most balanced trade-off, providing high throughput while maintaining fairness. By reducing ACK and data packet loss, it enables BBRv3 to maintain high bandwidth utilization while preserving fairness with competing TCP flows.

5. Discussion

In this section, we discuss the practical considerations for deploying the proposed network architecture, including the feasibility of introducing QUIC proxies and OpenFlow components, deployment on mobile devices, and the trade-offs between network overhead, throughput, and fairness.

5.1. The Practical Deployment Considerations and Limitations of Introducing QUIC Proxies and OpenFlow Components

In some scenarios, OpenFlow may not be available. However, by leveraging MPQUIC, which extends QUIC to support multihomed networks, the proposed network architecture can be realized through a QUIC proxy, which can be implemented as an application. Additionally, QUIC packets may be dropped by middleboxes along the network path. This possibility can be mitigated by limiting QUIC usage to short network segments, and, by placing the QUIC proxy close to the client within the network, the likelihood of packet drops can be further reduced.

5.2. Deployment of the Proposed Network Architecture on Mobile Devices

On mobile devices, OS restrictions and limited system resources may prevent direct use of the proposed network architecture. However, mobile applications such as Speedify [22], which provide channel bonding over multiple network paths, are already in practical use. By implementing a QUIC proxy in a similar manner, the proposed architecture can be utilized on mobile devices. Furthermore, bicasting can be supported by leveraging MPQUIC, enabling functionality without relying on OpenFlow. The implementation and evaluation of the proposed architecture on mobile devices will be addressed in future work.

5.3. Trade-Off Between Network Overhead, Throughput, and Fairness in Bicasting with BBRv3

Bicasting inherently increases network load because identical data packets are transmitted over multiple paths. This results in higher overall transmitted data compared with unicasting, particularly on the server side. However, server-side bicasting (server-side and bidirectional schemes) reduces data packet loss, which helps to maintain higher throughput even under lossy conditions. Moreover, even when packet loss rates increase, server-side bicasting allows BBRv3 to utilize a large portion of the bottleneck bandwidth while maintaining fairness with competing flows.
Consequently, server-side bicasting presents a trade-off as it improves communication speed and fairness while increasing the total transmitted data and overall network load. Client-side bicasting, in contrast, has a minimal impact on transmitted data because only ACK packets are duplicated, but it does not significantly improve throughput as data packet loss remains unchanged.
In BBRv3, the choice among the four communication schemes should be made based on the characteristics of the application and the network condition, taking into account the trade-off between increased transmitted data, throughput, and fairness.

6. Conclusions

In this study, we proposed and implemented a novel multihomed network architecture that combines QUIC with OpenFlow to mitigate throughput reduction in lossy wireless networks. By leveraging QUIC’s flexibility in congestion control, we evaluated BBRv1 and BBRv3 across four transmission modes: unicasting, client-side bicasting, server-side bicasting, and bidirectional bicasting.
The experimental results demonstrate that both BBRv1 and BBRv3 significantly outperform TCP with CUBIC under packet loss conditions. For BBRv1, unicasting and client-side bicasting reduce file download time by 87% compared with TCP at a 1% packet loss rate, while server-side and bidirectional bicasting achieve an 82% reduction at a 10% packet loss rate. For BBRv3, unicasting and client-side bicasting reduce download time by 56% and 43%, respectively, compared with TCP at a 2% packet loss rate. At a 10% packet loss rate, BBRv3 server-side bicasting reduces download time by 40%, and bidirectional bicasting achieves a 28% reduction compared with their TCP baseline methods.
BBRv1 faces significant unfairness in unicasting, consuming most of the bottleneck bandwidth. However, client-side bicasting improves fairness by reducing ACK loss, which enables BBR to more accurately estimate network conditions and avoid excessive bandwidth consumption. BBRv3 further enhances fairness through its loss-responsive rate control, although unicasting and client-side bicasting underutilize the bottleneck bandwidth. Server-side bicasting improves throughput but slightly reduces fairness. Bidirectional bicasting achieves the best balance: reduced ACK loss enables accurate network estimation, allowing BBRv3 to utilize most of the available bandwidth while preserving fairness with competing traffic.
Among the evaluated configurations, QUIC with BBRv3 using bidirectional bicasting provides the optimal trade-off between throughput and fairness in lossy wireless networks, although it increases the overall network load.
The current implementation employs either unicasting or bicasting continuously, which increases network load even under low-packet-loss conditions. Future work should introduce a mechanism to dynamically switch between unicasting and bicasting based on real-time network conditions, such as packet loss rate and latency. Additionally, further optimization of BBRv3 is needed to improve bandwidth utilization in the proposed architecture.

Author Contributions

Conceptualization, T.K. and N.Y.; methodology, T.K.; software, T.K.; validation, T.K., R.N. and N.Y.; formal analysis, T.K.; investigation, T.K.; resources, T.K.; data curation, T.K.; writing—original draft preparation, T.K. and R.N.; writing—review and editing, T.K. and R.N.; visualization, T.K. and R.N.; supervision, N.Y.; project administration, N.Y.; funding acquisition, N.Y. All authors have read and agreed to the published version of the manuscript.

Funding

This research received no external funding.

Data Availability Statement

The original contributions presented in this study are included in the article. Further inquiries can be directed to the corresponding author.

Conflicts of Interest

The authors declare no conflicts of interest.

Abbreviations

The following abbreviations are used in this manuscript:
ACKAcknowledgment
BBRBottleneck bandwidth and round-trip propagation time
BDPBandwidth–delay product
cwndCongestion window
HTTPHypertext transfer protocol
MPQUICMultipath QUIC
MPTCPMultipath TCP
OSOperating system
RTTRound-trip time
TCPTransport layer network
UDPUser datagram protocol

References

  1. Percentage of Mobile Device Website Traffic Worldwide from 1st Quarter 2015 to 2nd Quarter 2025. Statista. Available online: https://www.statista.com/statistics/277125/share-of-website-traffic-coming-from-mobile-devices (accessed on 28 January 2026).
  2. Aniket, M.; Niklas, C.; Carey, W.; Arlitt Martin, A. Ambient interference effects in wi-fi networks. In Proceedings of the 9th IFIP TC 6 International Conference on Networking (NETWORKING’10), Chennai, India, 11–15 May 2010. [Google Scholar]
  3. Xu, L.; Ha, S.; Rhee, I.; Goel, V.; Egger, L. CUBIC for Fast and Long-Distance Networks, RFC 9438, 2023. Available online: https://www.rfc-editor.org/info/rfc9438 (accessed on 28 January 2026).
  4. Cardwell, N.; Cheng, Y.; Gunn, C.S.; Yeganeh, S.H.; Jacobson, V. BBR: Congestion-Based Congestion Control. ACM Queue 2016, 14, 20–53. [Google Scholar] [CrossRef] [Scilit]
  5. Kleinrock, L. Internet congestion control using the power metric: Keep the pipe just full, but no fuller. Ad Hoc Netw. 2018, 80, 142–157. [Google Scholar] [CrossRef] [Scilit]
  6. Ford, A.; Raiciu, C.; Handley, M.; Bonaventure, O.; Paasch, C. TCP Extensions for Multipath Operation with Multiple Addresses, RFC 8684, 2020. Available online: https://www.rfc-editor.org/info/rfc8684 (accessed on 28 January 2026).
  7. Lopez, I.; Aguado, M.; Pinedo, C.; Jacob, E. SCADA Systems in the Railway Domain: Enhancing Reliability through Redundant MultipathTCP. In Proceedings of the IEEE 18th International Conference on Intelligent Transportation Systems, Gran Canaria, Spain, 15–18 September 2015. [Google Scholar]
  8. Iyengar, J.; Thomson, M. QUIC: A UDP-Based Multiplexed and Secure Transport, RFC 9000, 2021. Available online: https://www.rfc-editor.org/info/rfc9000 (accessed on 28 January 2026).
  9. Kawana, T.; Nakagawa, R.; Yamai, N. Communication Multiplexing of Server with QUIC and SDN in Multihomed Networks. In Proceedings of the 2024 International Conference on Information Networking ICOIN, Ho Chi Minh City, Vietnam, 17–19 January 2024. [Google Scholar]
  10. Mishra, A.; Sun, X.; Jain, A.; Pande, S.; Joshi, R.; Leong, B. The Great Internet TCP Congestion Control Census. Proc. ACM Meas. Anal. Comput. Syst. 2019, 3, 1–24. [Google Scholar] [CrossRef] [Scilit]
  11. Pavur, J.; Strohmeier, M.; Lenders, V.; Martinovic, I. QPEP: An Actionable Approach to Secure and Performant Broadband From Geostationary Orbit. In Proceedings of the 28th Annual Network and Distributed System Security Symposium, NDSS 2021, Virtual Event, 21–25 February 2021. [Google Scholar]
  12. Huwyler, J.; Pavur, J.; Tresoldi, G.; Strohmeier, M. QPEP in the Real World: A Testbed for Secure Satellite Communication Performance. In Proceedings of the Workshop of the Security of Space and Satelite Systems (SpaceSec), San Diego, CA, USA, 27 February 2023. [Google Scholar]
  13. Hock, M.; Bless, R.; Zitterbart, M. Experimental Evaluation of BBR Congestion Control. In Proceedings of the IEEE 25th International Conference on Network Protocols (ICNP), Toronto, ON, Canada, 10–13 October 2017. [Google Scholar]
  14. Scholz, D.; Jaeger, B.; Schwaighofer, L.; Raumer, D.; Geyer, F.; Carle, G. Towards a Deeper Understanding of TCP BBR Congestion Control. In Proceedings of the IFIP Networking Conference (IFIP Networking) and Workshops, Zurich, Switzerland, 14–16 May 2018. [Google Scholar]
  15. Piotrowska, A. Performance Evaluation of TCP BBRv3 in Networks with Multiple Round Trip Times. Appl. Sci. 2024, 14, 5053. [Google Scholar] [CrossRef] [Scilit]
  16. Gomez, J.; Kfoury, E.F.; Crichigno, J.; Srivastava, G. Evaluating TCP BBRv3 performance in wired broadband networks. Comput. Commun. 2024, 222, 198–208. [Google Scholar] [CrossRef] [Scilit]
  17. De Coninck, Q.; Bonaventure, O. Multipath QUIC: Design and Evaluation. In Proceedings of the 13th International Conference on emerging Networking EXperiments and Technologies, Seoul/Incheon, Republic of Korea, 12–15 December 2017. [Google Scholar]
  18. Mogensen, R.S.; Markmoller, C.; Madsen, T.K.; Kolding, T.; Pocovi, G.; Lauridsen, M. Selective Redundant MP-QUIC for 5G Mission Critical Wireless Applications. In Proceedings of the IEEE 89th Vehicular Technology Conference (VTC2019-Spring), Kuala Lumpur, Malaysia, 28 April 2019–1 May 2019. [Google Scholar]
  19. Zohaib, A.; Zao, Q.; Sippe, J.; Alaraj, A.; Houmansadr, A.; Durumeric, Z.; Wustrow, E. Exposing and circumventing SNI-based QUIC censorship of the great firewall of China. In Proceedings of the 34th USENIX Conference on Security Symposium (SEC ’25), Seattle, WA, USA, 13–15 August 2025. [Google Scholar]
  20. Usage Statistics of HTTP/3 for Websites. Available online: https://w3techs.com/technologies/details/ce-http3 (accessed on 28 January 2026).
  21. Picoquic. Available online: https://github.com/private-octopus/picoquic (accessed on 28 January 2026).
  22. Speedify—Use All of Your Internet Connections at the Same Time. Available online: https://speedify.com (accessed on 20 February 2026).
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Article Metrics

Citations

Article Access Statistics

Journal Statistics
Multiple requests from the same IP address are counted as one view.
Blockchain-Enabled Decentralized End Hopping for Proactive Network Defense
Previous
On the Effect of the Time Step in Discrete-Time Framework Analysis
Next