Pith. sign in

REVIEW 4 major objections 6 minor 20 references

When Discovery Becomes a Storm: A ROS 2 Discovery Model for Wireless Robotic Networks

T0 review · 4 major / 6 minor · reviewed 2026-08-04 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This paper presents the first closed-loop analytical model of ROS 2 discovery, showing that shared-channel delay feeds back into reliability timers and amplifies retransmission traffic into discovery storms.

desk verdict A genuinely new closed-loop model of ROS 2 discovery storms, well validated by 1,350 runs, but missing key parameter values (O_kappa, W_i) and an empirical 'upper bound' that needs softening before the numbers are reproducible. read the letter →

arxiv 2608.02242 v1 pith:PVF6SDMJ submitted 2026-08-03 cs.NI

Yeonwoo Choi , Sanghoon Lee , Kyung-Joon Park This is my paper · ORCID
classification cs.NI
keywords discoverystormROS2DDSRTPSwirelessroboticnetworksclosed-loopmodelingreliabilityrepairHEARTBEATpacing
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper argues that ROS 2 discovery storms over wireless links are not simply a scaling problem of first-transmission metadata; they arise from a feedback loop in which shared-channel delay postpones receiver recognition, timer-driven delivery checks and repairs are generated, and those extra messages reenter the same channel, further delaying remaining metadata. It presents the first closed-loop analytical model that couples a shared wireless service with receiver states and reliability timers, and predicts both discovery completion time and per-class message counts from deployment structure, DDS timers, and a wireless-service profile. Validation across 1,350 runs and 90 two-host configurations shows an open-loop airtime baseline captures only about 17% of observed high-load completion time, while the closed-loop model reproduces the rise and conservatively upper-bounds the high-load range. The same model motivates a response-aware HEARTBEAT pacing policy that cuts mean completion time by 25.3% to 39.7%. A sympathetic reader would care because the model turns a previously qualitative 'storm' phenomenon into a quantity that can be predicted and managed.

What carries the argument

The load-bearing object is a closed-loop event model: a single shared wireless channel that serves one fragment at a time with service demand a(c) = O + 8B(c)/R; a finite source queue with admission control; receiver states P, R, X that update only on complete delivery; sender repair states U/R/Q/S/A; and five protocol timers whose expirations schedule new message-generation events. Each completed delivery updates receiver state, and each timer expiry generates checks or repairs that reenter the same channel, so message generation and delivery latency are mutually dependent rather than fixed inputs.

What would settle it

Run the same 90 two-host configurations over a mesh or cellular link (or with 802.11n A-MPDU aggregation disabled) and compare observed high-load completion times and message counts with the model's upper bound; if any observed value exceeds the model prediction, the deterministic single-server service idealization is falsified.

Watch

Extended reading notes

Core claim

The central discovery is that delayed delivery alone, without packet loss, can trigger the repair machinery of DDS discovery and amplify traffic by an order of magnitude. The paper models the wireless channel as a shared service process with per-fragment service demand, keeps receiver state unchanged until a packet is fully received, and lets five reliability timers generate HEARTBEATs, ACKNACKs, and Repair SEDP DATA from that state. These generated messages reenter the same shared service, closing the loop. The model thereby separates the topology-determined first-transmission burst from the timer-driven repair amplification and reproduces the sharp rise in completion time at high participa

Load-bearing premise

The model's upper-bound prediction rests on treating the shared Wi-Fi channel as one deterministic server carrying one fragment at a time with fixed protocol overhead and on assuming zero delay between middleware delivery and application observation; if real contention, aggregation, or middleware processing behaves differently, the upper bound may not hold.

Editorial extensions

If this is right

  • Discovery completion time and per-class message counts can be predicted from deployment structure, DDS timer values, and a wireless-service profile, rather than measured heuristically.
  • Open-loop airtime estimates understate high-load completion by roughly a factor of six (median 17.1% of observed), so feedback must be included in any capacity analysis of wireless discovery.
  • Repair traffic can be triggered by delay alone: loopback runs already contain Repair SEDP DATA in 48 configurations, so loss is not a prerequisite for storms.
  • Pacing periodic HEARTBEATs to reader responsiveness reduces mean completion time by 25.3% to 39.7%, even when total message count rises, showing that contention timing matters as much as volume.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the deterministic single-server channel idealization is replaced by a model with A-MPDU aggregation and MAC backoff, the upper-bound coverage may shrink; the paper's claim to conservatively upper-bound high-load behavior is testable under other Wi-Fi settings.
  • The same closed-loop mechanism should apply to any reliable discovery or keepalive protocol running over a shared wireless channel, suggesting the modeling approach transfers beyond ROS 2/DDS.
  • The response-aware pacing result implies that receiver-state feedback could be used to schedule other periodic control traffic in wireless robotic networks, not just HEARTBEATs.
  • The zero middleware-to-application delay assumption means application-visible completion may lag the model's completion time; including that delay would shift predictions and likely reduce the observed M/O margin.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper proposes a closed-loop model of ROS 2/DDS discovery in wireless networks. The model couples the shared wireless service with receiver-side recognition state and reliability timers: delayed delivery prevents receiver recognition, timer expirations generate HEARTBEATs, ACKNACKs, and repair traffic that re-enter the same channel, producing self-reinforcing discovery storms. The model outputs discovery completion time and per-class message counts. It is evaluated on 1,350 runs over 90 two-host configurations with Fast DDS and 802.11n. An open-loop airtime baseline is reported to capture only about 17% of high-load completion time, while the closed-loop model is said to conservatively upper-bound about 90% of high-load runs. The paper also proposes a response-aware HEARTBEAT pacing policy that reduces mean discovery completion time by 25.3% to 39.7%.

Significance. If the model's parameters are fully specified and the validation is tightened, this is a genuine advance over prior work that treats delivery conditions as fixed inputs: the closed-loop coupling between channel delay and reliability-generated traffic is the core missing piece in existing discovery-storm analyses. The experimental basis is substantial (1,350 runs, 90 configurations, loopback/Ethernet/Wi-Fi comparison), and the model inputs are fixed before model-to-observation comparison, which mitigates circularity concerns. The response-aware HEARTBEAT pacing result is interesting and suggests that the model can inform mitigation. However, the central predictive claims currently rest on unspecified service/queue parameters and on an empirical coverage statement that is weaker than the phrase 'conservatively upper-bounds' implies.

major comments (4)
  1. [§III-B, Eq. (5), Table III] The per-fragment channel-access/protocol overhead O_{κ(c)} in Eq. (5) and the finite source-queue capacity W_i in §III-B are never given numerical values, nor is it stated how they were set in the 1,350-run validation. These parameters directly control the buffering delay that keeps metadata invisible to receivers, which is exactly the feedback loop the model is designed to capture. Without them the event-driven trajectory is underspecified: different O and W choices change when HEARTBEATs, ACKNACKs, and repairs are generated, and therefore change both completion-time and message-count predictions. Provide a complete parameter table (including O_u, O_m, W_i, MTU/fragment-size handling) and a runnable artifact or, at minimum, a precise enumeration of all inputs used in every reported configuration.
  2. [§IV-C, Fig. 6] Model completion time is defined as receiver-state completion under the 'zero middleware-to-application propagation-delay' assumption, while observations are application-level proxy-match timestamps polled every 1 ms. The paper acknowledges but never quantifies this delay. For low-load configurations this unmodeled delay could dominate the comparison; for high load it is likely small, but the manuscript does not demonstrate that. Quantify the middleware-to-application polling/processing delay (or give an upper bound) and state how the model's T_disc is aligned with the observed timestamp. Otherwise the central completion-time validation is not fully specified.
  3. [Table IV, Abstract] The 'conservative upper-bound' claim is an empirical coverage statement (90.7% completion and 90.4% messages for high load; 68.0% and 84.2% overall), not a proven bound. Moreover, since O_{κ(c)} and W_i are unspecified, it is possible to inflate predictions arbitrarily and thereby 'cover' any run. Recommend replacing 'upper-bounds' with a precise coverage statement and reporting sensitivity of the coverage to the service-demand and queue parameters. This matters because coverage is the main quantitative support for the model's predictive claim.
  4. [§IV-D, Table IV] The paper claims per-class message-count prediction, but Table IV reports validation only for total messages. The text states that Repair SEDP DATA is the most sensitive metric and that capture cannot distinguish the cause of duplicates, yet no per-class coverage or error metric is reported for repair DATA, HEARTBEAT, or ACKNACK in the wireless runs. To support the per-class claim, report per-class coverage and MAPE for the high-load configurations, or explicitly restrict the validation claim to completion time and total message counts.
minor comments (6)
  1. [§III-B, Eq. (5)] Clarify whether O_{κ(c)} is a per-fragment overhead or per-packet/per-submessage overhead, and define how it relates to the fragment count. Table III should include the numerical overheads used in the experiments.
  2. [§III-C] The Initial ACKNACK delay τ_I is used in §IV-A but is not listed among the five timers defined in §III-C. Introduce it together with the other timers.
  3. [§IV-C, Fig. 6] The figure caption says 'SEDP first-recognition completion,' but the model's completion condition (Eq. (10)) includes all receiver states, including SPDP and all descriptor types. Make the caption consistent with the definition.
  4. [General] The phrase 'zero middleware-to-application propagation-delay assumption' appears only in §IV-C, but it is an assumption of the model; move it to Section III and state it explicitly.
  5. [Table V] Define B, A, and Δ(%) in the caption or table header; currently 'B/A (s)' and 'Δ(%)' are not explained in the text.
  6. [Introduction] Typo: 'adiscovery storm' in the first paragraph; also check spacing in 'by25.3%to39.7%'.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: model inputs are fixed from protocol/wireless profiles before comparison; self-citations are baselines, not load-bearing.

full rationale

I walked the derivation chain from Section III through Section IV. The closed-loop model is constructed from a structural workload (Eq. 1-2), a DDS/Fast DDS timer and trigger profile (Table III), and a wireless service process (Eq. 5-6). The six event rules in Section III-C generate HEARTBEAT, ACKNACK, and repair traffic from receiver state and timer expirations; the outputs (Eq. 10, message-count sums) are not fed back into any model input. The paper explicitly states: 'The model inputs are fixed before the model-to-observation comparison... Measured completion times and message counts are then used to evaluate the resulting model predictions.' The failure-free reference (Eq. 3-4) is checked independently against loopback captures (MAPE 0.82% for total submessages), not calibrated to the Wi-Fi completion-time data. Self-citations [3] and [4] are used only as an open-loop baseline and as related-work comparisons; no load-bearing derivation step invokes them to force a conclusion. The unstated numerical values of O_kappa in Eq. 5 and W_i in Section III-B are a reproducibility limitation, not a circular reduction: an under-specified model is not a tautological one unless the missing values are shown to be fitted to the target. The 'conservatively upper-bounds' claim is an empirical coverage statement (Table IV), not a property derived from the model, so it cannot be circular. The zero middleware-to-application delay assumption is acknowledged and does not make the prediction equal to its inputs. No self-definitional, fitted-input-called-prediction, self-citation-load-bearing, uniqueness-imported, ansatz-smuggled, or renaming pattern is present.

Assumptions & free parameters 3 free parameters · 4 assumptions · 0 invented entities

The model introduces no new protocol entities; it composes existing Fast DDS timers and Wi-Fi service. The main unstated numeric inputs are the per-fragment overheads in Eq (5) and the source-queue capacity W_i; both affect completion timing and the upper-bound claim. The policy adds hand-chosen constants epsilon/Tmin/Tmax. The model's core assumptions are the deterministic single-server channel and the fidelity of the Fast DDS event rules.

free parameters (3)
  • Per-fragment channel-access/protocol overhead O_kappa(c)
    Appears in Eq (5) as part of wireless service demand a(c); numerical values are not given in the manuscript, so an independent reproduction must choose them. If chosen to force upper-bound behavior, this would be a fitted parameter.
  • Source-queue capacity W_i
    Introduced in Section III-B as a finite queue admission threshold; no value or source is specified. It affects how much traffic is admitted and therefore the completion timing.
  • Policy constants epsilon, Tmin, Tmax = epsilon=0.05, (Tmin,Tmax)=(0.1,3.0) s
    Hand-chosen constants in Section IV-E for the response-aware heartbeat schedule; they affect the reported 25.3-39.7% completion-time reduction but are not derived from the model.
assumptions (4)
  • domain assumption The shared wireless channel is modeled as a single server carrying one fragment at a time with deterministic service demand a(c)=O+8B/R (Eq 5,6); real Wi-Fi losses, MAC retries, A-MPDU aggregation and contention-dependent backoff are not explicitly modeled.
    Underpins the entire closed-loop service model; acknowledged in Section IV-D as a simplification, with A-MPDU aggregation listed as a cause of the model's upper-range tendency.
  • domain assumption All processes start synchronized and discovery messages are the only traffic; application completion is approximated by 1-ms polling of matched-endpoint counters.
    Validation uses synchronized runs (Section IV-A3); the model assumes zero middleware-to-application propagation delay (Fig. 6 caption) and ignores non-discovery traffic.
  • domain assumption The protocol state machine faithfully follows Fast DDS 2.6.11 behaviors, including SPDP unicast/multicast, Initial ACKNACK timer, HEARTBEAT/ACKNACK timers, suppression, and piggyback triggers.
    These rules close the feedback loop in Section III-C; any mismatch between the model's event rules and the real implementation would break the predicted counts.
  • domain assumption The failure-free reference counts (alpha profile counts) and topology-normalized loopback captures are valid proxies for first-transmission discovery demand.
    Used in Eqs (3)-(4) and validated against loopback in Section IV-D; the model's amplification is measured relative to this reference.

how reviews work

0 comments
Cite this review

Pith. "Pith review of When Discovery Becomes a Storm: A ROS 2 Discovery Model for Wireless Robotic Networks." pith.science (2026). https://pith.science/paper/PVF6SDMJ

@misc{pith2026260802242,
  author       = {Pith},
  title        = {Pith review of: When Discovery Becomes a Storm: A ROS 2 Discovery Model for Wireless Robotic Networks},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/PVF6SDMJ}},
  note         = {Machine review of arXiv:2608.02242}
}
read the original abstract

In Robot Operating System 2 (ROS 2), Data Distribution Service (DDS) participants must discover one another before exchanging data. In wireless environments, delayed or lost discovery messages cause reliability timers to expire, triggering retransmissions that intensify channel contention and further delay the delivery of discovery messages. This self-reinforcing feedback can escalate into a discovery storm. Existing models characterize discovery demand under fixed delivery conditions, but do not capture how shared-channel delay changes protocol state and generates further traffic. To address this issue, we present the first closed-loop analytical model of ROS 2 discovery that characterizes how delay-induced feedback amplifies retransmission overhead and leads to severe discovery storms. Our model represents channel contention as a shared service process, coupling message-delivery latency with receiver states and reliability timers. The model predicts both discovery completion time and per-class message counts. We validate the model through 1,350 experimental runs across 90 topology configurations. An open-loop airtime baseline captures only a fraction of the high-load completion time. The closed-loop model reproduces this rise and conservatively upper-bounds the observed high-load range. Guided by insights from the model, we further design a response-aware discovery policy that reduces mean discovery completion time by 25.3% to 39.7%.

Figures

Figures reproduced from arXiv: 2608.02242 by the authors.

Figure 1
Figure 1. Homogeneous DDS discovery topology used in the evaluation, with [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Ratio of the wireless and wired run-mean total discovery-message [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Closed-Loop discovery service. Channel service controls receiver [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: Writer-side repair state for one descriptor. Confirmation moves any [PITH_FULL_IMAGE:figures/full_fig_p004_4.png]
Figure 5
Figure 5. Figure 5: Total discovery submessages (top row) and ACKNACKs (bottom row) for loopback, Ethernet, and Wi-Fi. Loopback and Ethernet use the same vertical [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]
Figure 6
Figure 6. Figure 6: Wireless discovery completion versus workload. Points show application [PITH_FULL_IMAGE:figures/full_fig_p008_6.png]
Figure 7
Figure 7. Figure 7: Discovery completion with the default and adaptive HEARTBEAT [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

20 extracted references

  1. [1]

    Robot Operating System 2: Design, architecture, and uses in the wild,

    S. Macenski, T. Foote, B. Gerkey, C. Lalancette, and W. Woodall, “Robot Operating System 2: Design, architecture, and uses in the wild,”Science Robotics, vol. 7, no. 66, p. eabm6074, May 2022

    2022

  2. [2]

    The Real-Time Publish-Subscribe Protocol: DDS Interoperability Wire Protocol (DDSI-RTPS), Version 2.5,

    Object Management Group, “The Real-Time Publish-Subscribe Protocol: DDS Interoperability Wire Protocol (DDSI-RTPS), Version 2.5,” Object Management Group, Tech. Rep. formal/22-04-01, Apr. 2022. [Online]. Available: https://www.omg.org/spec/DDSI-RTPS/2.5

    2022

  3. [3]

    Discovery Storm: Scalability analysis of DDS and Zenoh in large-scale wireless robotic networks,

    S. Lee, Y . Choi, J. Chae, and K.-J. Park, “Discovery Storm: Scalability analysis of DDS and Zenoh in large-scale wireless robotic networks,” in Proceedings of IEEE INFOCOM, May 2026, pp. 1–6

    2026

  4. [4]

    An analytical latency model of the Data Distribution Service in ROS 2,

    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,” inProceedings of IEEE INFOCOM, May 2025, pp. 1–10

    2025

  5. [5]

    Bloom filter-based discovery protocol for DDS middleware,

    J. S ´anchez-Monedero, J. Povedano-Molina, J. M. L ´opez-Vega, and J. M. L´opez-Soler, “Bloom filter-based discovery protocol for DDS middleware,” Journal of Parallel and Distributed Computing, vol. 71, no. 10, pp. 1305– 1317, Oct. 2011

    2011

  6. [6]

    Content-based filtering discovery protocol (CFDP): Scalable and efficient OMG DDS discovery protocol,

    K. An, A. S. Gokhale, D. C. Schmidt, S. Tambe, P. Pazandak, and G. Pardo-Castellote, “Content-based filtering discovery protocol (CFDP): Scalable and efficient OMG DDS discovery protocol,” inProceedings of the 8th ACM International Conference on Distributed Event-Based Systems (DEBS), May 2014, pp. 130–141

    2014

  7. [7]

    A centralized discovery-based method for integrating Data Distribution Service and Time-Sensitive Networking for In-Vehicle Networks,

    F. Luo, Y . Ren, Y . Yu, Y . Li, Q. Liu, and X. Zhang, “A centralized discovery-based method for integrating Data Distribution Service and Time-Sensitive Networking for In-Vehicle Networks,”Ad Hoc Networks, vol. 178, p. 103950, Nov. 2025

    2025

  8. [8]

    Impact of ROS 2 node composition in robotic systems,

    S. Macenski, A. Soragna, M. Carroll, and Z. Ge, “Impact of ROS 2 node composition in robotic systems,”IEEE Robotics and Automation Letters, vol. 8, no. 7, pp. 3996–4003, Jul. 2023

    2023

Show all 20 references
  1. [9]

    Exploring the effects of multicast communication on DDS performance,

    K. Peeroo, P. Popov, and V . Stankovic, “Exploring the effects of multicast communication on DDS performance,” inProceedings of the 18th European Dependable Computing Conference (EDCC) Student Forum, Sep. 2022

    2022

  2. [10]

    Performance evaluation of DDS-based middleware over wireless channel for recon- figurable manufacturing systems,

    B. Almadani, M. N. Bajwa, S.-H. Yang, and A.-W. A. Saif, “Performance evaluation of DDS-based middleware over wireless channel for recon- figurable manufacturing systems,”International Journal of Distributed Sensor Networks, vol. 11, no. 7, p. 863123, Jul. 2015

    2015

  3. [11]

    The synchronization of periodic routing messages,

    S. Floyd and V . Jacobson, “The synchronization of periodic routing messages,”IEEE/ACM Transactions on Networking, vol. 2, no. 2, pp. 122–136, Apr. 1994

    1994

  4. [12]

    The broadcast storm problem in a mobile ad hoc network,

    S.-Y . Ni, Y .-C. Tseng, Y .-S. Chen, and J.-P. Sheu, “The broadcast storm problem in a mobile ad hoc network,”Wireless Networks, vol. 8, no. 2–3, pp. 153–167, 2002

    2002

  5. [13]

    MAD-DDS: Memory-efficient automatic discovery Data Distribution Service for large- scale distributed control network,

    W.-P. Nwadiugwu, D.-S. Kim, W. Ejaz, and A. Anpalagan, “MAD-DDS: Memory-efficient automatic discovery Data Distribution Service for large- scale distributed control network,”IET Communications, vol. 17, no. 12, pp. 1432–1446, Jul. 2023

    2023

  6. [14]

    Exploring the performance of ROS 2,

    Y . Maruyama, S. Kato, and T. Azumi, “Exploring the performance of ROS 2,” inProceedings of the 13th ACM International Conference on Embedded Software (EMSOFT), Oct. 2016, pp. 1–10

    2016

  7. [15]

    Systematic analysis of DDS implementations,

    V . Bode, D. Buettner, T. Preclik, C. Trinitis, and M. Schulz, “Systematic analysis of DDS implementations,” inProceedings of the 24th ACM/IFIP International Middleware Conference, 2023, pp. 234–246

    2023

  8. [16]

    Latency analysis of ROS 2 multi-node systems,

    T. Kronauer, J. Pohlmann, M. Matth ´e, T. Smejkal, and G. Fettweis, “Latency analysis of ROS 2 multi-node systems,” inProceedings of the 2021 IEEE International Conference on Multisensor Fusion and Integration for Intelligent Systems (MFI), Sep. 2021, pp. 1–7

    2021

  9. [17]

    Evaluation of the Data Distribution Service for a lossy autonomous hybrid system,

    P. Thulasiraman, Y . K. D. Cheng, and B. Allen, “Evaluation of the Data Distribution Service for a lossy autonomous hybrid system,” in Proceedings of the 2022 IEEE International Systems Conference (SysCon), Apr. 2022, pp. 1–8

    2022

  10. [18]

    Swarm robot communications in ROS 2: An experimental study,

    J.-B. Castillo-S ´anchez, E. Gonz ´alez-Parada, and J.-M. Cano-Garc ´ıa, “Swarm robot communications in ROS 2: An experimental study,”IEEE Access, vol. 12, pp. 142 930–142 943, 2024

    2024

  11. [19]

    Bounding the data-delivery latency of DDS messages in real-time applications,

    G. Sciangula, D. Casini, A. Biondi, C. Scordino, and M. Di Natale, “Bounding the data-delivery latency of DDS messages in real-time applications,” inProceedings of the 35th Euromicro Conference on Real-Time Systems (ECRTS), ser. Leibniz International Proceedings in Informatics...

    2023

  12. [20]

    Toward the automatic network resource management of Robot Operating System in programmable mobile networks,

    G. Szab´o, “Toward the automatic network resource management of Robot Operating System in programmable mobile networks,”IEEE Access, vol. 11, pp. 65 934–65 955, 2023

    2023

Pith tools

Reviewed August 4, 2026 · model on record in the stance chip above.