REVIEW 4 major objections 4 minor 1 cited by
Optimizing ROS 2 Communication for Wireless Robotic Systems
T0 review · 4 major / 4 minor · reviewed 2026-08-05 · deepseek-v4-flash
Pith's one-line read A lightweight, fully compatible DDS optimization framework that tunes QoS parameters via XML configuration keeps ROS 2 large-payload streams flowing over lossy wireless links where default DDS modes fail, while preserving low end-to-end lat
desk verdict Plausible and useful ROS 2 QoS tuning fix, but the visible text lacks the methods to verify the numbers, and the abstract's 'low latency' claim is contradicted by the 512 KB row. read the letter →
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
The reading
What carries the argument
The central object is the 'Optimized DDS Profile,' a set of QoS parameter values (notably fragment size, retransmission interval, and history cache depth) applied via XML-based QoS configuration in the standard ROS 2 application interface. The framework maps link and payload characteristics to these parameters, targeting the three identified failure mechanisms: avoiding IP fragmentation by choosing a fragment size compatible with the path MTU, retransmitting lost fragments promptly rather than on a backoff schedule, and sizing the history cache to absorb bursts without overflowing. This profile carries the whole argument: no code changes, no protocol changes, just a configuration change.
What would settle it
Apply the optimized profile to a different wireless setup, such as real 802.11 with a mobile robot or an independently generated loss trace, and measure reception rate for 256 KB payloads. If the profile drops below the stated ~30 Hz or fails to beat default DDS on an unseen channel, the claimed generality of the parameter mapping is false.
Extended reading notes
Core claim
The paper's central claim is that the root causes of ROS 2 large-payload communication failure over wireless are not fundamental transport limits but three identifiable network-layer defects: excessive IP fragmentation (large payloads split into many small fragments that any single loss corrupts), inefficient retransmission timing (the DDS reliability protocol waits too long or retransmits too slowly), and congestive buffer bursts (bounded history caches overflow when bursts arrive). The proposed remedy is a DDS optimization framework expressed as a QoS profile that adjusts fragment size, retransmission timing, and history cache depth according to link characteristics and payload size. The p
Load-bearing premise
The loss and outage patterns used in the experiments stand in for real wireless channels, and the optimized profile's parameters must not have been selected by looking at results on those same patterns; if either fails, the comparison against default modes could overstate the benefit.
Editorial extensions
If this is right
- ROS 2 deployments can transport high-rate image and LiDAR streams over Wi-Fi without switching to TCP or modifying application code.
- A single XML QoS profile becomes a deployable artifact, making network-aware tuning accessible to non-experts.
- The three failure mechanisms become diagnostic checks: for wireless ROS 2 links that drop large payloads, engineers can inspect fragmentation, retransmission timing, and buffer depth first.
- Edge and cloud offloading scenarios that rely on ROS 2 wireless links gain a low-effort path to reliability.
- The approach preserves DDS interoperability because it uses standard QoS knobs rather than vendor-specific transports.
Reading between the lines
- The identified mechanisms likely apply to any UDP/RTPS-based DDS implementation, so similar QoS tuning may rescue non-ROS DDS systems over wireless.
- The static XML profile suggests a natural next step the paper does not take: adaptive or online tuning that re-selects fragment size and retransmission timing as channel conditions change.
- The paper tests periodic one-to-one traffic; its own conclusion flags event-driven and multi-node cases as open, so the profile's benefit under bursty or interfering streams remains an empirical question.
- If the profile's parameters are robust across channels rather than tuned to this testbed, the result implies the default DDS settings are optimized for wired, clean links—a claim worth testing by profiling defaults under LAN conditions.
Signed reviews
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. The paper addresses a practical and important problem: ROS 2's DDS stack performs poorly when transmitting large payloads (e.g., 256-512 KB sensor data) over lossy wireless links. The authors claim to identify three root causes—excessive IP fragmentation, inefficient retransmission timing, and congestive buffer bursts—and propose a lightweight DDS optimization framework that tunes QoS parameters through standard ROS 2 XML configuration. The main evidence is Table II, which compares Default DDS, LARGE DATA mode, and the proposed Optimized DDS Profile under ideal, mild-loss, severe-loss, and link-outage conditions. The paper concludes that the proposed profile delivers large payloads where existing modes fail, while maintaining low latency.
Significance. If the empirical claims are well supported, the contribution is valuable: the solution is standards-compliant, requires no protocol or application changes, and directly targets a widely acknowledged bottleneck in ROS 2 wireless operation. The premise is important for edge/cloud robotics, and a parameter-free or minimally tuned XML-only solution would be a practical advance. However, the current manuscript does not provide enough experimental detail to verify the claims, and one headline claim is contradicted by the paper's own data. The significance is therefore conditional on a substantially revised presentation.
major comments (4)
- [Abstract vs. Table II (c,d)] The abstract states the framework 'successfully delivers large payloads in conditions where existing DDS modes fail, while maintaining low end-to-end latency.' This is not supported for the largest payload. In Table II(c) Severe Loss, the Optimized DDS Profile at 512 KB achieves only 12.91 Hz reception rate, 1300.60 ms average latency, and 701.73 ms jitter. Table II(d) Link Outage shows 10.57 Hz and 306.38 ms. The conclusion itself admits the exception: 'except 512 KB.' Since the paper targets high-resolution images and LiDAR point clouds, which often exceed 256 KB, the abstract's unqualified claim is an overclaim. Please qualify the claim, define a latency deadline, and specify the payload range for which 'low latency' holds. This is a load-bearing issue because the practical value for exactly the target applications is weaker if the benefit is limited to <=256 KB.
- [Section V / Table II] The experimental methodology is essentially absent. No hardware details, wireless setup, loss generation model, packet-loss parameters, number of trials, or error bars are reported for Table II. The labels 'mild loss,' 'severe loss,' and 'link outage' are not defined. Without this information, the reception rates and latencies cannot be assessed for statistical reliability or reproducibility. The authors need to add a complete Section V describing the testbed, the channel emulation (including loss process, duration, and correlation), the exact DDS versions and QoS parameters, and the number of independent trials. Confidence intervals or per-trial distributions are needed, especially for the high-variance 512 KB rows.
- [Section IV] The paper claims to identify three key issues 'through systematic modeling,' and lists 'quantitatively evaluate each factor's impact' as a contribution. However, the provided text contains no equations, model derivation, or sensitivity analysis linking fragment size, retransmission timeout, or history-cache depth to the observed failures. The three issues are asserted rather than derived. Please present the model (e.g., expected transmission time as a function of fragment loss, retransmission timer, and buffer occupancy) and use it to justify the parameter choices in the Optimized DDS Profile. This is load-bearing because the framework's design should follow from the analysis, not from post-hoc tuning.
- [Section V / Optimized DDS Profile selection] The framework tunes parameters (fragment size, retransmission policy, history-cache depth) based on link and payload characteristics. The evaluation then tests the optimized profile under conditions that are presumably similar to those used for tuning. This makes the comparison partly a measure of manual per-condition optimization rather than a robust, generalizable method. To address this circularity, the authors should either: (a) fix a single profile using one set of link parameters and test it across held-out conditions, or (b) provide a sensitivity analysis showing that performance is stable over a range of parameter values. Without this, the claimed advantage over default modes may not transfer to real channels.
minor comments (4)
- [Throughout] Units are inconsistent: Table II uses 'Kb' and 'Mbps' while the text and abstract use 'KB' and 'MB'. Use SI units consistently (e.g., KB = 1024 B, Mb = 10^6 b) and clarify the intended meaning.
- [Table II caption] The table caption and each subtable have no column/row definitions. Add a sentence describing the DDS implementations, the platform, and the meaning of '—' (e.g., no messages received).
- [Section VI] The concluding paragraph contains the qualification 'across all payloads except 512 KB,' but the final sentence in Section VI states 'robust and real-time wireless communication is achievable' without that caveat. Please make the scope and limitations consistent throughout.
- [Section I] The claim of being 'the first in-depth network-layer analysis' should be supported by a broader related-work discussion, particularly with regard to wireless ROS 2 studies and DDS tuning. A more measured claim would also be safer.
Circularity Check
No significant circularity: the framework's advantage is an empirical, tunable configuration compared against fixed baselines, not a prediction that reduces to its own inputs.
full rationale
The paper proposes an optimization framework that selects DDS QoS parameters (fragment size, retransmission timing, history cache depth) based on link and payload characteristics, then compares the resulting 'Optimized DDS Profile' against Default and LARGE DATA modes in experiments. This is an empirical engineering comparison, not a circular derivation: the performance numbers in Table II are measurements, not constructed equalities, and the optimized profile could in principle underperform. No fitted parameter is relabeled as a prediction; the paper does not claim to predict unseen outcomes from a model fit to those outcomes. There are no load-bearing self-citations: the references cited (ROS 2, DDS, QoS documentation) are external standards, not prior work by the same authors invoked to justify the central claim. The only notable issue is an internal inconsistency between the Abstract's unqualified 'low end-to-end latency' and the paper's own Table II showing 1300.60 ms latency for 512 KB under severe loss, which the Conclusion partially acknowledges ('except 512 KB'). That is a correctness/overclaim concern, not circularity. The limitation statement about periodic, one-to-one communication is an honest scope restriction and does not reveal a circular step. Therefore the derivation chain is self-contained with respect to circularity.
Assumptions & free parameters
free parameters (3)
- Maximum fragment size (DDS fragment or UDP payload size) =
Not reported in excerpt
- Retransmission timeout and retry count =
Not reported in excerpt
- HistoryCache depth (buffer size) =
Not reported in excerpt
assumptions (3)
- domain assumption The three identified failure mechanisms (IP fragmentation, retransmission timing, buffer bursts) are the dominant causes of large-payload loss in ROS 2 DDS over wireless links.
- domain assumption Fast DDS's UDP-based behavior and its QoS parameters generalize to other DDS implementations and wireless environments.
- domain assumption The experimental loss and outage models in Section V/Table II are representative of real wireless channels.
Cite this review
Pith. "Pith review of Optimizing ROS 2 Communication for Wireless Robotic Systems." pith.science (2026). https://pith.science/paper/RXPDMCFG
@misc{pith2026250811366,
author = {Pith},
title = {Pith review of: Optimizing ROS 2 Communication for Wireless Robotic Systems},
year = {2026},
howpublished = {\url{https://pith.science/paper/RXPDMCFG}},
note = {Machine review of arXiv:2508.11366}
}
read the original abstract
Wireless transmission of large payloads, such as high-resolution images and LiDAR point clouds, is a major bottleneck in ROS 2, the leading open-source robotics middleware. The default Data Distribution Service (DDS) communication stack in ROS 2 exhibits significant performance degradation over lossy wireless links. Despite the widespread use of ROS 2, the underlying causes of these wireless communication challenges remain unexplored. In this paper, we present the first in-depth network-layer analysis of ROS 2's DDS stack under wireless conditions with large payloads. We identify the following three key issues: excessive IP fragmentation, inefficient retransmission timing, and congestive buffer bursts. To address these issues, we propose a lightweight and fully compatible DDS optimization framework that tunes communication parameters based on link and payload characteristics. Our solution can be seamlessly applied through the standard ROS 2 application interface via simple XML-based QoS configuration, requiring no protocol modifications, no additional components, and virtually no integration efforts. Extensive experiments across various wireless scenarios demonstrate that our framework successfully delivers large payloads in conditions where existing DDS modes fail, while maintaining low end-to-end latency.
Forward citations
Cited by 1 Pith paper
-
Dependency Chain Analysis of ROS 2 DDS QoS Policies: From Lifecycle Tutorial to Static Verification
A dependency chain of 16 DDS QoS policies is formalized into 41 violation rules and implemented as QoS Guard, an offline XML validator for ROS 2.
Reference graph
Works this paper leans on
-
[1]
Optimizing ROS 2 Communication for Wireless Robotic Systems Sanghoon Lee , Taehun Kim , Jiyeong Chae , and Kyung-Joon Park Department of Electrical Engineering and Computer Science, DGIST, Daegu, Republic of Korea Email: {leesh2913, taehun, cowldud3, kjp }@dgist.ac.kr Abstract—Wireless transmission of large payloads, such as high-resolution images and LiD...
arXiv 2025
Reviewed August 5, 2026 · model on record in the stance chip above.
Discussion (0). Continue with ORCID to comment.