Network Working Group P. S. Kim Internet-Draft TU Korea Intended status: Informational Expires: 3 January 2027 3 July 2026 QUIC Application for ROS2 with MQTT draft-pskim-ros2-quic-mqtt-00 Abstract While DDS (Distributed Data Service) protocol, managed by Object Management Group (OMG), for ROS (Robot Operating System) 2 is intended to provide a universal communication layer, interoperability across different DDS middleware implementations is not always consistent. Variations in transport protocol usage (e.g., TCP/IP, UDP, shared memory) can hinder direct data exchange, and cross-domain communication efficiency is generally lower compared to protocols such as HTTP. Therefore, to resolve limitations of DDS in ROS2, this draft considers a couple of standards protocols, QUIC of IETF and MQTT (Message Queuing Telemetry Transport), managed by OASIS Open. Status of This Memo 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 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. P.S. Kim Expires 2 January 2027 [Page 1] Internet-Draft QUIC Application for ROS2 with MQTT July 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. QoS Setting for ROS2 . . . . . . . . . . . . . . . . . . . . 3 2.1. Overview of ROS2 . . . . . . . . . . . . . . . . . . . . 3 2.2. ROS2 QOS Setting . . . . . . . . . . . . . . . . . . . . 4 3. DDS in ROS2 . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Overview of DDS . . . . . . . . . . . . . . . . . . . . . 4 3.2. Rich QoS Policies of DDS . . . . . . . . . . . . . . . . 5 3.3. Role of DDS in ROS2 . . . . . . . . . . . . . . . . . . . 5 4. Addressing DDS Challenges with MQTT . . . . . . . . . . . . . 6 4.1. Limitations of DDS . . . . . . . . . . . . . . . . . . . 6 4.2. Introduction to MQTT . . . . . . . . . . . . . . . . . . 6 5. QUIC Application for ROS2 with MQTT . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction ROS (Robot Operating System) 2, an open-source robotics operating system with a rich ecosystem, is often the preferred choice for robotics application development[ROS2]. ROS2 is supported and tested on Linux, Windows, and macOS, as well as various embedded platforms via micro-ROS, allowing seamless development and deployment of on-robot autonomy, back-end management, and user interfaces. ROS2 provides various QoS (Quality of Service) policies that can tune communication between nodes. Through appropriate combinations of QoS policies, ROS2 can implement numerous states ranging from stable communication like TCP to best-effort communication like UDP, as well as those in between. Unlike ROS1, which primarily supported only TCP, ROS2 leverages the flexibility of DDS (Distributed Data Service)[DDS] to optimize for lossy wireless network environments where best-effort policies are more suitable or real-time computing systems that require appropriate QoS profiles to meet deadlines. The adoption of DDS as the communication middleware in ROS2 has demonstrated its capability as a P.S. Kim Expires 2 January 2027 [Page 2] Internet-Draft QUIC Application for ROS2 with MQTT July 2026 reliable real-time distributed system [DDS-ROS2]. To abstract DDS complexity for ROS2 users while leveraging its functionality, ROS2 converts its native messages into DDS format for transmission. DDS also provides a scoping mechanism called a domain; each ROS2 process creates a DDS participant upon initialization, and there is a limit on the number of participants within a single domain. Despite being designed as a universal communication standard, DDS protocol used in ROS2 exhibits interoperability challenges across heterogeneous DDS middleware implementations. Such limitations arise primarily from differences in transport protocol configurations, including TCP/IP, UDP, and shared memory, which may impede direct communication. Furthermore, the DDS shows optimal performance within intra-domain environments, whereas its efficiency in inter-domain communication is comparatively lower than that of protocols such as HTTP. Thus, to resolve limitations of DDS in ROS2, this draft considers a couple of standards protocols, QUIC[RFC9000] of IETF and MQTT (Message Queuing Telemetry Transport), managed by OASIS Open[MQTT]. Due to its lightweight design, reliability, and scalability, the MQTT over QUIC protocol [MQTT-QUIC] can be considered an effective solution for enabling communication between ROS2 nodes and enterprise systems. 1.1. Requirements Language 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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. QoS Setting for ROS2 2.1. Overview of ROS2 ROS is an open source software development kit for robotics applications. ROS offers a standard software platform to developers across industries that will carry them from research and prototyping all the way through to deployment and production. For over 20+ years ROS project has produced a vast ecosystem of software for robotics by nurturing a global community of millions of developers and users who contribute to and improve that software. ROS is developed by and for that community, who will be its stewards into the future. Since ROS was started in 2007, a lot has changed in the robotics and ROS community. ROS2, an open-source robotics operating system with a rich ecosystem, is often the preferred choice for robotics application development. P.S. Kim Expires 2 January 2027 [Page 3] Internet-Draft QUIC Application for ROS2 with MQTT July 2026 ROS2 is supported and tested on Linux, Windows, and macOS, as well as various embedded platforms (via micro-ROS), allowing seamless development and deployment of on-robot autonomy, back-end management, and user interfaces. The tiered support model allows for ports to new platforms, such as real-time and embedded operating systems, to be introduced and promoted as they gain interest and investment. Companies large and small from around the world are committing their resources to making open source contributions to ROS2, in addition to developing products on top. 2.2. ROS2 QOS Setting ROS2 provides various QoS policies that can tune communication between nodes. Through appropriate combinations of QoS policies, ROS2 can implement numerous states ranging from stable communication like TCP to best-effort communication like UDP, as well as those in between. Unlike ROS1, which primarily supported only TCP, ROS2 leverages the flexibility of DDS transmission to optimize for lossy wireless network environments where best-effort policies are more suitable or real-time computing systems that require appropriate QoS profiles to meet deadlines. Multiple QoS policies are combined to form a QoS profile. Because selecting the correct QoS policy for a specific scenario is complex, the ROS2 provides a set of predefined QoS profiles for common use cases (e.g., sensor data). At the same time, developers have the flexibility to control specific policies within the QoS profiles. QoS profiles can be specified for publishers, subscribers, service servers, and clients. While QoS profiles can be applied independently to each of the aforementioned entities, using different profiles may cause compatibility issues and prevent message delivery. 3. DDS in ROS2 3.1. Overview of DDS The DDS standard, managed by Object Management Group (OMG), is the software connectivity standard that enables secure real-time information exchange, modular application development and rapid integration in distributed systems. The DDS integrates system components to provide low-latency data connectivity, high reliability, and a highly scalable architecture, making it suitable for various commercial-grade IoT applications. DDS functions as a publish?subscribe messaging protocol that supports real-time, reliable, and scalable data distribution. It was originally used in industrial automation, where large amounts of data had to be collected and transmitted in real time to ensure high performance and dependable control. Due to its strong real-time P.S. Kim Expires 2 January 2027 [Page 4] Internet-Draft QUIC Application for ROS2 with MQTT July 2026 capabilities, reliability, and scalability, DDS rapidly became the standard protocol in this field. Over time, its use has expanded to areas such as aerospace, automotive, healthcare, and beyond. DDS's scalability and QoS are tailored to meet the demands of industrial automation, focusing on reliability, scale, and customization. Thus, DDS rapidly became the standard protocol in this field. DDS underpins a wide range of industry protocols and system framework standards, such as ROS2 and Adaptive AUTOSAR, etc. 3.2. Rich QoS Policies of DDS DDS applies a range of QoS parameters to filter data. Since not all nodes require every piece of data from the data center, DDS ensures that each node receives only the information it needs based on QoS policies. It guarantees reliable data delivery to intended recipients, dynamically adapts transmission according to system changes, and leverages multicast for rapid updates. In security-sensitive environments, DDS manages access control, regulates data flow, and performs real-time encryption. DDS offers a comprehensive set of QoS policies to manage the quality of data transmission and communication, addressing aspects such as timeliness, traffic prioritization, reliability, and resource constraints. QoS parameters, such as reliability, performance, security, durability, deadline, lifespan, ownership, time-based filter, resource limits, can be configured to meet specific application requirements for data transfer and communication. 3.3. Role of DDS in ROS2 In robotic and autonomous driving systems, cooperative perception, where robots exchange sensor data over wireless communication, has introduced a new dimension. Due to functional safety requirements, robots rely on real-time and highly reliable sensor inputs. To support decision-making and information sharing with nearby robots, they are equipped with numerous sensors that generate diverse data streams. The adoption of DDS as the communication middleware in ROS2 has demonstrated its capability as a reliable real-time distributed system. To abstract DDS complexity for ROS2 users while leveraging its functionality, ROS2 converts its native messages into DDS format for transmission. DDS also provides a scoping mechanism called a domain; each ROS2 process creates a DDS participant upon initialization, and there is a limit on the number of participants within a single domain. Efficiently managing a large number of sensors and messages requires P.S. Kim Expires 2 January 2027 [Page 5] Internet-Draft QUIC Application for ROS2 with MQTT July 2026 multiple ROS2 nodes within a robot. Furthermore, in cooperative perception scenarios, even more ROS2 nodes may be needed when a robot operates as a single ROS2 entity. Due to DDS participant limitations, these nodes cannot all reside within a single domain, making inter-domain communication unavoidable. Additionally, multiple vendor-specific DDS implementations exist, each with its own configurations, which significantly influence communication among ROS2 nodes. As a result, inter-robot or inter-node communication depends heavily on vendor configurations, data types, data sizes, and the specific DDS middleware used. 4. Addressing DDS Challenges with MQTT 4.1. Limitations of DDS The DDS middleware abstracts applications from the specific details of the operating system, network transport, and low-level data formats. It offers consistent concepts and APIs across diverse programming languages, enabling applications to exchange information across different operating systems, languages, and processor architectures. The middleware manages underlying elements such as data formats, discovery, connectivity, reliability, protocols, transportation, QoS, and security. Although the DDS protocol is designed to be universal, compatibility between various DDS middleware implementations can be inconsistent. For example, the DDS can utilize different transport protocols for data transfer, such as TCP/IP, UDP, or shared memory. Varying implementations may use different transport protocols, preventing direct data exchange. DDS is designed to enable cross-domain communication; however, several practical challenges are commonly observed. For example, while DDS performs efficiently within a single domain, its performance across domains is generally lower compared to protocols such as HTTP. 4.2. Introduction to MQTT MQTT, managed by OASIS Open, is a lightweight messaging protocol built on a publish/subscribe architecture, designed primarily for IoT environments with limited bandwidth and unreliable network conditions. It enables real-time, dependable communication between devices while requiring minimal code. Key features of MQTT include efficient bandwidth usage, asynchronous data exchange, and strong scalability, making it ideal for connecting large numbers of devices. As a result, MQTT is widely adopted across various fields such as IoT, mobile networks, smart devices, connected vehicles, smart cities, telemedicine, and the energy sector, including power and oil industries. P.S. Kim Expires 2 January 2027 [Page 6] Internet-Draft QUIC Application for ROS2 with MQTT July 2026 MQTT and DDS differ in several ways, including their communication models and decentralization. DDS excels in intra-domain communication, while MQTT is advantageous for cross-domain communication due to its lightweight nature, resulting in lower bandwidth usage and latency. DDS can leverage MQTT for cross-domain communication. An MQTT-DDS Proxy is introduced to function as both a DDS node and an MQTT node. It transmits the necessary data from the DDS domain to the MQTT broker, and then relays it to the appropriate DDS domain, thereby enabling cross-domain communication between DDS systems. The conversion process introduces only a small serialization overhead, which is typically insignificant. As for the second issue, adding a single node to a DDS network has minimal impact on overall performance. Furthermore, due to the structure of the DDS global data space, the MQTT-DDS Proxy selectively transmits only the required data to another domain. This approach is more efficient than directly merging data from nodes across two DDS domains to manage a unified global data space. 5. QUIC Application for ROS2 with MQTT QUIC (RFC 9000) is the underlying transport protocol of the next-generation Internet protocol HTTP/3, which provides connectivity for the modern mobile Internet with less connection overhead and message latency compared to TCP/TLS protocols. QUIC has many advantages over existing TLS over TCP implementation. As mentioned before, MQTT is a connection-oriented IoT communication protocol featuring a compact message format, allowing reliable data transmission even on highly constrained devices and in low-bandwidth, high-latency network conditions. Its support for features such as keep-alive, last will messages, and multiple QoS levels enables it to handle a wide range of IoT use cases. However, in more complex network environments, MQTT may exhibit inherent limitations stemming from its reliance on the underlying TCP transport protocol. For example, connected robot users often encounter similar challenges. Robots may operate in environments where entering signal dead zones or switching between base stations (commonly known as spotty network coverage) can lead to connection disruptions. Frequent disconnections and delays in re-establishing connections can significantly degrade the user experience. For services that demand high levels of real-time data transmission and reliability, such as L4 autonomous robots, addressing these issues can result in substantial costs for customers. In such scenarios, QUIC demonstrates clear advantages with its low connection overhead and multi-path support. Upon further analysis, it can be expected that MQTT over QUIC offers an effective solution to P.S. Kim Expires 2 January 2027 [Page 7] Internet-Draft QUIC Application for ROS2 with MQTT July 2026 this challenge. Leveraging QUIC's 0-RTT/1-RTT connection and reconnection capabilities, along with its connection migration support, it can significantly enhance user experience in weak or unstable network conditions and across unpredictable network paths. ROS2 typically runs on Linux or Windows and does not provide strict real-time guarantees. To overcome this limitation, micro-ROS was developed as a subproject of ROS2[MQTT-ROS2]. It runs on top of an RTOS to enable real-time performance. Micro-ROS supports key ROS concepts, including nodes, publish/subscribe, and client/service communication, allowing it to integrate seamlessly with the broader ROS2 ecosystem. There can be a typical micro-ROS deployment scenario. In a multi-robot system, a master control node based on ROS2 handles high-level task scheduling and decision-making, while individual robots operate micro-ROS nodes responsible for low-level functionalities, including direct sensor interfacing and actuator control. The master control node can be deployed locally; however, in most cases, remote management of the robotic system is preferred. For instance, in industrial manufacturing environments, a ROS2 based master node is capable of aggregating production data from multiple micro-ROS nodes across the network and transmitting it to the MES system for process optimization and predictive maintenance. Furthermore, integration with an ERP system enables the generation of production plans and tasks based on factors such as orders and inventory levels. These tasks can then be remotely delivered to the ROS2 node, where they are decomposed into specific sub-tasks and allocated to micro-ROS nodes according to their respective roles. In such architectures, the MQTT-QUIC protocol, recognized for its lightweight design, reliability, and scalability, is often considered an effective solution for enabling communication between ROS2 nodes and enterprise systems. 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations The same security considerations as those described in RFC7880 will apply to this document. P.S. Kim Expires 2 January 2027 [Page 8] Internet-Draft QUIC Application for ROS2 with MQTT July 2026 8. References [ROS2] S. Macenski, T. Foote, B. Gerkey, C. Lalancette, W. Woodall, "Robot Operating System 2: Design, architecture, and uses in the wild," Science Robotics, vol. 7, May 2022. [DDS] OMG, Data Distribution Service for Real-time Systems Version 1.4, April 2015. [DDS-ROS2] H. S. Park, S. Lee, D. Um, H. Ryu and K. J. Park, "An Analytical Latency Model of the Data Distribution Service in ROS 2," IEEE INFOCOM 2025 - IEEE Conference on Computer Communications, London, United Kingdom, 2025, pp. 1-10. [MQTT] A. Banks, E. Briggs, K. Borgendale, and R. Gupta, Ed., MQTT Version 5.0, OASIS Standard, March 2019. [MQTT-QUIC] EMQ Technologies, MQTT Over QUIC: The Next-Generation IoT Standard Protocol, December 2024. [MQTT-ROS2] EMQX Team, MQTT & micro-ROS: Building Efficient Robotics Applicationsl, July 2024. [RFC9000] J. Iyengar, Ed., M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . Authors' Addresses Pyung Soo Kim Tech University of Korea Siheung, Gyeonggi South Korea Email: pskim@tukorea.ac.kr P.S. Kim Expires 2 January 2027 [Page 9]