{"id":"d7148b4f-55c1-46dc-8a6c-915c42fd1783","arxiv_id":"2412.07485","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"In a benchmark of ROS2 middleware, same-domain communication usually beat cross-domain communication, eProsima Fast-DDS lagged most on cross-domain transfers, and no vendor won across all conditions.","lead":"This paper measures how quickly ROS2 robots can exchange messages across different DDS communication domains, using different hardware and data types. It finds that no single DDS vendor performs best in every scenario, and that cross-domain communication often adds latency.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Eq. (3) does not yield a valid one-way latency: it splits publisher-side overhead across two wireless legs and assumes path symmetry, so the Section 6 hard-real-time conclusion is not tied to a validated latency metric.","rationale":"I read the paper as an engineering benchmark whose central conclusion is the Section 6 statement that cross-domain wireless ROS2/DDS cannot meet hard real-time AV requirements. The most load-bearing premise is that Eq. (3) yields the one-way latency used in every comparison. I find that premise insecure: the equation subtracts only the relay's measured T4 - T3 from RTT and halves the remainder, while RTT also contains the initiating publisher's send/receive overhead; with a laptop on one end and a Pi on the other, and with Wi-Fi asymmetry, the two legs and the two endpoints' overheads are not equal. The paper offers no synchronized-clock one-way measurement or raw distributions to bound this bias. A further gap is that 'hard real-time' is never given a latency bound, so even a corrected latency cannot be classified. This is a real internal-validity concern, not a disagreement with community consensus. It does not make the qualitative observation that cross-domain bridging adds latency implausible; rather it means the specific hard-real-time verdict is not established by the reported numbers. A PTP-synchronized re-run with true one-way timestamps and a stated deadline would settle it. This supports the reader's CONDITIONAL verdict rather than changing it.","tokens_in":9464,"tokens_out":10145,"duration_ms":110266,"concrete_test":"Using the published repository, instrument the publisher with timestamps immediately before and after the publish() call and the subscriber with a receipt timestamp, synchronizing both machines with PTP (IEEE 1588) over the same wired and wireless setups. Compute true forward one-way latency for the same same-domain and cross-domain configurations in Section 4 and compare it with the Eq. (3) value from the same runs. Also state the hard real-time deadline under test (e.g., 10 ms or 100 ms) and report the fraction of messages exceeding it; if the Eq. (3) error is larger than the margin to that deadline, the Section 6 conclusion is not supported.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 3.2 defines RTT as T2 - T1, where T1 is taken when the publisher sends and T2 when the reply arrives back at the publisher. The relay node records T3 on receipt and T4 on relay-publish, so the intermediate-process time is T4 - T3. Eq. (3) then reports one-way latency as (RTT - intermediate-process time)/2. This is valid only if the only non-network time inside RTT is the measured relay processing and the two wireless legs are identical. In the described setup, RTT also contains the initiating publisher's send-side and receive-side processing, which are not in T4 - T3. Because the publisher and subscriber are different devices (e.g., laptop vs. Raspberry Pi in Table 2), those overheads are not equal and are not correctly split by the division. On Wi-Fi, forward and return legs can also differ in contention and retry behavior, so the result is neither the forward one-way delay nor a bounded estimator of it. All vendor comparisons in Section 4 and the hard-real-time claim in Section 6 are built on this quantity. The paper provides no raw RTT or intermediate-time distributions and no clock-synchronized one-way measurement to show that the bias is small, so the central quantitative conclusion is not established.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper evaluates three vendor-specific DDS implementations (Eclipse Cyclone DDS, eProsima Fast DDS, RTI Connext DDS) with their bridging services in ROS2 Humble for same-domain and different-domain communication over wired and wireless links. It reports latency measurements for binary, string, and IMU data types on Raspberry Pi 3/4, Jetson Nano, and laptops, and concludes that no single DDS vendor dominates, that eProsima performs worst for different-domain communication, and that ROS2 vendor-specific DDS implementations are not capable of fulfilling hard real-time requirements for cooperative driving over wireless.","tokens_in":9667,"tokens_out":4308,"duration_ms":45883,"significance":"If validated, the comparison of same-domain versus different-domain bridging across vendors would be a useful practical reference for ROS2 developers in cooperative driving and multi-robot systems. The paper has concrete strengths: it uses heterogeneous physical hardware, multiple data types, a real camera stream test, and it makes the experiment code available online. However, the central latency metric in Eq. (3) rests on untested symmetry assumptions, and the reported comparisons lack any statistical confidence information, so the quantitative vendor ranking and the hard-real-time conclusion are not yet established.","major_comments":[{"comment":"The latency estimator in Eq. (3) is not a valid one-way latency. The RTT includes the initiating publisher's send-side and receive-side processing, which are not captured by the relay's T4−T3 interval, and the halving assumes the two legs are symmetric in both network conditions and endpoint processing. Since the publisher and subscriber are different devices (Table 2), their per-message processing times are not equal; on Wi-Fi the forward and return paths can also differ due to contention, retries, and rate adaptation. All §4 comparisons and the §6 hard-real-time conclusion are built on this quantity. The paper should either measure one-way latency with synchronized clocks (e.g., PTP/chrony), or report RTT and intermediate-processing time separately without dividing by two, or provide a quantitative bound showing that the bias is negligible for the conclusions drawn.","section":"§3.2, Eq. (3)"},{"comment":"No trial counts, error bars, standard deviations, or raw latency distributions are reported. The text relies on visual descriptions of plots, including the unexpected result that 502 KB files often yield higher latency than 1 MB files (figures 3b and 3c), and the cross-vendor rankings. Without measures of dispersion or at least a stated number of repetitions per configuration, these differences cannot be distinguished from measurement noise. This undermines the central vendor-level claims, including the recommendations to avoid eProsima for different-domain communication and to prefer RTI Connext for mixed-domain workloads. Please report the number of repetitions, per-configuration statistics, and, where possible, confidence intervals.","section":"§4"},{"comment":"The claim that 'ROS2's vendor-specific DDS implementations are not capable enough to fulfill the hard real-time requirements' is not tied to any quantified deadline. Hard real-time is an application-specific property; the paper should state the assumed end-to-end latency bound (e.g., a braking or cooperative-perception deadline) and compare the measured values against that bound. Without a stated threshold, the central conclusion is not falsifiable and cannot be assessed. This is load-bearing because it motivates the entire framing of the paper as a cooperative-driving evaluation.","section":"§6"}],"minor_comments":[{"comment":"The text says 'This paper presents a noble performance comparison' but should read 'novel performance comparison'.","section":"Contribution paragraph"},{"comment":"The word 'intermediate-processtime' appears without a space; it should be 'intermediate-process time' for consistency with the surrounding text.","section":"§3.2"},{"comment":"The statement that Docker on the host network produces 'negligible latency overhead' is supported only by a citation to a general container/VM comparison; the manuscript should verify this for the specific DDS/UDP multicast workloads used, since even a small constant bias can affect absolute latency comparisons with real-time thresholds.","section":"§3.3 Software"},{"comment":"The figure captions in §4 do not fully specify axes, units, or the meaning of the plotted curves; please ensure every panel has labeled axes with latency units and a legend, and that the captions explicitly state which domain and connectivity scenario each panel represents.","section":"§4 figure captions"},{"comment":"Reference [24] is a shortened URL that may become unstable; use a stable identifier or direct URL, and check formatting consistency across the reference list.","section":"References"}],"recommendation":"major_revision","confidential_remarks":"The paper reads more like a workshop or work-in-progress report than a full archival study. The experimental breadth is commendable, but the reviewer's main concern is not the breadth rather the validity of the primary metric and the absence of statistical treatment. If the authors can re-measure with a defensible one-way latency protocol or clearly reframe the paper around RTT, and add repetition statistics, the paper could become a solid systems evaluation. I would not recommend rejection outright because the qualitative pattern (cross-domain costs, no universal winner, eProsima often worst) is plausible and the code and hardware choices are reproducible."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Simon, here's my read on Paul et al. (arXiv:2412.07485). The paper benchmarks three DDS implementations in ROS2 Humble, comparing same-domain and different-domain communication over wired/wireless links on several ARM/x86 boards. That scenario is genuinely new—I don't know of another study that looks at cross-domain bridging across vendor DDS stacks for cooperative-driving workloads. The authors use realistic data types (binary images, IMU, string) and report per-device trends. The qualitative takeaway—cross-domain communication costs extra latency, eProsima's Integration Service is consistently the worst, and no single vendor wins everywhere—is plausible and practically useful.\n\nThe main problem is the latency metric. Section 3.2, Eq. (3) computes one-way latency as (RTT − intermediate-process time)/2. That only works if the two network legs have symmetric delays and if the only non-network time inside the RTT is the relay's measured processing time. But the RTT also includes the initiating publisher's send-side and receive-side processing, which is not in T4−T3 and is not split correctly by the division, especially when the two ends are different machines (e.g., laptop vs Raspberry Pi). On Wi-Fi, forward and return paths can also differ due to contention and retries. The paper neither justifies nor tests this symmetry assumption, so the reported latencies are not a clean one-way measure and could carry a systematic bias. The hard-real-time conclusion in Section 6 rests on this quantity, so it is not as strong as stated.\n\nThe other soft spots are statistical. There are no error bars, no trial counts, no raw RTT distributions, and no archived dataset, so the 502KB spike and the machine-dependent reversals (e.g., different-domain beating same-domain for large files) could easily be noise. The recurring 502KB anomaly is acknowledged but not investigated. That is honest, but also a sign that the analysis was not pushed far enough.\n\nWhat the paper does well: the hardware setup is varied, the parameter space is clearly described, and the authors ship their code on GitHub. That gives a referee something to check. The related-work citations are adequate.\n\nFor peer review: I would send this to review, but with major revisions. A serious referee should demand proper latency validation (e.g., clock-synchronized one-way measurements or at least RTT histograms), statistical reporting, and an explanation or removal of the 502KB anomaly. The qualitative findings are likely robust, but the quantitative claims need rebuilding on solid ground. It's a reasonable starting point for the community, just not ready as-is.","headline":"A useful but statistically thin benchmark of cross-domain ROS2/DDS bridging; the latency metric in Eq. (3) is not validated, so the hard-real-time conclusion is overstated.","tokens_in":10222,"tokens_out":3053,"would_cite":false,"duration_ms":30011,"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":"This paper claims that current ROS2 DDS vendor implementations, used for different-domain communication over wireless links, cannot meet hard real-time cooperative driving requirements, and no vendor wins in all cases.","keywords":["ROS2","DDS","vendor-specific DDS implementations","domain participant","same-domain communication","different-domain communication","cooperative driving","latency"],"falsifier":"Re-run the cross-domain ping-pong experiment on a wireless link with synchronized clocks on both nodes and measure one-way latency directly in each direction; if the directly measured values diverge from the paper's (RTT - intermediate-process time)/2 estimate, the absolute latency conclusions are biased. A second check is to repeat the 502KB file-size sweep with finer size steps to confirm whether the spike is a real fragmentation threshold.","tokens_in":9229,"feed_emoji":"🚗","tokens_out":8165,"duration_ms":74855,"temperature":0.7,"pith_summary":"This paper asks whether the middleware that connects ROS2 nodes can carry cooperative-driving data when vehicles, sensors, and robots cannot all share one DDS domain. It measures round-trip latency across same-domain and different-domain communication for three vendor DDS implementations, several data types and sizes, wired and wireless links, and five physical devices. The central finding is that same-domain communication usually outperforms different-domain communication, that no single vendor dominates every case, and that eProsima Fast-DDS is consistently the worst for cross-domain transfers. From these results the paper concludes that current vendor DDS implementations are not capable enough for hard real-time requirements over wireless cross-domain links, which matters because cooperative perception needs reliable, low-latency exchange of sensor data.","feed_headline":"Cross-domain ROS2 wireless latency misses hard real-time bar","feed_subtitle":"Three DDS vendors, five devices, one result: cross-domain wireless can't meet hard real-time.","key_machinery":"The argument is carried by a ping-pong round-trip test with a relay node. A publisher in one DDS domain (e.g., domain 5) timestamps a message and sends it; a subscriber in another domain (e.g., domain 10) receives it and relays it back on a second topic; the publisher timestamps the return. One-way latency is computed as (RTT - intermediate-process time)/2, where the intermediate time is measured locally on the relay node as the gap between receiving and relaying. Every cross-domain path therefore contains a vendor-specific bridging service (Zenoh plugin, Integration Service, or Routing Service), and the latency behavior the paper reports is the behavior of those bridges plus the transport. The DDS domain is the scoping mechanism that forces the relay; the bridge is the object whose performance is under test.","core_discovery":"The central discovery is an empirical characterization of cross-domain latency in ROS2. Because DDS limits participant counts per domain, a vehicle or platoon with many nodes must bridge across domains via vendor-specific services: Zenoh for Eclipse Cyclone DDS, Integration Service for eProsima Fast-DDS, and Routing Service for RTI Connext DDS. Across a large parameter sweep, same-domain communication generally beat different-domain communication; eProsima Fast-DDS was worst at cross-domain communication for all data types, connectivities, and devices; Cyclone DDS was best for large files over wireless different domains; and RTI Connext showed the smallest gap between same-domain and different-domain performance. The paper also observed a systematic latency spike for 502KB binary files across vendors. The conclusion is that different-domain DDS over wireless is not hard-real-time capable at this moment, and the likely culprit is the bridging services.","pith_inferences":["The paper's latency formula assumes symmetric one-way paths; on wireless links this is often false, so the absolute latency values may be biased even if the relative vendor rankings hold.","If hard real-time cannot be met across DDS domains, the practical route for cooperative driving may be to keep safety-critical control loops inside one domain or on a dedicated link, and use cross-domain DDS only for non-critical perception data.","The 502KB spike hints at a fragmentation or buffer threshold near that size; probing with sizes between 400KB and 600KB could turn the anomaly into a diagnosable implementation detail.","The evaluation is static in the sense of fixed QoS; combining the same setup with deadline-based QoS or 5G transport could test whether cross-domain DDS at least meets soft real-time constraints."],"forward_implications":["Developers should keep ROS2 nodes in the same DDS domain whenever possible, since same-domain communication usually had lower latency.","eProsima Fast-DDS should be avoided for different-domain communication; it showed the worst performance in every tested wired and wireless scenario.","RTI Connext DDS is the safer default when an application needs both same-domain and cross-domain links, because it showed the smallest latency gap between the two.","For large binary files sent across wirelessly connected different domains, Eclipse Cyclone DDS provided better latency than the alternatives.","Binary frames around 502KB should be investigated or avoided: they triggered a latency spike across DDS implementations, sometimes exceeding the latency of 1MB frames."],"supporting_citations":[{"why":"Supplies the ROS2-based self-driving car architecture that motivates the multi-node, multi-sensor communication scenario.","marker":"[1]"},{"why":"Defines cooperative perception over wireless as the application context for cross-vehicle data exchange.","marker":"[7]"},{"why":"Documents the RTI Connext participant-per-domain limit that makes different-domain communication unavoidable.","marker":"[8]"},{"why":"Provides the Zenoh-DDS bridge used for Eclipse Cyclone DDS cross-domain communication.","marker":"[10]"},{"why":"Supplies the baseline ROS1-versus-ROS2 latency comparison and message-size methodology that frames the evaluation.","marker":"[12]"},{"why":"Establishes the round-trip time measurement pattern and the wider middleware comparison (DDS, OPC UA, MQTT, ROS1).","marker":"[14]"},{"why":"Justifies using round-trip time rather than one-way latency because of clock-synchronization difficulty.","marker":"[16]"},{"why":"Supports the claim that Docker adds negligible latency overhead on the host network, validating the containerized test setup.","marker":"[27]"}],"fun_headline_variants":["DDS cross-domain wireless fails hard real-time in AVs","Cross-domain DDS: wireless latency defies hard real-time","ROS2 DDS bridges: cross-domain wireless misses real-time bar","Vendor DDS bridges can't clear hard real-time over wireless"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that one-way latency equals half of the round-trip time minus half of the relay node's measured handling time; if the outward and return wireless paths take different amounts of time, which is common on wireless links, the reported latencies are systematically biased.","fun_headline_variants_meta":{"raw":{"variants":["DDS cross-domain wireless fails hard real-time in AVs","Cross-domain DDS: wireless latency defies hard real-time","ROS2 DDS bridges: cross-domain wireless misses real-time bar","Vendor DDS bridges can't clear hard real-time over wireless"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000858,"raw_usage":{"total_tokens":3768,"prompt_tokens":1032,"completion_tokens":2736,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":648,"completion_tokens_details":{"reasoning_tokens":2663}},"tokens_in":648,"tokens_out":2736,"duration_ms":21121,"temperature":1.0,"reasoning_tokens":2663,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T18:47:28.359598+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Re-run the cross-domain ping-pong experiment on a wireless link with synchronized clocks on both nodes and measure one-way latency directly in each direction; if the directly measured values diverge from the paper's (RTT - intermediate-process time)/2 estimate, the absolute latency conclusions are biased. A second check is to repeat the 502KB file-size sweep with finer size steps to confirm whether the spike is a real fragmentation threshold.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the ROS2-based self-driving car architecture that motivates the multi-node, multi-sensor communication scenario."},{"cited_title":"URL: https:// community.rti.com/kb/what-maximum-number-participants-domain","cited_arxiv_id":null,"evidence_quote":"Documents the RTI Connext participant-per-domain limit that makes different-domain communication unavoidable."},{"cited_title":"URL: https://zenoh.io/blog/2021-04-28-ros2-integration","cited_arxiv_id":null,"evidence_quote":"Provides the Zenoh-DDS bridge used for Eclipse Cyclone DDS cross-domain communication."},{"cited_title":"Profanter, A","cited_arxiv_id":null,"evidence_quote":"Establishes the round-trip time measurement pattern and the wider middleware comparison (DDS, OPC UA, MQTT, ROS1)."}],"review_version":1}