Ishikawa et al.

, Int J Comput Softw Eng 2023, 8: 184

https://doi.org/10.15344/2456-4451/2023/184

International Journal of
Computer & Software Engineering
Original Article Open Access

Evaluation of a File Transfer Protocol with QUIC

Yudai Ishikawa and Tomofumi Matsuzawa*
Department of Information Sciences, Tokyo University of Science, Tokyo 162-8601, Japan

Abstract Publication History:

In May 2021, a new transport layer protocol, QUIC, was standardized by the Internet Engineering Received: March 29, 2023
Task Force (IETF). Although QUIC is mainly designed to be optimized for the newWeb communication Accepted: April 09, 2023
(HTTP/3), QUIC created by the IETF is also intended for applications other than the Web. To investigate Published: April 10, 2023
the performance of QUIC as a transport layer, we evaluate the performance of a method implemented on
QUIC based on FTP, a file transfer protocol, and discuss the characteristics of QUIC. Keywords:
QUIC, File Transfer, Performance

Introduction • Realization of multiplexed communication by streaming

The amount of data exchanged on the Internet today is enormous, When a packet loss occurs in TCP, the operating system first asks
and attempts have been made to reduce the amount of traffic flowing the endpoint to retransmit the packet. Then, after the packet loss is
over the network and to minimize communication latency. In recovered, the data is passed to the application. At this point, even if
November 2009, Google proposed a new communication protocol subsequent packets are received, the data cannot be processed until
called SPDY1, which attempts to speed up communication by adding the packet loss is recovered. This is called HoL Blocking. On the other
features such as multiple connections and pipelining to HTTP/1.1. hand, QUIC can efficiently process data even in the case of packet loss,
Since then, SPDY has gone through several iterations and is now because it can pass subsequent packets to the application. If application
standardized by RFC 9113[1] under the name HTTP/2. However, layer data needs to be encrypted, encryption methods such as TLS
because SPDY and its successor HTTP/2 were Transmission Control over TCP can be used. Since TLS cannot encrypt information related
Protocol (TCP)-based protocols, they could not overcome the latency to the control of the communication path, a malicious third party can
that occurs at the TCP layer. eavesdrop on the communication state. In QUIC, however, TLS is
absorbed by QUIC itself and used internally. Therefore, information
To solve the above issues in SPDY and HTTP/2, a transport related to the control of the communication paths can also be
protocol called QUIC was proposed by Google in 2013. QUIC is encrypted. QUIC can have multiple communication management
designed on top of UDP with multiple connections, connection units called ”streams” on a single connection. Each stream is reliable
management functions equivalent to TCP, and packet management on a per-stream basis, and packet loss recovery and sequencing can
functions. This overcame the latency caused by TCP, which could not be performed without affecting other streams. This allows data to be
be solved by SPDY or HTTP/2. QUIC has had several iterations and processed more efficiently than with TCP. Each stream is assigned
was standardized by the Internet Engineering Task Force (IETF) in an integer value called a stream ID to uniquely identify the stream.
May 2021 as RFC 9000 [2]. HTTP/3, which relies on QUIC, was also Stream IDs are numbered according to the following rules (Table 1).
standardized as RFC 9114 [3] in June 2022.
Start side Stream direction Lower 2 bits Example of
On the other hand, there have been active attempts to make existing Stream ID
application protocols available over QUIC, and in December 2020, Client Bi-directional 00 0, 4, 8, 12, · · ·
Internet-Draft2, an improved version of SSH that can be used on Server Bi-directional 01 1, 5, 9, 13, · · ·
QUIC, was proposed. In addition, Microsoft has implemented SMB
over QUIC on Windows Server 20223, and the groundwork is being Client Uni-directional 10 2, 6, 10, 14, · · ·
laid for further QUIC adoption. Server Uni-directional 11 3, 7, 11, 15, · · ·
Table 1: Stream ID numbering rules.
In this study, we propose an application of QUIC to file transfers,
and aim to realize secure file transfers with lower latency than existing Related Work
methods. We also compare the performance of QUIC with existing
file transfer protocols and evaluate its performance. Nepomuceno et al. [5] conducted experiments to measure the time
to retrieve a Web page using HTTP for each of QUIC and TCP, and
QUIC
QUIC (Quick UDP Internet Connections) is a User Datagram
*
Corresponding Author: Prof. Tomofumi Matsuzawa, Department of
Information Sciences, Tokyo University of Science, Tokyo 162-8601, Japan, E-mail:
Protocol (UDP)[4] based transport protocol standardized by t-matsu@is.noda.tus.ac.jp
RFC 9000 [2]. Unlike TCP, UDP does not have features such as
retransmission control, sequence control, and congestion control, all Citation: Ishikawa Y, Matsuzawa T (2023) Evaluation of a File Transfer Protocol
with QUIC. Int J Comput Softw Eng 8: 184. doi: https://doi.org/10.15344/2456-
of which are implemented in QUIC. This gives QUIC the following 4451/2023/184
advantages.
Copyright: © 2023 Ishikawa. This is an open-access article distributed under the
• Avoiding HoL Blocking at the Transport Layer Level terms of the Creative Commons Attribution License, which permits unrestricted
use, distribution, and reproduction in any medium, provided the original author
• Transport layer level encryption and source are credited.

Int J Comput Softw Eng IJCSE, an open access journal

ISSN: 2456-4451 Volume 8. 2023. 184
Citation: Ishikawa Y, Matsuzawa T (2023) Evaluation of a File Transfer Protocol with QUIC. Int J Comput Softw Eng 8: 184. doi: https://doi.org/10.15344/2456-
4451/2023/184

Page 2 of 4

gave a quantitative evaluation. The experiment first uses Alexa’s page The following procedure is used for file transfer, similar to the
access ranking to determine the top 100 pages to be used for the test. active mode in FTP.
Then, the tool Mahimahi is used to record HTTP (HTTPS) traffic.
Under the network traffic condition by Wang et al. research [6], we 1. The server opens a bi-directional stream for the number of files
replay the page fetches on the network and measure the time it takes to be transferred. This stream is called a data stream. Data is
to load the page. Experiments are also conducted with and without transferred using the data stream from this point on.
web browser caching enabled. The experimental results show that 2. The client creates threads for the number of files to be received
RTT variations have a significant impact on QUIC performance, and performs the following processing.
while TCP performance is not significantly affected, and packet loss
rate has no significant impact on either performance. The paper also (a) Opens the destination file.
shows that QUIC outperformed TCP in each test by less than 40%. (b) Reads a sequence of bytes from the stream.
Furthermore, with caching enabled, TCP performed better than (c) Writes the read bytes to the file.
QUIC. The paper attributes this to the rendering engine’s inability to (d) Closes the file.
handle QUIC efficiently and the fact that the web pages used in the (e) Closes the data stream from the client side.
experiments were not optimized for QUIC.
Experiments and Discussion
Proposed Method
Both the client and server programs are implemented in the Go
Memory constraints programming language. The library for handling QUIC packets is
quic-go4, created by L. Clemente.
In this study, we propose to apply QUIC to secure multiple file
transfers, taking advantage of QUIC’s capability for multiplexed Table 2 shows the specifications of the computer used as the
connections and encrypted communications. We implement a experimental environment.
prototype of a file transfer protocol that runs on QUIC, based on the
FTP[7] specification. Client Server
OS Ubuntu 22.04.01 LTS Debian 11
The following procedure is used to initiate communication.
CPU Intel Core i7-8550U Broadcom BCM2711
1. The QUIC file transfer client (hereinafter referred to as ”client”) RAM 20GB 8GB
establishes a QUIC connection to the server. The port used is Table 2: Specifications of the computer.
UDP N (N is known to the client).
2. A bidirectional stream is opened from the client to the QUIC file All experiments were conducted within the local network, and
transfer server (hereinafter referred to as ”server”). This stream is fault elements such as packet loss and packet delivery delays were
called the ”control stream”. The control stream is used to control reproduced by intentionally generating them using the tc command.
data communication. In our experiments, we measure the throughput of transferring small
files in parallel and the throughput of transferring a single large file.
For this purpose, the following two types of files are prepared.
The following procedure is used to initiate communication.
• File group 1: 100 JPEG files
1. The client sends a comma-separated list of the names of the files
it requests to be transferred as an ASCII string to the server.
-Minimum: 177KB
2. The server concatenates the names of the requested files that can -Maximum: 1.72MB
be transferred with commas and sends them to the client. If the -Average: 658KB
file does not exist, an empty string is sent. -Standard Deviation (SD): 407KB

A schematic diagram of a file request is shown in Figure 1. • File group 2: 1 ISO file

In the list of received file names, files that do not exist on the server – Size: 1.47GB
or that are inaccessible due to permission issues are omitted from the
list, and only files that can be transferred are reported to the client.

Figure 1: Schematic of file request.

Int J Comput Softw Eng IJCSE, an open access journal

ISSN: 2456-4451 Volume 8. 2023. 184
Citation: Ishikawa Y, Matsuzawa T (2023) Evaluation of a File Transfer Protocol with QUIC. Int J Comput Softw Eng 8: 184. doi: https://doi.org/10.15344/2456-
4451/2023/184

Page 3 of 4

We perform packet capture using Wireshark and measure the The transfer time of the proposed method using QUIC increases
time required to transfer the above file groups 1 and 2 with the linearly with increasing packet loss rate in the order of about 0.1
implementation of the proposed method according to the conditions second. On the other hand, in the comparison experiment with
in Table 3. 5 The same conditions are also used in the SCP6 experiment SCP, the transfer time increases with increasing packet loss rate by
for comparison. an order of magnitude larger than the first power of the packet loss
rate. In addition, the transfer time of the proposed method is almost
Fault File Fault File constant even when the delay increases, while the transfer time of
Elements group Elements group
SCP increases linearly with a unit of about 1 second. Based on the
File group File group
above results, it can be said that the proposed method improves the
QUIC - 1 SCP - 1 throughput of file group 1.
QUIC Delay 5ms 2 SCP Delay 5ms 2
QUIC Delay 10ms 1 SCP Delay 10ms 1 Experimental results show that the proposed method performs
better than the existing methods in environments where packet
QUIC Delay 15ms 2 SCP Delay 15ms 2
loss and packet delivery delays occur. In particular, the difference in
QUIC Delay 20ms 1 SCP Delay 20ms 1 transfer time between the proposed and existing methods becomes
QUIC Delay 25ms 2 SCP Delay 25ms 2 larger as the network disturbance factor increases. This is due to the
fact that the overhead caused by HoL blocking exceeds the overhead
QUIC Loss ratio 1% 1 SCP Loss ratio 1% 1
caused by asynchronous processing as the packet loss rate increases
QUIC Loss ratio 2% 2 SCP Loss ratio 2% 2 and the number of seconds of delay in packet delivery increases.
QUIC Loss ratio 3% 1 SCP Loss ratio 3% 1 Therefore, the proposed method is superior for the case where many
QUIC Loss ratio 4% 2 SCP Loss ratio 4% 2 files are transferred simultaneously in an environment with faulty
elements.
QUIC Loss ratio 5% 1 SCP Loss ratio 5% 1
Table 3: Experimental conditions. When there is no faulty element, the file transfer time using the
proposed method is slightly longer. This is due to the processing
time of the computer. The proposed method processes multiple
Figure 2 shows the time required to transfer file group 1 when the streams asynchronously when downloading multiple files, which
fault elements are set according to Table 3. increases the load on the computer compared to existing methods.
In our experiments, this asynchronous processing affected the results.
On the horizontal axis, packet loss rate is expressed in %, and packet However, since it is rare for real networks to be free of such obstacles,
delay is expressed in ms. this performance difference can be ignored as a practical matter.

When a fault factor is set, the implementation of the proposed In light of the above, the proposed method is expected to perform
method does not show a significant effect on the transfer time. On well when transferring a large number of files in a real network
the other hand, the transfer time increases with the size of the fault environment.
in SCP.

Figure 2: Fault element and transfer time for file group 1.

5
The time from the start of the handshake to the disconnection of communication is
defined as the time required for the transfer. Figure 3 shows the time required for the transfer of file group 2
6
An application protocol for file transfers using SSH (Secure Shell), an encrypted remote when the fault elements are set according to Table 3.
login system.

Int J Comput Softw Eng IJCSE, an open access journal

ISSN: 2456-4451 Volume 8. 2023. 184
Citation: Ishikawa Y, Matsuzawa T (2023) Evaluation of a File Transfer Protocol with QUIC. Int J Comput Softw Eng 8: 184. doi: https://doi.org/10.15344/2456-
4451/2023/184

Page 4 of 4

Figure 3: Fault element and transfer time for file group 2.

In both cases, the transfer time of the proposed method is about 30 outside the context of HTTP. This study is significant in the recent
seconds longer than that of SCP. For both the proposed method and trend of various application protocols supporting QUIC.
SCP, the transmission time increases as the packet loss rate increases.
On the other hand, the transfer time is almost constant for both the Competing Interests
proposed method and SCP. In all conditions, SCP was 30 seconds
faster for file group 2, and the proposed method did not improve the The author declare that he has no competing interests.
throughput. From the experimental results, it can be seen that the
proposed method requires 30 seconds more transfer time regardless References
of the presence or absence of error elements. In this experiment, New 1. Thomson M, Benfield C (2022) “HTTP/2”, RFC 9113.
Reno was used as the congestion control algorithm, and the size of the
2. Iyengar J, Thomson M (2021) QUIC: A UDP-Based Multiplexed and Secure
send/receive buffer was set to 21,299,200 bytes (− ~ 20.3 MiB). So, it is
Transport, RFC 9000.
clear that these factors are irrelevant to the results.
3. Bishop M (2022) “HTTP/3”, RFC 9114.
4. Postel J (1980) User Datagram Protocol, RFC 768.
According to the packet capture results, 924,454 SSH packets were
sent and received. On the other hand, 1,340,576 QUIC packets were 5. Nepomuceno K, de Oliveira IN, Aschoff RR, Bezerra D, Ito MS, et al. (2018)
“QUIC and TCP: A Performance Evaluation”. IEEE Symposium on Computers
sent and received, which is about 1.5 times the number of SSH packets. and Communications (ISCC), pp. 00045-00051.
In this experiment, it is assumed that the time required to encrypt
6. Wang XS, Balasubramanian A, Krishnamurthy A, Wetherall D (2014) How
and decrypt a large number of QUIC packets has greatly affected the speedy is spdy?”, The 11th USENIX Symposium on Networked Systems
transfer time. Design and Implementation (NSDI).
7. Postel J, Reynolds J (1985) File Transfer Protocol (FTP), RFC 959.
Based on the above, the proposed method is not suitable for
transferring large files, at least in our implementation.

Conclusions

In this study, we proposed a fast and highly secure file transfer

protocol that exploits the low latency and multiple connectivity of
QUIC for file transfers. In this study, we implemented a prototype file
transfer protocol running on QUIC using existing libraries.

Experiments were conducted to measure the throughput of small

files transferred in parallel and the throughput of large files transferred
in one shot. Similar experiments were also performed on SCP, an
existing method, to compare the throughput of the two methods. The
experimental results showed the superiority of the proposed method
over the existing method in the former case, but not in the latter case.

While many studies have discussed the superiority of QUIC in

the context of HTTP, this study evaluated the performance of QUIC

Int J Comput Softw Eng IJCSE, an open access journal

ISSN: 2456-4451 Volume 8. 2023. 184