HTTP3
HTTP3 for IoT?
The issue with legacy network protocols
Legacy network protocols have been deployed with great success. In particular, the TCP/IP layer has been the narrow-waist of the internet, enabling the web and mobile applications we are now accustomed to. However, it has been designed for different requirements than those we are now facing.
Many improvements to the TCP/IP stack have been proposed and implemented, but they come at the cost of reduced performance.
A re-architecture is therefore required, and new initiatives for technologies able to support next generation protocols have started to emerge, especially in ETSI and IETF (see for instance https://www.etsi.org/committee/nin and https://irtf.org).
Connectivity for the IoT
The existing platforms for managing connected objects focus their priority on essential services for fleets of connected objects: manage the multi-protocol connectivity of objects (SigFox, LoRa, Nb-IoT, 5G, etc.), master the inventory of deployed objects and configure or update them via a "Device Management" module (LWM2M, OMA-DM, TR-069 / CWMP, etc.), and allow the feedback and the provision of data generated by the objects (DTLS, CoAP, MQTT, AMQP, etc.). Due to the drastic energy and bandwidth constraints, the vast majority of IoT networks do not follow the Internet model based on IP protocols. Indeed, the TCP/IP stack is too greedy for constrained devices. HTTP has long been considered unfit for embedded use cases. Due to those limitations, a protocol called CoAP, based on UDP, has been gaining in popularity. A recently approved IETF standard, SCHC, provides a compression mechanism to reduce CoAP/IPv6 headers to just a few bytes, which can be transported by LPWAN networks. We successfully tested SCHC for the mediam use cases (see dedicated section on SCHC).
Therefore, one can envision an adaptation layer between IPv6 and the LPWAN connectivity to support IoT use cases. However, CoAP being specific, interoperability with the rest of the web still requires the use of mappings. For security more specifically, there are interoperability concerns between TLS, OSCore and Edhoc. This not only presents an interoperability problem but a security issue too, since end-to-end encryption becomes harder when intermediaries are required, and leads to unnecessary least privilege access.
The choice of using a protocol over another highly depends on the use case under examination and the workloads intrinsically generated within them. However, the improvements in HTTP protocol have received little interest. Previous work has evaluated the fitness of HTTP2 and HTTP3 for the IoT:
An experimental port of HTTP/2 to Contiki validates the feasibility of this approach, and results
suggest an UDP transport may be a better fit,
Lars Eggert has adapted an HTTP/3 client and experimented on 2 different boards (argon and
ESP32-devkit), but profiling proves to be challenging on real hardware.
HTTP/3, now available as an IETF draft standard, has therefore the potential to solve the fragmentation of IoT frameworks and improve security. Unlike HTTP/1.1, the new protocol provides header compression (QPACK). The redesign around UDP streams (QUIC) is a natural fit for battery powered devices and opens the door to more efficient congestion controls. Unlike CoAP, it enables a direct compatibility between constrained devices and enterprise networks. This is critical if we want IoT devices to implement end-toend encryption and even more to support identity and access management (IAM) for things. Our work prototyped an implementation of HTTP3 for IoT devices, as an alternative to CoAP, as well as concrete examples and guides for device designers. The priority use case is related to the implementation of IAM protocols adapted for IoT workloads, such as OAuth ACE (which ported OAuth2 to CoAP) or the more recent GNAP being developed at IETF. Our implementation is based on https://github.com/fimbault/h3.
Future possibilities beyond our prototype
Going beyond a basic prototype would require:
a choice of which functionalities to enable: available implementations, made for web workloads, do
not enable clear profiles (client, server, both), nor do they allow to handle specific architectures
(32 bits processors, non-POSIX networking APIs, use of hardware cryptographic primitives, etc.)
or to adapt the capabilities to constrained requirements.
HTTP/3 is not easy to implement correctly. Recent advances demonstrate the importance of
measurements and root cause analysis, especially for advanced features like flow and congestion
control, 0-RTT, multiplexing and packetization. In the IoT domain, this is even more challenging
since logging is very limited. The objective is to test on a simulation platform (qemu and FPGA,
such as simfire), as well as real hardware, opensource (RISC-V) or not.
Last updated
