QUIC Usage Guidance in the Internet of Things (IoT)

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 . 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 . 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 .

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.