{"id":"f88f5ebd-6d2d-49ba-996b-2c52d4ec29b8","arxiv_id":"2501.15348","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"ReInc trains dynamic GNNs on large graphs up to 12.8x to 17.7x faster than DynaGraph and ESDGNN by reusing cached aggregations, incremental delta-based updates, and a communication-free snapshot placement.","lead":"ReInc is a system for training dynamic graph neural networks that reuses intermediate computations, incrementally updates graph aggregations, and places snapshots so machines rarely communicate. On four large graph datasets it trains stacked and integrated DGNNs up to about 10 to 18 times faster than two state-of-the-art frameworks, with matching prediction accuracy.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Zero-communication claim hinges on an unmeasured snapshot-overlap assumption; for T=100, L=8, M=8, keeping all sequences local requires replicating about (M-1)(L-1) boundary snapshots, and the fallback branch of §3.4.1 adds network traffic that Table 1 omits.","rationale":"The reader's weakest assumption is also the most load-bearing gap I found. The paper's central and most distinctive claim is that ReInc eliminates communication overhead in distributed DGNN training. That claim depends directly on each machine holding every snapshot needed by its mini-batch sequences. Section 3.4.1 explicitly hedges this with two branches — overlapped snapshot placement when memory permits, and remote snapshot retrieval otherwise — but the evaluation never reports which branch was active, how much memory the overlap cost, or how much communication and slowdown the fallback branch causes. The scaling experiments in Figure 13 vary machines, sequence length, and change ratio, but not this parameter, so the distributed headline is untested at exactly the point where the assumption is weakest. My rough arithmetic for the stated setup shows that the overlap is not a negligible corner case: with T=100, L=8, and M=8, keeping every sequence local requires replicating the first L-1 snapshots of each block, about 49 extra snapshot copies across the cluster. That is material on the largest dataset. This is an experimental and evidential gap, not a logical contradiction: the incremental aggregation equations and the reuse arguments are coherent, and the matching MAE curves in Figure 14 support correctness under the stated conditions. It therefore strengthens the case for the reader's CONDITIONAL verdict rather than changing it. I agree with the reader's identification of the same concern, and the concrete test I propose would settle whether the zero-communication claim survives in the actual reported setting.","tokens_in":22579,"tokens_out":8358,"duration_ms":82276,"concrete_test":"Re-run the reported distributed configuration (T=100, L=8, M=8, batch size 10,000, [25,10] sampling, OGB-Papers) while instrumenting per-machine peak host memory and total network bytes excluding gradient synchronization, under two branches: (a) overlapped snapshot placement with no remote fetches, and (b) no overlap with remote snapshot fetches. If branch (a) increases host memory by more than about 20% over the base partition, or branch (b) transfers any nonzero bytes, then Table 1's 'REINC 0 GB' entry and the no-communication claim require a stated condition; also report branch (b) epoch time to check how much of the speedup survives when remote fetches are needed.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The flagship distributed claim — 'no communication', Table 1's 0 GB entry, and the abstract's claim of eliminating remote feature access — is only true in the overlapped snapshot placement branch of §3.4.1. The paper does not report which branch was used in the experiments, how much extra host memory the overlap required, or the network bytes and time incurred when a machine instead fetches remote snapshots during training. For the evaluation configuration (T=100 snapshots, M=8 machines, L=8), if sequences are assigned to the machine containing their first snapshot, every machine except the last needs the first L-1 snapshots of the next block, i.e. about (M-1)(L-1)=49 additional snapshot copies across the cluster compared with the 100 base snapshots. On OGB-Papers, where one snapshot already has 1.6B edges and features for 111M nodes, this extra memory is not obviously negligible, and it is never measured. If the fallback branch is used instead, the '0 GB' entry is not zero, the forward pass is no longer independent across machines, and the reported speedups are mixed with an unquantified network cost. The incremental aggregation and reuse core may still be correct and fast, but the central distributed claim is conditional on an unstated resource assumption that the paper neither justifies nor evaluates.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents ReInc, a system for distributed training of discrete dynamic graph neural networks (DGNNs). It identifies three reuse opportunities (across RNN gates, across overlapping sliding-window sequences, and between encoder/decoder teacher-forcing inputs), proposes incremental aggregation through delta graphs, introduces a two-level cache with a DGNN-aware eviction policy, and proposes a consecutive-block snapshot placement with sequence-first mini-batching that is claimed to eliminate remote feature access and intermediate-result redistribution. The evaluation compares ReInc with DynaGraph and ESDGNN on four DGNN architectures and four large graph datasets, reporting speedups of 2.9--12.8x and 2.8--17.7x respectively, and identical test MAE on a correctness check.","tokens_in":22757,"tokens_out":7749,"duration_ms":70472,"significance":"If the claims hold, ReInc addresses a real bottleneck in scaling DGNN training: the combination of graph structure and temporal dependencies causes redundant computation and communication in existing systems. The incremental aggregation identity in Eq. (2) is correct for sum aggregation, and the reuse-based computation preserves exact aggregate values, so the core optimization is mathematically sound. The paper also provides a broad empirical comparison across multiple architectures and baselines, and it explicitly checks correctness against an independent baseline with matching MAE. The main limitations are that the headline zero-communication distributed claim is conditional on an unmeasured memory-replication branch, the incremental aggregation treatment is incomplete for mean (and partly for max/min), and the two largest datasets are synthetic dynamizations of static graphs. These issues are fixable but currently prevent the central claims from being accepted as stated.","major_comments":[{"comment":"Equation (2) is presented as the general incremental aggregation rule, but it is only valid for sum aggregation. For mean aggregation, Agg_t is defined in Eq. (1) as the mean of neighbor features, yet subtracting and adding raw neighbor features does not account for the change in degree. Concretely, if at t-1 a node has neighbor features {1,3} with mean 2, and at t the edge to feature 3 is deleted and an edge to feature 5 is inserted, Eq. (2) gives 2 - 3 + 5 = 4, whereas the true new mean is (1+5)/2 = 3. If ReInc internally stores unnormalized sums and divides by degree only at consumption, that design must be stated and Eq. (2) must be rewritten accordingly; otherwise the claim that mean() is a supported built-in incremental aggregation is unsupported.","section":"§3.2, Eq. (2)"},{"comment":"The '0 GB communication' entry in Table 1 and the abstract's claim of eliminating remote feature access apply only to the overlapped snapshot placement branch of §3.4.1. The paper does not report whether the distributed experiments used overlapped placement, how much additional host memory the overlap required, or the network bytes and time incurred when the fallback branch ('retrieves remote snapshots from other machines during training as needed') is used. For the evaluation configuration with T=100 snapshots, M=8 machines, and L=8, the overlap branch requires roughly (M-1)(L-1)=49 additional snapshot copies across the cluster, and on OGB-Papers a single snapshot already has 1.6B edges and 111M nodes. This is load-bearing because the central distributed claim is that ReInc eliminates communication; please report branch selection, memory overhead, and fallback communication cost, or qualify the abstract and Table 1.","section":"§3.4.1 and Table 1"},{"comment":"The two largest datasets, OGB-Products and OGB-Papers, are static graphs converted into dynamic ones by randomly modifying edges and features with change ratios drawn uniformly from 0% to 100%, and the traffic datasets are scaled by replication. The headline speedups are therefore measured on synthetic dynamism rather than on real large dynamic graphs, and random rewiring at 100% change is not the 'slowly changing' regime that motivates incremental aggregation. This limits the external validity of the central performance claim. The paper acknowledges the scarcity of public large DGNN datasets, but the abstract's phrase 'real-world graph datasets' overstates the evidence; please add at least one real large dynamic dataset or a sensitivity analysis that varies the structure of changes.","section":"§5, Experimental Setup"}],"minor_comments":[{"comment":"The user-defined threshold for falling back to from-scratch aggregation when the change ratio is high is never given a default value, and the experiments in Fig. 13 that vary change ratio do not report when the fallback was triggered.","section":"§3.2"},{"comment":"The text says 'cached aggregations in the global cache can be assessed across layers'; 'assessed' should be 'accessed'.","section":"§3.3"},{"comment":"Equation (3), Priority = F(Agg)/S(Agg) - I(Agg), mixes dimensionless future access count, size, and timestep-based imminence without specifying normalization, and the claim of equal weights is not tested via an ablation.","section":"§3.3.3"},{"comment":"Correctness is shown only for METR-LA-LARGE; the statement that convergence curves on all other datasets 'align consistently' with the baselines is not accompanied by a figure or quantitative comparison.","section":"§5.6"},{"comment":"Table 1 reports epoch communication volume and time but does not describe the dataset, model, sequence length, or hardware configuration used to produce those numbers; a caption or a pointer to the experimental setup is needed.","section":"Table 1"},{"comment":"The title uses 'ReInc' while the body and abstract consistently use 'REINC'; please unify the notation.","section":"Title/Abstract"}],"recommendation":"major_revision","confidential_remarks":"The manuscript does not reference a code repository or artifact release, which is unusual for a systems paper and would materially help reproducibility. The comparison with DynaGraph and ESDGNN is based on prototypes implemented by the authors; please consider asking whether the baseline implementations are available or how faithfully they match the original systems. The paper's core incremental aggregation idea is sound for sum aggregation, but the mean-aggregation gap and the unmeasured overlap-memory assumption need to be addressed before the distributed claims can be accepted."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Read ReInc. Short version: real systems paper, correct core, speedups plausible — but the “zero communication” distributed claim is softer than the abstract and Table 1 suggest, because the paper’s own §3.4.1 conditions it on an overlapped-snapshot-placement branch whose memory cost is never measured.\n\nWhat’s actually new: the three reuse opportunities individually trace to prior work (DynaGraph for gate reuse, Tegra/EGraph for incremental aggregation, CBGNN/PaGraph for caching), but the combination is new, and the future-access-aware cache policy and seq-first mini-batching are the fresh pieces. The incremental aggregation identity (Eq. 2) is correct for sum/mean — delta-based maintenance of a linear aggregation — and max/min get an honest stated fallback. The test MAE curves matching baselines on METR-LA-LARGE is the right correctness evidence, and the cache-policy ablation against LRU/LFU is exactly what a systems paper should ship. The paper is also upfront in §3.2 about the change-ratio fallback threshold.\n\nThe soft spot is the distributed claim. §3.4.1 says: if a machine has memory for the extra snapshots, use overlapped placement; otherwise fetch remote snapshots over the network. The abstract and Table 1 report 0 GB, but the evaluation never says which branch ran, what the overlap memory was, or what the network cost is in the fallback. For the test config (T=100, M=8, L=8), keeping boundary sequences local costs on the order of (M−1)(L−1) ≈ 49 extra snapshot replicas; on OGB-Papers that is real memory. So the headline is conditional on a stated but unquantified resource assumption — and §5.1’s “REINC incurs no communication” overstates what the paper itself established. This is an evidential gap, not a logical flaw; the local-branch speedups and the incremental core stand.\n\nSmaller items: the two largest datasets are OGB graphs made dynamic by random edge/feature modification, and ESDGNN is a re-implementation ported by the authors. Both are understandable — public large DGNN benchmarks barely exist — but they cap how much I’d trust the absolute speedup factors until code ships. No code or data release, which for a systems paper is a real cost.\n\nWho it’s for: anyone working on DGNN training systems or benchmarking dynamic-graph frameworks. It deserves a serious referee. My recommendation: send it out, and require the authors to report which placement branch the experiments used, the overlap memory overhead, fallback communication volume, and release the code.","headline":"Correct incremental-aggregation core, plausible speedups, but the headline zero-communication claim rests on an unevaluated snapshot-overlap branch the paper itself only mentions in passing.","tokens_in":23390,"tokens_out":7262,"would_cite":true,"duration_ms":61887,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"ReInc claims that distributed training of dynamic graph neural networks can be made communication-free in the forward pass and up to 17.7x faster than prior systems by reusing intermediate aggregations and placing graph snapshots as…","keywords":["dynamic graph neural networks","incremental aggregation","distributed training","snapshot reuse","two-level caching","mini-batch training","traffic forecasting","graph partitioning"],"falsifier":"Run the same four DGNNs with a sequence length larger than the per-machine snapshot budget on a graph whose snapshots exceed one machine's host memory, and compare per-epoch time and network bytes against the paper's zero-communication claim; if remote snapshot fetch dominates, the claimed scaling does not hold. Alternatively, train a max()-aggregation model on a graph with frequent edge deletions, where the paper's own fallback to from-scratch aggregation should eliminate the incremental speedup.","tokens_in":22291,"feed_emoji":"⚡","tokens_out":8589,"duration_ms":66354,"temperature":0.7,"pith_summary":"The paper proposes REINC, a training system for dynamic graph neural networks (DGNNs) that combine a GNN with an RNN. Its claim is that three reuse opportunities—across RNN gates, across overlapping sliding-window sequences, and between decoder and encoder under teacher forcing—plus incremental aggregation over delta graphs, a two-level DGNN-aware cache, and a consecutive-block snapshot placement that keeps each training sequence local, make distributed DGNN training faster by roughly an order of magnitude. On four DGNN architectures and four large graphs it reports 2.9–12.8× speedups over DynaGraph and 2.8–17.7× over ESDGNN, with the same test MAE in a correctness comparison. The broader importance is that scaling DGNNs to large dynamic graphs has been blocked by communication and redundant computation; if REINC is right, both bottlenecks can be removed without sacrificing accuracy.","feed_headline":"Reusing graph snapshots speeds dynamic GNN training up to 17.7x","feed_subtitle":"A new distributed scheme eliminates feature and intermediate communication during the forward pass while matching earlier test accuracy.","key_machinery":"The load-bearing identity is incremental aggregation over delta graphs: $\\mathrm{Agg}_t = \\mathrm{Agg}_{t-1} - F_{t-1} \\ast_{\\text{aggr}} G^-_t + F_t \\ast_{\\text{aggr}} G^+_t$, where $G^-_t$ and $G^+_t$ collect edge deletions and insertions between consecutive snapshots and feature changes are rewritten as deletions plus insertions. This turns recomputing each snapshot from scratch into a small correction, which is effective because real-world dynamic graphs change slowly relative to their size. The accompanying machinery is a two-level cache store with a DGNN-aware priority score based on future access count, imminence, and size, plus consecutive-block snapshot placement with seq-first mini-batch iteration so that cached aggregations are reused while sequences stay local. The identity carries the computational savings; the placement carries the communication savings.","core_discovery":"REINC's central claim is that the execution of a DGNN, whether the GNN and RNN are stacked or integrated into a GraphRNN, can be made communication-free in the forward pass by placing consecutive snapshots as blocks on machines: because time dependencies exist only within a training sequence and sequences are independent, each machine holds the full sequence of snapshots its mini-batch needs, so no remote feature pulls or intermediate redistribution occur. On top of this placement, REINC avoids recomputation by caching and reusing aggregations and by computing each snapshot's aggregation from the previous one using only the changed edges, with feature changes encoded as edge deletions and insertions. The paper supports the claim with experiments showing 2.9–12.8× and 2.8–17.7× epoch-time speedups over DynaGraph and ESDGNN respectively across GCRN-M1, CD-GCN, GCRN-M2, and T-GCN on four large graphs, and identical test MAE on METR-LA-LARGE with 2.9× and 8.1× speedups.","pith_inferences":["An implication the paper leaves implicit is that the zero-communication forward pass is contingent on sequence locality; for sequences longer than a machine's snapshot block, the fallback of remote snapshot fetch would reintroduce network traffic and should be measured.","The same delta-graph incremental aggregation could be applied to streaming or continuous-time GNN training, where changes arrive as edge events rather than discrete snapshots, but attention-style weighted aggregations would need re-aggregation after weight updates.","If change ratios are high in a deployment, the incremental speedup shrinks toward the from-scratch baseline; the paper's own fallback threshold makes the benefit workload-dependent, so the reported speedups generalize best to slowly evolving graphs.","The seq-first mini-batch strategy is a general scheduling idea for any sequence-of-snapshots workload: iterating over time before sampling nodes maximizes reuse of cached intermediate results."],"forward_implications":["REINC's reuse and incremental aggregation make integrated GraphRNN architectures trainable at scale, closing the gap that previous systems left for stacked-only or integrated-only optimization.","Longer sequences and larger feature or hidden dimensions no longer create proportional communication and recomputation overhead, so DGNN training can scale to more history and richer features.","The seq-first mini-batch order enables near-complete cache reuse at modest cache sizes, reducing GPU memory pressure during training.","Because the correctness run matches prior test MAE, the distributed strategy and optimizations can be adopted without changing model accuracy."],"supporting_citations":[{"why":"DynaGraph is the main baseline for integrated DGNN optimization and random node partitioning; it anchors the 2.9–12.8× speedup comparison.","marker":"[15]"},{"why":"ESDGNN is the baseline for sequence placement across machines; it anchors the 2.8–17.7× speedup comparison.","marker":"[4]"},{"why":"GCRN-M1 and GCRN-M2 are the stacked and integrated DGNN models used in evaluation.","marker":"[55]"},{"why":"T-GCN is the GRU-based integrated DGNN model used in evaluation.","marker":"[79]"},{"why":"CD-GCN is the stacked DGNN model used in evaluation.","marker":"[45]"},{"why":"METR-LA-LARGE is one of the two scaled traffic graph datasets used in experiments and in the correctness run.","marker":"[26]"},{"why":"PEMS-BAY-LARGE is the other scaled traffic graph dataset and the source of the DCRNN-style traffic forecasting setup.","marker":"[41]"},{"why":"OGB-Products and OGB-Papers provide the two largest evaluation graphs, converted to dynamic snapshots.","marker":"[21]"},{"why":"The GDSF caching policy is the basis of REINC's priority scoring for cached aggregations.","marker":"[7]"},{"why":"DGL supplies the message-passing backend and appears as the static-GNN baseline in the communication comparison table.","marker":"[65]"}],"fun_headline_variants":["ReInc: communication-free forward pass speeds DGNNs 17.7x","Cached snapshots and incremental aggregation cut DGNN training 17.7x","DGNN training gets 17.7x speedup via snapshot reuse","No remote fetches: ReInc reuses snapshots for 17.7x faster DGNN training"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that each machine's assigned training sequences are fully local after snapshot placement; if a machine lacks memory to hold overlapping snapshots, it must fetch remote snapshots, which would replace the headline zero communication with network traffic.","fun_headline_variants_meta":{"raw":{"variants":["ReInc: communication-free forward pass speeds DGNNs 17.7x","Cached snapshots and incremental aggregation cut DGNN training 17.7x","DGNN training gets 17.7x speedup via snapshot reuse","No remote fetches: ReInc reuses snapshots for 17.7x faster DGNN training"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.00054,"raw_usage":{"total_tokens":2600,"prompt_tokens":965,"completion_tokens":1635,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":581,"completion_tokens_details":{"reasoning_tokens":1545}},"tokens_in":581,"tokens_out":1635,"duration_ms":10097,"temperature":1.0,"reasoning_tokens":1545,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T14:22:50.115917+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the same four DGNNs with a sequence length larger than the per-machine snapshot budget on a graph whose snapshots exceed one machine's host memory, and compare per-epoch time and network bytes against the paper's zero-communication claim; if remote snapshot fetch dominates, the claimed scaling does not hold. Alternatively, train a max()-aggregation model on a graph with frequent edge deletions, where the paper's own fallback to from-scratch aggregation should eliminate the incremental speedup.","supporting_citations":[{"cited_title":"Dynagraph: Dynamic graph neural networks at scale","cited_arxiv_id":null,"evidence_quote":"DynaGraph is the main baseline for integrated DGNN optimization and random node partitioning; it anchors the 2.9–12.8× speedup comparison."},{"cited_title":"Chakaravarthy, Shivmaran S","cited_arxiv_id":null,"evidence_quote":"ESDGNN is the baseline for sequence placement across machines; it anchors the 2.8–17.7× speedup comparison."},{"cited_title":"Structured sequence modeling with graph convolutional recurrent networks, 2016","cited_arxiv_id":null,"evidence_quote":"GCRN-M1 and GCRN-M2 are the stacked and integrated DGNN models used in evaluation."},{"cited_title":"T-gcn: A tempo- ral graph convolutional network for traffic prediction","cited_arxiv_id":null,"evidence_quote":"T-GCN is the GRU-based integrated DGNN model used in evaluation."},{"cited_title":"Dynamic graph convolutional networks","cited_arxiv_id":null,"evidence_quote":"CD-GCN is the stacked DGNN model used in evaluation."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"METR-LA-LARGE is one of the two scaled traffic graph datasets used in experiments and in the correctness run."},{"cited_title":"Dif- fusion convolutional recurrent neural network: Data- driven traffic forecasting","cited_arxiv_id":null,"evidence_quote":"PEMS-BAY-LARGE is the other scaled traffic graph dataset and the source of the DCRNN-style traffic forecasting setup."},{"cited_title":"Improving WWW proxies per- formance with greedy-dual-size-frequency caching pol- icy","cited_arxiv_id":null,"evidence_quote":"The GDSF caching policy is the basis of REINC's priority scoring for cached aggregations."}],"review_version":1}