| Internet-Draft | QUIC in IoT | August 2026 |
| Gomez, et al. | Expires 15 February 2027 | [Page] |
This document provides guidance on how to use QUIC in Constrained-Node Networks (CNNs), which are a characteristic of the Internet of Things (IoT).¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 2 February 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
QUIC is a modern transport-layer protocol intended to provide end-to- end reliability and security [RFC9000][RFC9001][RFC9002]. It was designed to overcome several issues of prior protocol stacks, such as Transmission Control Protocol (TCP)/Transport Layer Security (TLS) [RFC9293][RFC9846].¶
QUIC was not specifically designed for Constrained-Node Networks (CNNs), which are typical in Internet of Things (IoT) environments [I-D.ietf-iotops-7228bis]. However, its increasing adoption on the Internet suggests that QUIC may become a protocol to consider also for CNNs. Reasons include compatibility with existing QUIC-based infrastructure, availability of a wide panoply of implementations and tools, and a significant community, among others.¶
Leveraging optional and configurable functionality in QUIC, this document aims to provide guidance on how QUIC can be tailored for improved operation over CNNs.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14 [RFC2119], [RFC8174], when, and only when, they appear in all capitals, as shown here.¶
The reader is assumed to be familiar with the terms and concepts defined in [RFC9000][RFC9001][RFC9002][I-D.ietf-iotops-7228bis].¶
CNNs are defined in [I-D.ietf-iotops-7228bis] as networks "whose characteristics are influenced by being composed of a significant portion of constrained nodes". The latter exhibit significant limitations on processing, memory, and energy resources [I-D.ietf-iotops-7228bis]. The first two dimensions pose constraints on the complexity and memory footprint of the protocols that constrained nodes can support. Energy availability constraints requires using techniques to save energy, such as radio duty-cycling in wireless devices [RFC8352], and the minimization of the number of messages transmitted/received, as well as their size.¶
[I-D.ietf-iotops-7228bis] lists typical network constraints in CNNs, including low achievable bitrate/throughput, high packet loss and high variability of packet loss, highly asymmetric link characteristics, severe penalties for using larger packets, limits on reachability over time, high latency (e.g., due to sleep intervals intended to save energy), etc. CNNs may use wireless or wired technologies (e.g., Power Line Communication), and the transmission rates are in many cases low (e.g., below 1 Mbit/s), even challenging responsiveness in scenarios where a human expects an action to occur after the transmission of a frame.¶
Many constrained nodes communicate end to end with capable nodes [I-D.ietf-iotops-7228bis] (e.g., located in the cloud or at the edge). However, end-to-end communication between constrained nodes is also possible.¶
This section provides guidance on how to use or configure QUIC for CNNs. Advice is provided in the following areas: connections, initial and minimum congestion window, reliable versus unreliable datagrams, header overhead, ACK frequency, and initial RTT and related parameters.¶
In QUIC, connection establishment is initiated by a client. In order to better accommodate possible energy-saving techniques (e.g., radio duty-cycling) of a constrained device, the latter is recommended to act as client in a QUIC connection. This approach makes it easier for the constrained device to initiate connection establishment when it is ready to do so.¶
In order to minimize protocol overhead, a connection between a client and a server should last for as long as possible. In fact, many CNN use cases involve sensors that periodically send measurement reports over years of battery lifetime. It is possible to disable the idle timeout (max_idle_timeout) when both endpoints omit this parameter or indicate a value of 0.¶
However, most practical environments involve middleboxes (e.g., firewalls) that may block a UDP flow after 30 seconds of inactivity [RFC9000]. In such cases, two approaches can be followed at the QUIC level to avoid connectivity issues between the client and the server: i) sending a packet containing a PING frame from the client before 30 seconds have passed since the last transmitted or received QUIC packet, and ii) opening a new connection between the same client and server when the client has new data to send and more than 30 seconds have passed since the last transmitted or received QUIC packet.¶
Another approach is using application-layer heartbeat messages. Periodic application-layer heartbeats can prevent early record deletion in middleboxes. If the UDP binding timeout for a middlebox to be traversed by a given connection is known, middlebox filter state deletion will be avoided if the heartbeat period is lower than the middlebox UDP binding timeout. One specific advantage of heartbeat messages is that they also allow liveness checks at the application level.¶
In QUIC, the recommended value for the initial congestion window is "ten times the maximum datagram size (max_datagram_size), while limiting the window to the larger of 14,720 bytes or twice the maximum datagram size". On the other hand, the recommended value for the minimum congestion window is equal to 2 * max_datagram_size. Some constrained devices may only be able to support smaller window sizes. For such devices, the initial and minimum congestion window need to be set accordingly, even if they result in smaller values than the default ones recommended.¶
In IoT scenarios, reliability requirements vary depending on the considered application. Some data packets require reliable delivery, whereas others do not. QUIC provides reliable data delivery by default, using Acknowledgments (ACKs) and retransmission of lost data. However, in order to reduce protocol overhead, it is possible to carry less critical data atop DATAGRAM frames [RFC9221]. Such frames elicit ACKs, but are not retransmitted upon loss detection.¶
Some of the fields in QUIC packet and frame formats, such as Connection ID and packet number fields, are of variable size. In some circumstances, it is possible to exploit this feature to reduce packet header overhead, considering the associated trade-offs.¶
Connection ID fields have a size between 0 and 20 bytes. Reducing the size of a Connection ID degrades communication privacy and may decrease the efficiency of load balancing operations. If these concerns do not apply or can be tolerated to some extent for a particular IoT scenario, the latter may benefit from using shorter-sized Connection ID fields. As described in RFC 9000, "a zero-length connection ID can be used when a connection ID is not needed to route to the correct endpoint". However, a zero-sized Connection ID may only be safely used in very controlled environments.¶
Packet numbers have a size between 1 and 4 bytes. Reducing the packet number size increases the probability of ambiguity in identifying packets. However, if the rate of packets to be sent over a connection is expected to be low (e.g., a sensor that transmits a reading every minute) or ACKs are received at a sufficient rate, a shorter packet number size can be safely used.¶
Many IoT use cases (e.g., a device periodically sending sensor readings) do not require more than a single stream per connection. This provides an intrinsic limitation to packet header overhead.¶
Another approach to reduce packet overhead in QUIC is using header compression. For example, Static Context Header Compression (SCHC) [RFC8724] has been proposed for QUIC [I-D.sirohi-schc-quic-compression].¶
A typical IoT use case is a sensor that periodically transmits a single data packet containing a sensor reading. Even if the minimum recommended congestion window is 2 packets, the sender in such use case will typically only keep one packet in flight at most. In such case, if an application-layer response is not elicited, the receiver will delay sending the corresponding ACK by max_ack_delay, which has the default value of 25 ms. This mechanism is an attempt to reduce the number of ACKs or packets transmitted by the receiver, but in this specific case, the ACK will just be unnecessarily delayed, potentially consuming more energy on the sensor, without decreasing the actual number of ACKs sent.¶
One way to request an ACK to be sent immediately is by including an IMMEDIATE_ACK frame in the packet carrying the STREAM frame with the user data, which increases the packet size by one byte. In this case, immediate ACK transmission applies only to the next ACK to be sent. It is also possible to request ACKs to be sent immediately by sending a packet containing an ACK_FREQUENCY frame with the Requested Max Ack Delay field set to zero microseconds. This is a request that should produce a steady-state ACK transmission behavior (of ACKs being sent immediately). Note that, in this case, the minimum value for min_ack_delay supported by the receiver needs to be zero.¶
For less constrained IoT devices, in scenarios allowing a large congestion window size, it may be useful to request a lower ACK rate than default in order to reduce the number of ACKs transmitted by the receiver. This can be done by sending an ACK_FREQUENCY frame with an appropriate value for Ack-Eliciting Threshold.¶
QUIC defines an initial value for the RTT estimate. According to RFC 9002, "when no previous RTT is available, the initial RTT should be set to 333 milliseconds". This value, denoted as kInitialRtt, serves as the starting point for the RTT estimator. One consequence is that the initial value of the Probe TimeOut (PTO) is 1 second. In turn, this value affects other parameters, as max_idle_timeout needs to be at least 3 times the PTO, and the persistent congestion duration is recommended to be 3 times the PTO.¶
However, in many IoT scenarios, the RTT is much greater than 1 second. This may be due to various reasons, which could be combined in some cases: i) bit rates may be low, sometimes below 1 kbit/s; ii) links may be duty-cycled, leading to long intervals (from seconds to days) where a constrained device may be in sleep state (i.e., radio off); iii) some constrained devices use connectivity provided by sparse satellite constellations supporting store and forward operation, introducing delays up to the order of hours; iv) some technologies (e.g., some Low Power Wide Area Network (LPWAN) technologies) require uplink transmission from a constrained device to enable downlink transmission.¶
RFC 9002 allows a kInitialRtt setting different from 333 ms. Therefore, in IoT scenarios, such parameter needs to be configured based on the expected RTT of the intended scenario, often requiring a greater value than the default one.¶
TO-DO¶
This document has no IANA considerations.¶
Carles Gomez has been supported in part by the Spanish Goverment's Ministerio de Ciencia, Innovacion y Universidades MCIU/AEI/10.13039/501100011033/FEDER/UE through project PID2023-146378NB-I00, and through the Estancias de Movilidad en Centros Extranjeros de Ensenanza Superior e Investigacion PRX24/00397 grant.¶
The authors would like to thank (in alphabetical order) TO-DO for useful considerations, reviews and comments.¶