# A Performance Evaluation of QUIC in Real-Time Networks

Matthieu Amet, Ludovic Thomas, Ye-Qiong Song

► To cite this version:

Matthieu Amet, Ludovic Thomas, Ye-Qiong Song. A Performance Evaluation of QUIC in Real-Time Networks. 32nd International Conference on Real-Time Networks and Systems (RTNS 2024), Nov 2024, Porto, Portugal. pp.255 - 265, 10.1145/3696355.3699698 . hal-04831715

HAL Id: hal-04831715

https://hal.science/hal-04831715v1

Submitted on 7 Nov 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
# A Performance Evaluation of QUIC in Real-Time Networks

Matthieu Amet

matthieu.amet@loria.fr

LORIA, Université de Lorraine, CNRS

Villers-Lès-Nancy, 54506, France

Ludovic Thomas

ludovic.thomas@loria.fr

LORIA, CNRS, Université de Lorraine

Villers-Lès-Nancy, 54506, France

Ye-Qiong Song

ye-qiong song@loria.fr

LORIA, Université de Lorraine, CNRS

Villers-Lès-Nancy, 54506, France

## Abstract

QUIC is a UDP-based transport protocol, standardized in RFC9000 (2021). It enhances privacy by encrypting entire packets and offers improvements over TCP, such as native multiplexing and connection migration. Despite these advantages, QUIC, like TCP, suffers from head-of-line blocking and variable latency, making it unsuitable for critical real-time systems.

RFC9221 addresses this by introducing an extension that allows QUIC to transmit datagrams without retransmission, improving its suitability for real-time applications. However, real-time networks require a thorough evaluation of QUIC's performance. The potential delays caused by its cryptographic operations and the complex traffic patterns it generates could impact time-sensitive traffic.

We conduct experiments using Mininet across a range of scenarios, including software updates in bandwidth-constrained environments and in the presence of malicious nodes. Additionally, we assess implementations in both Go and C. The performance of QUIC, along with its datagram extension, is compared against UDP and DTLS. Finally, the results are validated through testing on a physical network testbed.

Our results show that, despite its cryptographic overhead, QUIC performs similarly to UDP and DTLS in most cases. However, it may interact poorly with lower-layer mechanisms like token-bucket filters. Overall, QUIC shows potential to replace older transport protocols in real-time systems.

## CCS Concepts

* **Networks** → *Network performance analysis*; *Transport protocols*; *Network experimentation*; *Network measurement*.

## Keywords

QUIC, Network, Performance, Latency, Real-time, Reliability, Evaluation

## ACM Reference Format:

Matthieu Amet, Ludovic Thomas, and Ye-Qiong Song. 2024. A Performance Evaluation of QUIC in Real-Time Networks. In *International Conference on Real-Time Networks and Systems (RTNS '24), November 6-8, 2024, Porto, Portugal*. ACM, New York, NY, USA, 11 pages. https://doi.org/10.1145/3696355.3699698

## 1 Introduction

Real-time networks are used in cyber-physical systems for interconnecting sensors, processing units, and actuators. They support safety-critical and security-critical applications [1] such as control loops in avionics [2, 3], industrial automation [4] and automotive industry [5].

To do so, real-time networks provide a deterministic service with a guarantee on the maximum transmission time of the data from a sending application to one or several receiving applications [6, §3.1]. By definition, a failure occurs whenever the network fails to deliver the data within this guaranteed maximum. The rate of network failures is then constrained by stringent probability requirements that depend on the industrial application and on the criticality of the data. RFC8578 [7] lists common requirements for the failure rates in various industrial applications including audio and video broadcast, electrical utilities, and industry automation.

Offering a guaranteed end-to-end (E2E) transmission time from application to application requires the participation of all layers of the Internet's layered model. Over the years, important work has been carried out on the link layer for both wireless and wired links. The 3rd Generation Partnership Project (3GPP) and the time-sensitive networking (TSN) working group of the Institute of Electrical and Electronics Engineers (IEEE) have developed schedulers and resource-sharing mechanisms to enable the deterministic service at the link layer and allow for the concurrent support of mixed-criticality flows [8, 9]. At the network layer, the deterministic networking (DetNet) working group of the Internet Engineering Task Force (IETF) addresses the growing need for real-time networks that span multiple subnets by developing an architecture for time-sensitive flows [6].

However, little work has been carried out on the transport layer since 1981. Most real-time networks use the user datagram protocol (UDP) and the transmission control protocol (TCP). The former merely offers a multiplexing feature (through port numbers) and is preferred for time-sensitive flows due to its lightweight nature, which minimally contributes to the E2E latency [10]. Deploying time-sensitive applications over a full UDP/IP stack comes with some overhead for the latency but allows for seamless integration with existing hardware, simplified debugging, and greater familiarity for engineers. This is a common practice even for air-gaped networks that cover a single subnet [10].

In addition, there exists a need for large-scale real-time networks, such as in smart-grid systems, factory automation and other uses-cases listed in RFC8578 [7]. The DetNet working group answers to these needs by specifying "*a set of technologies that enable creation of deterministic flows on IP-based networks of a potentially wide area* [...] potentially merging [*time-sensitive*] operational technology (OT) traffic with best-effort information technology (IT) traffic, and placing OT network components into contact with IT network

<footnote>Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for third-party components of this work must be honored. For all other uses, contact the owner/author(s).

RTNS '24, November 6-8, 2024, Porto, Portugal

© 2024 Copyright held by the owner/author(s).

ACM ISBN 979-8-4007-1724-6/24/11

https://doi.org/10.1145/3696355.3699698</footnote>
components, thereby exposing the OT traffic and components to se-
curity threats that were not present in an isolated OT network" [11,
§1]. The transport layer plays an important role in addressing these
security challenges. For example, it can provide encryption, as with
datagram transport layer security (DTLS). Yet the deployment of
transport-protocol stacks that meet the security requirements of
future real-time networks on both OT and IT hardware affects the
guaranteed latency of time-sensitive flows. This effect must be
evaluated to guarantee the deterministic service.

In this context, the QUIC transport protocol [12] represents an
opportunity. Introduced by Google in 2012, it already replaces TCP
in version 3 of the hypertext transfer protocol (HTTP). Designed
with decades of experience in network security, it also supports
both data streams and datagrams [13]. Its approach based on the
user space of computer systems ensures its widespread deployment,
already reaching millions of smartphones and computers. Hence,
QUIC represents an interesting candidate for supporting both OT-
to-OT time-sensitive traffic and OT-to-IT best-effort traffic.

In this paper, we evaluate the suitability of the QUIC protocol
combined with its datagram extension [13] (which we call QUIC DG
in this paper) for real-time networks. To the best of our knowledge,
this paper is the first to present latency-performance results for
this datagram extension, and more broadly, to offer an analysis of
QUIC's application in real-time networks. We focus on a typical use
case of real-time networks: the smart-grid systems. In [7, §3], the
specifications for teleprotection applications in smart-grid systems
require 99.9% of packets to reach their destination within 5ms.
Hence, we compare the distribution tail of the one-way delay for
packets sent with QUIC DG, UDP and DTLS and compare their
performance at the 99.9th percentile.

Our main contributions are:

* We assess QUIC DG's time overhead on the datagram encapsu-
  lation and encryption and compare it with DTLS and UDP. Our
  findings reveal that transitioning from UDP or DTLS to QUIC DG
  introduces a small delay, that is less significant than the delay in-
  curred when switching the programming languages used for the
  implementation of the protocols.

* We characterize the interactions between QUIC DG and lower-layer quality of service (QoS) mechanisms (schedulers and filters). We find that these interactions do not lead to dramatic latency increase.

* We develop a testbed on which we validate our analysis on a real-life case study. We find that QUIC DG is suitable to replace older protocols but can lead to negative interactions when combined with a traffic filter.

The paper is organized as follows. We provide the necessary
background on QUIC in Section 2 by comparing its features with
respect to TCP, UDP and DTLS and discuss the related work on
QUIC's performance analysis in Section 3. We then compare the
latency overhead introduced by QUIC DG with respect to UDP and
DTLS in Section 4. In Section 5, we investigate the interactions
between QUIC and lower-layer QoS mechanisms on typical sce-
narios of real-time networks for smart-grid systems and evaluate
the suitability of QUIC DG in real-time networks in comparison to
UDP and DTLS. We then validate QUIC DG's performance based
on a real-life case study in Section 6. We provide our conclusive
remarks in Section 7.

2 Background on QUIC

QUIC is a recent transport protocol introduced by Google. It is
similar to TCP [14] and was standardized by the IETF in 2021.
QUIC is constructed upon UDP [15] to maintain compatibility with
existing Internet infrastructure.

The QUIC protocol is detailed in RFC8999 [16], RFC9000 [12], RFC9001 [17] and RFC9002 [18]. These documents delineate the differences between versions, the constant properties across versions, detailed protocol operations, cryptographic methods, and mechanisms for loss detection and retransmission.

QUIC replicates some fundamental behaviors of TCP, such as
loss detection, retransmission of lost packets, and in-order deliv-
ery. It also introduces several default features that enhance both
performance and security. For example, QUIC mitigates the head-
of-line (HOL) blocking, which occurs when the delay of one packet
impedes on the processing of subsequent packets. It does so by
multiplexing multiple data streams within a single connection and
by allowing for their concurrent transmission. Additionally, QUIC
enhances the connection handshake by accomplishing both connec-
tion establishment and security negotiation in a single handshake,
whereas TCP necessitates a separate handshake for security (using
TLS). This improvement significantly reduces the time to establish
a connection in QUIC when compared to TCP. Furthermore, QUIC
offers enhanced security compared to TCP by encrypting the entire
packet including its content and part of the header.

In addition to these core features, QUIC includes several capa-
bilities that are optional in TCP. For instance, QUIC allows greater
control over data transmission by inherently supporting both bidi-
rectional and unidirectional data streams. It can seamlessly manage
changes in a client's IP address (such as those occuring when a
user transitions between different networks) by using unique con-
nection identifiers to specify a connection. QUIC also incorporates
built-in congestion-control algorithms to avoid network congestion.
Its selective-acknowledgment capability allows QUIC to specifically
identify lost packets, thus avoiding unnecessary retransmissions.

These features position QUIC as a faster and more secure alter-
native to TCP and form the basis of the new HTTP/3 [19] protocol.
Recently, an extension of QUIC has been introduced to support unre-
liable datagram transmission over the network. RFC9221 [13], stan-
dardized recently, facilitates the use of QUIC in practical real-time
networking environments. This extension is particularly beneficial
for scenarios where retransmission is not required. The extension
still provides for the detection of losses for applications that might
require it. In this paper, we denote by QUIC DG the use of the
protocol QUIC with its datagram extension.

UDP is used in real-time networks due to its minimal latency and
low overhead [20, 21]. This makes it suitable for applications where
speed is critical and occasional packet loss is acceptable. However,
UDP lacks built-in security features, which can be a limitation for
certain use cases. The DTLS protocol [22] is another protocol that
offers an alternative to UDP by encrypting the content of a packet.
Similar to QUIC, DTLS is based on UDP but focuses on encrypting
the data without the overhead of loss detection and retransmission.

When comparing DTLS to QUIC DG, there are notable differ-
ences. While both protocols are built on UDP and provide encryp-
tion, QUIC DG distinguishes itself with additional features. These
include the use of a congestion-control algorithm and the ability to transmit both reliable streams and unreliable datagrams within the same connection. Furthermore, QUIC (and by extension QUIC DG) uses TLS 1.3, which supports the updating of cryptographic keys during a connection. Additionally, QUIC regularly updates its connection identifiers after the connection is established. This results in additional traffic that can interfere with the current use case and requires slightly more bandwidth than the other protocols such as UDP and DTLS.

In conclusion, QUIC is designed to be a more efficient and secure protocol than TCP, with built-in features that enhance its performance. It is used for the new HTTP/3 protocol and includes extensions that provide interesting potential for time-sensitive applications.

## 3 Related Work

Since its development, numerous performance analyses have been conducted on the QUIC protocol. As QUIC was primarily designed for web applications, the majority of these analyses focus on metrics such as the page load time (PLT) and round-trip time (RTT) [23, 24]. These studies compare the performance of QUIC against TCP, either locally [25] or by using internet endpoints to establish a benchmark. The evaluations typically involve the use of HTTP/3 over QUIC in both real and controlled environments. Additionally, some of these analyses examine the throughput of QUIC and TCP by downloading files of varying sizes, and thus provide further insights into their relative performance [26].

Some performance evaluations, like the work by Bulgarella et al. [27], attempt to measure the performance of QUIC before its standardization, which means that some details may differ from subsequent studies. They focused on measuring delay by modifying certain bits that are "in clear", such as the spin bit, and introduced a delay bit of their own. The spin bit toggles based on the communication between the receiver and the sender. Through these modifications, Bulgarella et al. were able to approximate the RTT at the transport level, thus providing an estimation of QUIC's performance.

In [28], Wang et al. implemented the QUIC protocol in the Linux Kernel and compared its performance against TCP. This study provides valuable insights into the practical performance differences between QUIC and TCP in a controlled Kernel environment.

A closely relevant study for our use case is presented in [29], where Han et al. introduce MPR-QUIC, a derivative of QUIC designed to support partially reliable data transmission over multipath networks. In MPR-QUIC, frames are selectively resent only if a specific deadline has not elapsed, which allows for situations where some sent data may not reach the server, diverging from QUIC's standard reliability model. Through a thorough performance analysis, the authors concluded that MPR-QUIC outperforms the original QUIC protocol based on quality of experience (QoE) metrics.

In essence, these studies explore how QUIC performs across different network conditions. They use methodologies such as RTT calculation from specific bits or application-level data analysis. Additionally, while previous analyses focus solely on the QUIC protocol, our research expands to include the evaluation of the unreliable datagram extension [13]. Indeed, our goal is to provide a

bounded latency, especially for stringent real-time communications where TCP (and even QUIC streams) might introduce delays due to HOL blocking. Hence, we are evaluating the use of the unreliable extension of QUIC in our test bed.

The concept of using QUIC with unreliable datagrams was initially proposed in [30]. The first practical implementation and proof of concept were carried out in [31], where the authors optimized QUIC for real-time multimedia traffic. They leveraged QUIC's multiplexing capability to transmit portions of an image at specific times. By using multiplexing, they effectively avoid HOL blocking, as the application could concurrently receive datagrams on separate streams. Moreover, they minimized unnecessary retransmissions of payloads that had already been sent.

In [32], Kanagarathinam et al. introduced an implementation of QUIC that integrates unreliable streams (*ustream* frames), enabling the multiplexing and transmission of datagrams. These *ustream* frames maintain a format similar to standard QUIC streams. Subsequently, the authors performed a performance evaluation of their protocol to assess its effectiveness.

Another approach to transmitting unreliable data over QUIC is detailed in the paper by Ravuri et al. [33]. Their study introduces a framework for sending partially reliable data by leveraging QUIC and HTTP/3. Through experimental evaluations, they assess the effectiveness of this framework.

The datagram extension for QUIC [13] (called QUIC DG in the current paper) was eventually published in 2022. It has gathered interest for soft real-time applications such as live streaming over the Internet. In [34, 35], Baldassin et al. evaluate the performances of encapsulating the real-time transport protocol (RTP) inside QUIC datagrams based on a now-expired Internet draft [36]. In particular, they analyze the interactions between QUIC's congestion control and the application-level congestion control implemented in the RTP client when streaming a video. They focus on performance metrics such as the video encoding bitrate, but not on the latency. To our knowledge, our work is the first to evaluate the latency performances of QUIC's datagram extension.

All the studies we have reviewed focus on soft real-time applications such as video games, video conferencing, streaming, multimedia, and web browsing, where timely delivery is important but occasional extra delays are generally tolerable. None of them address hard real-time applications that require highly reliable and deterministic performance. As such, the existing studies primarily focus on simple stochastic measures of performance metrics such as the mean, median, or quartiles. These indicators overlook worst-case scenarios: As opposed to UDP [37], there exists no work that addresses a worst-case delay analysis of QUIC.

Our study bridges this gap by emphasizing on the distribution tail of QUIC's latency. To our knowledge, this paper is the first to provide analyses of the performance of QUIC in real-time networks.

## 4 Evaluating the Time Overhead of QUIC

This section assesses the time overhead introduced by the QUIC DG protocol. The experiment is designed to precisely measure the execution time attributed to the protocol itself, with no concurrent flows or network-induced delays. The setup assumes links
with infinite capacity and considers only the time induced by the protocol.

First, we define the network topology and the metrics utilized. Next, we describe the test environment employed for the experiments. Finally, we discuss the results obtained.

## 4.1 Network Topology and Traffic Setup

To assess the performance of QUIC DG in a real-time network, we utilize a representative topology of a smart-grid network as depicted in Figure 1. This topology reflects the common architecture found in smart-grid networks [38], including two phasor measurement units (PMUs), one remote terminal unit (RTU), and one phasor data concentrator (PDC). The two PMUs connect to a switch labeled SW1, which is linked to the router R1, and R1 is subsequently connected to the PDC.

<figure><img src="image_2.png" /><figcaption>Figure 1: Network topology used as a testbed. It consists of PMU1, PMU2, and RTU connected to a switch (SW1), that is connected to a router (R1), and then to a PDC. This topology is representative of a smart-grid network.</figcaption></figure>

In this configuration, each PMU collects phase-angle measurements every 10 milliseconds and sends them to the PDC. To simulate the collected data we create a payload that includes the system's time in nanoseconds, padded with blank bytes (0x00) to reach a total of one thousand bytes. This results in a payload of one thousand bytes being transmitted every 10 milliseconds. Upon receiving a packet from a PMU, the PDC calculates the one-way trip delay by subtracting its current time from the time received in the payload.

## 4.2 Test Environment

To understand the performance of QUIC DG in real-time networks, we compare it against UDP and DTLS. UDP is known for its low latency, making it popular in real-time networking [10, 37], while DTLS adds encryption to UDP for enhanced security. As QUIC also includes encryption, this comparison evaluates the encryption overhead between DTLS, UDP, and QUIC.

To assess this overhead, we use two implementations of each protocol in two different programming languages (C and Go). For QUIC, we utilize QUIC-Go [39] for Go and MsQuic [40] for C. For DTLS, we use Pion DTLS [41] for Go and [42] for C. Lastly, for UDP, we rely on the Go UDP package for Go and on a traditional socket implementation in C.

In Sections 4 and 5, we use the Mininet network emulator [43] to test the time each protocol requires to operate within the specified network topology. We use Mininet's default settings, which does not alter bandwidth: Link capacity is based on processor speed. This avoids introducing additional delays or technological latencies that could affect the results. Our setup provides a controlled environment for evaluating the operational time of QUIC DG, UDP, and DTLS from application to application.

We use the virtual machine (VM) provided by the Mininet website [43] with system upgrades. The upgraded Mininet VM runs Ubuntu Noble 24.04 LTS. We conducted initial tests to compare the performances on a Kernel version 6.6.30 with and without real-time patches [44] and observed no significant differences. Therefore, this paper only reports results from the non-real-time version on the subsequently updated Kernel 6.8.0.

All hosts within the topology in Figure 1 are synchronized, as Mininet's design ensures consistent timekeeping across the entire network. This synchronization is a result of running the emulation on a single machine. Tests are performed using multiple clones of the VM, each equipped with a 4-core 2 GHz processor and 8 GB of RAM. This setup allows us to run multiple tests simultaneously, particularly for long-duration tests. Overall, it provides a robust and reliable environment for accurately assessing the performance of QUIC DG within our network topology.

## 4.3 Results

The results of the experiment are shown in Figure 2. This figure represents the cumulative distribution function (CDF) of the one-way delay from application to application. The results are based on 2 million packets to ensure that rare events are sufficiently frequent to be observable. This helps verify that both packet loss and the percentage of packets arriving outside a 5ms window remain below 0.1%, as specified in [7, §3].

The plot compares three protocols — QUIC DG (green), DTLS (orange), and UDP (blue) — across two implementations: C and Go. Each curve represents an experiment of a protocol in a specific language implementation. Solid lines indicate the implementation in C, while dashed lines represent the implementation in Go. The y-axis shows the packet delivery rate ($\lambda_{packets}$), which is the proportion of packets received within the corresponding delay. The x-axis displays time in milliseconds. Each curve in the plot is accompanied by a 95% confidence interval [45] based on the independent and identically distributed random variables (i.i.d.) hypothesis. This inclusion enhances the robustness of the findings.

When examining the plot, we can delineate two distinct spaces: one for the C implementations (left) and one for the Go implementations (right). In both cases, we can assert that UDP, represented by the blue lines, achieves the highest packet delivery rate the quickest. Similarly, in both implementations, DTLS, indicated by the orange lines, follows UDP, showing a slight extra delay due to its encryption overhead. QUIC DG, shown by the green lines, exhibits the most significant delay among the three protocols but still achieves a high packet delivery rate.

The transition from UDP to DTLS and from UDP to QUIC DG in both implementations demonstrates the impact of adding encryption. Moreover, the delay shift at a specified packet delivery
<figure><img src="image_3.png" /><figcaption>Figure 2: Results with unlimited links and no interfering traffic. Cumulative distribution function of the one-way delay with QUIC DG, UDP, and DTLS protocols in C and Go languages over the network topology shown in Figure 1, based on the results from transmitting 2,000,000 packets using Mininet.</figcaption></figure>

rate from UDP to DTLS and UDP to QUIC DG is relatively consistent, indicating a predictable performance cost associated with encryption. The horizontal dashed line at $y = 0.9990$ represents the 99.9th percentile of the sample and highlights the differences in guaranteed delays for 99.9% of the packets across the protocols.

The analysis shows that UDP, which lacks encryption, unsurprisingly achieves the highest packet delivery rates with minimal delay. DTLS, which adds encryption, introduces a slight delay, and QUIC DG, with more extensive features and default encryption, shows the most considerable delay among the three protocols. However, the delay introduced by QUIC DG is comparable to the delay between UDP and DTLS. Despite the added encryption and features of QUIC DG, the performance degradation remains within an acceptable range. The consistency of the results across different implementations suggests that, despite its encryption overhead, QUIC DG's behavior is predictable and similar to other protocols, even in the worst case. This provides confidence that QUIC DG will not exhibit critical performance issues in further sections of the study.

Although transitioning from UDP to DTLS or from DTLS to QUIC DG incurs a performance cost, this cost is relatively minor compared to the performance impact of switching between different programming languages. Thus, the observed performance overhead is manageable and does not overshadow the benefits of using QUIC DG. Since Go's performance closely mirrors that of C

with only a slight delay, we focus exclusively on the results from the C implementation for the remainder of the paper.

## 5 Interactions between QUIC and the Lower-Layer QoS Mechanisms

In this section we evaluate the use of QUIC DG by examining two scenarios commonly encountered in smart-grid systems. Given that QUIC's packet size can vary due to packets' content, it is crucial to consider how the interactions of these properties with lower layers might affect the real-time performances of QUIC DG. Unlike UDP and DTLS 1.2, QUIC introduces regular updates of the connection identifiers throughout the connection. These updates may affect layer two and three mechanisms. To investigate these interactions with lower layers, we conduct experiments that involve concurrent flows, bandwidth limitations, QoS mechanisms, and varying levels of network noise. Additionally, in line with RFC8578 [7, §3], all packets must arrive within a 5ms deadline otherwise they are considered lost.

The following subsections define and analyze two different scenarios.

### 5.1 Behavior of QUIC DG over a Fixed-Priority Queue

Using the topology defined in Figure 1, we explore a common smart-grid scenario where software upgrades are performed from the RTU to the PDC while time-sensitive data continues to be transmitted from the PMUs to the PDC. In this scenario, it is typical for the network to employ a fixed-priority queue that prioritizes time-sensitive data to avoid significant delays. This setup allows us to assess QUIC's performance under the influence of a fixed-priority queue.

To set up the scenario, we use the same Mininet-defined structure but limit the link from R1 to the PDC to 8 megabits per second. By using traffic-control rules, we configure a queue discipline on the router R1 to prioritize the PMUs that send time-sensitive data. As detailed in Section 4, the PMUs send a payload of one thousand bytes every 10ms. Immediately after starting the experiment, we initiate a large TCP download from the RTU to the PDC to simulate a best-effort network load that represents a software upgrade running throughout the experiment.

The results of the experiment are shown in Figure 3. UDP (blue line) achieves the highest packet delivery rate with the least delay, crossing the 99.9% delivery threshold at around 3.25ms. DTLS (orange line), follows closely, with slightly more delay at 3.3ms but still far away from the 5ms mark. QUIC DG (green line) shows the highest delay among the three protocols, crossing the 99.9% delivery threshold at around 3.7ms. Although QUIC DG shows a slightly higher delay compared to UDP and DTLS, all three protocols successfully meet the 99.9% delivery requirement within the 5ms threshold.

We observe that DTLS and UDP exhibit very similar performance, with only a slight difference between them. This minor discrepancy can be attributed to the time overhead introduced by DTLS's encryption process. However, there is a noticeably negative effect on QUIC DG's performance. The performance gap between QUIC DG
<figure><img src="image_4.png" /><figcaption>Figure 3: Results with a priority queue at R1. Cumulative distribution function of the one-way delay with QUIC DG, UDP, and DTLS protocols over the network topology shown in Figure 1.</figcaption></figure>

and DTLS in Figure 3 is significantly larger than the difference observed in Figure 2. This indicates that while QUIC DG's encryption is indeed more complex than DTLS (as discussed in Section 2 and demonstrated in Figure 2), encryption alone does not fully account for the reduced performance of QUIC DG observed in Figure 3.

The increased complexity of QUIC DG's traffic pattern compared to DTLS could explain the observed differences. This complexity is largely due to the frequent updates of connection identifiers (see Section 2), which DTLS does not perform. In MsQUIC, these updates occur as frequently as every 20 seconds. This difference in traffic-pattern structure may contribute to the observed performance variation: larger and varying packet sizes with QUIC DG lead to a higher burst for the QUIC DG flow, which worsens its maximum delay at R1.

Though slightly worse, QUIC's performance in terms of packet delivery rate and delay remains comparable to that of other protocols. In particular, QUIC DG still performs within acceptable limits, staying under the critical 5ms threshold at 99.9%. The most significant differences between QUIC DG and the other protocols occur at higher percentiles, meaning on very rare occasions. A large portion of the traffic is not affected by these outliers, as indicated by the relatively small differences between the curves for QUIC DG and those for DTLS/UDP below 99.9%.

In summary, the cross-layer interactions introduced by QUIC DG's more complex traffic pattern result in slightly higher delays compared to other protocols. However, this effect is limited and

does not critically impact its performance with respect to the requirements of RFC8578 [7, §3]. The protocol's behavior remains within acceptable bounds. Thus, we demonstrate that in scenarios involving priority queues, QUIC DG performs adequately, proving that its additional features and encryption overhead do not lead to a significant performance cost.

## 5.2 Behavior of QUIC DG over a Token-Bucket Filter (TBF)

Using the topology defined in Figure 1, we now explore another common smart-grid scenario where one PMU transmits excessive data while time-sensitive data from the other PMU continues to be transmitted to the PDC. To prevent network inefficiencies and ensure proper operation, it is common to implement a token-bucket filter (TBF) [46]. This subsection examines how QUIC performs in this kind of environment.

To set up the scenario, we maintain the Mininet-defined structure and limit the link from R1 to the PDC to 2 megabits per second, which makes it the bottleneck. To prioritize the time-sensitive data, we configure a queue discipline on router R1 by applying traffic-control rules that give precedence to packets from the two PMUs over any other traffic. Additionally, a TBF is set up on each PMU using traffic-control rules to limit the sending rate to 1100 bytes every 10ms, which corresponds to 880 kbit/s. This restriction is necessary to avoid any overcapacity situation of the 2 Mbit/s link: A normal-behaving PMU sends packets with a maximum size of 1100 bytes every 10ms, which leads to approximately 1.6 Mbit/s of traffic on the link (R1, PDC) for two normal-behaving PMUs.

To simulate excessive data transmission, PMU2 in this scenario sends twice as many packets, each with a payload of 1000 bytes. This effectively doubles its transmission rate, which would create an overcapacity situation on the (R1, PDC) link if the TBF were not in place. This setup allows us to observe how QUIC DG's time-sensitive data is prioritized under these conditions and ensures that the transmission from the properly functioning PMU is not compromised.

The results of the experiment are illustrated in Figure 4. UDP (blue line) consistently achieves the highest packet delivery rate with the least delay, reaching the 99.9% delivery mark at approximately 1.7ms. DTLS (orange line) follows closely, with a slightly increased delay, crossing the 99.9% threshold around 2ms. QUIC DG (green line), shows the most significant delay among the protocols, with the 99.9% delivery rate achieved at 2.5ms. Despite these differences, all protocols manage to meet the 99.9% delivery threshold before the critical 5ms mark.

All protocols exhibit better performance in Figure 3 compared to Figure 4, primarily due to the absence of a best-effort TCP flow. This absence eliminates the non-preemption delay in R1, the effects of which are noticeable on the E2E in Figure 4. However, the delay differences between the protocols are more pronounced in this experiment. Under bandwidth-limited conditions, UDP maintains its speed advantage due to the lack of encryption, while DTLS experiences some delay due to its security features. The significant delay increase for QUIC DG after the 99.9% threshold, compared to DTLS, highlights that although QUIC DG provides enhanced features and security, these benefits come with a noticeable performance cost.
<figure><img src="image_5.png" /><figcaption>Figure 4: Results with a TBF on each PMU. Cumulative distribution function of QUIC DG, UDP, and DTLS protocols over the network topology shown in Figure 1, based on the results from transmitting 2,000,000 packets.</figcaption></figure>

in constrained conditions. This suggests that the factors impacting QUIC DG performance identified in Section 5.1 become more pronounced when a TBF is implemented in the network. It underscores the significant impact of QUIC DG's encryption and additional features on network performance when used with a token-bucket filter and in the presence of a malicious node.

As discussed in Section 5.1, the complexity of QUIC DG's traffic pattern, driven by frequent updates of connection identifiers (every 20 seconds in MsQUIC), contributes to these increased delays. The experiment in this section highlights the importance of evaluating both network capacity and traffic patterns when assessing protocol performance. For protocols like QUIC DG, which feature extensive functionality and encryption, understanding their effect under various conditions is crucial for making informed deployment decisions. We will further investigate QUIC's performance in real-life network environments in the remaining section of the paper.

# 6 Experimentations on a Real-Life Case Study

This section examines the performance of QUIC DG in a real-world setting by replicating the previous experiments within a physical test environment. We conduct two real-life experiments to validate the performance of QUIC under conditions with no interfering traffic and to further investigate a scenario with more pronounced performance contrasts.

First, we describe our test environment in detail. Then, we analyze the results of the experiments conducted in this section to

assess QUIC DG's performance and its behavior in practical, physical conditions compared to the simulated scenarios.

## 6.1 Test Environment

The testbed is composed of multiple Raspberry Pis and an NXP Switch LS1028ARDB, configured as follows:

* The PMUs and the PDC are Raspberry Pi 5 devices

* The RTU is a Raspberry Pi 3

* The router (R1) is a Raspberry Pi 4

* The switch (SW1) is a TSN NXP Switch LS1028ARDB

All Raspberry Pis run the Raspberry Pi OS Lite 64-bit version from March 15, 2024, with Kernel Version 6.6.20 based on Debian 12 Bookworm. The testbed follows the topology defined in Figure 1, with all hosts connected via Cat 5e Ethernet cables, supporting speeds of up to 1 Gbps.

Time synchronization between the PMUs and the PDC is crucial for accurate calculation of the one-way delay, that is determined by subtracting the packet send time from the packet reception time. To achieve this synchronization, we use the precision time protocol (PTP) [47] with Raspberry Pi 5 for the PMUs and the PDC. This Raspberry Pi model is equipped with hardware clocks on the Ethernet interface, which significantly reduces the margin of error in time synchronization between hosts. The TSN NXP switch (SW1) serves as the grandmaster clock for the PTP, as it is also equipped with hardware clocks on its Ethernet interfaces. To enhance synchronization accuracy, an additional cable directly connects SW1 to the PDC for synchronization purposes only (Figure 1), which removes any hops between the NXP grandmaster and the hosts to be synchronized.

For the experiment in Section 5.1, it is essential to prevent a bottleneck between SW1 and R1 to ensure that SW1 does not drop any packets. On Mininet, we configured the limiting link to be only between R1 and the PDC, avoiding this bottleneck. However, replicating this setup in real-life scenarios is challenging due to the lack of adequate equipment, as the experiment requires infinite bandwidth between the PMUs and R1 for accuracy. To maintain consistency with the Mininet experiment, we opted not to implement a priority queue on the switch. Instead, the fixed-priority queue remains at R1, which makes replication of the experiment defined in Section 5.1 unfeasible under these conditions.

We conducted all experiments twice with 100,000 sent packets each. This approach allows us to verify the independence of the one-way delays and ensure the consistency of the results.

## 6.2 Experiment Without Interfering Traffic

To gain an initial understanding of how our network setup functions under a real environment in ideal conditions, we first run the network without any concurrent flows or noise. In this setup, each PMU sends a packet every 10 milliseconds, mirroring the conditions described in Section 4, without the presence of any parallel traffic. This allows us to observe the baseline performance of the system and establish a reference point for further experiments.

Figure 5a shows the first experiment we conducted, while Figure 5b presents the second performed with identical settings. UDP (blue line) is the first to cross the 99.9% threshold in both experiments at 0.62ms in the experiment of Figure 5a and at 0.78ms in
<figure><img src="image_6.png" /><figcaption>Figure 5: Results of two experiments of 100,000 packets following the scenario of Section 4. Cumulative distribution functions of QUIC DG, UDP, and DTLS protocols over the network topology shown in Figure 1.</figcaption></figure>

<figure><img src="image_7.png" /><figcaption>Figure 6: Results of the two experiments of Figure 5 merged into a single curve of 200,000 packets. Cumulative distribution function of QUIC DG, UDP, and DTLS protocols over the network topology shown in Figure 1.</figcaption></figure>

experiment of Figure 5b. We observe that the rare cases (over 99.9%) experience higher delays in the second experiment compared to the first one. DTLS (orange line) follows by crossing the 99.9% threshold at around 0.85ms in the first experiment and 0.81ms in the second experiment. QUIC DG (green line) follows then by crossing the 99.9% threshold at 0.9ms for the first experiment and 1.08ms for the second experiment. Again, all of the protocols manage to meet the 99.9% delivery threshold before the critical 5ms mark.

We observe that the curves differ between Figures 5a and 5b, and their confidence intervals do not intersect, which undermines the i.i.d. hypothesis [45, §2]. In Section 6.3, we dive deeper into a possible explanation for this lack of independence. However, to gain initial insights into QUIC DG's performance in real-time networks, we now examine the distribution-tail trends by merging the samples from Figures 5a and 5b into a single dataset showed in Figure 6.

The main trend reveals that the performances of QUIC DG (green line), DTLS (orange line), and UDP (blue line) are quite similar, particularly at the high percentiles. This consistency at high percentiles suggests that all the protocols offer comparable performance in terms of maximum delay.

We observe a reduction in delay compared to the Mininet emulation. Indeed, in a Mininet emulation, a single processor handles encryption and decryption tasks for all hosts. In our simulation, each real host naturally enjoys its own processor, allowing for more effective management of these tasks. In this topology, we are well below the 5ms objective and comfortably exceed the 99.9% delivery rate. Packets with a one-way delay exceeding the 5ms deadline are extremely rare. The vast majority of packets arrive in less than 1ms.

Broadly speaking, the real-life experiment without interfering traffic confirms the experiment we emulated in Mininet. All the protocols in the experiment cross the 99.9% threshold before the critical 5 ms mark. This reinforces the reliability of QUIC DG for use in real-time networks.

## 6.3 Experiment With a Token-Bucket Filter (TBF)

For the second set of experiments, we decide to replicate the conditions from Section 5.2. This choice is based on the curves from Figure 4, which reveal the most significant differences between the protocols compared to other scenarios. Moreover, as explained in Section 6.1, it is necessary to have a non-limiting link between SW1 and R1 to reproduce the scenario from Section 5.1. For this reason we focus here on the experiment of Section 5.2, whose implementation is more straightforward with respect to our available equipment.

With traffic-control rules, we consider a fixed-priority queue on R1 that prioritizes PMU1 and PMU2. Then, still using traffic-control rules we implement a TBF on each PMU to limit them from sending more than 1100 bytes every 10ms, which corresponds to 880 kbit/s. We mirror the experiment in Section 5.2 by configuring one PMU to be malicious: It sends twice as many packets. We conduct again two identical experiments, each involving the transmission of 100,000 packets.

Figures 7a and 7b display the results of the two experiments conducted. As observed, the outcomes show significant differences between the experiments. In both experiments, UDP (blue line) crosses the 99.9% threshold first, at 0.56ms in Figure 5a and at 0.79ms in Figure 5b. DTLS (orange line) follows, reaching the 99.9% threshold at approximately 0.57ms in the first experiment and 0.82ms in the second. QUIC DG (green line) then crosses the 99.9% threshold
<figure><img src="image_8.png" /><figcaption>Figure 7: Results of two experiments of 100,000 packets following the scenario of Section 5.2. Cumulative distribution functions of QUIC DG, UDP, and DTLS protocols over the network topology shown in Figure 1.</figcaption></figure>

at 0.84ms in the first experiment but significantly lags in the second experiment, reaching 5.20ms. Notably, the second experiment of QUIC DG fails to meet the 99.9% delivery threshold before the critical 5ms mark.

As we can see, the confidence intervals do not overlap between Figure 7a and Figure 7b, which violates the i.i.d. hypothesis. By diving into the logs of the second experiment we observe a significant delay affecting one packet. This delay cascaded to subsequent packets, as indicated by the gradual decrease in latency, suggesting a buffer-emptying process. Hence the HOL blocking in buffers is the main reason behind the violation of the i.i.d. hypothesis.

In the following, we will merge the data from both experiments to derive trends and insights on the behavior of QUIC DG.

Figure 8 illustrates the results of merging the two experiments from Figure 7 into a single dataset. In this combined experiment, UDP (blue line) crosses the 99.9% threshold at 0.78ms, DTLS (orange line) crosses it at 0.80ms, and QUIC DG (green line) crosses at 0.95ms. This shows more significant differences in QUIC DG's performance compared to the other protocols beyond the 99.9th percentile. These observations suggest that QUIC's more complex traffic pattern, compared to UDP and DTLS, might interact negatively with the queuing discipline of the lower layers, indicating a need for further investigation.

A plausible explanation is that the presence of a TBF's queue overflow results in backpressure on the application, triggering a blocking mechanism instead of dropping packets. This blocking mechanism is specific to our QUIC implementation (MsQUIC [40]): If the QUIC socket indicates that it cannot accept a new packet, MsQUIC retains the packet until the next allowable transmission opportunity. To support this explanation, we observe that the malicious PMU, which is configured to intentionally overflow its own TBF, experiences continuously increasing one-way delays, reaching more than 100,000ms by the end of the experiment. This suggests that the malicious PMU's application has withheld the excessive packets instead of dropping them. In response, we opened a pull request<fnref n="1" /> for MsQUIC to drop a datagram when a message cannot

<figure><img src="image_9.png" /><figcaption>Figure 8: Results of the two experiments of Figure 7 merged into a single curve of 200,000 packets. Cumulative distribution function of QUIC DG, UDP, and DTLS protocols over the network topology shown in Figure 1.</figcaption></figure>

be sent. This proposed update makes MsQUIC more suitable for time-sensitive applications.

Another hypothesis is that the delay could have occured because a processor might have been preoccupied with tasks other than packet routing, leading to a buffer overflow until it could resume normal processing. It is unclear if this situation could have occured with other protocols as the exact cause of the delay remains unknown.

In addition, below the 99.9% threshold, all protocols exhibit similar performance characteristics. Overall, our real-life experiments confirm the need for caution with TBF interactions, indicating potential implications for QUIC DG's behavior in real-time environments. However, these results also validate that up to the 99.9% delivery rate threshold demanded by smart-grids [7], QUIC DG is suitable for use in such systems. This demonstration underscores the reliability of QUIC DG in smart-grid applications, though further scrutiny is recommended when implementing traffic-control measures like TBF.

## 7 Conclusion

In this paper, we aim to raise awareness about the use of QUIC in real-time networks by conducting experiments in both an emulated environment and a real-life testbed. We analyzed the performance of QUIC's datagram extension (QUIC DG) in various real-time scenarios, focusing on high-percentile delays in priority queues with filtering, concurrent flows, and bandwidth constraints.

<footnote n="1">¹https://github.com/microsoft/msquic/pull/4320</footnote>
Our findings show that, in most cases, QUIC DG behaves similarly to other protocols, with only a minimal overhead that is less significant than transitioning to another programming language. However, we observed a performance degradation when a TBF was introduced, which suggests a potential interference between QUIC DG and lower-layer network protocols.

While QUIC DG offers enhanced security and features, our study emphasizes the need for further evaluation and optimization before its widespread adoption in real-time networks. The observed performance fluctuations, particularly under constrained conditions, highlight the importance of considering network capacity and traffic patterns when assessing QUIC DG's suitability for time-sensitive applications.

In conclusion, QUIC DG remains a promising option for secure, real-time communication in smart-grid and other critical environments. This study paves the way towards QUIC's broader adoption in real-time networking.

Future research could explore alternative queuing disciplines and traffic-management strategies to further optimize QUIC DG's performance in real-time networks. Moreover, applying real-time Linux kernel patches in a dedicated real-time testbed may improve our understanding of QUIC's interaction with lower-layer components. These approaches could enhance QUIC DG's overall effectiveness.

## Acknowledgments

The authors would like to thank the ORION program for its contribution to the funding of MA's research internship. This work has benefited from a French government grant managed by the Agence Nationale de la Recherche with the reference ANR-20-SFRI-0009.

## References

[1] Doğanalp Ergenç, Cornelia Brülhart, Jens Neumann, Leo Krüger, and Mathias Fischer. On the Security of IEEE 802.1 Time-Sensitive Networking. In *2021 IEEE International Conference on Communications Workshops (ICC Workshops)*, pages 1–6, June 2021. https://ieeexplore.ieee.org/document/9473542.

[2] Jérôme Grieu. Analyse et Évaluation de Techniques de Commutation Ethernet Pour l'interconnexion Des Systèmes Avioniques. These de doctorat, Toulouse, INPT, January 2004. https://www.theses.fr/2004INPT041H.

[3] Draft Standard for Local and metropolitan area networks—Time-Sensitive Networking for Aerospace Onboard Ethernet Communications. https://1.ieee802.org/tsn/802-1dp/, March 2023.

[4] IEC/IEEE 60802 Time-Sensitive Networking Profile for Industrial Automation. https://1.ieee802.org/tsn/iec-ieee-60802/, March 2023.

[5] Draft Standard for Local and metropolitan area networks — Time-Sensitive Networking Profile for Automotive In-Vehicle Ethernet Communications. https://1.ieee802.org/tsn/802-1dp/, December 2021.

[6] Norman Finn, Pascal Thubert, Balazs Varga, and János Farkas. Deterministic Networking Architecture. Request for Comments RFC 8655, Internet Engineering Task Force, October 2019. https://datatracker.ietf.org/doc/rfc8655.

[7] Ethan Grossman. Deterministic Networking Use Cases. Request for Comments RFC 8578, Internet Engineering Task Force, May 2019. https://datatracker.ietf.org/doc/rfc8578.

[8] Andres J. Gonzalez, Jose Ordonez-Lucena, Bjarne E. Helvik, Gianfranco Nencioni, Min Xie, Diego R. Lopez, and Pål Grønsund. The Isolation Concept in the 5G Network Slicing. In *2020 European Conference on Networks and Communications (EuCNC)*, pages 12–16, June 2020. https://ieeexplore.ieee.org/document/9200939.

[9] Time-Sensitive Networking (TSN) Task Group | https://1.ieee802.org/tsn/.

[10] AEE. Aircraft data network part 7, avionics full duplex switched ethernet (AFDX) network, ARINC specification 664, 2002.

[11] Ethan Grossman, Tal Mizrahi, and Anew J. Hacker. Deterministic Networking (DetNet) Security Considerations. Request for Comments RFC 9055, Internet Engineering Task Force, June 2021. https://datatracker.ietf.org/doc/rfc9055.

[12] Jana Iyengar and Martin Thomson. QUIC: A UDP-Based Multiplexed and Secure Transport. Request for Comments RFC 9000, Internet Engineering Task Force, May 2021. https://datatracker.ietf.org/doc/rfc9000.

[13] Tommy Pauly, Eric Kinnear, and David Schinazi. An Unreliable Datagram Extension to QUIC. Request for Comments RFC 9221, Internet Engineering Task Force, March 2022. https://datatracker.ietf.org/doc/rfc9221.

[14] Wesley Eddy. Transmission Control Protocol (TCP). Request for Comments RFC 9293, Internet Engineering Task Force, August 2022. https://datatracker.ietf.org/doc/rfc9293.

[15] User Datagram Protocol. Request for Comments RFC 768, Internet Engineering Task Force, August 1980. https://datatracker.ietf.org/doc/rfc768.

[16] Martin Thomson. Version-Independent Properties of QUIC. Request for Comments RFC 8999, Internet Engineering Task Force, May 2021. https://datatracker.ietf.org/doc/rfc8999.

[17] Martin Thomson and Sean Turner. Using TLS to Secure QUIC. Request for Comments RFC 9001, Internet Engineering Task Force, May 2021. https://datatracker.ietf.org/doc/rfc9001.

[18] Jana Iyengar and Ian Swett. QUIC Loss Detection and Congestion Control. Request for Comments RFC 9002, Internet Engineering Task Force, May 2021. https://datatracker.ietf.org/doc/rfc9002.

[19] Mike Bishop. HTTP/3. Request for Comments RFC 9114, Internet Engineering Task Force, June 2022. https://datatracker.ietf.org/doc/rfc9114.

[20] D. Saraiva, D. Corujo, and R. Aguiar. IEC 61850 data transfer evaluation over public networks. In *Wireless Personal Multimedia Communications Symp. - WPMC*, pages –, November 2019.

[21] Peter Drahoš, Erik Kučera, Oto Haffner, and Ivan Klimo. Trends in industrial communication and OPC UA. In *2018 Cybernetics & Informatics (K&I)*, pages 1–5, January 2018. https://ieeexplore.ieee.org/document/8337560.

[22] Eric Rescorla and Nagena Modadugu. Datagram Transport Layer Security Version 1.2. Request for Comments RFC 6347, Internet Engineering Task Force, January 2012. https://datatracker.ietf.org/doc/rfc6347.

[23] Késsia Nepomuceno, Igor Nogueira de Oliveira, Rafael Roque Aschoff, Daniel Bezerra, Maria Silvia Ito, Wesley Melo, Djamel Sadok, and Géza Szabó. QUIC and TCP: A Performance Evaluation. In *2018 IEEE Symposium on Computers and Communications (ISCC)*, pages 00045–00051, June 2018. https://ieeexplore.ieee.org/abstract/document/8538687.

[24] Xiang Qin, Xiaochou Chen, Wenju Huang, Yi Xie, and Yixi Zhang. Measurement and Analysis: Does QUIC Outperform TCP? In *2022 18th International Conference on Mobility, Sensing and Networking (MSN)*, pages 954–959, December 2022. https://ieeexplore.ieee.org/abstract/document/1007677/keywords#keywords.

[25] Alexander Yu and Theophilus A. Benson. Dissecting Performance of Production QUIC. In *Proceedings of the Web Conference 2021, WWW '21*, pages 1157–1168, New York, NY, USA, June 2021. Association for Computing Machinery. https://doi.org/10.1145/3442381.3450103.

[26] Tanya Shreedhar, Rohit Panda, Sergey Podanev, and Vaibhav Bajpai. Evaluating QUIC Performance Over Web, Cloud Storage, and Video Workloads. *IEEE Transactions on Network and Service Management*, 19(2):1366–1381, June 2022. https://ieeexplore.ieee.org/abstract/document/9646248.

[27] Fabio Bulgarella, Mauro Cociglio, Giuseppe Fioccola, Guido Marchetto, and Riccardo Sisto. Performance measurements of QUIC communications. In *Proceedings of the Applied Networking Research Workshop*, pages 8–14, Montreal Quebec Canada, July 2019. ACM. https://dl.acm.org/doi/10.1145/3340301.3341127.

[28] Peng Wang, Carmine Bianco, Janne Riihjärvi, and Marina Petrova. Implementation and Performance Evaluation of the QUIC Protocol in Linux Kernel. In *Proceedings of the 21st ACM International Conference on Modeling, Analysis and Simulation of Wireless and Mobile Systems*, MSWIM '18, pages 227–234, New York, NY, USA, October 2018. Association for Computing Machinery. https://doi.org/10.1145/3242102.3242106.

[29] Biao Han, Cao Xu, Yahui Li, Xiaoyan Wang, and Peng Xun. MPR-QUIC: Multi-path partially reliable transmission for priority and deadline-aware video streaming. *Journal of Systems Architecture*, 153:103195, August 2024. https://www.sciencedirect.com/science/article/pii/S1383762124001322.

[30] Philipp S. Tiesel, Mirko Palmer, Balakrishnan Chandrasekaran, Anja Feldmann, and Joerg Ott. Considerations for Unreliable Streams in QUIC. Internet Draft draft-tiesel-quic-unreliable-streams-01, Internet Engineering Task Force, October 2017. https://datatracker.ietf.org/doc/draft-tiesel-quic-unreliable-streams-01.

[31] Vivian Band. QUICsilver: Optimising QUIC for use with Real-Time Multimedia Traffic.

[32] Madhan Kanagarathinam, Syed Faraz Hasan, Sujith Rengan, Sukhdeep Singh, Gunjan Kumar Choudhary, Nawab Muhammad Faseeh Qureshi, and Hoejoo Lee. Enhanced QUIC Protocol for transferring Time-Sensitive Data. In *2022 IEEE International Conference on Communications Workshops (ICC Workshops)*, pages 1–6, May 2022. https://ieeexplore.ieee.org/abstract/document/9882167.

[33] Hemanth Kumar Ravuri, Maria Torres Vega, Jeroen Der Van Hooft, Tim Wauters, and Filip De Turck. Adaptive Partially Reliable Delivery of Immersive Media Over QUIC-HTTP/3. *IEEE Access*, 11:38094–38111, 2023. https://ieeexplore.ieee.org/abstract/document/10103593.

[34] David Baldassin, Ludovic Roux, Guillaume Urvoy-Keller, and Dino Martin Lopez Pacheco. A practical assessment approach of the interplay between WebRTC and QUIC. In *Proceedings of the 22nd ACM Internet Measurement Conference, IMC '22*, pages 768–769, New York, NY, USA, October 2022. Association for Computing
Machinery. https://dl.acm.org/doi/10.1145/3517745.3563030.

[35] David Baldassin, Guillaume Urvoy-Keller, and Dino Martin Lopez Pacheco. Sur l'interaction entre les algorithmes de congestion de WebRTC et QUIC. In *CoRes 2024: 9èmes Rencontres Francophones Sur La Conception de Protocoles, l'Evaluation de Performance et l'Expérimentation Des Réseaux de Communication*, Saint-Briac-sur-Mer, France, May 2024. https://hal.science/hal-04567691.

[36] Joerg Ott and Mathis Engelbart. RTP over QUIC. Internet Draft draft-engelbart-rtp-over-quic-04, Internet Engineering Task Force, June 2022. https://datatracker.ietf.org/doc/draft-engelbart-rtp-over-quic.

[37] Yuanliang Fan, Qinghua Wang, Hui Peng, Shu Lin, Kaijun Fan, and Yu Chen. GOOSE over UDP transmission mechanism for real-time data fast transmission in distribution network. In *2016 Seventh International Green and Sustainable Computing Conference (IGSC)*, pages 1-5, November 2016. https://ieeexplore.ieee.org/document/7892588.

[38] Théo Docquier, Ye-Qiong Song, Vincent Chevrier, Ludovic Pontnau, and Abdelaziz Ahmed-Nacer. Performance evaluation methodologies for Smart Grid Substation Communication Networks: A survey. *Computer Communications*, 198:228-246, January 2023. https://www.sciencedirect.com/science/article/pii/

S0140366422004285.

[39] Quic-go/quic-go. quic-go, July 2024. https://github.com/quic-go/quic-go.

[40] Nick Banks. Microsoft/msquic. Microsoft, July 2024. https://github.com/microsoft/msquic.

[41] Pion/dtls: DTLS 1.2 Server/Client implementation for Go. https://github.com/pion/dtls.

[42] DTLS-Examples/src/dtls_udp纵c at master · nplab/DTLS-Examples. https://github.com/nplab/DTLS-Examples/blob/master/src/dtls_udp纵c.

[43] Mininet: An Instant Virtual Network on Your Laptop (or Other PC) - Mininet. https://mininet.org/.

[44] Realtime:start [Wiki]. https://wiki.linuxfoundation.org/realtime/start.

[45] Jean-Yves Le Boudec. Performance Evaluation of Computer and Communication Systems. EPFL Press, Lausanne, Switzerland, 2010.

[46] Tc-tbf(8) - Linux manual page.

[47] IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems. IEEE Std 1588-2019 (Revision of IEEE Std 1588-2008), pages 1-499, June 2020. https://ieeexplore.ieee.org/document/9120376.