Investigating QUIC’s Suitability for the Internet of Things
QUIC is a connection-oriented, stateful, and flow-controlled transport protocol. Instead of identifying connections with IP addresses and port numbers, unique connection IDs are used — allowing for connections to persist after network changes or address re-mappings. QUIC packets consist of long or short headers followed by one or more frame types. Data is securely and reliably exchanged between endpoints. QUIC optionally allows 0-RTT connection establishment. Unlike with TCP, byte-streams can be logically isolated from one another through stream multiplexing. Loss of data on one stream does not affect any other streams, effectively minimizing Head-of-Line Blocking (HoLB). These characteristics prompted the move from TCP to QUIC for the of one of the most widely used protocols on the Internet — HTTP.
We investigate QUIC’s suitability as a transport protocol solution for the Internet of Things (IoT).
Bench-marking Quality of Experience Between HTTP/2 and HTTP/3 using Lighthouse [1]
We investigated an early implementation of HTTP/3 (whose underlying transport protocol is QUIC) against the more traditional HTTP/2 over TLSv1.3. Cloudflare’s QUICHE project delivered draft specification h3-27 support of HTTP/3 to our NGINX web-server. Our specific research focus was to gauge a user’s Quality of Experience (QoE) when it came to either protocol on a web browser. While other research has solely measured Page Load Time (PLT), our study levered Google’s Lighthouse – an open-source and metric diverse auditing tool. PLT only captures a single point in time and does not tell the full QoE story – especially for modern websites with various media sources, objects, and stylesheets. Rather, our investigation included commentary on First Contentful Paint, Time to Interactive, Speed Index, Largest Contentful Paint, Total Blocking Time, and Cumulative Layout Shift. Further, NetEm was used to emulate different network impairments while we collected Lighthouse metric data for HTTP/3 and HTTP/2. We found that this early implementation of HTTP/3 fared mostly worse than HTTP/2 in terms of QoE.
A Pure HTTP/3 Alternative to MQTT-over-QUIC in Resource-Constrained IoT [2]
To address the issue of scalable, interoperable, and timely dissemination of information in resource-constrained IoT, we propose an HTTP/3 publish-subscribe solution. Other works have migrated applications like MQTT to run over QUIC, citing the need to change critical APIs and data structures. We hypothesized that i.) because of HTTP/3’s native support with QUIC in various libraries, it may take better advantage of QUIC’s full feature-set and ii.) QUIC features such as 0-RoundTrip-Time (RTT) and QPACK header compression will help HTTP be a viable publish-subscribe solution. Performance, network overhead, and device overhead were investigated for our solution as well as an open-source MQTT-over-QUIC implementation. Network conditions according to the NarrowBand-IoT (NB-IoT) standard were considered. Our HTTP/3-based solution satisfied our timely dissemination requirement by offering a key performance savings of 1-RTT for published messages to arrive at the broker. In IoT networks, with typically high RTT, this savings is significant. On the other hand, we found that MQTT-over-QUIC was marginally more frugal in terms of resource consumption.
Tuning QUIC-Based Publish-Subscribe Architectures in IoT [3]
Since IoT greatly differs from traditional networks in terms of architecture and resources, IoT specific parameter tuning has proven to be of significance. While RFC 9006 offers a guideline for tuning TCP within IoT, we have not found an equivalent for QUIC. This paper is the first of our knowledge to contribute empirically based insights towards tuning QUIC for IoT. We improved our pure HTTP/3 publish-subscribe architecture and rigorously benchmarked it against an alternative: MQTT-over-QUIC. To investigate the impact of transport-layer parameters, we ran both applications on Raspberry Pi Zero hardware. Eight metrics were collected while emulating different network conditions and message payloads. We enumerate the points we experimentally identified (notably, relating to authentication, MAX_STREAM frames, and timers) and elaborate on how they can be tuned to improve resource consumption and performance. Our application offered lower latency than MQTT-over-QUIC with slightly higher resource consumption, making it preferable for reliable time-sensitive dissemination of information.
Mass Configuration of Heterogeneous IIoT Nodes: A Proposal and Experimental Evaluation [4]
Securely managing IoT devices is a fundamental challenge. Management protocols for IoT must be scalable and extensible, especially when dealing with device heterogeneity. Because of device resource limitations in IoT and the sheer size of such networks, traditional management protocols may not be well-suited. In this paper, we propose our HTTP/3 publish-subscribe architecture to meet the ends of en masse device configuration, on-boarding, and monitoring. We compared our solution to industry-standard protocols by collecting data from real traffic in networks of up to 500 clients. We found our solution to excel in ease of use and performance, while having slightly higher CPU utilization compared to the other protocols.
Trimming the Fat: Introducing QUIC Thin-Apps for the Internet of Things [5]
Researchers have proposed variants of application-layer protocols such as MQTT, CoAP, and AMQP all using QUIC transport. In this paper, we aim to show that since QUIC is so feature-rich on its own, many of the upper-layer complexities of traditional protocols can be greatly reduced or even eliminated. To exemplify this, we have designed what we call a ‘QUIC thin-app’ for IoT relying almost entirely on QUIC’s specification. We achieved comparable functionality to MQTT, doing away with the need for much of its control messaging. Furthermore, our experimentation with our solution against MQTTv5 shows significant reductions in signaling overhead while maintaining comparable CPU and memory utilization.
References
[1] D. Saif, C. -H. Lung and A. Matrawy, “An Early Benchmark of Quality of Experience Between HTTP/2 and HTTP/3 using Lighthouse,” ICC 2021 – IEEE International Conference on Communications, Montreal, QC, Canada, 2021, pp. 1-6, doi: 10.1109/ICC42927.2021.9500258.
[2] D. Saif and A. Matrawy, “A Pure HTTP/3 Alternative to MQTT-over-QUIC in Resource-Constrained IoT,” 2021 IEEE Conference on Standards for Communications and Networking (CSCN), Thessaloniki, Greece, 2021, pp. 36-39, doi: 10.1109/CSCN53733.2021.9686113.
[3] D. Saif and A. Matrawy, “An Experimental Investigation of Tuning QUIC-Based Publish–Subscribe Architectures in IoT,” in IEEE Internet of Things Journal, vol. 11, no. 3, pp. 4924-4933, 1 Feb.1, 2024, doi: 10.1109/JIOT.2023.3302160.
[4] D. Saif and A. Matrawy, “Mass Configuration of Heterogeneous IIoT Nodes: A Proposal and Experimental Evaluation,” 2024 International Conference on Computing, Networking and Communications (ICNC), Big Island, HI, USA, 2024, pp. 932-937, doi: 10.1109/ICNC59896.2024.10556270.
[5] D. Saif, A. Matrawy, “Trimming the Fat: Introducing QUIC Thin-Apps for the Internet of Things,” TechRxiv Preprint. November 12, 2024, doi: 10.36227/techrxiv.173143070.04378246/v1