NetReplica: Network-Aware Data & Replication

• NetReplica is a concept that combines realistic ML data generation with a network-aware replication abstraction for geo-distributed systems.
• The system generates training data by injecting controlled cross-traffic profiles, reducing transmission prediction error by up to 47%.
• Its design principles also optimize replica migration, state transfer, and consistency, achieving improvements like 30% reduction in migration time.

Searching arXiv for papers on “NetReplica” and closely related replica-management/state-transfer work. NetReplica denotes two closely related usages in the arXiv literature. In the most explicit sense, it is a system for generating training data for networking machine-learning models that combines realism in protocol dynamics with controllability of network conditions, introduced to address the domain adaptation problem in networking (Daneshamooz et al., 17 Jul 2025). In a broader design-oriented sense, “NetReplica” is also used as a hypothetical network-aware replica-management abstraction for geo-distributed systems, encompassing replica migration scheduling, replica consistency, state transfer, dynamic replica replacement, and non-uniform replication (Mseddi et al., 2015, Campêlo et al., 2020, Chiba et al., 2021, Cabrita et al., 2017, Chiba et al., 2022). Taken together, these usages position NetReplica at the intersection of network-aware control, replication semantics, and systems adaptation under heterogeneous, time-varying conditions.

1. Naming, scope, and conceptual lineage

The explicit system named NetReplica is presented in “Addressing the ML Domain Adaptation Problem for Networking: Realistic and Controllable Training Data Generation with NetReplica” (Daneshamooz et al., 17 Jul 2025). Its stated purpose is to generate training datasets with two critical properties: realism in protocol dynamics and controllability of network conditions. The system models networks as collections of bottleneck links with specific attributes, leverages production network traces, and exposes fine grained control knobs for each link attribute (Daneshamooz et al., 17 Jul 2025).

A second, design-oriented usage appears in several earlier papers, where “NetReplica” is introduced as a hypothetical system name for applying published mechanisms to replica management. In this usage, NetReplica is described as a system focused on network-efficient replica placement and migration in geo-distributed storage (Mseddi et al., 2015), as a replica-consistency layer for cloud storage (Campêlo et al., 2020), as a network-aware and bandwidth-adaptive mechanism for replica synchronization and state transfer (Chiba et al., 2021), and as a network-aware adaptive replication system for dynamic replica replacement in geo-replicated state machines (Chiba et al., 2022).

This dual usage is significant because it separates a concrete implementation domain—networking ML data generation—from a more general architectural vocabulary for replication systems. A plausible implication is that the term has become a convenient label for network-aware replication problems whose common structure is adaptation to heterogeneity, whether the objects being “replicated” are machine-learning training conditions, storage partitions, service state, or semantically compressed CRDT state.

2. NetReplica as a networking ML data-generation system

In its primary published form, NetReplica addresses the observation that machine learning models in networking suffer from the domain adaptation problem: models trained in one domain often fail when deployed in different production environments (Daneshamooz et al., 17 Jul 2025). The paper identifies a typical mismatch between source domains such as campus networks, cloud labs, or crowdsourced platforms like Puffer or M-Lab, and target domains such as last-mile access links, high-latency paths, heavily contended WiFi, cellular, or specific ISP segments (Daneshamooz et al., 17 Jul 2025).

NetReplica’s core claim is that improving generalization requires changing the training data itself rather than merely increasing its volume. The system therefore aims to generate data that preserves closed-loop protocol dynamics while allowing deliberate construction of underrepresented or rare network conditions (Daneshamooz et al., 17 Jul 2025). Its evaluation using Puffer reports that models trained on NetReplica augmented datasets show substantially improved generalizability, reducing transmission time prediction error by up to 47% for challenging network conditions compared to models trained solely on Puffer data (Daneshamooz et al., 17 Jul 2025).

The system is built around a bottleneck-link abstraction. A network path is modeled as one or more bottleneck links, each with static attributes—link capacity, base propagation delay, maximum queue length, queue management or AQM policy, and traffic shaping policy—and dynamic attributes capturing cross-traffic intensity, burstiness, and heterogeneity (Daneshamooz et al., 17 Jul 2025). Realism is obtained from packet captures collected at the gateway router of a medium-sized campus network with approximately 48k active users and an 8.2 Gbps bidirectional Internet connection (Daneshamooz et al., 17 Jul 2025). These traces are transformed into cross-traffic profiles, or CTPs, through host-based decomposition, time-series construction in 100 ms bins, hierarchical aggregation over IP prefixes, and sliding-window extraction over durations from 1 to 60 seconds (Daneshamooz et al., 17 Jul 2025).

A notable feature is that CTPs are stored in PostgreSQL and indexed by intensity, burstiness, and heterogeneity, which enables queryable selection of traffic profiles for controlled experiments (Daneshamooz et al., 17 Jul 2025). NetReplica can then combine these selected CTPs with configurable shaping rate, delay, and queue policy using Linux tc, netem, LibreQoS, and tcpreplay, while running unmodified target applications such as NDT or Puffer over the resulting path (Daneshamooz et al., 17 Jul 2025). This design preserves protocol realism because cross-traffic originates from production traces and target applications run in real time, yet it remains programmable because bottleneck parameters and CTP-selection criteria are explicit inputs (Daneshamooz et al., 17 Jul 2025).

3. Architectural model: realism, controllability, and bottleneck semantics

NetReplica’s system model formalizes a bottleneck link $L$ with capacity $C_L$, base propagation delay $d_L$, queue size $Q_L$, queue-management policy $f_L$, cross-traffic time series $X_L(t)$, and target application traffic $A_L(t)$ (Daneshamooz et al., 17 Jul 2025). The instantaneous utilization is expressed as

$U_L(t) = \frac{X_L(t) + A_L(t)}{C_L},$

while queueing delay and loss are emergent outcomes of the recent utilization history under the selected queue-management policy (Daneshamooz et al., 17 Jul 2025). The paper emphasizes that these quantities are not imposed through a simplified analytical model; instead, they emerge from Linux and LibreQoS implementations, which is intended to preserve protocol realism.

The realism–controllability trade-off is central. Realism derives from endogenous packet traces and live application execution, whereas controllability is achieved through explicit knobs for static link attributes and CTP selection or transformation (Daneshamooz et al., 17 Jul 2025). The paper further introduces two mechanisms for adapting cross-traffic to shaped links. “Profile Filtering” retains only CTPs whose peak throughput is below a threshold relative to the shaping rate, while “Profile Trimming” rescales bursts to satisfy a target peak while preserving temporal structure and normalized burstiness (Daneshamooz et al., 17 Jul 2025). The reported outcome is that trimmed CTPs preserve burstiness better than filtered ones and expand the number of usable high-intensity profiles, with an example of 169k versus 28k profiles above 1 Mbps (Daneshamooz et al., 17 Jul 2025).

This architecture is closely aligned with the broader NetReplica design language found in systems papers on replica migration and state transfer. Those works likewise treat network conditions as first-class constraints and formulate scheduling or allocation against bandwidth, delay, or congestion structure rather than assuming homogeneous links (Mseddi et al., 2015, Chiba et al., 2021, Chiba et al., 2022). This suggests a common systems principle: network-aware replication is most effective when the substrate is represented explicitly rather than absorbed into an opaque transport layer.

4. Relationship to replica migration, state transfer, and consistency

Although the 2025 NetReplica paper concerns data generation for ML, earlier papers provide a broad systems context in which “NetReplica” denotes a hypothetical network-aware replica system. In “On Optimizing Replica Migration in Distributed Cloud Storage Systems,” the hypothetical NetReplica is framed around the transitional problem of moving from an initial placement $C^I$ to a final placement $C^F$ while minimizing migration time, avoiding congestion, and preserving a minimum availability threshold (Mseddi et al., 2015). The underlying CRANE model represents the network as a graph $C_L$0, with link capacities $C_L$1, migration indicators $C_L$2, replica-existence variables $C_L$3, link loads $C_L$4, and an objective

$C_L$5

which captures migration makespan (Mseddi et al., 2015).

CRANE’s heuristic organizes transfers into migration waves $C_L$6, selects one source per missing replica, estimates migration time based on link capacities and concurrent flows, and ensures that availability remains above threshold $C_L$7 throughout (Mseddi et al., 2015). Compared to OpenStack Swift, the reported improvements are up to 30% lower replica creation time and 25% lower inter-data-center traffic, while ensuring the minimum required availability of the data (Mseddi et al., 2015). In the design notes, these ideas are explicitly proposed as lessons for a hypothetical system “NetReplica” (Mseddi et al., 2015).

Replica consistency is treated separately in “A Brief Survey on Replica Consistency in Cloud Environments,” where NetReplica appears as a hypothetical consistency layer supporting data-centric models such as weak, PRAM/FIFO, causal, sequential, and strict consistency, and client-centric models such as eventual consistency, monotonic reads, monotonic writes, read-your-writes, and writes-follow-reads (Campêlo et al., 2020). The survey further classifies methods into fixed consistency methods, configurable consistency methods, and consistency monitoring methods, and maps systems such as PNUTS, Spanner, Clock-SI, Vela, Harmony, VFC3, Pileus, Indigo, GEO, SSOR, DynamoDB, VICOS, DMR-PDP, and CaaS onto these categories (Campêlo et al., 2020). In the accompanying design walk-through, NetReplica is envisioned as a multi-tier consistency architecture that could expose strong, causal, and eventual tiers, use quorums satisfying $C_L$8, and integrate invariant management and auditing (Campêlo et al., 2020).

State transfer adds another dimension. “A State Transfer Method That Adapts to Network Bandwidth Variations in Geographic State Machine Replication” introduces a chunk-based, bandwidth-proportional state transfer method in which a recovering replica estimates per-sender bandwidth $C_L$9, computes $d_L$0, and allocates chunk sets according to

$d_L$1

subject to

$d_L$2

The evaluation on Amazon EC2 reports a reduction in state transfer time of up to 47% compared with the existing method (Chiba et al., 2021). A closely related paper extends this mechanism to dynamic replica replacement in geo-replicated SMR and again reports up to 47% reduction in state transfer time, while also showing replica relocation times of 40 seconds versus 55 seconds and 35 seconds versus 55 seconds against PBFT in two replacement scenarios (Chiba et al., 2022). These results are explicitly presented as directly reusable design principles for a “NetReplica”-like system (Chiba et al., 2021, Chiba et al., 2022).

5. Formal models and algorithmic patterns associated with NetReplica

Across the literature, NetReplica is associated with a recurring set of formal patterns rather than a single algorithm. These patterns include bottleneck-link modeling for ML data generation, availability-constrained flow scheduling for storage migration, bandwidth-proportional chunk assignment for state transfer, quorum and consistency contracts for geo-distributed storage, and observable-equivalence semantics for non-uniform replication (Daneshamooz et al., 17 Jul 2025, Mseddi et al., 2015, Chiba et al., 2021, Cabrita et al., 2017).

The non-uniform replication line is particularly relevant because it provides a semantic compression model for replicated state. “Non-uniform Replication” defines a replicated system as non-uniform if, in a quiescent state, all replicas are observable equivalent: $d_L$3 Observable equivalence is weaker than full state equivalence and requires only that all read-only queries return the same result: $d_L$4 The paper further defines non-uniform eventual consistency through a set of core operations $d_L$5 such that

$d_L$6

and provides a generic propagation protocol with object-specific functions maskedForever, hasObservableImpact, mayHaveObservableImpact, and compact (Cabrita et al., 2017). Concrete NuCRDT instances include Top-K with removals, Top Sum, Top-K without removals, and Histogram (Cabrita et al., 2017). The evaluation reports that for Top Sum, NuCRDT uses about 55% of the bandwidth of delta-based CRDTs, while also reducing storage (Cabrita et al., 2017). In the accompanying discussion, these mechanisms are explicitly proposed for a system called NetReplica (Cabrita et al., 2017).

At the opposite end of the replication spectrum lies network-agnostic Byzantine SMR. “Network-Agnostic State Machine Replication” presents a single SMR protocol that adapts to whether the network is synchronous or asynchronous, with thresholds $d_L$7 and $d_L$8 satisfying

$d_L$9

and proves this trade-off optimal (Blum et al., 2020). While this work does not use NetReplica as a system label in its title, the supplied design notes interpret it “in the sense of this paper” as a NetReplica-style SMR mechanism that does not assume a priori whether the network is synchronous or asynchronous (Blum et al., 2020). A plausible implication is that the NetReplica vocabulary can also encompass control paths that adapt not only to bandwidth variation but to synchrony assumptions themselves.

6. Evaluation results, performance envelopes, and empirical significance

The clearest empirical identity of NetReplica comes from the 2025 networking ML paper. In the Puffer case study, NetReplica generates data under shaping rates of 4, 6, 8, and 10 Mbps and base latencies spanning nine values between 76 ms and 444 ms, using approximately 5000 selected CTPs stratified by burstiness (Daneshamooz et al., 17 Jul 2025). The resulting datasets $Q_L$0 are then filtered to slow-path conditions with delivery rate at most 6 Mbps and minimum RTT thresholds of 100, 200, 300, and 400 ms (Daneshamooz et al., 17 Jul 2025). The paper reports that $Q_L$1 contains 48.6k chunks versus 10.8k in the corresponding Puffer subset $Q_L$2, providing a fourfold increase in data for the most severe latency regime (Daneshamooz et al., 17 Jul 2025).

Several empirical findings delimit NetReplica’s operating regime. First, feature distributions for RTT, transmission time, and chunk size in $Q_L$3 lie within the range of Puffer’s full dataset $Q_L$4, indicating that NetReplica does not merely fabricate outliers disconnected from real traffic (Daneshamooz et al., 17 Jul 2025). Second, the delivery-rate distribution and its temporal variability differ from $Q_L$5, reflecting the deliberate injection of more bursty conditions through CTP selection (Daneshamooz et al., 17 Jul 2025). Third, Mahalanobis-distance analysis in a 62-D feature space yields a median distance of 5.85 from $Q_L$6, while 13.4% of $Q_L$7 points have distance greater than 10, indicating substantial overlap with Puffer data alongside extension into adjacent regions of feature space (Daneshamooz et al., 17 Jul 2025). Finally, on NetReplica test sets representing slow-path, high-burstiness conditions, models trained or fine-tuned on NetReplica-generated data reduce Fugu’s mean absolute percentage error by up to 47% relative to a model trained on years of Puffer data (Daneshamooz et al., 17 Jul 2025).

The systems-oriented NetReplica literature yields similarly concrete performance envelopes. CRANE’s migration scheduling reduces replica creation or migration time by up to 30%, inter-data-center data by about 25%, and improves availability by up to 10% during migration relative to Swift (Mseddi et al., 2015). Bandwidth-adaptive SMR state transfer reduces transfer time by up to 47% relative to CST, achieves near-perfect balance in per-replica transfer time with a max/min ratio of approximately 1.01, and maintains bandwidth-estimation error within 10% in the reported EC2 experiments (Chiba et al., 2021, Chiba et al., 2022). The non-uniform replication work reports lower storage and network bandwidth than traditional replication, with the Top Sum NuCRDT using about 55% of the bandwidth of delta-based CRDTs (Cabrita et al., 2017).

Taken together, these evaluations support a cross-domain interpretation of NetReplica as an empirical methodology for exploiting heterogeneity rather than masking it. In ML data generation, the heterogeneity is deliberately synthesized from real traces; in storage migration and SMR state transfer, it is inferred and scheduled against; in non-uniform replication, it is compressed according to query relevance.

7. Limitations, ambiguities, and future directions

NetReplica’s principal limitation in its explicit 2025 form is that cross-traffic is replayed without adapting to the emulated bottleneck or the target application, even though the original traces were generated by real applications and protocols (Daneshamooz et al., 17 Jul 2025). The paper characterizes this as a hybrid model: endogenous in generation, exogenous in adaptation (Daneshamooz et al., 17 Jul 2025). It also notes that the current implementation does not specialize for WiFi, DOCSIS, cellular, or satellite networks; depends on access to representative production packet captures; and currently scales to approximately eight parallel experiments before kernel-level issues in netem degrade fidelity (Daneshamooz et al., 17 Jul 2025).

The broader NetReplica design literature raises a distinct set of limitations. CRANE assumes a centralized controller, known topology and capacities, discrete time slots, and no explicit failure handling during migration (Mseddi et al., 2015). The adaptive SMR state-transfer methods assume checkpoint-plus-log state, modest control overhead, and bandwidth fluctuations on timescales longer than the adaptation interval $Q_L$8, with some performance sensitivity to the number of chunks $Q_L$9 and interval length (Chiba et al., 2021, Chiba et al., 2022). Non-uniform replication depends on deterministic query semantics and on the ability to classify updates as core, forever masked, or potentially observable; it is not presented as a general solution for arbitrary SQL-like queries or strict causal visibility at all times (Cabrita et al., 2017). The consistency survey further emphasizes CAP trade-offs, performance versus consistency, and trust in providers and tenants as persistent open issues (Campêlo et al., 2020).

A further encyclopedic complication is lexical ambiguity. “NetReplica” in the provided literature is not a single continuous software lineage. It is an actual named system in networking ML (Daneshamooz et al., 17 Jul 2025), but elsewhere it functions as a didactic or hypothetical design label attached to independent lines of work on migration scheduling, consistency control, state transfer, non-uniform replication, and network-agnostic SMR (Mseddi et al., 2015, Campêlo et al., 2020, Chiba et al., 2021, Cabrita et al., 2017, Blum et al., 2020, Chiba et al., 2022). This suggests that NetReplica is best understood not as one monolithic platform, but as a family resemblance among systems that make network conditions explicit in replica-related control logic.

Future directions stated or implied across the papers are correspondingly broad. The NetReplica ML paper points toward better hybrid models for cross-traffic, extension to wireless and access technologies, and larger-scale deployment on platforms such as FABRIC (Daneshamooz et al., 17 Jul 2025). The replica-management literature suggests online migration planning, richer telemetry, failure-aware transfer, multiple simultaneous migrations, hierarchical controllers, and tighter integration of placement and transfer decisions (Mseddi et al., 2015, Chiba et al., 2022). The consistency literature suggests tunable multi-model consistency, policy engines mapping SLAs to quorums and routing, and integrated auditing or verification layers (Campêlo et al., 2020).

In aggregate, NetReplica identifies a research program rather than a single method: represent the network explicitly, expose the right control knobs, and adapt replication or learning behavior to the part of the operating space that most strongly determines correctness, performance, or generalization.