pith. sign in

arxiv: 2604.27854 · v1 · submitted 2026-04-30 · 💻 cs.NI

NetSatBench: A Distributed LEO Constellation Emulator with an SRv6 Case Study

Andrea Detti , Shahram Dadras , Giuseppe Tropea This is my paper

Pith reviewed 2026-05-07 06:59 UTC · model grok-4.3

classification 💻 cs.NI
keywords LEO satellite emulationSRv6handover strategiesdistributed emulationVXLAN overlaysatellite constellationnetwork protocol testingtime-varying routing
0
0 comments X

The pith

NetSatBench emulates large LEO satellite constellations with distributed Linux containers to test protocols such as SRv6 under realistic handovers.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

NetSatBench runs satellites, gateways, and user terminals as Linux containers spread across a cluster of machines. Emulated links use a Layer-2 VXLAN overlay while an Etcd store and epoch files propagate changing link states and tasks to local control agents inside each container. Users define experiments through declarative JSON scenario files and a command-line interface instead of writing control code. The platform supports built-in IPv4 and IPv6 routing including IS-IS and ideal time-varying routing, with external plug-ins handling physical-layer and routing details. An SRv6 case study demonstrates protocol-level experiments under LEO motion and shows that handover policies must jointly consider the satellites serving both the user and the gateway to maintain stable data tunnels.

Core claim

NetSatBench is a distributed emulation platform for large-scale LEO systems in which satellites, gateways, and terminals are implemented as Linux containers on a cluster, with links realized through VXLAN overlays. System state is maintained in Etcd and updated via epoch files that propagate link and task changes to local agents. The platform decouples physical-layer and routing modeling from the core through external plug-ins while providing built-in IPv4/IPv6 routing including IS-IS and ideal time-varying routing. Rather than focusing on micro-performance, the work illustrates what the platform enables through an SRv6-based LEO architecture where control procedures manage data tunnels and,

What carries the argument

Distributed container emulation with VXLAN overlays and epoch-file state propagation from an Etcd store to model time-varying LEO link dynamics and routing.

If this is right

  • Protocol designers can experiment with SRv6 control procedures for data tunnels in time-varying LEO topologies.
  • End-to-end handover strategies that jointly account for user-serving and gateway-serving satellites are required to keep tunnels stable.
  • Declarative JSON scenario files enable flexible protocol and workload testing without custom control programs.
  • Plug-in support for routing and physical-layer models allows different LEO dynamics to be swapped into the same emulator core.
  • Built-in time-varying routing support facilitates studies of protocol behavior under realistic satellite motion.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The platform could shorten the cycle of designing and validating new LEO routing schemes before hardware deployment.
  • Distributed container techniques like those in NetSatBench might be applied to emulate other highly dynamic networks such as UAV swarms or vehicular meshes.
  • If emulation results match physical measurements, the tool could guide selection of handover algorithms for future constellation operators.
  • Adding support for full application workloads beyond SRv6 would allow direct assessment of user-experienced performance in LEO settings.

Load-bearing premise

The container-based emulation using Linux containers, VXLAN overlays, and epoch-file state propagation accurately models real LEO satellite link dynamics, handovers, and protocol behavior without introducing significant artifacts or fidelity gaps.

What would settle it

Running identical SRv6 handover scenarios on a physical LEO satellite testbed or real constellation trace and comparing measured latency, packet loss, and throughput against the emulation outputs.

Figures

Figures reproduced from arXiv: 2604.27854 by Andrea Detti, Giuseppe Tropea, Shahram Dadras.

Figure 1
Figure 1. Figure 1: RTT measurements between two users and the gateway in a OneWeb view at source ↗
Figure 2
Figure 2. Figure 2: Architecture of the NetSatBench emulator. view at source ↗
Figure 3
Figure 3. Figure 3: Experiment workflow common node configuration and IP auto-assignment "node-config-common": [ {"match-key": "type", "match-value": "satellite", "config-common": { "image": "msvcbench/sat-container:latest", "cpu-request": "100m", "mem-request": "100MiB", "L3-config": { "enable-routing": true, "routing-module": "extra.routing.isisv6", "auto-assign-ips": true, "auto-assign-super-cidr": [{ "match-key": "type","… view at source ↗
Figure 5
Figure 5. Figure 5: MATLAB visualization of emulated OneWeb-like system with 588 view at source ↗
Figure 4
Figure 4. Figure 4: Scenario-generation pipeline based on StarPerf and NetSatBench view at source ↗
Figure 6
Figure 6. Figure 6: SRv6-based LEO architecture. gateway user Registration Request [USSv6] Registration Accept [USSv6,GSSv6,Gv6] heartbeat, m-report heartbeat Handover Command [new USSv6, new GSSv6, Gv6] Handover Complete Periodic handover control default via SRv6 route [USSv6, GSSv6, Gv6] Uv6 via SRv6 route [GSSv6,USSv6,Uv6] default via SRv6 route [new USSv6, new GSSv6, Gv6] Uv6 via SRv6 route [new GSSv6, new USSv6, Uv6] view at source ↗
Figure 7
Figure 7. Figure 7: Control-plane message exchange. Table I END-TO-END POLICY FILTERS Filter Effect Minimum lifetime Discard any GSS–USS pair for which the remain￾ing visibility time of either the GSS or the USS is smaller than Tlt. Minimum orbit hops Retain only the GSS–USS satellite pairs with the minimum ISL hop count among all candidates. Max-min visibility Define the visibility of a GSS–USS pair as the minimum of the rem… view at source ↗
Figure 8
Figure 8. Figure 8: RTT measurements between users 1,7 and the gateway 5 in a OneWeb view at source ↗
Figure 9
Figure 9. Figure 9: RTT measurements between a user and the gateway in a OneWeb-like view at source ↗
Figure 10
Figure 10. Figure 10: TCP-cubic bitrate between user 1 and the gateway 5 in a OneWeb view at source ↗
read the original abstract

NetSatBench is a distributed emulation platform for evaluating communication protocols and application workloads over large-scale LEO satellite systems. Satellites, gateways, and user terminals are implemented as Linux containers distributed across a cluster of bare-metal or virtual machines, while emulated links are realized through a Layer-2 VXLAN overlay. The system state is maintained in an Etcd key-value store and updated through epoch files, which propagate link and task changes to local control agents running inside the emulated nodes. In contrast to library-oriented tools that require users to write control programs, NetSatBench adopts a higher-level declarative workflow based on JSON "scenario files" and a command-line interface. The platform decouples physical-layer and routing modeling from the emulator core through external plug-ins, while providing built-in support for IPv4 and IPv6 routing, including IS-IS and ideal time-varying routing. Rather than focusing on emulator micro-performance alone, we illustrate what NetSatBench enables through an SRv6-based LEO architecture in which control procedures manage data tunnels between users and gateways under different handover policies. This case study shows how NetSatBench can support protocol-level experimentation under time-varying LEO dynamics and highlights the importance of end-to-end handover strategies that jointly account for the satellites serving both the user and the gateway.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

3 major / 2 minor

Summary. The paper presents NetSatBench, a distributed emulation platform for large-scale LEO satellite systems. Satellites, gateways, and user terminals are realized as Linux containers spread across a cluster, with emulated links provided by a Layer-2 VXLAN overlay. System state is kept in an Etcd store and disseminated via epoch files to local control agents. The platform uses declarative JSON scenario files and a CLI rather than library-based control programs, decouples physical-layer and routing models through external plug-ins, and supplies built-in IPv4/IPv6 routing including IS-IS and ideal time-varying routing. Utility is shown via an SRv6 case study that examines control procedures for data tunnels between users and gateways under alternative handover policies, stressing the need for end-to-end strategies that consider satellites serving both endpoints.

Significance. If the emulation fidelity can be established, NetSatBench would offer a practical, scalable tool for protocol and workload experimentation in dynamic LEO environments, lowering the barrier relative to library-oriented simulators and addressing a growing need as mega-constellations are deployed. The declarative workflow and plug-in architecture are positive design choices. The SRv6 case study usefully illustrates protocol-level issues such as joint user-gateway handover management. However, the current lack of any quantitative validation or performance data substantially weakens the manuscript's ability to demonstrate these benefits.

major comments (3)
  1. [SRv6 Case Study] SRv6 Case Study section: The case study describes control procedures for SRv6 tunnels under different handover policies and claims that the platform 'supports protocol-level experimentation under time-varying LEO dynamics,' yet supplies no quantitative results (handover latency, packet-loss statistics, throughput, routing convergence times, or any error analysis). Without such metrics the central claim that NetSatBench enables meaningful protocol evaluation cannot be assessed.
  2. [Emulation Architecture] Emulation Architecture description (container, VXLAN, and epoch-file sections): The manuscript asserts that the Linux-container + VXLAN + epoch-file architecture faithfully reproduces time-varying LEO link states and handovers. No side-by-side comparison against real LEO testbeds, hardware traces, or reference simulators (ns-3 satellite extensions, STK, or OMNeT++) is reported. Consequently, any observed SRv6 behavior could be an artifact of container scheduling jitter, VXLAN encapsulation overhead, or epoch-file propagation delay rather than genuine LEO dynamics.
  3. [Abstract] Abstract and platform overview: The abstract states that the platform 'illustrates what NetSatBench enables' through the SRv6 study, but the text contains neither performance numbers for the emulator itself nor any fidelity assessment. This absence is load-bearing for the claim that NetSatBench is a reliable distributed emulator for LEO protocol work.
minor comments (2)
  1. [State Management] Clarify the timing semantics and consistency model of epoch-file propagation in the state-management section; without explicit bounds on propagation delay it is difficult to judge how accurately time-varying link states are reproduced.
  2. [Introduction] Add a short related-work paragraph contrasting NetSatBench with existing satellite emulation efforts (e.g., ns-3 satellite modules or Mininet-based LEO testbeds) so readers can immediately see the claimed novelty of the declarative workflow and plug-in decoupling.

Simulated Author's Rebuttal

3 responses · 1 unresolved

We thank the referee for the constructive and detailed review. The comments correctly identify the need for quantitative support to substantiate the platform's claims. We have revised the manuscript to include micro-benchmarks of the emulator, quantitative results from the SRv6 case study, and an expanded discussion of fidelity limitations. Point-by-point responses are provided below.

read point-by-point responses

  1. Referee: [SRv6 Case Study] The case study describes control procedures for SRv6 tunnels under different handover policies and claims that the platform 'supports protocol-level experimentation under time-varying LEO dynamics,' yet supplies no quantitative results (handover latency, packet-loss statistics, throughput, routing convergence times, or any error analysis). Without such metrics the central claim that NetSatBench enables meaningful protocol evaluation cannot be assessed.

    Authors: We agree that quantitative metrics are necessary to evaluate the platform's utility for protocol work. The original case study focused on demonstrating the declarative scenario workflow and the conceptual need for joint user-gateway handover policies. In the revised manuscript we have added measured results from the emulator runs, including average handover latency, packet loss rates, and end-to-end throughput for each policy. These data were obtained by instrumenting the containers with standard Linux monitoring tools and are now presented in a new table and accompanying analysis. This addition directly addresses the concern while retaining the illustrative purpose of the section. revision: yes

  2. Referee: [Emulation Architecture] The manuscript asserts that the Linux-container + VXLAN + epoch-file architecture faithfully reproduces time-varying LEO link states and handovers. No side-by-side comparison against real LEO testbeds, hardware traces, or reference simulators (ns-3 satellite extensions, STK, or OMNeT++) is reported. Consequently, any observed SRv6 behavior could be an artifact of container scheduling jitter, VXLAN encapsulation overhead, or epoch-file propagation delay rather than genuine LEO dynamics.

    Authors: We acknowledge the absence of external validation. The revised manuscript now contains a new subsection on emulation fidelity that reports micro-benchmarks for epoch-file propagation delay, VXLAN encapsulation overhead, and container scheduling jitter under varying node counts. We also compare the built-in ideal time-varying routing against a simple analytical model of LEO link dynamics. However, a full side-by-side comparison with physical LEO testbeds or equivalent experiments in ns-3/STK is not included, as it would require resources and access beyond the scope of this study. We have added an explicit limitations paragraph discussing potential artifacts from the container and overlay approach. revision: partial

  3. Referee: [Abstract] The abstract states that the platform 'illustrates what NetSatBench enables' through the SRv6 study, but the text contains neither performance numbers for the emulator itself nor any fidelity assessment. This absence is load-bearing for the claim that NetSatBench is a reliable distributed emulator for LEO protocol work.

    Authors: We have revised the abstract to include a concise reference to the emulator's demonstrated scalability (hundreds of nodes across a cluster) and to the quantitative findings from the SRv6 case study, specifically the improvement in tunnel stability under joint handover policies. The main text now contains the performance numbers and fidelity discussion referenced in the responses to the other comments, and the abstract has been updated to point readers to these results. revision: yes

standing simulated objections not resolved
  • A comprehensive side-by-side empirical validation of emulation fidelity against a real LEO hardware testbed or equivalent large-scale runs in reference simulators such as ns-3 with satellite modules, due to the substantial additional infrastructure, datasets, and computational resources required.

Circularity Check

0 steps flagged

No circularity; purely descriptive system and case-study paper

full rationale

The manuscript presents NetSatBench as a container-based distributed emulator (Linux containers + VXLAN + Etcd + epoch files + declarative JSON scenarios) and demonstrates it via an SRv6 handover case study. No equations, derivations, predictions, fitted parameters, or load-bearing self-citations appear. All claims are architectural descriptions or qualitative observations about what the platform enables; none reduce by construction to their own inputs. The skeptic's concern about missing fidelity benchmarks is an evidence-strength issue, not a circularity issue. The derivation chain is empty, so the paper is self-contained.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The central claim rests on the fidelity of container virtualization for satellite emulation and the utility of the described SRv6 experiment; no free parameters or new entities are introduced.

axioms (1)
  • domain assumption Linux containers and VXLAN overlays can faithfully emulate satellite nodes, dynamic links, and handover events in LEO constellations
    This is the foundational premise for the entire emulation approach described in the abstract.

pith-pipeline@v0.9.0 · 5536 in / 1401 out tokens · 66440 ms · 2026-05-07T06:59:09.104047+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

25 extracted references · 25 canonical work pages

  1. [1]

    A multifaceted look at starlink performance,

    N. Mohan, A. E. Ferguson, H. Cech, R. Bose, P. R. Renatin, M. K. Marina, and J. Ott, “A multifaceted look at starlink performance,” in Proceedings of the ACM Web Conference 2024, 2024, pp. 2723–2734

    work page 2024

  2. [2]

    Leocc: Making internet congestion control robust to leo satellite dynamics,

    Z. Lai, Z. Li, Q. Wu, H. Li, J. Li, X. Xie, Y . Li, J. Liu, and J. Wu, “Leocc: Making internet congestion control robust to leo satellite dynamics,” in Proceedings of the ACM SIGCOMM 2025 Conference, 2025, pp. 129– 146

    work page 2025

  3. [3]

    SaTCP: Link-layer informed TCP adaptation for highly dynamic LEO satellite networks,

    X. Cao and X. Zhang, “SaTCP: Link-layer informed TCP adaptation for highly dynamic LEO satellite networks,” inProceedings of the IEEE INFOCOM 2023 - IEEE Conference on Computer Communications. IEEE, May 2023, pp. 1–10

    work page 2023

  4. [4]

    Spacecloud cloud computing and in-orbit demonstration,

    O. Flordal, A. Synodinos, M. Herlitz, H. Magnusson, D. Steenari, K. F¨orster, M. Castorina, T. George, I. Troxel, S. Reid, C. Brunskill, and F. Bruhn, “Spacecloud cloud computing and in-orbit demonstration,” Jun. 2021. [Online]. Available: https://doi.org/10.5281/zenodo.5522872

    work page doi:10.5281/zenodo.5522872 2021

  5. [5]

    From emerging leo satellite constellations to the space cloud: Emulation platforms and orchestration methods,

    C. R. Milla, F. Patrone, J. A. Fraire, and M. Marchese, “From emerging leo satellite constellations to the space cloud: Emulation platforms and orchestration methods,”Computer Networks, p. 111970, 2026

    work page 2026

  6. [6]

    OpenSN: An open source library for emulating LEO satellite networks,

    W. Lu, Z. Wang, H. Zhang, S. Zhang, and H. Luo, “OpenSN: An open source library for emulating LEO satellite networks,”IEEE Transactions on Parallel and Distributed Systems, vol. 36, no. 8, pp. 1574–1590, 2025

    work page 2025

  7. [7]

    StarryNet: Empowering researchers to evaluate futuristic integrated space and terrestrial networks,

    Z. Lai, H. Li, Y . Deng, Q. Wu, J. Liu, Y . Li, J. Li, L. Liu, W. Liu, and J. Wu, “StarryNet: Empowering researchers to evaluate futuristic integrated space and terrestrial networks,” inProceedings of the 20th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’23). Boston, MA: USENIX Association, April 2023, pp. 1309–1324. [Online]. Av...

    work page 2023

  8. [8]

    [Online]

    NetSatBench GitHub website. [Online]. Available: https://github.com/ mSvcBench/NetSatBench

    work page

  9. [9]

    A transport protocol’s view of starlink,

    G. Huston, “A transport protocol’s view of starlink,” https://blog.apnic. net/2024/05/17/a-transport-protocols-view-of-starlink/, May 2024, aP- NIC Blog, accessed April 29, 2026

    work page 2024

  10. [10]

    A fast and high quality multilevel scheme for partitioning irregular graphs,

    G. Karypis and V . Kumar, “A fast and high quality multilevel scheme for partitioning irregular graphs,”SIAM Journal on Scientific Computing, vol. 20, no. 1, pp. 359–392, 1998

    work page 1998

  11. [11]

    Satellite constellations,

    J. G. Walker, “Satellite constellations,”Journal of the British Interplan- etary Society, vol. 37, p. 559, 1984

    work page 1984

  12. [12]

    Segment routing: A com- prehensive survey of research activities, standardization efforts, and implementation results,

    P. L. Ventre, S. Salsano, M. Polverini, A. Cianfrani, A. Abdelsalam, C. Filsfils, P. Camarillo, and F. Clad, “Segment routing: A com- prehensive survey of research activities, standardization efforts, and implementation results,”IEEE Communications Surveys & Tutorials, vol. 23, no. 1, pp. 182–221, 2020

    work page 2020

  13. [13]

    Load-balancing routing algorithm based on segment routing for traffic return in leo satellite networks,

    W. Liu, Y . Tao, and L. Liu, “Load-balancing routing algorithm based on segment routing for traffic return in leo satellite networks,”IEEE Access, vol. 7, pp. 118 044–118 058, 2019

    work page 2019

  14. [14]

    Srv6-enabled routing optimization in leo satellite networks: A reinforcement learning ap- proach,

    C. He, H. Sun, Z. Bian, Y . Zhang, and M. Yao, “Srv6-enabled routing optimization in leo satellite networks: A reinforcement learning ap- proach,” in2025 IEEE 25th International Conference on Communication Technology (ICCT). IEEE, 2025, pp. 1–9

    work page 2025

  15. [15]

    Source routing for leo mega-constellations based on bloom filter,

    H. Zhang, Z. Wang, W. Lu, S. Zhang, and H. Luo, “Source routing for leo mega-constellations based on bloom filter,”IEEE Transactions on Mobile Computing, 2025

    work page 2025

  16. [16]

    Handover protocol learning for leo satellite networks: Access delay and collision minimiza- tion,

    J.-H. Lee, C. Park, S. Park, and A. F. Molisch, “Handover protocol learning for leo satellite networks: Access delay and collision minimiza- tion,”IEEE Transactions on Wireless Communications, vol. 23, no. 7, pp. 7624–7637, 2023

    work page 2023

  17. [17]

    Seamless handover in leo-based non-terrestrial networks: Service continuity and optimization,

    F. Wang, D. Jiang, Z. Wang, J. Chen, and T. Q. S. Quek, “Seamless handover in leo-based non-terrestrial networks: Service continuity and optimization,”IEEE Transactions on Communications, vol. 71, no. 2, pp. 1008–1023, 2023

    work page 2023

  18. [18]

    Handover strategy for leo satellite networks using bipartite graph and hysteresis margin,

    S. Eydian, M. Hosseini, and G. Karabulut Kurt, “Handover strategy for leo satellite networks using bipartite graph and hysteresis margin,”IEEE Open Journal of the Communications Society, vol. 6, pp. 1470–1484, 2025

    work page 2025

  19. [19]

    Handover strategies for emerging leo, meo, and heo satellite networks,

    A. M. V oicu, A. Bhattacharya, and M. Petrova, “Handover strategies for emerging leo, meo, and heo satellite networks,”IEEE Access, vol. 12, pp. 31 523–31 537, 2024. 12 Table III COMPARISON OFLEONETWORK CONTAINER-BASED DISTRIBUTED EMULATION PLATFORMS Feature StarryNet OpenSN NetSatBench Link creation speed Moderate; per-linkveth, VLAN, and bridge setup Ve...

    work page 2024

  20. [20]

    A com- parative evaluation of tcp congestion control schemes over low-earth- orbit (leo) satellite networks,

    G. Barbosa, S. Theeranantachai, B. Zhang, and L. Zhang, “A com- parative evaluation of tcp congestion control schemes over low-earth- orbit (leo) satellite networks,” inProceedings of the 18th Asian Internet Engineering Conference, 2023, pp. 105–112

    work page 2023

  21. [21]

    Tcp congestion control per- formance over starlink,

    J. Garcia, S. Sundberg, and A. Brunstrom, “Tcp congestion control per- formance over starlink,” inProceedings of the 2025 Applied Networking Research Workshop, 2025, pp. 70–77

    work page 2025

  22. [22]

    Celestial: Virtual software system testbeds for the LEO edge,

    T. Pfandzelter and D. Bermbach, “Celestial: Virtual software system testbeds for the LEO edge,” inProceedings of the 23rd ACM/IFIP International Middleware Conference (Middleware ’22). Quebec, QC, Canada: ACM, November 2022, pp. 298–311

    work page 2022

  23. [23]

    Link-identified routing architecture in space,

    H. Zhang, Z. Wang, S. Zhang, Q. Meng, and H. Luo, “Link-identified routing architecture in space,”IEEE Transactions on Network Science and Engineering, vol. 12, no. 1, pp. 392–408, 2024

    work page 2024

  24. [24]

    Fast reroute algorithms for satellite network with segment routing,

    X. Chen, Z. Chen, X. Chang, T. Ji, Z. Wu, and C. Li, “Fast reroute algorithms for satellite network with segment routing,”IEEE Access, vol. 11, pp. 133 509–133 520, 2023

    work page 2023

  25. [25]

    Intent-driven segment rout- ing design for large-scale leo satellite networks,

    S. Mao, Y . Ouyang, C. Yang, and Z. Wang, “Intent-driven segment rout- ing design for large-scale leo satellite networks,” in2025 International Wireless Communications and Mobile Computing (IWCMC), 2025, pp. 138–143

    work page 2025