{"id":"602cad88-d9f7-4f4b-b6c4-9691250b9e21","arxiv_id":"2607.29306","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":10,"one_line_summary":"A fully in-network AE-GraphSAGE pipeline on Tofino switches detects and locates optical soft failures with F1 above 98% while cutting control-plane bandwidth by two to three orders of magnitude.","lead":"RIGEL puts a graph neural network for diagnosing optical-network faults directly inside programmable switch hardware, replacing slow centralized analysis. If it works as reported, operators could detect and locate soft failures in microseconds-to-milliseconds while cutting control-plane traffic by orders of magnitude.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Data-plane description appears to implement only 1-hop neighbor aggregation, not the 2-layer GraphSAGE claimed in §4; feature packets carry only AE embeddings, never intermediate h_feat, so the system may not be a distributed 2-hop GNN.","rationale":"The reader's weakest assumption (lossy PCA→UQ→VQ preprocessing) is a valid external-validity concern, but the more load-bearing issue is internal: the described data-plane packet exchange appears inconsistent with the claimed 2-hop GraphSAGE. The full-precision model in §4 uses two SAGEConv layers; layer 2 requires each node to aggregate the layer-1 embeddings of its neighbors. In the data plane, feature packets carry only AE outputs (n_feat), and Pipe-2's AGG_table receives h_feat only from local Pipe-1, not from neighbor switches. Consequently, the second SAGEConv layer cannot access neighbors' updated embeddings. This is not merely a missing detail: it directly affects the central novelty—distributed multi-hop network awareness. If the implementation is actually 1-hop, the system is less novel than claimed but still a plausible laboratory demonstration. The reader's CONDITIONAL verdict remains appropriate, but the condition should include verifying the architectural equivalence, not only releasing artifacts and correcting overclaims. I also note the numerical inconsistency in Table 6 ('~400,000 testing samples' vs. ~234,000 total samples) and the 557x vs. 'three orders of magnitude' overclaim, which reinforce the need for correction but are secondary to the architecture concern.","tokens_in":22955,"tokens_out":10395,"duration_ms":107805,"concrete_test":"Inspect the compiled P4 artifacts (or source) and verify whether Pipe-2's AGG_table can read a neighbor register containing h_feat—i.e., whether any packet or register carries a neighbor's post-aggregation state. Alternatively, run a controlled testbed experiment with a 3-node lightpath A→B→C: induce an anomaly at A that is only visible at C after two hops; check whether C's switch ever reports root=A. If C never reports, or if the deployed model's outputs on two-hop-dependent cases systematically diverge from the full-precision 2-layer GraphSAGE, the data plane implements only 1-hop aggregation.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim—'stateful distributed in-network inference through collaborative GNNs on Tofino switches'—rests on the on-switch model being the same 2-layer GraphSAGE as the full-precision baseline. But the data-plane description does not support 2-hop aggregation. In §3.2 and §6, feature packets exchanged between switches carry the AE output (n_feat), not the intermediate aggregated representation (h_feat). Pipe-1's AGG_table combines local s_feat and neighbor n_feat into h_feat; Pipe-1 then sends h_feat to Pipe-2, where AGG_table yields cls/root. There is no mechanism for a switch to receive its neighbors' h_feat, which is required for GraphSAGE layer 2 (aggregating neighbors' layer-1 embeddings). Thus the implemented pipeline appears to perform one round of neighbor aggregation followed by a classifier, i.e., a 1-hop graph model, not the 2-hop GraphSAGE described in §4 and Figure 5. This matters because the claimed network-awareness and the diagnostic advantage over single-point methods rely on propagation signatures over multiple hops. If the deployed model is only 1-hop, the 'first distributed on-switch GNN' claim is materially overstated, even if the 1-hop approximation still achieves high accuracy on the testbed. The paper provides no equivalence proof, no P4 code inspection, and no experiment that separates 1-hop from 2-hop behavior.","agreement_with_reader":"disagree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes RIGEL, a system that performs optical anomaly diagnosis entirely in the data plane of P4/Tofino switches, using distributed GraphSAGE-style inference. The design preprocesses high-dimensional OPM spectra on the OPM CPU with a PCA→UQ→VQ pipeline, encodes each sample as a VQ codebook index, and then performs AE-based feature extraction and GraphSAGE-based neighbor aggregation inside the switch via match-action tables. The authors claim that this is the first stateful distributed in-network GNN diagnosis system, report above 99% classification/location accuracy and above 98% F1-scores on a packet-over-optical testbed, and report a reduction in control-plane data exchange overhead by more than three orders of magnitude relative to centralized GNN baselines.","tokens_in":23366,"tokens_out":4797,"duration_ms":47437,"significance":"If the claims hold, RIGEL is a substantive engineering contribution: it demonstrates that a GNN-based diagnostic model can be compiled into MATs on Tofino switches, that stateful multi-switch aggregation is feasible with small resource footprints (6/12 stages, <4% SRAM), and that VQ-based discretization can avoid per-dimension iterative processing. The paper's strengths include a real testbed with optical components and Tofino switches, concrete hardware resource measurements, a clearly described multi-step quantization/training pipeline (Algorithm 1 and Appendix A), and systematic ablation of the three bit-widths bvq, buq, and bagg. The reported generalization experiments across topologies and unseen anomalies are also useful. However, the central claims are currently supported by experiments that have several load-bearing gaps: the data-plane description does not fully substantiate the 2-hop GraphSAGE claim, hyperparameters appear to be selected on the same test set used for final reporting, and the stated number of testing samples is inconsistent with the dataset size.","major_comments":[{"comment":"The data-plane implementation appears to perform only one round of neighbor aggregation, not the two-layer GraphSAGE claimed in §4. The feature packets exchanged between switches carry the AE embedding n_feat (Figure 6, Pipe-1 Local_feature_reg/Neigh_feature_reg), not the intermediate h_feat produced by the first AGG_table. Pipe-1 sends h_feat directly to Pipe-2, where AGG_table yields cls/root, but there is no mechanism for a switch to receive its neighbors' h_feat. Therefore the implemented inference is 1-hop feature aggregation followed by classification, whereas the full-precision model in §4 aggregates 2-hop neighborhoods. Since the paper's central novelty is 'distributed in-network inference through collaborative GNNs' and the diagnostic advantage is attributed to propagation over multiple hops, please clarify this discrepancy: provide P4-level pseudocode or a definitive state mach","section":"§3.2, §4, §6, Figure 6"},{"comment":"The optimal configuration (bvq=11, buq=6, bagg=7) is selected directly from Table 3, which appears to report test-set performance for all hyperparameter combinations. The same configuration is then used for the end-to-end results in Table 1 and the comparison in Table 6. If the test set is used for model selection, the reported accuracies and F1-scores are optimistically biased. The paper should either use a separate validation set for selecting bit-widths, report performance on a truly held-out test set after selection, or present nested cross-validation. Additionally, no repeated-run variance or error bars are given anywhere, so it is not possible to judge whether the differences between configurations (e.g., 99.45 vs 99.18 in Table 3) are meaningful.","section":"§7.3, Table 3, Table 1, Table 6"},{"comment":"The text states that the experiments in Table 6 run over 'all the ~400,000 testing samples.' However, §4 reports a total dataset of ~234,000 samples and a 0.6/0.2/0.2 train/validation/test split, which yields about 46,800 test samples, not 400,000. This is a large numerical inconsistency that directly affects the reproducibility of the reported interaction counts (66,950 vs 6,490) and the claimed overhead-reduction ratios. Please correct the sample count and recompute the ratios, or explain what 'testing samples' means here.","section":"§7.5, Table 6"},{"comment":"The microbenchmark compares one GraphSAGE aggregation layer on Tofino (~800 ns) against a CPU server (~10 ms) while 'deliberately excluding the latency due to inter-node communication.' For a distributed system, inter-switch feature exchange and state synchronization are part of the end-to-end diagnostic latency, and the paper elsewhere emphasizes that 'adding more neighbors increases diagnosis latency.' Please report the total diagnosis latency including feature-packet exchange, or at least bound it, so that the 'real-time' claim is supported.","section":"§7.2, 'In-Switch Inference Latency'"}],"minor_comments":[{"comment":"The text says 'to improve diagnosis accuracy, an operator should first try to increase the VQ/UQ bit-widths, while adding more neighbors in each neighbor aggregation should always be the second choice.' This seems inconsistent with the immediately preceding observation that bagg is the main performance bottleneck and that increasing bagg from 6 to 7 gives the largest F1 gains. Clarify whether 'adding more neighbors' refers to the aggregation neighbor count (S1, S2) or the aggregation codebook bit-width bagg, and reconcile the recommendation with Table 3.","section":"§7.3, last paragraph"},{"comment":"Figure 8 shows performance up to bvq=12, but the text says 'we will select bvq ∈ [9,11]' after discussing the figure. Specify why bvq=12 is shown and then excluded from later experiments (presumably MAT-size constraints), or adjust the figure/text for consistency.","section":"Figure 8 and §7.3"},{"comment":"The multi-root reporting threshold for retraining is described only qualitatively ('preset threshold'). Since §7.4 reports multi-root reporting rates for known and unseen anomalies, please state the threshold used and how sensitive the results are to it.","section":"§3.4, §7.4"},{"comment":"The number of sampled neighbors per GraphSAGE aggregation is set to 1, which means each node aggregates exactly one neighbor at each hop. This is a strong constraint, and its effect on accuracy versus larger sampling counts is not investigated. Please justify this choice or note its impact.","section":"§4, §7.1"},{"comment":"Several related works on in-network ML (e.g., Taurus, IIsy, Planter) are cited in the introduction but not discussed in comparison with RIGEL's quantization approach. A short paragraph contrasting RIGEL with these systems would help position the contribution.","section":"General"}],"recommendation":"major_revision","confidential_remarks":"The paper has a strong engineering story and a plausible system, but the review found a material mismatch between the claimed 2-hop GNN and the described data-plane implementation, a test-set selection issue, and an inconsistent sample count. These are all fixable with additional clarity or experiments, so I do not recommend rejection. The authors should be asked to provide P4-level evidence for the aggregation depth or soften the novelty claim, rerun or re-report selection/held-out numbers, and correct the testing-sample count. The paper would benefit from at least one independent repetition with seeds to establish variance."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"This is a real systems paper with a genuinely useful idea: encoding high-dimensional spectral data as a single VQ codebook index and using that index as an exact-match table key to run a GraphSAGE-like model on Tofino switches. That VQ-to-MAT move directly addresses the per-dimension processing bottleneck that has blocked prior NN-on-switch work, and the testbed evaluation is more realistic than most in this area. The resource utilization numbers are detailed and the deployment story is coherent. Credit is due for the software–hardware co-design and for actually building and measuring a multi-switch prototype.\n\nThe soft spots are real, though. The most serious is the 2-hop claim. The full-precision model is described as a 2-layer GraphSAGE sampling neighbors at each hop, but the data-plane description in Section 6 shows only one round of neighbor aggregation: each switch receives its neighbors' raw features (n_feat), aggregates them with its own feature into h_feat, and then goes straight to the classifier in Pipe-2. Nothing in the described pipeline sends h_feat to neighbors for a second aggregation. So as written, the on-switch model is a 1-hop graph model, not the 2-hop GraphSAGE the paper claims and not what the baseline was trained to be. That is a load-bearing gap for the 'first distributed on-switch GNN' claim. It may be that the implementation does something not fully described, but the reader cannot tell from the paper, and the authors should be asked to clarify.\n\nOther issues are fixable but should not be quietly skipped. The hyperparameter search in Table 3 looks like it was done on the test set, or at least the paper never says it was done on a validation set. Section 7.5 says experiments ran over ~400,000 testing samples, but the whole dataset is ~234,000 samples with a 0.2 test split. The abstract and conclusion say 'more than three orders of magnitude' reduction in communication overhead, but the actual numbers in Table 6 are 2,568x versus C-GNN and 557x versus C-GNN-UQ; only one of those exceeds 1000x. There are also no error bars and no code/data release, which makes it hard to judge stability or reproducibility. These are the kind of issues that a serious referee would want fixed, but they are not fatal to the core idea.\n\nI think the paper deserves a serious referee. The VQ-index mechanism is novel and potentially reusable beyond optical networks, and the testbed work is substantial. It just needs a major revision to align the implementation description with the claims, move the hyperparameter selection off the test set, fix the data-count and overhead statements, and ideally release artifacts. If that happens, this could be a solid contribution to the in-network ML literature.","headline":"A serious systems paper with a genuinely clever VQ-index trick, but the on-switch implementation as described looks like a 1-hop GNN rather than the 2-hop GraphSAGE claimed, and the evaluation has several fixable but hard-to-ignore inconsistencies.","tokens_in":23906,"tokens_out":3986,"would_cite":true,"duration_ms":38622,"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":"RIGEL runs graph-neural-network diagnosis of optical anomalies entirely on programmable switches, cutting controller traffic by over three orders of magnitude.","keywords":["optical anomaly diagnosis","in-network inference","graph neural networks","vector quantization","programmable data plane","soft failure detection","P4 switches","stateful inference"],"falsifier":"Measure the preprocessing latency and diagnostic accuracy on a stock OPM CPU using real 640-dimensional spectra. If the preprocessing cannot finish within the OPM monitoring interval, or if classification accuracy for the filter-drift classes (±12.5 GHz) falls below the reported levels, then the in-network inference has lost the information it needs and the reported results do not transfer beyond the testbed.","tokens_in":22806,"feed_emoji":"⚡","tokens_out":4583,"duration_ms":43641,"temperature":0.7,"pith_summary":"RIGEL is an attempt to make optical-network anomaly diagnosis happen at line rate inside the data plane, without shipping telemetry to a controller. The paper's central claim is that a graph neural network can be split across interconnected programmable switches and executed in a stateful, distributed way, as long as each node's high-dimensional spectrum is first compressed to a single integer codebook index. The authors build a testbed with real optical components and programmable switches, and report over 99% accuracy in classifying and locating soft failures while reducing control-plane data exchange by more than three orders of magnitude. If this holds, it points to a practical way to embed network-aware machine learning deeply into the network itself.","feed_headline":"On-switch GNNs diagnose optical faults in real time","feed_subtitle":"RIGEL cuts controller telemetry by over 1000x via single-index spectrum compression.","key_machinery":"The VQ codebook index is the load-bearing object. It is a learned integer ID that represents a full spectral sample; RIGEL uses it as both the match-action table lookup key for the autoencoder and as the compact token exchanged between switches for GraphSAGE neighbor aggregation. The graph model is a two-layer GraphSAGE with fixed-size neighbor sampling, chosen because its inductive, deterministic aggregation fits the non-iterative pipeline of a programmable switch. The entire inference path is compiled into match-action tables and registers, coordinated by neighbor state machines that track which local and remote features have arrived.","core_discovery":"The paper's central discovery is that vector quantization—mapping each high-dimensional spectral sample to an integer codebook index—simultaneously solves the two problems that block GNNs on switch hardware: it turns the input into a single match-action table key (eliminating per-dimension arithmetic loops), and it shrinks inter-switch feature messages to a few bits. Around this key, the authors build an autoencoder to compress raw spectrum, a GraphSAGE model to aggregate features from neighboring switches, and neighbor state machines to coordinate asynchronous arrivals. On a six-node packet-over-optical testbed, the resulting system reports 99.47% classification accuracy and 99.54% location","pith_inferences":["The preprocessing on the OPM CPU (PCA to UQ to VQ) moves the real computational cost off the switch; if that CPU becomes a bottleneck, the 'real-time' advantage depends on the OPM vendor's compute budget rather than on the switch itself.","The reported three-orders-of-magnitude overhead reduction assumes the switch only sends anomaly alerts; in a network with high anomaly rates, the saving shrinks as alerts dominate traffic.","The VQ-index approach could be applied to other graph-structured network telemetry (e.g., wireless, datacenter, or multi-domain optical), but the paper's testbed is single-domain and may not capture cross-domain propagation effects.","The one-bit jump in aggregation codebook size (from 6 to 7 bits) produced the largest accuracy gains, suggesting that the inter-switch feature bottleneck, not the input quantization, is the current limiter."],"forward_implications":["If correct, operators can diagnose soft failures without centralized analytics, freeing controllers for other tasks and avoiding round-trip latency across metro and backbone distances.","The VQ-index trick may generalize to other high-dimensional telemetry (e.g., power, BER, q-factor) that currently overwhelms in-network machine learning.","The multi-root reporting mechanism offers a cheap way to detect unseen anomalies and trigger automatic retraining.","Cross-topology generalization means a model trained on one network can be deployed on another without retraining, easing network expansion.","The hardware footprint (six of twelve stages, under 4% SRAM) suggests the diagnosis model can coexist with normal forwarding on the same switch."],"fun_headline_variants":["Vector quantization puts GNNs on switches for optical fault detection","Switch-based GNNs diagnose optical faults with 99.5% accuracy","Stateful in-network GNNs cut telemetry 1000x for optical diagnosis","Distributed GNNs on Tofino switches spot optical anomalies in real time","Compressed spectrum enables on-switch GNNs for optical diagnosis"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The system's accuracy depends on the OPM's CPU being able to run PCA, uniform quantization, and vector quantization on 640-dimensional spectra fast enough and with enough fidelity that the resulting codebook index still separates the subtle failure classes, especially the ±12.5 GHz filter drifts.","fun_headline_variants_meta":{"raw":{"variants":["Vector quantization puts GNNs on switches for optical fault detection","Switch-based GNNs diagnose optical faults with 99.5% accuracy","Stateful in-network GNNs cut telemetry 1000x for optical diagnosis","Distributed GNNs on Tofino switches spot optical anomalies in real time","Compressed spectrum enables on-switch GNNs for optical diagnosis"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000192,"raw_usage":{"total_tokens":1180,"prompt_tokens":737,"completion_tokens":443,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":481,"completion_tokens_details":{"reasoning_tokens":344}},"tokens_in":481,"tokens_out":443,"duration_ms":4584,"temperature":1.0,"reasoning_tokens":344,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-03T09:32:19.513225+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Measure the preprocessing latency and diagnostic accuracy on a stock OPM CPU using real 640-dimensional spectra. If the preprocessing cannot finish within the OPM monitoring interval, or if classification accuracy for the filter-drift classes (±12.5 GHz) falls below the reported levels, then the in-network inference has lost the information it needs and the reported results do not transfer beyond the testbed.","supporting_citations":[],"review_version":1}