Yasin Engin · Future Networks
What should a network assume when stable reachability disappears?
My future-network work studies designs where content names, long delay, intermittent contact, moving topology, and constrained links are first-class conditions rather than rare exceptions.
One direction, three changes in assumption
Traditional Internet design is an essential baseline, but it is not the only useful starting point. NDN asks what changes when content names become central. DTN asks what changes when an end-to-end path may not exist at the time of sending. LEO/NTN systems ask what changes when topology, delay, and handover behavior are continuously shaped by orbital movement.
I am interested in the overlap: naming, routing, caching, contact planning, emulation, and distributed control. The goal is not to declare one architecture the replacement for another. It is to build enough experiment structure to compare behavior and understand tradeoffs.
The three experiment tracks
- NDN and ICNNamed content, Interest/Data exchange, forwarding strategies, in-network caching, NFD concepts, and ndnSIM-based scenarios.
- Delay-Tolerant NetworkingStore-carry-forward behavior, contact schedules, bundle implementations, and repeatable comparison across ION-DTN, uD3TN, HDTN, and DTN7-go.
- LEO and NTN emulationNetSatBench, distributed workers, Etcd state, VXLAN overlays, Linux tc/netem, routing checks, and measurable handover or path behavior.
Project evidence
- NDN Simulation Labs
ndnSIM, NS-3, NFD concepts, caching, forwarding, and scenario design. - DTN Implementation Labs
A shared six-node topology and contact schedule across multiple DTN stacks. - NetSatBench Lab Guide
A Turkish reproducible guide to distributed LEO network emulation. - Research Reading Library
Papers on LEO networking, NDN/ICN, orchestration, and the computing continuum.
How I separate research from implementation
| Layer | What it means on this site |
|---|---|
| Built | A repository, configuration, guide, or scenario exists and is linked from its case study. |
| Reproduced | An external system or paper workflow has been translated into repeatable lab steps. |
| Studied | The source is part of the research library and informs a question, but no implementation claim is made. |
| Planned | The case study names a future validation, metric, or scenario that is not presented as complete. |
Questions guiding the next experiments
- How do caching and forwarding choices change under moving or intermittently reachable paths?
- Which metrics make DTN implementation comparisons fair across the same contact plan?
- How should emulators expose handover, routing convergence, queueing, and loss without hiding timing assumptions?
- Where can information-centric or delay-tolerant ideas complement—not merely compete with—existing IP and satellite architectures?