{"id":"fc0200a9-dd2a-4f8a-b521-d716eac6af96","arxiv_id":"2608.02242","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"ROS 2 discovery storms on wireless links are driven by delayed delivery triggering reliability retransmissions, and a closed-loop model reproduces this amplification and guides a heartbeat-pacing fix.","lead":"A new model of ROS 2's discovery protocol treats wireless delays and retransmissions as a feedback loop, predicting when startup gets stuck in a 'discovery storm.' The authors validate the model on 1,350 test runs and use it to design a heartbeat-pacing fix that cuts average discovery time by up to about 40%.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The closed-loop model's key inputs — the channel-access/protocol overhead O_kappa in Eq. 5 and the source-queue capacity W_i — are never given numerical values, so the predicted trajectories and Table IV upper-bound coverage cannot be independently reproduced.","rationale":"The reader's weakest-assumption analysis identified the same load-bearing gap: the model depends on unspecified channel-overhead and source-queue parameters, and the upper-bound claim is empirical rather than formal. My stress-test pass confirms this is the most consequential weakness. The paper's event-driven rules are detailed, and the 1,350-run dataset is a genuine empirical effort, but the absence of O_kappa and W_i values means the central 'predictive model' claim cannot be checked by a third party. I also considered the SPDP scaling in Eq. (11), where c_SPDP squares the participant-population ratio while Eq. (4) includes both multicast and unicast components; this may affect the loopback reference validation, but it is secondary to the parameter-specification gap. Since the reader's conditional verdict already accounts for this concern, I recommend no change to the verdict.","tokens_in":13356,"tokens_out":9325,"duration_ms":80812,"concrete_test":"Run an independent implementation of the Section III event-driven model using the authors' exact parameter files, which must include numerical values for O_u, O_m, W_i for all 90 configurations, the three service-order rules, and the timer values. Recompute the Table IV high-load coverage and the Fig. 6 closed-loop completion curve, then compare to the published 90.7% / 90.4% coverage and the 17% open-loop baseline. If the published numbers cannot be reproduced, the predictive claim fails; if the authors cannot provide the numerical parameters, the model is not independently verifiable.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim is that the model predicts discovery completion time and per-class message counts from deployment structure, DDS timers, and a wireless-service profile. But Eq. 5 defines the service demand as a(c) = O_kappa + 8B(c)/R_kappa, and O_kappa is never assigned a value. Similarly, Section III-B defines W_i as the finite source-queue capacity but never states its numerical value or how it was set in the 1,350-run validation. These two parameters directly control the buffering delay that delays receiver recognition — the very feedback the model is designed to characterize. Without them, the model's event-driven trajectory is underspecified: different choices of O_kappa and W_i will change when HEARTBEATs, ACKNACKs, and repairs are generated, and therefore change both completion-time and message-count predictions. The paper's conservative-upper-bound claim is empirical coverage (90.7% completion, 90.4% messages at high load), not a proven property; if O_kappa is large or W_i is small, it is trivial to manufacture upper-range estimates. Additionally, Section IV-C compares the model's receiver-state completion time against application-level proxy-match timestamps while assuming zero middleware-to-application delay; this assumption is acknowledged but not quantified. The absence of code or a complete parameter table prevents a reader from distinguishing a genuine closed-loop predictive model from a parameterized curve fit, so the strongest claim is not currently reproducible.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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%.","tokens_in":13686,"tokens_out":5454,"duration_ms":45279,"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":[{"comment":"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.","section":"§III-B, Eq. (5), Table III"},{"comment":"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.","section":"§IV-C, Fig. 6"},{"comment":"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.","section":"Table IV, Abstract"},{"comment":"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.","section":"§IV-D, Table IV"}],"minor_comments":[{"comment":"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.","section":"§III-B, Eq. (5)"},{"comment":"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.","section":"§III-C"},{"comment":"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.","section":"§IV-C, Fig. 6"},{"comment":"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.","section":"General"},{"comment":"Define B, A, and Δ(%) in the caption or table header; currently 'B/A (s)' and 'Δ(%)' are not explained in the text.","section":"Table V"},{"comment":"Typo: 'adiscovery storm' in the first paragraph; also check spacing in 'by25.3%to39.7%'.","section":"Introduction"}],"recommendation":"major_revision","confidential_remarks":"The paper has a strong experimental dataset and a plausible closed-loop mechanism, but the absent O and W parameters and the mismatch between 'upper-bound' language and empirical coverage need to be addressed before I can recommend acceptance. The self-citation to prior INFOCOM work for the open-loop baseline is reasonable, but the dependence of the baseline on that reference should be made explicit."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"First, the thing you should know: this paper has a genuinely new mechanism — the closed-loop feedback where shared-channel delay activates reliability timers, which generate more traffic that delays discovery further — and the 1,350-run validation makes a credible case that this mechanism matters. The open-loop airtime baseline predicts only ~17% of high-load completion time; the closed-loop model captures the rise. That is a real result. The model-guided HEARTBEAT pacing, cutting completion time 25–40% even when total traffic rises, is a nice practical payoff.\n\nThe paper does several things well. The separation of initial vs repair SEDP DATA, the loopback reference validation (MAPE 0.82% for the failure-free model), and the check that the service-order policy barely affects results are all careful. The message-class decomposition, showing that repair traffic amplifies 54,000x wired-to-wireless in one case, makes the storm concrete.\n\nNow the soft spots, in proportion. The biggest is that the model is underspecified. Eq. (5) defines service demand a(c) = O_kappa + 8B(c)/R_kappa, and Section III-B defines source-queue capacity W_i, but neither receives a numeric value anywhere in the paper. So the event-driven model cannot be independently reproduced, and since these parameters directly control buffering delay — the very feedback the model is about — the predictions are not checkable as published. The paper also calls the model 'analytical' when it's implemented as a discrete-event simulation; that's a naming issue, but it sets expectations.\n\nSecond, the 'conservatively upper-bounds' claim is empirical, not proven. Table IV shows coverage of 90.7% (completion) and 90.4% (messages) at high load, with median M/O of about 2. That's a useful conservative range estimate, but it's not a bound in any formal sense. At low load coverage drops to near zero, which the authors acknowledge but the abstract's wording hides. A referee should push for either softened language or a rigorous argument.\n\nThird, the completion-time comparison uses application-level proxy-match timestamps against a model that assumes zero middleware-to-application delay. That acknowledged assumption might explain part of the upper-range tendency, but it's not quantified.\n\nNone of this kills the central idea. The paper is honest about its limitations — the repair-count ambiguity, the low-load weakness — and the qualitative predictions are robust to the service-order policy. I think the mechanism is right and the validation is adequate for a workshop-to-journal paper after revision. But the missing parameters are a reproducibility problem that the authors need to fix before the numbers are taken seriously.\n\nFor you: if you work on ROS 2, DDS, or wireless robot fleets, this is worth reading and citing after revision. It deserves a serious referee, not a desk reject. My recommendation: send it to peer review, but tell the authors to publish parameter values or code, and to soften 'upper-bounds' to 'upper-range estimates' unless they can prove it.","headline":"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.","tokens_in":14186,"tokens_out":3564,"would_cite":false,"duration_ms":30186,"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 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.","keywords":["discovery storm","ROS 2","DDS","RTPS","wireless robotic networks","closed-loop modeling","reliability repair","HEARTBEAT pacing"],"falsifier":"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.","tokens_in":13219,"feed_emoji":"📡","tokens_out":3977,"duration_ms":33381,"temperature":0.7,"pith_summary":"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.","feed_headline":"Closed-loop model captures ROS 2 discovery storms","feed_subtitle":"Delayed delivery feeds retransmissions; the model upper-bounds real Wi-Fi runs and paces heartbeats to cut completion by up to 40%.","key_machinery":"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.","core_discovery":"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","pith_inferences":["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."],"forward_implications":["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."],"fun_headline_variants":["Delayed Wi-Fi alone triggers ROS 2 discovery storms","First closed-loop model for ROS 2 discovery storms","Model reduces ROS 2 discovery time by up to 40%","How delay feedback amplifies ROS 2 discovery traffic"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Delayed Wi-Fi alone triggers ROS 2 discovery storms","First closed-loop model for ROS 2 discovery storms","Model reduces ROS 2 discovery time by up to 40%","How delay feedback amplifies ROS 2 discovery traffic"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000882,"raw_usage":{"total_tokens":3658,"prompt_tokens":762,"completion_tokens":2896,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":506,"completion_tokens_details":{"reasoning_tokens":2841}},"tokens_in":506,"tokens_out":2896,"duration_ms":17556,"temperature":1.0,"reasoning_tokens":2841,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-04T10:48:37.281307+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[],"review_version":1}