Yasin Engin · Future Networks
What should a network assume when stable reachability disappears?
I am studying designs where content names, long delay, intermittent contact, moving topology, and constrained links are normal conditions. The items below separate reading, implemented scaffolds, executed runs, and future work.
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.
Current study tracks
- NDN and ICNReading and scenario design around named content, Interest/Data exchange, forwarding strategies, and caching. No dedicated implementation repository is currently claimed.
- Delay-Tolerant NetworkingSix-node implementation scaffolds under a shared synthetic schedule, plus current ION-DTN work. A controlled cross-stack benchmark is still planned.
- LEO and NTN emulationNetSatBench setup, ION integration, orbital/link calculations, and selected retained runs. No general constellation-performance claim is made.
Project evidence
- NDN Simulation Study Plan
Reading notes and a planned ndnSIM workflow; no completed run is claimed. - NetSatBench and ION-DTN Laboratory Work
Implemented scaffolds, synchronized plans, and selected retained outputs with explicit evidence boundaries. - 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 claims are separated
| Layer | What it means on this site |
|---|---|
| Implemented | Linked code or configuration exists for the stated feature. |
| Executed | A retained output from a named run exists. |
| Checked | Output was compared with an explicit expectation, reference, or tolerance. |
| Studied / planned | A source informs the work or a future step is defined, but no execution result is claimed. |
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?