QUIC Application for ROS2 with MQTT
draft-pskim-ros2-quic-mqtt-00

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, 
              <https://www.rfc-editor.org/info/rfc9000>.

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]