The problem
Network monitoring provides telemetry, but an operational response also requires a model of the network, a way to issue commands, and evidence that the intended change took effect. DT4N brings these paths together in a controlled SDN testbed.
Why this matters to me
The technical objective was to build an inspectable Network Digital Twin: synchronize a Mininet / Ryu testbed with Eclipse Ditto, explore bounded what-if scenarios, and trace control actions through the returning network state.
My role
Project Lead for a UIT-supported undergraduate research project. I built the SDN testbed and synchronization layer, implemented the anomaly detector, and developed the closed-loop controller. The work also includes experiment scripts and archived evaluation artifacts.
Research Advisor
Dr. Huynh Van Dang
Faculty of Computer Networks and Communications, University of Information Technology, VNU-HCM
Technical approach
- Built a Mininet / Ryu SDN testbed and represented hosts and links as Eclipse Ditto Things.
- Implemented upward telemetry synchronization and a downward command path, verifying control actions through the returning network state.
- Added a detector trained on normal traffic, a bounded what-if model, and a controller that rate-limits a host identified as causing congestion.
- Preserved raw observations, model versions, evaluation criteria, and scripts for offline reproduction. The system also includes an AWS automation integration.
Results & current status
p95 upward synchronization delay, 30 trials; seed 20260915, 1 s collection period.
Controller OFF → ON, 32 trials in 8 blocks; seed 20260920. Mean difference 1.8514 Mbps, 95% CI [1.7729, 1.9122]; exact randomization p = 0.0078125.
Median absolute throughput error across 62 in-domain rate entries in a retrospective evaluation. Maximum 0.097 Mbps; entries are not independent trials.
Results from archived project experiments. Eight offline reproduction checks and 193 artifact integrity checks matched on 6 November 2026. These checks reprocess existing data; they are not new testbed measurements.
Limitations & open questions
- Experiments use a small, single-machine testbed. They do not establish performance on a production network.
- The detector caught 4/4 flood and bottleneck-shift incidents, but bandwidth-reduction detection was 0.40 against a target of 0.875. Maximum detection delay was about 20 s against a 3 s target.
- Zero false-alarm events were observed over approximately two normal-traffic hours; this does not imply a zero false-alarm rate. The stored one-sided 95% upper bound is about 1.50 events/hour.
- The controller throughput result has a possible ceiling effect noted in the stored analysis. The what-if model has an explicit operating region.
What I learned
DT4N connects observations, a network model, and control actions in one system. Evaluating that system raises a further question: how do the observations and response model affect the quality of the decision itself? This connects the engineering project to my ongoing State–Model–Regret research.
Explore the next research question →
Under the hood
Original architecture diagram from the DT4N repository. The diagram and source documentation describe the implemented system.