{"id":"8de4f25c-9d4d-4cd1-82ae-c0c12589b695","arxiv_id":"2504.19613","paper_version":2,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"Automatic channel identification for quantum testbeds can be done with serial or parallel on/off light signaling for detector-to-TDC wiring, and with pulse-based pub/sub or pattern-decoding schemes for switch-to-node links.","lead":"This paper designs protocols that let quantum network testbeds automatically figure out which detectors and switches are wired to which nodes, instead of manually tracing cables. It is a useful step toward making larger quantum networks practical to set up and operate.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Pub/sub matching can associate the wrong physical channel when two activation pulses share duration and overlap in time, and the pseudocode's filtering/verification steps are not specified tightly enough to rule this out.","rationale":"The reader's weakest_assumption concerns a deployment precondition (pre-registered NODE_IDs and known node count) which is explicit in the paper and fixes a termination condition, but does not threaten the protocol's correctness under the stated assumptions. A stronger concern is that the Section V matching phase is underspecified: Algorithm 1 and Algorithm 2 contain 'extract(filter(m))' and 'verify(candidate)' without definitions, and the text describes candidate-list construction and verification only informally. The serial node-to-TDC protocol (Section IV) is concrete and correct under its stated assumptions; the parallel pattern scheme is also well specified at the message level. The pattern-decoding protocol (Algorithm 3) is more concrete. The paper's evaluation figures (Fig. 6, Fig. 7) are not backed by released code or a formal analysis of the matching algorithm, so the claimed 'all channels discovered for every port' depends on an unverified matching sub-protocol. This warrants no change from the reader's CONDITIONAL verdict, but for a different reason than the reader's primary concern.","tokens_in":14322,"tokens_out":1339,"duration_ms":12858,"concrete_test":"Define extract, filter, and verify exactly, then run a discrete-event simulation over switch-BSA and Q-Fly topologies with N up to 32, using the paper's stated random activation/duration scheme, and record (a) probability that every channel is matched to the correct peer and (b) time to completion; repeat with the paper's stated doubling/backoff rules and verify that the final neighbor table is correct with probability 1 over repeated trials. If ambiguity remains, amend the matching rule to require a confirmation round-trip between the two candidate endpoints before marking a channel CONFIGURED.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The central claim in Section V is that after the matching phase, nodes 'verify the connectivity of the corresponding channel' and eventually identify all active channels. The load-bearing condition is that the candidate list and verification step uniquely identify the true peer. The protocol's conflict handling only reacts to exact collisions in (activation time, duration) or (detection time, duration); Fig. 7 quantifies channels 'identified per step' as if matching succeeds. But the published pseudocode never defines 'extract(filter(m))' or 'verify(candidate)', and the described candidate-list construction does not disambiguate overlapping pulses of equal duration with different start times, or pulse trains that produce coincidental duration matches through a switch. Algorithm 2 halts all activation on conflict and resumes after a timeout without a defined convergence bound, so it is not established that the protocol terminates with the correct neighbor table under the stated randomized retry rule. The strongest_claim's 'until all channels are discovered for every port' therefore rests on an unproven matching/verification sub-protocol, not on the clearly specified message-level flow.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper addresses the practical problem of manually configured optical quantum network testbeds. It proposes two sets of automatic configuration protocols. The first set (Section IV) associates single-photon detectors with their network nodes via a TDC service, using either serial identification, where one node turns on at a time, or parallel identification, where nodes transmit distinct on/off light patterns. The second set (Section V) addresses node-to-node channel discovery: a single-pulse pub/sub protocol that correlates activation and detection events through a classical message bus, and a pattern-decoding protocol that uses unique optical patterns resolved through a lookup table. The paper presents pseudocode (Algorithms 1-3), message semantics, assumptions, and a qualitative and quantitative evaluation (Figures 6-7, Table II). It is framed as a roadmap for near-term testbed implementation rather than an experimental demonstration.","tokens_in":14510,"tokens_out":7236,"duration_ms":76968,"significance":"If the protocols operate as claimed, they would fill a genuine practical gap: eliminating manual fiber tracing and enabling automated neighbor discovery in near-term quantum testbeds. The paper is honest about its assumptions and does not fit data or tune free parameters to make the protocols look good; the error rates and timing parameters in the evaluation are scenario inputs. The main significance is conditional, however, on the correctness of the channel-matching and verification steps in the pub/sub protocol, which are currently underspecified. The pattern-decoding approach is more concrete, and the protocol suite as a whole is a plausible starting point for implementation, but it is not yet a complete, machine-checkable specification.","major_comments":[{"comment":"The correctness of the channel-discovery claim depends entirely on the operations extract(filter(m)) and verify(candidate), but these operations are never defined. The text says nodes 'filter out unrelated events' and 'verify connectivity' after constructing a candidate list, but no concrete filtering rule or verification handshake is given. In particular, when two activation pulses have the same duration and overlapping time windows, or when a switch produces a coincidental duration match, the described candidate-list construction gives no criterion that guarantees the true peer remains in the list and no false peer is selected. Please define these subroutines and prove that the matching phase identifies the unique peer under the stated assumptions.","section":"Section V.A, Algorithms 1 and 2"},{"comment":"The port activation process has no termination or correctness proof. Activation times and durations are chosen randomly, and the conflict reactions described in the text (increasing D_i, doubling the parameters, setting activation to a maximum, and resuming after a timeout) are not reflected in the pseudocode. It is not shown that the while loop over unconfigured output ports terminates with all ports correctly configured, nor that the protocol cannot label a channel incorrectly when it does terminate. Since the protocol is intended to replace manual configuration, the paper should either prove termination with probability one, provide a deterministic fallback, or state an explicit stopping condition that can be evaluated by the nodes.","section":"Section V.A, Algorithm 2"},{"comment":"The conflict-resolution rules given in the prose are not present in Algorithm 2. The text states that a node increases its activation and duration parameters when it sees two published messages with the same duration, doubles them when two published messages have the same detection time and duration, and halts activation during a verification conflict by setting its activation time to the maximum value; Algorithm 2 contains none of these actions. This mismatch makes it impossible to determine whether the pseudocode is a complete specification of the proposed protocol. Please align the algorithm with the described conflict handling, or explicitly state that the text describes an intended enhancement not captured by the current algorithm.","section":"Section V.A.2, Message Semantics"}],"minor_comments":[{"comment":"The plot lacks axis labels. The x-axis appears to be the number of detectors and the y-axis the runtime in units of t_act, but this should be stated explicitly in the caption, along with a description of how the bit-level error rates are converted to identification failure probabilities.","section":"Section VI, Fig. 6"},{"comment":"The caption does not describe the simulation or estimation method for the 'average identified channels per step,' and no error bars or number of trials are provided. Please add this information so the reader can assess the variance of the reported averages.","section":"Section VI, Fig. 7"},{"comment":"The description of the header '0111111110' followed by an 8-bit payload needs clarification on how a receiver identifies the start of the header when the pattern is repeated, and how the reserved value 255 is encoded. A bit-stuffing or explicit start-delimiter rule would remove ambiguity.","section":"Section IV.B"},{"comment":"The protocol assumes the TDC service knows the number of attached nodes and their pre-registered NODE_IDs. Please state how this registry is populated and what happens when the observed number of light-carrying channels is inconsistent with the expected node count.","section":"Sections IV.A and IV.E"},{"comment":"References [10] and [20] are duplicate citations of the same Krutyanskiy et al. paper; please consolidate.","section":"References"},{"comment":"Algorithm 3 uses informal constructs such as 'Reserve a light source' and does not specify timeout or retry behavior for the confirmation handshake. Please specify the exact message sequence and failure handling for the pattern-decoding approach.","section":"Section V.B, Algorithm 3"}],"recommendation":"major_revision","confidential_remarks":"For the editor: I found no circularity or hidden parameter fitting in this manuscript. The main blocker is the underspecified matching and verification logic in the pub/sub protocol, together with the absence of a termination argument. If the authors provide precise subroutines and a correctness proof, the paper could become acceptable; the pattern-decoding section and the overall framing are promising."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Two things to know. First, the paper attacks a real problem—manual cable tracing in quantum testbeds—and the node-to-TDC serial/parallel protocol is simple, clearly specified at the message level, and likely implementable as described. Second, the node-to-switch pub/sub protocol is the weak link: the matching and verification logic is left as undefined extract(filter(m)) and verify(candidate) calls, and the paper never shows that overlapping pulses or coincidental duration matches resolve to the correct peer. The stress-test concern lands.\n\nWhat's actually new: applying on/off light signaling and classical discovery ideas (ARP/LLDP analogs) to the specific wiring problems of shared TDCs and optical switches. The paper is careful about assumptions (one-way light, trusted nodes, pre-registered IDs) and explicitly labels itself a roadmap rather than a demonstration. Credit where due: the message definitions for the TDC protocol are precise, the runtime formula for parallel identification is sensible, and the pattern-decoding scheme is a reasonable adaptation of MAC-like addressing.\n\nSoft spots, in proportion. The main one is the pub/sub matching. Algorithms 1 and 2 are pseudocode with undefined helper functions, and the conflict-resolution rule (double activation/duration on coincidence, halt on verification conflict) has no correctness or termination argument. Fig. 7 plots identified channels per step as if the matching always succeeds, but the paper gives no simulation details or code, so those numbers aren't checkable. Second, the TDC protocol's termination depends on the service already knowing how many nodes are attached and having NODE_IDs pre-registered; that's acknowledged, but it means the protocol doesn't bootstrap from zero. Third, the evaluation is entirely analytic and qualitative; no testbed run, no released data. These are fixable, not fatal.\n\nWho it's for: people building or operating quantum network testbeds, and protocol designers looking for examples of classical-control-plane tricks applied to quantum hardware. A careful reader gets a clear enumeration of assumptions and two concrete protocol families to try.\n\nRecommendation: send it to peer review. The problem is real, the TDC half is solid, and the underspecified pub/sub matching is exactly what referees should push on. With a tightened algorithm and at least one reproducible simulation, it would be a useful citable contribution.","headline":"A practical, honest protocol roadmap for automating quantum testbed wiring, with the TDC half solid and the switch-discovery half underspecified where it matters.","tokens_in":15042,"tokens_out":3153,"would_cite":false,"duration_ms":31486,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":["03.67.Hk","42.79.Sz"],"model":"deepseek-v4-flash","headline":"This paper argues that automatic configuration protocols can identify physical channels in optical quantum networks using only light on/off control and classical messages.","keywords":["quantum network configuration","channel discovery","time-to-digital converter","SNSPD","optical switch","topology discovery","publish-subscribe protocol","optical address resolution"],"falsifier":"Run either node-to-TDC algorithm on a real testbed with known wiring: record which physical fiber connects each detector to which TDC port, start from the unconfigured state, and compare the resulting NODE_ID-to-CHAN_ID map against the recorded wiring. The central claim falls if the protocol reports CONFIGURED with a mismatched map, or if it never terminates when one node is dark.","tokens_in":14122,"feed_emoji":"⚛️","tokens_out":6356,"duration_ms":60399,"temperature":0.7,"pith_summary":"Quantum networking testbeds are still wired and labeled by hand: single-photon detectors are bundled into shared cryostats and time-to-digital converters, and optical switches pass light without knowing what is attached to them. This paper proposes two families of protocols that automate this layer of configuration. The first identifies which TDC input channel belongs to which measurement or Bell-state analyzer node, using serial or parallel light-on identification coordinated by a classical TDC service. The second identifies which nodes sit at the other end of each optical switch port, either by pulsing light with randomized timing and matching events over a publish-subscribe bus, or by encoding a unique optical pattern that sinks decode and resolve through a pattern lookup table. If the protocols work, a testbed can move from an unconfigured wiring state to a fully labeled neighbor table without manual tracing, which is a prerequisite for topology discovery, link monitoring, resource naming, and routing.","feed_headline":"Quantum testbeds can label their own channels automatically","feed_subtitle":"On/off light pulses plus classical messages identify which detector and switch ports connect to which nodes.","key_machinery":"The load-bearing mechanism is endpoint light monitoring plus classical coordination: every channel is identified by correlating the controlled appearance of light at a source output port with its detection at a sink input port, without attributing any quantum state to the light. For node-to-TDC configuration, the machinery is the TDC service API with ID_REQ, ID_START, ID_RETRY, ID_COMPLETE, ID_LOOKUP, and ID_STATUS messages, together with a state machine that maps unconfigured channels to nodes. For node-to-node channels, the paper offers two mechanisms: a single on-off pulse coding scheme in which nodes publish activation times and durations to a \"channel/active\" topic, listeners publish detections to \"channel/detect\", and matching events with conflict-driven backoff produce candidate lists; and a pattern-encoding scheme in which each output port is assigned an optical PATTERN analogous to a MAC address, announced into a lookup table, and decoded by sinks to resolve NODE_ID and PORT_ID, analogous to reverse address resolution.","core_discovery":"The paper's central claim is that the correspondence between physical channels and network nodes in an optical quantum testbed does not have to be established by hand. A TDC service that knows the number of attached nodes and their pre-registered NODE_IDs can learn which of its channels serves which detector by letting each node turn light on, either one at a time or according to a unique 8-bit on/off pattern, and watching which unconfigured channel lights up. For inter-node channels, the paper claims that a network of sources, switches, and detectors can discover all active channels incrementally: sources announce and emit pulses with randomized start times and durations, sinks report what they detect, and nodes correlate announcements with detections to build candidate lists and verify links; alternatively, a source can encode a unique pattern in its light and a sink can decode it and look up the source's NODE_ID in an optical address table. Once source-side ports are resolved, light with known provenance can be forwarded through switches to expose the next layer of channels, until every port's neighbor is recorded. The protocols require no wavelength-specific hardware and only presence-or-absence light monitoring, not interference or tomography.","pith_inferences":["A natural next step, not developed in the paper, is to remove the pre-registration requirement and let the TDC assign NODE_IDs dynamically, turning the discovery protocol into a true plug-and-play process.","The same presence/absence monitoring could double as a continuous link-integrity check after configuration: unexpected light on a dark channel, or absence on a lit one, would flag a broken or swapped fiber.","Because the mechanism does not rely on quantum properties, it likely transfers to classical all-optical networks with passive switches, where the pub/sub matching protocol could replace manual patch-panel documentation.","The conflict-backoff rules in the pub/sub scheme suggest a testable prediction: discovery time depends on the probability that two sources choose overlapping activation windows, so the protocol's average-case behavior could be modeled as a classical contention problem."],"forward_implications":["A testbed can transition from raw, unlabeled fiber to a source-of-truth neighbor table without any manual tracing or physical inspection of ports.","The parallel TDC algorithm's runtime scales roughly logarithmically in detector count, so shared-detector pools with hundreds of channels remain configurable quickly.","The pattern-encoding scheme gives optical quantum networks an ARP-like primitive: a physical optical pattern acts as a hardware address, and a lookup table resolves it to a node identity.","With channel maps in place, higher-layer services such as quantum topology discovery, link quality monitoring, and routing can treat physical connectivity as known input rather than a manual assumption.","The protocols are wavelength-agnostic and work for free-space or fiber channels as long as sources can be turned on and off and endpoints can sense light, which broadens their applicability across testbed hardware."],"supporting_citations":[{"why":"Defines the MEAS, BSA, EPPS, and OSW node types whose ports the protocols must associate.","marker":"[14]"},{"why":"Demonstrates a link-layer style management protocol for quantum links, the layer this configuration work sits beneath.","marker":"[21]"},{"why":"Supplies the Q-Fly with DPHD testbed topology used in the switch-discovery evaluation.","marker":"[6]"},{"why":"Supplies the switch-BSA pool topology used to estimate channels identified per step.","marker":"[36]"},{"why":"Documents switch hardware with built-in light sensing, which supports the endpoint-monitoring assumption.","marker":"[31]"}],"fun_headline_variants":["Quantum testbeds self-discover their connections with light patterns","On/off pulses automate channel mapping in quantum networks","Protocols let quantum nodes auto-identify their links","Quantum networks use light blinks to auto-configure"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The protocols assume that at the start some service already knows how many nodes are attached and holds a pre-registered identifier for each one; if that registry is missing, the process has no way to know when it is done or to distinguish an absent node from a failed identification.","fun_headline_variants_meta":{"raw":{"variants":["Quantum testbeds self-discover their connections with light patterns","On/off pulses automate channel mapping in quantum networks","Protocols let quantum nodes auto-identify their links","Quantum networks use light blinks to auto-configure"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000276,"raw_usage":{"total_tokens":1643,"prompt_tokens":938,"completion_tokens":705,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":554,"completion_tokens_details":{"reasoning_tokens":651}},"tokens_in":554,"tokens_out":705,"duration_ms":7636,"temperature":1.0,"reasoning_tokens":651,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-16T05:47:33.559594+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run either node-to-TDC algorithm on a real testbed with known wiring: record which physical fiber connects each detector to which TDC port, start from the unconfigured state, and compare the resulting NODE_ID-to-CHAN_ID map against the recorded wiring. The central claim falls if the protocol reports CONFIGURED with a mismatched map, or if it never terminates when one node is dark.","supporting_citations":[{"cited_title":"All SDN optical switches,","cited_arxiv_id":null,"evidence_quote":"Documents switch hardware with built-in light sensing, which supports the endpoint-monitoring assumption."}],"review_version":1}