{"id":"17d60212-3732-441d-bf98-fae6fe85b7b0","arxiv_id":"2505.17337","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"A proposed extension to libp2p GossipSub that uses PREAMBLE and IMRECEIVING notifications to reduce duplicate large-message transmissions, cutting reported bandwidth by up to 61% and dissemination latency by up to 35% in shadow simulations.","lead":"This paper proposes two new control messages, PREAMBLE and IMRECEIVING, to help the libp2p GossipSub protocol handle large messages with fewer duplicates and lower latency. GossipSub carries much of Ethereum and IPFS traffic, so cutting large-message bandwidth by up to 61% in simulations could reduce network costs and speed up blockchain data propagation.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Gains hinge on PREAMBLE/IMRECEIVING being processed and delivered before the large-message transfer completes, a timing assumption the paper acknowledges but never quantifies; without control-message prioritization or a measured Δ/τ_D bound, the 61%/35% reductions are not established.","rationale":"The reader's weakest-assumption is the same one that seems most load-bearing: IMRECEIVING's value is entirely in early cancellation, so the timing of control messages is not a secondary detail. I do not see an internal inconsistency in the protocol logic; the proposals are plausible and the evaluation is substantial. But the paper's own conclusion flags the missing priority mechanism, and the simulation section does not tell us whether the control messages were effectively privileged (e.g., sent before data on fresh yamux streams) or competed with data. Without a measured Δ/τ_D, the headline reductions are not robust to real transport queuing. This supports the reader's CONDITIONAL verdict rather than changing it.","tokens_in":11225,"tokens_out":11725,"duration_ms":141522,"concrete_test":"Reproduce Scenario 1 (400KB–1.4MB) and Scenario 2 with the nim-libp2p/yamux stack used in the paper, adding instrumentation to record for each PREAMBLE/IMRECEIVING the time from enqueue to upper-layer processing at the receiver. Compute the empirical Δ/τ_D. If the median ratio is below 0.1 and the current results reproduce, the concern is resolved; if the ratio is order 1 or the 61%/35% figures shrink when queued control traffic is interleaved with large-message data, the reported gains require explicit transport-level prioritization and should be re-reported as conditional on it.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The central mechanism in Section III-B is a race: IMRECEIVING must reach a mesh member before that member's duplicate transfer of the large message is committed. The paper models this with Δ for PREAMBLE processing and claims Δ ≪ τ_D. If a PREAMBLE or IMRECEIVING control message is queued behind large-message data on a congested yamux connection, Δ can approach or exceed τ_D, and the cancellation window closes. Section V concedes that 'the lack of prioritization mechanisms at the transport layer can delay the transmission of these messages,' and the evaluation deliberately runs without transport prioritization. The paper never reports the distribution of Δ/τ_D, nor any sensitivity analysis over this ratio. Since the headline 61% bandwidth and 35% latency reductions are produced by this duplicate-cancellation race, the quantitative claims remain conditional on an unverified queuing assumption.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper addresses large-message performance in libp2p GossipSub. It identifies duplicate transmissions and IWANT-related overhead caused by long transfer times, and proposes: a PREAMBLE control message to identify incoming large messages, an IMRECEIVING notification sent at reception start, IWANT request reductions, and reduced forwarding to K mesh members with immediate IHAVE announcements. Using the shadow simulator with nim-libp2p, it compares GossipSub v1.2 against IMRECEIVING, IWANT improvements, the combined GossipSub v1.4, and reduced sending. It reports up to 61% bandwidth reduction and up to 35% latency reduction, with duplicate and bandwidth results across three scenarios.","tokens_in":11419,"tokens_out":5584,"duration_ms":70964,"significance":"The proposed mechanisms are simple, fit within GossipSub's existing message flow, and address a real operational problem; the performance gains are large and, if confirmed, would be practically valuable. The paper's strengths include a clear parameterized description of the protocol changes, a public PoC implementation link, and multi-scenario simulation covering varying message sizes, publisher counts, and network sizes. However, the quantitative claims rest on timing assumptions and point estimates that are not validated with error bars, confidence intervals, or sensitivity analysis; the manuscript itself acknowledges the transport-prioritization caveat. The contribution is promising, but the evidence presented is not yet sufficient for the stated headline claims.","major_comments":[{"comment":"The duplicate-cancellation mechanism requires PREAMBLE processing time Δ to satisfy Δ ≪ τD, but the paper never reports a measured distribution of Δ/τD or a sensitivity analysis over this ratio. Since the evaluation runs without transport-layer prioritization, and Section V concedes that the lack of prioritization mechanisms can delay the transmission of control messages, a PREAMBLE or IMRECEIVING message queued behind large-message data on a congested yamux connection could close the cancellation window before the duplicate transfer is prevented. Please add direct measurements of control-message delivery delay relative to τD and a sensitivity analysis with artificially delayed or prioritized control traffic; without this, the headline 61% bandwidth and 35% latency reductions remain conditional on an unverified queuing assumption.","section":"Section III-B, Section V"},{"comment":"All performance results are reported as single point estimates with no error bars, confidence intervals, run counts, or random seeds. The 'up to' maxima are not supported by a distribution, so the reader cannot assess the variability or statistical reliability of the claimed improvements. Please report multiple independent simulation runs with specified seeds, show variability (e.g., boxplots or confidence intervals), and state the number of replications in Table I or the text.","section":"Section IV, Figs. 3-4"},{"comment":"The paper proposes PREAMBLE as a new control message transmitted immediately before every large message, but the evaluation 'uses IDONTWANT messages as PREAMBLEs' with modified semantics. The measured gains therefore test a modified IDONTWANT, not the dedicated PREAMBLE with the property of being sent immediately before the payload. The timing of IDONTWANT delivery relative to the data transfer may differ from a true PREAMBLE, so the mechanism's claimed benefit is not directly validated. Please evaluate the protocol as specified, or explicitly state that the implementation uses a proxy and analyze how the proxy affects the measured gains.","section":"Section III-A, Section IV"},{"comment":"The abstract and Section III claim that the proposed modifications preserve GossipSub resilience, but no resilience evaluation is presented. All experiments use a trusted environment, as Section V states, and the reduced-forwarding parameter K = Dlow − 1 is hand-picked on the basis of 'extensive simulations' without sensitivity analysis or adversarial/partition scenarios. The qualitative argument that immediate IHAVE announcements preserve redundancy is plausible but not empirically verified. Please add tests with non-conforming peers, churn, or network partitions, or at minimum a sensitivity analysis over K, and state explicitly what resilience properties are and are not covered by the evaluation.","section":"Section III-D, Section V, Table II"}],"minor_comments":[{"comment":"There is a typo: 'GossipSup v1.2' should read 'GossipSub v1.2'.","section":"Section IV, first paragraph"},{"comment":"Reference [24] contains garbled text: 'Omtermet Emgomeeromg Task Force' should be 'Internet Engineering Task Force'.","section":"Reference [24]"},{"comment":"The paper defines large messages as exceeding 50 KB, but Scenario 2 in Table I uses message size 50 KB exactly; please clarify whether 50 KB is considered large and why the proposed changes, which activate only above a threshold, are evaluated at this boundary size.","section":"Section II, Table I"},{"comment":"The notation 'Reduced Send (K)' is listed in Table II as Dlow − 1, but the meaning of K and its role in forwarding are not explained until Section III-D; please add a forward reference from Table II to that discussion.","section":"Section III-D, Table II"},{"comment":"The spelling 'IWANT' versus 'IW ANT' is inconsistent throughout the text and figures; please choose one form and use it consistently.","section":"Throughout"},{"comment":"The figure labels and legends are shown at a very small size and are difficult to read in the PDF; please enlarge fonts or provide vector versions, and ensure protocol versions are clearly identified in every legend.","section":"Figures 2-4"}],"recommendation":"major_revision","confidential_remarks":"For the editor: this is an engineering/standards-oriented paper rather than a formal theory contribution. The main risk is that the unquantified control-message queuing assumption and the absence of statistical replication cause the headline numbers to be over-interpreted. A major revision with additional measurements and sensitivity analysis would make the claims substantially more credible."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague, this paper is worth your time if you have any stake in libp2p or large-message pubsub. The core idea is simple and sound: before sending a large message, announce it with a PREAMBLE so receivers can immediately send IMRECEIVING notices to their mesh members to cancel duplicates. That directly attacks the well-known problem that IDONTWANT arrives too late because it's only sent after full download. The IMRECEIVING construct is new, as is using PREAMBLE to suppress IWANT requests. The authors also propose reduced forwarding with immediate IHAVEs, which is more derivative but reasonable.\n\nCredit where due: they implemented this in nim-libp2p, have a PoC branch, and a spec PR under review. The evaluation in shadow covers three dimensions (message size, publisher count, network size) and reports bandwidth, latency, and duplicate counts. The reported gains—up to 45% bandwidth for 400KB, 61% above 1MB, and 35% latency at high publisher counts—are consistent with the mechanism.\n\nThe soft spots are real but not fatal. First, the evaluation is statistically bare: point estimates with no error bars, run counts, or seeds. For a simulation paper this is a serious omission and undermines the headline numbers. Second, the resilience claim is asserted, not tested; the paper admits a trusted environment. Third, the reduced-forwarding degree K is hand-picked in the same simulations that report its benefit, so that part is mildly circular.\n\nOn the stress-test concern: the gains do rely on PREAMBLE/IMRECEIVING arriving before duplicate transfers commit. The paper models a processing delay Δ and asserts Δ ≪ τ_D, but never measures the ratio. Section V honestly notes that transport-layer queues could delay these control messages, and the simulations run without prioritization. My read is that the reported numbers already reflect that lack of prioritization, so the mechanism survived in the tested scenarios; but without a sensitivity sweep over Δ/τ_D, we don't know how close to the edge the benefit sits. That's an empirical hole, not a conceptual one.\n\nWho is the reader? Protocol designers and anyone deploying GossipSub for large payloads. It deserves a serious referee, but the referee should demand error bars and a sensitivity analysis before the numbers are trusted. I'd send it to review.","headline":"Genuinely new protocol extension for large-message GossipSub; the simulation evidence is promising but needs error bars and a sensitivity analysis before the headline numbers are trusted.","tokens_in":11978,"tokens_out":2943,"would_cite":true,"duration_ms":19661,"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":"PREAMBLE and IMRECEIVING cut GossipSub bandwidth by up to 61%.","keywords":["GossipSub","libp2p","publish-subscribe","large message dissemination","duplicate suppression","bandwidth utilization","IMRECEIVING","PREAMBLE"],"falsifier":"Deliberately add a controllable queueing delay to PREAMBLE and IMRECEIVING at the transport layer while keeping payload conditions fixed, then measure bandwidth and dissemination time for 1MB messages. The stated mechanism predicts that the gains shrink as that control-message delay approaches the full message transfer time; if the bandwidth reduction remains at 61% even when those messages wait behind other traffic, the paper's explanation would need revision.","tokens_in":10984,"feed_emoji":"📡","tokens_out":7487,"duration_ms":51564,"temperature":0.7,"pith_summary":"The paper identifies a timing blind spot in GossipSub: peers only learn that a message is in flight after the full payload arrives, so large-message transfers invite duplicate sends and redundant IWANT requests. It proposes two small protocol additions, a PREAMBLE sent before each large message and an IMRECEIVING message that tells mesh members an incoming message is already being received, so duplicate suppression can happen at the start of a transfer instead of at the end. The reported evaluations show up to 61% lower bandwidth utilization and up to 35% lower network-wide dissemination time under different traffic conditions. The changes matter because large messages, from hundreds of kilobytes to megabytes, are common in decentralized applications, and the existing IDONTWANT mechanism acts too late to stop redundant transfers.","feed_headline":"Two new messages cut GossipSub bandwidth by up to 61%","feed_subtitle":"Early warnings about incoming large messages slash duplicate transfers and shrink dissemination time.","key_machinery":"The engine of the proposal is the PREAMBLE: a short control message bearing a message ID and a length, sent immediately before a large data message and processed as soon as it arrives. Because the receiving peer learns the message's identity at the start of the transfer rather than at the end of the download, it can emit IMRECEIVING notifications to its mesh members almost immediately, cancelling duplicate transmissions that would otherwise begin during the long transfer. The same early knowledge suppresses unnecessary IWANT requests, since a peer no longer asks for a message it can see is already arriving.","core_discovery":"GossipSub's forwarding logic treats all messages as if they arrive instantly, but for large messages the transfer time is long enough that peers start receiving the same message from several senders simultaneously and issue many duplicate IWANT requests. The paper's central discovery is that the fix is temporal: tell receivers what is coming before it arrives. PREAMBLE is a tiny control message carrying the message ID and length, sent immediately before a large message; the receiver then instantly tells its mesh members via IMRECEIVING that it is already receiving the message and they should not resend it. This shifts duplicate suppression from the end of a transfer, where IDONTWANT acts, to the start, while the PREAMBLE also lets peers stop firing IWANT requests for messages already in flight. In simulation, the combined GossipSub v1.4 protocol reduces bandwidth utilization by up to 45% for 400KB messages, up to 61% for messages larger than 1MB, and dissemination latency by up to 35% in high-publisher scenarios.","pith_inferences":["We infer that the protocol's real-world impact hinges on control-plane timeliness: the measured gains should become more robust if PREAMBLE and IMRECEIVING are given explicit priority over payload traffic at the transport layer.","The announce-before-transfer pattern could be applied to other pubsub or gossip protocols where payload transfer time is non-negligible, not just libp2p GossipSub.","Because the evaluation uses IDONTWANT as the PREAMBLE, we infer that a dedicated PREAMBLE type could decouple the sender's commitment semantics from IDONTWANT and make the design easier to reason about.","Since the assessments assume a trusted environment, an immediate next test is whether an attacker sending PREAMBLEs without delivering the promised payload can disrupt propagation despite the proposed peer-scoring penalty."],"forward_implications":["For messages above 1MB, the combined protocol reduces bandwidth utilization by up to 61% and brings average duplicates per peer down to about two.","For 400KB messages, the combined protocol reduces bandwidth by up to 45%, and for large messages in the evaluated scenarios it also reduces dissemination latency by up to 23%.","In high-publisher settings, the combined protocol cuts network-wide message dissemination latency by up to 35% by lowering the workload on peers along optimal forwarding paths.","The reduced-forwarding variant, which sends to a subset of mesh members and issues immediate IHAVE announcements to the rest, saves about 15-20% bandwidth but can increase latency, so the paper positions it as weaker than the full PREAMBLE plus IMRECEIVING design.","The proposed changes take effect only above a size threshold, so small-message behavior remains unchanged and normal GossipSub operation is preserved."],"supporting_citations":[{"why":"Defines IDONTWANT, the existing duplicate-suppression mechanism that PREAMBLE and IMRECEIVING extend and that the evaluation uses as the PREAMBLE.","marker":"[18]"},{"why":"Defines the GossipSub baseline protocol with full-message mesh, gossip mesh, IHAVE, and IWANT mechanics that the paper modifies.","marker":"[14]"},{"why":"Introduces peer scoring and makes IWANT replies optional in GossipSub v1.1, creating the redundant IWANT-request problem that the IWANT improvements target.","marker":"[16]"},{"why":"Earlier work by the authors that quantifies store-and-forward delays and introduces fragmentation and staggering for large messages, providing the analytical starting point.","marker":"[19]"},{"why":"Supplies the discrete-event simulation environment used for all performance measurements.","marker":"[28]"},{"why":"The protocol implementation that was extended with PREAMBLE support to run the evaluations.","marker":"[25]"},{"why":"Supplies the upper-bound analysis of average duplicates that frames the duplicate measurements.","marker":"[29]"}],"fun_headline_variants":["GossipSub's early-warning messages slash bandwidth up to 61%","PREAMBLE and IMRECEIVING: cut GossipSub bandwidth by 61%","Early warning in GossipSub cuts 61% bandwidth, 35% latency","GossipSub v1.4: temporal fix slashes large-message bandwidth 61%","How to stop GossipSub duplicate floods: tell peers what's coming"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that the new control messages are processed instantly on arrival, so a peer learns about an incoming large message almost immediately instead of only after the whole payload has been downloaded.","fun_headline_variants_meta":{"raw":{"variants":["GossipSub's early-warning messages slash bandwidth up to 61%","PREAMBLE and IMRECEIVING: cut GossipSub bandwidth by 61%","Early warning in GossipSub cuts 61% bandwidth, 35% latency","GossipSub v1.4: temporal fix slashes large-message bandwidth 61%","How to stop GossipSub duplicate floods: tell peers what's coming"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000772,"raw_usage":{"total_tokens":3365,"prompt_tokens":836,"completion_tokens":2529,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":452,"completion_tokens_details":{"reasoning_tokens":2418}},"tokens_in":452,"tokens_out":2529,"duration_ms":14639,"temperature":1.0,"reasoning_tokens":2418,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T14:48:07.233926+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Deliberately add a controllable queueing delay to PREAMBLE and IMRECEIVING at the transport layer while keeping payload conditions fixed, then measure bandwidth and dissemination time for 1MB messages. The stated mechanism predicts that the gains shrink as that control-message delay approaches the full message transfer time; if the bandwidth reduction remains at 61% even when those messages wait behind other traffic, the paper's explanation would need revision.","supporting_citations":[{"cited_title":"gossipsub v1.2 minimal extension to the gossipsub v1.1 protocol,","cited_arxiv_id":null,"evidence_quote":"Defines IDONTWANT, the existing duplicate-suppression mechanism that PREAMBLE and IMRECEIVING extend and that the evaluation uses as the PREAMBLE."},{"cited_title":"gossipsub v1.1: Security extensions to improve on attack re- silience and bootstrapping,","cited_arxiv_id":null,"evidence_quote":"Introduces peer scoring and makes IWANT replies optional in GossipSub v1.1, creating the redundant IWANT-request problem that the IWANT improvements target."},{"cited_title":"Staggering and Fragmentation for Improved Large Message Handling in libp2p GossipSub","cited_arxiv_id":"2504.10365","evidence_quote":"Earlier work by the authors that quantifies store-and-forward delays and introduces fragmentation and staggering for large messages, providing the analytical starting point."},{"cited_title":"The shadow simulator,","cited_arxiv_id":null,"evidence_quote":"Supplies the discrete-event simulation environment used for all performance measurements."},{"cited_title":"The nim implementation of the libp2p networking stack,","cited_arxiv_id":null,"evidence_quote":"The protocol implementation that was extended with PREAMBLE support to run the evaluations."},{"cited_title":"The streamr network: Performance and scala- bility,","cited_arxiv_id":null,"evidence_quote":"Supplies the upper-bound analysis of average duplicates that frames the duplicate measurements."}],"review_version":1}