# Proxy-Based Adaptive Transmission of MP-QUIC in Internet-of-Things Environment
## 1 Introduction  
As a lot of Internet of Things (IoT) services and applications have recently been developed, efficient data transmission schemes are crucially required for real-time IoT data traffics. For effective data transmissions over the network, many multipath transport protocols can be used, which include Multi-Path TCP (MP-TCP) [1] and Stream Control Transport Protocol (SCTP) [2]. MP-TCP is an extension of TCP that can utilize multiple paths concurrently in the network to enhance the transmission throughputs. The traditional TCP uses only a single path between the two endpoints, whereas MP-TCP can transfer data by using two or more paths at the same time. SCTP is another transport layer protocol to support the multi-homing features for real-time and high-quality services, such as Internet telephony. With this SCTP multi-homing feature, a more enhanced scheme has also been developed, called Concurrent Multipath Transfer for SCTP (CMT-SCTP) [3]. These MP-TCP and CMT-SCTP schemes can be used for multipath transport effectively, as shown in the related works [4, 5]. However, these are basically categorized as 'transport-layer protocols', which are based on TCP and SCTP, usually with _kernel-level_ implementations, not _user-level_ implementations. Accordingly, there are still some limitations to the wide deployment of these schemes into real-world networks.  
In the meantime, the IETF has recently developed a new transport protocol, QUIC, for UDP-based multiplexed and secure transport [6]. The QUIC protocol has been madebased on the previous works on SPDY [7] that are being used for HTTP/2-based Web services. QUIC is a general-purpose transport protocol. It was first designed to support HTTP/3 transmissions [8], but it can also be used for other application protocols. QUIC uses UDP [9] as its underlying protocol, and it provides many distinctive features, which include stream multiplexing, stream, and connection-level flow control, low-latency connection establishment, connection migration, and authentication/encryption with Transport Layer Security version 3 [10]. In particular, it is noted that QUIC can be implemented at the user level. This feature is helpful to easy deployment of QUIC in real-world networks.  
More recently, Multi-Path QUIC (MP-QUIC) [11] is being proposed as an extension of QUIC for multipath transport in the network environment with multiple paths. By using MP-QUIC, each data stream of QUIC can be delivered to different paths concurrently in the network. This feature will be helpful to enhance the transmission throughput for mission-critical application services.  
This paper addresses how to enhance the throughput performance of MP-QUIC by considering the dynamic network conditions. In this paper, we propose a proxy-based adaptive MP-QUIC transmission in an IoT environment. In the proposed scheme, a proxy device is employed between IoT clients and IoT servers in the network so as to aggregate the data traffics of clients in the access network. The proxy device will be used to transmit these data traffics to the server, adaptively to the dynamic network conditions, by using multiple paths in the backbone network. For this purpose, the proxy employs a _path manager_ and a _connection manager_. The _path manager_ is used to monitor the current network conditions, and the _connection manager_ will be used to manage the MP-QUIC connections between the proxy and the IoT server over the backbone network with multiple paths. For effective MP-QUIC transmission, the proxy will transmit the prioritized packets to the server by using the best path with the lowest RTT, whereas the non-prioritized packets are delivered over the other paths for traffic load balancing in the network.  
This paper is organized as follows. Section 2 reviews the existing works on QUIC. Section 3 describes the proposed proxy-based adaptive MP-QUIC transmission scheme. Section 4 discusses the testbed experimentations for performance analysis. Finally, Section 5 concludes this paper.