{"id":"8ef9ec56-3424-432b-ac38-0e6f33e7f9a7","arxiv_id":"2508.11366","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"A QoS configuration tuning framework for ROS 2's DDS stack restores reliable large-payload delivery over lossy wireless links without protocol changes.","lead":"ROS 2, the standard robotics middleware, drops large sensor payloads on lossy wireless links. This paper identifies three causes and shows an XML-based QoS profile keeps large payloads flowing where default DDS modes fail.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Abstract's 'low end-to-end latency' is contradicted by Table II: optimized 512 KB under severe loss has 1300.60 ms latency; the central claim needs qualification or a defined latency bound.","rationale":"The Reader's weakest_assumption centers on possible overfitting of the optimized profile to the tested loss/outage conditions. That is a legitimate methodological risk, but the more immediate load-bearing problem is visible in the reported data itself: the central claim promises low end-to-end latency across large payloads, yet Table II shows a 1300.60 ms average latency for the 512 KB payload under severe loss, and 306.38 ms under link outage. The paper's own conclusion concedes the exception for 512 KB, which is in direct tension with the abstract's unqualified phrasing. This is not a matter of external representativeness; it is an internal inconsistency between the headline claim and the experimental results. If the 512 KB case is excluded from the 'low latency' part of the claim, the framework's usefulness for the motivating use cases (large LiDAR point clouds, high-resolution images) is less clear. I also agree with the Reader that the manuscript lacks methodological detail, but the latency overclaim is the more decisive issue because it would remain even if the profile parameters were perfectly honest and not overfit. The correct verdict remains CONDITIONAL: the paper can be accepted if the authors qualify the latency claim, define a latency bound, and provide the missing experimental detail. Since the Reader already assigned CONDITIONAL, my recommendation is UNCHANGED rather than a new verdict category.","tokens_in":3271,"tokens_out":5784,"duration_ms":70049,"concrete_test":"Re-run the severe-loss and link-outage experiments reporting a binary pass/fail against a specified latency deadline appropriate to the target robotics application (e.g., 95th-percentile end-to-end latency <=100 ms, or a deadline the authors explicitly justify). Recompute Table II with each 512 KB entry marked against this deadline, and also report per-run standard deviations or confidence intervals. If the 512 KB severe-loss entry (1300.60 ms) fails the deadline, revise the abstract and conclusion to state 'low latency for payloads up to 256 KB; larger payloads are delivered but with latency up to ~1.3 s under severe loss.'","verdict_should_be":"UNCHANGED","load_bearing_attack":"The strongest claim ('successfully delivers large payloads ... while maintaining low end-to-end latency', Abstract) is not supported by the paper's own Table II for the largest payload under adverse conditions. In Table II(c) Severe Loss, the Optimized DDS Profile at 512 Kb shows a reception rate of only 12.91 Hz, an average latency of 1300.60 ms, and jitter of 701.73 ms. In Table II(d) Link Outage, the 512 Kb row has 10.57 Hz and 306.38 ms latency. The conclusion itself admits 'fast and low-latency transmission across all payloads except 512 KB--even under link disruption.' Since the experiments explicitly include 512 KB as a column, the abstract's unqualified 'low end-to-end latency' is an overclaim in exactly the large-payload regime the paper targets. The table provides no error bars, no latency distribution, and no deadline with which 'low' is defined, so a reader cannot judge whether 306 ms or 1300 ms is acceptable for any robotic application. This concern is load-bearing because if 'low latency' is restricted to payloads <=256 KB, the framework's practical value for high-resolution images and LiDAR point clouds (often >256 KB) is substantially weaker.","agreement_with_reader":"disagree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":3567,"tokens_out":2694,"duration_ms":31951,"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":[{"comment":"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":"Abstract vs. Table II (c,d)"},{"comment":"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":"Section V / Table II"},{"comment":"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":"Section IV"},{"comment":"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.","section":"Section V / Optimized DDS Profile selection"}],"minor_comments":[{"comment":"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.","section":"Throughout"},{"comment":"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":"Table II caption"},{"comment":"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":"Section VI"},{"comment":"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.","section":"Section I"}],"recommendation":"major_revision","confidential_remarks":"The paper targets a real problem and the proposed approach is practical. The main issues are methodological transparency and a significant overclaim in the abstract. The central idea is defensible if the authors add a proper experimental section, report variability, and restrict the latency claim to the payload range actually supported. I do not see evidence of misconduct, but the 'first' novelty claim should be checked against existing literature. Fit with the journal's scope is acceptable after revision."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: this paper attacks a real problem and has a sensible, lightweight fix that appears to work in their experiments. But the visible excerpt is missing the methods needed to check the numbers, and the abstract claims 'low end-to-end latency' in a way that Table II contradicts at 512 KB.\n\nWhat's new: the diagnosis (IP fragmentation, retransmission timing, buffer bursts) is plausible, and the proposed XML-level QoS tuning is a good practical contribution. The table shows that under mild or severe loss, default DDS and the existing LARGE_DATA mode collapse, while the optimized profile keeps 30 Hz for payloads up to 256 KB and still delivers 12.9 Hz at 512 KB under severe loss. That's the kind of result worth looking at.\n\nWhere I'd push back. First, there is no experimental methodology in the text we see—no hardware, emulation setup, trial count, or error bars. So the precision of Table II is unverifiable. Second, the abstract's 'low end-to-end latency' doesn't survive contact with Table II(c): 512 KB severe loss gives 1300 ms average latency and 700 ms jitter. The conclusion actually qualifies 'except 512 KB,' which is honest, but the abstract should do the same. Third, while the framework tunes parameters based on link conditions, we can't tell whether the reported numbers come from the same conditions that determined the parameters—a validation split is needed. That's not fatal; it's a missing detail. Fourth, there's no reference list, so the 'first' claim can't be checked.\n\nBottom line: the paper deserves a serious referee, not a desk reject. The core idea is sound and the problem is important for ROS 2 edge/cloud workloads. But the full version needs to supply methodology, error bars, a defined latency bound, and a clearer statement on overfitting before anyone should rely on the numbers. I'd bring it to a reading group to discuss the tuning methodology, but I wouldn't cite it yet.","headline":"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.","tokens_in":4040,"tokens_out":2358,"would_cite":false,"duration_ms":25394,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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","keywords":["ROS 2","DDS","wireless communication","large payload","QoS tuning","IP fragmentation","retransmission","buffer management"],"falsifier":"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.","tokens_in":3170,"feed_emoji":"📡","tokens_out":4118,"duration_ms":42484,"temperature":0.7,"pith_summary":"The paper claims that ROS 2's default DDS stack fails on large payloads such as images and LiDAR data over wireless because of three fixable configuration problems: excessive IP fragmentation, inefficient retransmission timing, and congestive buffer bursts. It proposes tuning standard DDS QoS parameters through a plain XML profile, requiring no protocol or application changes. Experiments across ideal, lossy, and outage conditions show the optimized profile sustains roughly 30 Hz reception for payloads up to 256 KB and often 512 KB, where default modes collapse to near zero. If true, wireless robotic systems can gain reliable large-payload delivery by configuration alone.","feed_headline":"Tuned DDS profile keeps ROS 2 at 30 Hz over lossy links","feed_subtitle":"Fragment-size, retransmission, and buffer tuning deliver 256 KB messages where stock DDS modes fail.","key_machinery":"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.","core_discovery":"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","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Establishes ROS 2 as the de facto standard robotics middleware, the context the entire argument operates in.","marker":"[1]"},{"why":"Defines DDS and its RTPS peer-to-peer architecture, the communication layer being optimized.","marker":"[2]"},{"why":"Supplies the fine-grained QoS configuration mechanism that the proposed framework exploits.","marker":"[3]"}],"fun_headline_variants":["Tune 3 DDS knobs to fix ROS 2 wireless large-payload drops","Fix ROS 2 wireless large-payload failures with 3 QoS tweaks","QoS tweaks fix ROS 2 wireless large-payload drops","Drop-in QoS profile fixes ROS 2 wireless data loss"],"cache_read_input_tokens":2816,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Tune 3 DDS knobs to fix ROS 2 wireless large-payload drops","Fix ROS 2 wireless large-payload failures with 3 QoS tweaks","QoS tweaks fix ROS 2 wireless large-payload drops","Drop-in QoS profile fixes ROS 2 wireless data loss"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001173,"raw_usage":{"total_tokens":4672,"prompt_tokens":718,"completion_tokens":3954,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":462,"completion_tokens_details":{"reasoning_tokens":3886}},"tokens_in":462,"tokens_out":3954,"duration_ms":28302,"temperature":1.0,"reasoning_tokens":3886,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-05T19:57:32.548652+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[],"review_version":1}