Pith. sign in

REVIEW 3 major objections 5 minor 39 references

DCSim: Computing and Networking Integration based Container Scheduling Simulator for Data Centers

T0 review · 3 major / 5 minor · reviewed 2026-08-12 · deepseek-v4-flash

Pith's one-line read DCSim couples Mininet network emulation with SimPy event simulation so container scheduling experiments respond to live network dynamics.

desk verdict A credible simulator integration whose central claim is undercut by a missing definition of how Mininet wall-clock traffic becomes SimPy event time—the network-aware scheduling results are not interpretable as simulation results until that mapping is specified. read the letter →

arxiv 2411.13809 v1 pith:EZ4XKTFB submitted 2024-11-21 cs.DC

classification cs.DC
keywords containerschedulingdatacentersimulatornetwork-awareMininetSimPydiscreteeventsimulationheterogeneouscomputingsoftware-definednetworking
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

DCSim is a container scheduling simulator for data centers that couples two existing tools: Mininet, a software-defined network emulator, and SimPy, a discrete-event simulation library. The paper's claim is that this coupling gives scheduling experiments a network that actually responds to topology, bandwidth, and packet loss, instead of the static bandwidth values used by most prior simulators. If that claim holds, researchers can compare container scheduling algorithms on the basis of average running time, communication time, and total cost under realistic congestion conditions, and can plug in their own scheduling strategies through the simulator's selection, placement, and execution interfaces. The paper's evidence consists of functional tests showing the modules work together and performance measurements showing the cost of Mininet emulation grows with node count.

What carries the argument

The load-bearing mechanism is the pairing of SimPy's discrete-event processes with Mininet's live network emulation. Each container's life cycle is a SimPy process—request, schedule, run, communicate, migrate, complete—and each host in the data center module gets a corresponding Mininet host node. A delay_matrix, a two-dimensional table of current latencies between all host nodes built by running ping between every pair of hosts and periodically refreshed, supplies current latency, while per-node iperf servers carry the actual traffic of container communications and migrations. The time those iperf transfers take feeds back into the container's communication time, so network conditions directly change scheduling outcomes rather than being read from a fixed table.

What would settle it

Run the same workload and the same built-in scheduling algorithms on a small physical cluster or on an independent network simulator, then compare per-container communication times and the final algorithm ranking; if the ranking changes once the network is modeled differently, the claim that DCSim's network layer improves scheduling evaluation is not supported.

Watch

Extended reading notes

Core claim

On its own terms, DCSim is a simulator that makes network state a first-class input to container scheduling. It models hosts with CPU, memory, and GPU (FLOPS) capacities; represents workloads as a job-task-container hierarchy; and uses Mininet links with configured bandwidth, latency, and loss. The reported experiments show that average container communication time rises as packet loss increases or bandwidth falls across the tested scheduling algorithms, and that the ranking of algorithms (JobGroup lowest, Round highest) is maintained and sharpened under those conditions. The authors take this as evidence that the simulator can reproduce the network-collaborative scheduling pressure that motivates computing-and-networking integration.

Load-bearing premise

The approach assumes that the latencies and transfer times produced by Mininet's emulated hosts faithfully represent how containers would communicate in a real data center network.

Editorial extensions

If this is right

  • A scheduling algorithm that groups dependent containers on the same host (JobGroup) yields the lowest average container running time, while a round-robin spread (Round) yields the highest, with the gap growing as packet loss increases.
  • Reducing link bandwidth or raising packet loss increases average container communication time under every tested scheduling algorithm, so network conditions should be part of the evaluation of scheduling strategies.
  • Network initialization time in DCSim grows linearly with node count (about 0.8 seconds per node), and memory use roughly doubles with node count; simulating 1,000 network nodes used an average of 1,342 MB.
  • The simulator exposes selection, placement, and execution interfaces, so the same infrastructure can be used to benchmark new or customized scheduling policies against the built-in heuristics.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Editorial inference: the same delay_matrix could be exposed as a live feature to learning-based schedulers, so a trained policy sees congestion exactly as the simulator does.
  • Editorial inference: because each Mininet node is a Linux process, the simulator's scale is bounded; a hybrid mode that emulates only the communication-heavy fraction of containers while accounting for the rest statistically would be a natural extension.
  • Editorial inference: if network-aware rankings from DCSim are validated against a physical testbed, the same architecture could be reused for edge-cloud or wide-area scheduling, where link dynamics matter even more.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper presents DCSim, a container scheduling simulator for data centers that integrates the SimPy discrete-event simulation library with Mininet-based network emulation. The system comprises five modules (data center, network simulation, container scheduling, discrete event driver, and data collection/analysis) and models heterogeneous hosts (CPU and GPU), a three-level Job/Task/Container workload model, and dynamic network behavior via ping-based delay matrices and iperf-based traffic simulation. The authors implement five basic scheduling algorithms (OverloadMigrate, FirstFit, Round, PerformanceFirst, JobGroup) and evaluate the simulator through functional tests (queue dynamics, communication time under varying link loss/bandwidth, scheduling decisions) and performance scaling tests up to 1000 network nodes. The central claim is that DCSim offers more faithful network-aware container scheduling simulation than static-bandwidth simulators by exposing dynamic latency and traffic to scheduling decisions.

Significance. If the central claims are substantiated, DCSim would fill a real gap: most container scheduling simulators model network with static bandwidth or ignore it, while DCSim attempts to couple discrete-event scheduling with emulated network dynamics. The modular design and the inclusion of five baseline scheduling algorithms make the system potentially useful for researchers developing communication-aware scheduling policies. However, the paper's evidence is currently limited to self-consistency checks: the simulator measures its own Mininet traffic and demonstrates that network parameters affect its own outputs. There is no external validation against a real cluster, a reference simulator, or a trace-driven ground truth, and the mapping from Mininet wall-clock measurements to SimPy event time is never defined. Thus the advertised advantage over static-bandwidth models is not yet established. The performance scaling results are useful as a rough resource-usage characterization, but they are not a substitute for validation of the simulation semantics.

major comments (3)
  1. [Section 3.4 and Section 3.6] The paper never specifies how the wall-clock results of Mininet ping and iperf commands are mapped to SimPy simulation time or to the duration of a container communication event. Section 3.4 states that communication is simulated through network nodes and that network traffic transmission is simulated via iperf, and Section 3.6 lists a periodic update_delay_matrix process, but no formula or algorithm is given for converting measured latency or throughput into an event duration. Without this mapping, Figures 5 and 8, which rank scheduling algorithms based on average communication time and average container running time, are uninterpretable as simulation results; they could reflect real-time emulation wall-clock time or an unspecified internal model. This is an internal correctness gap that must be closed.
  2. [Section 4.1.2 and Section 4.1.3] The validation is entirely self-referential. The paper's main demonstration that network configuration affects scheduling outcomes relies on DCSim's own Mininet measurements (Figures 5 and 8), with no comparison against a real data center cluster, a trace-driven ground truth, or a reference network simulator. Consequently, the central claim that DCSim provides 'authentic' dynamic network modeling (stated in Sections 1 and 3.4) is not established. The authors should provide at least one of: (a) a comparison of DCSim's communication times against a real cluster or Mininet-alone measurements, (b) a comparison against a known simulator such as NS-3 or CloudSim with an equivalent network model, or (c) a direct argument and calibration experiment showing that Mininet's emulation of TCP/latency is representative for the intended scheduling studies.
  3. [Section 3.3] The container runtime model increments run_at by the host CPU speed each second, implying that execution time decreases linearly with host CPU speed and is otherwise independent of other host characteristics, load, or interference. This ad-hoc assumption directly drives the scheduling algorithm rankings reported in Sections 4.1.2 and 4.1.3. The paper provides no empirical justification or sensitivity analysis for this model. Since the conclusions about scheduler performance depend on it, the authors should either validate the linear-scaling assumption with measurements or show that the qualitative conclusions are robust to plausible deviations from it.
minor comments (5)
  1. [Equation (1)] Equation (1) is not properly rendered: it contains '???' placeholders for the matrix entries, making the definition of the delay_matrix incomplete. Please write the equation explicitly with indexed elements.
  2. [Section 4.1.2 and Section 5] The text 'Reason: Improved clarity, vocabulary, and technical accuracy while maintaining the original meaning.' appears at the end of Section 4.1.2 and again after Section 5. This is an editing artifact and should be removed.
  3. [Table 6] Table 6 lists parameters such as 'Iperf failed retransmission count' and 'Congestion determination threshold' that are never described in the module design (Sections 3.3-3.6). Please clarify how these parameters are used in the simulator.
  4. [Introduction and Table 1] Mininet is described as a 'network simulation tool' and DCSim as providing 'packet-level network modeling,' but Mininet is an emulator that runs real Linux networking rather than a packet-level discrete-event simulator. The terminology should be corrected to 'emulation' and 'packet-level emulation' to avoid misrepresenting the simulation semantics.
  5. [Figure 6 caption] The captions for Figures 4(b)-(d) all read 'Number of containers in deployed queue,' while the surrounding text refers to running, waiting, and completing queues. The captions appear inconsistent with the data being plotted and should be corrected.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: DCSim integrates Mininet and SimPy without fitting parameters or importing load-bearing claims from the authors' prior work.

full rationale

DCSim is an engineering/systems paper that describes a simulator and tests its modules. The load-bearing derivation chain would be circular if, e.g., the network communication time used to rank scheduling algorithms were fitted from the same scheduling outcomes, or if the claimed packet-level modeling were justified by an unverified self-citation. No such reduction appears. The network module independently uses Mininet's ping and iperf to generate delay and traffic, while SimPy drives scheduling events; communication times are then fed into container runtime. Figure 5 and Figure 8 show that changes in Mininet's configured link loss/bandwidth change measured communication/runtime, which is a self-consistency check of the integration, not a derivation of a predicted quantity from an equivalent input. There are no fitted parameters, no author self-citations carrying uniqueness arguments, and no ansatz smuggled in via citation. The absence of validation against a real cluster or an established network simulator is an external-evidence/correctness limitation, not circularity, and per the hard rules it does not raise the circularity score. The performance measurements in Section 4.2 are direct resource-use observations, not circular predictions. Thus the paper is self-contained with respect to the circularity criteria.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

The ledger is small because the paper is an engineering report rather than a derivation: there are no fitted constants and no invented physical entities. The load-bearing assumptions are the fidelity of Mininet-based network emulation and the linear container runtime model; both are stated but not externally calibrated.

assumptions (3)
  • domain assumption Mininet emulation of the data center network is faithful enough: ping round-trip times and iperf throughput on emulated hosts represent real container communication times.
    Invoked throughout Section 3.4 and used to draw conclusions in Figures 5 and 8; no comparison to a real cluster or to an established packet-level simulator is provided.
  • ad hoc to paper Container execution time scales linearly with host CPU speed and resource request, with run_at incrementing by the host's CPU speed each second.
    Section 3.3 defines the runtime model based on container_type and host processing speed; this model is untested against real container runtimes and can dominate scheduling comparisons.
  • domain assumption A one-second discrete event granularity is sufficient to represent container scheduling, communication, and migration dynamics.
    Simulation control, container generation, dispatch, and statistics processes run once per second as shown in Table 3; the effect of this discretization on measured metrics is never quantified.

how reviews work

0 comments
Cite this review

Pith. "Pith review of DCSim: Computing and Networking Integration based Container Scheduling Simulator for Data Centers." pith.science (2026). https://pith.science/paper/EZ4XKTFB

@misc{pith2026241113809,
  author       = {Pith},
  title        = {Pith review of: DCSim: Computing and Networking Integration based Container Scheduling Simulator for Data Centers},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/EZ4XKTFB}},
  note         = {Machine review of arXiv:2411.13809}
}
read the original abstract

The increasing prevalence of cloud-native technologies, particularly containers, has led to the widespread adoption of containerized deployments in data centers. The advancement of deep neural network models has increased the demand for container-based distributed model training and inference, where frequent data transmission among nodes has emerged as a significant performance bottleneck. However, traditional container scheduling simulators often overlook the influence of network modeling on the efficiency of container scheduling, primarily concentrating on modeling computational resources. In this paper, we focus on a container scheduling simulator based on collaboration between computing and networking within data centers. We propose a new container scheduling simulator for data centers, named DCSim. The simulator consists of several modules: a data center module, a network simulation module, a container scheduling module, a discrete event-driven module, and a data collection and analysis module. Together, these modules provide heterogeneous computing power modeling and dynamic network simulation capabilities. We design a discrete event model using SimPy to represent various aspects of container processing, including container requests, scheduling, execution, pauses, communication, migration, and termination within data centers. Among these, lightweight virtualization technology based on Mininet is employed to construct a software-defined network. An experimental environment for container scheduling simulation was established, and functional and performance tests were conducted on the simulator to validate its scheduling simulation capabilities.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

39 extracted references · 37 canonical work pages

  1. [1]

    Scheduling frameworks for cloud container services

    Zhou R, Li Z, Wu C. Scheduling frameworks for cloud container services. IEEE/acm transactions on networking, IEEE, 2018, 26(1): 436–450

  2. [2]

    Building a cloud on earth: A study of cloud computing data center simulators

    Sharkh M A, Kanso A, Shami A, et al. Building a cloud on earth: A study of cloud computing data center simulators. Computer Networks, Elsevier, 2016, 108: 78–96

  3. [3]

    ContainerCloudSim: An environment for modeling and simulation of containers in cloud data centers

    Piraghaj S F, Dastjerdi A V, Calheiros R N, et al. ContainerCloudSim: An environment for modeling and simulation of containers in cloud data centers. Software: Practice and Experience, 2017, 47(4): 505–521. 19

  4. [4]

    Cloudanalyst: A cloudsim-based visual modeller for analysing cloud computing environments and applications

    Wickremasinghe B, Calheiros R N, Buyya R. Cloudanalyst: A cloudsim-based visual modeller for analysing cloud computing environments and applications. 2010 24th IEEE international conference on advanced information networking and applications. IEEE, 2010: 446–452

  5. [5]

    Gdcsim: A tool for analyzing green data center design and resource management techniques

    Gupta S K, Gilbert R R, Banerjee A, et al. Gdcsim: A tool for analyzing green data center design and resource management techniques. 2011 International Green Computing Conference and Workshops. IEEE, 2011: 1–8

  6. [6]

    GroudSim: An Event-Based Simulation Framework for Computational Grids and Clouds

    Ostermann S, Plankensteiner K, Prodan R, et al. GroudSim: An Event-Based Simulation Framework for Computational Grids and Clouds. M.R. Guarracino, F. Vivien, J.L. Träff, et al. Euro-Par 2010 Parallel Processing Workshops. Berlin, Heidelberg: Springer Berlin Heidelberg, 2011, 6586: 305–313

  7. [7]

    EdgeCloudSim: An environment for performance evaluation of edge computing systems

    Sonmez C, Ozgovde A, Ersoy C. EdgeCloudSim: An environment for performance evaluation of edge computing systems. Transactions on Emerging Telecommunications Technologies, 2018, 29(11): e3493

  8. [8]

    An automated implementation of hybrid cloud for performance evaluation of distributed databases

    Mansouri Y, Prokhorenko V, Babar M A. An automated implementation of hybrid cloud for performance evaluation of distributed databases. Journal of Network and Computer Applications, 2020, 167: 102740

Show all 39 references
  1. [9]

    Communication Efficient Distributed Machine Learning with the Parameter Server

    Li M, Andersen D G, Smola A J, et al. Communication Efficient Distributed Machine Learning with the Parameter Server. Advances in Neural Information Processing Systems. Curran Associates, Inc., 2014, 27

  2. [10]

    Scaling Distributed Machine Learning with the Parameter Server

    Li M, Andersen D G, Park J W, et al. Scaling Distributed Machine Learning with the Parameter Server. 2014: 583–598

  3. [11]

    QoS-Aware Orchestration of Network Intensive Software Utilities within Software Defined Data Centres: An Architecture and Implementation of a Global Cluster Manager

    Paščinski U, Trnkoczy J, Stankovski V, et al. QoS-Aware Orchestration of Network Intensive Software Utilities within Software Defined Data Centres: An Architecture and Implementation of a Global Cluster Manager. Journal of Grid Computing, 2018, 16(1): 85–112

  4. [12]

    /2024-04-05

    GitHub - mininet/mininet: Emulator for rapid prototyping of Software Defined Networks. /2024-04-05. https://github.com/mininet/mininet

  5. [13]

    Introduction to Network Simulator 2 (NS2)

    Issariyakul T, Hossain E. Introduction to Network Simulator 2 (NS2). Introduction to Network Simulator NS2. Boston, MA: Springer US, 2009: 1–18

  6. [14]

    /2024-04-06

    Documentation | ns-3. /2024-04-06. https://www.nsnam.org/documentation/

  7. [15]

    /2024-04-05

    Overview - SimPy 4.1.1 documentation. /2024-04-05. https://simpy.readthedocs.io/en/latest/

  8. [16]

    /2024-04-05

    clusterdata/cluster-trace-gpu-v2020 at master · alibaba/clusterdata · GitHub. /2024-04-05. https://github.com/alibaba/clusterdata/tree/master/cluster-trace-gpu-v2020

  9. [17]

    Compute first networking: Distributed computing meets ICN, Proceedings of the 6th ACM Conference on Information-Centric Networking

    Król M, Mastorakis S, Oran D, et al. Compute first networking: Distributed computing meets ICN, Proceedings of the 6th ACM Conference on Information-Centric Networking. 2019: 67-77

  10. [18]

    A Survey of Compute First Networking, 2023 IEEE 23rd International Conference on Communication Technology (ICCT)

    Gong X, Bai C, Ren S, et al. A Survey of Compute First Networking, 2023 IEEE 23rd International Conference on Communication Technology (ICCT). IEEE, 2023: 688-695

  11. [19]

    Reproducible network experiments using container-based emulation

    Handigol N, Heller B, Jeyakumar V, et al. Reproducible network experiments using container-based emulation. Proceedings of the 8th international conference on Emerging networking experiments and technologies. Nice France: ACM, 2012: 253–264

  12. [20]

    CloudSim: a toolkit for modeling and simulation of cloud computing environments and evaluation of resource provisioning algorithms

    Calheiros R N, Ranjan R, Beloglazov A, et al. CloudSim: a toolkit for modeling and simulation of cloud computing environments and evaluation of resource provisioning algorithms. Software: Practice and Experience, 2011, 41(1): 23–50

  13. [21]

    Mallet F. SimJava. School of Informatics, The University of Edinburgh/2024-04-05. https://www.icsa.inf.ed.ac.uk/research/groups/hase/simjava/. 20

  14. [22]

    BRITE: An approach to universal topology generation

    Medina A, Lakhina A, Matta I, et al. BRITE: An approach to universal topology generation. MASCOTS 2001, Proceedings Ninth International Symposium on Modeling, Analysis and Simulation of Computer and Telecommunication Systems. IEEE, 2001: 346–353

  15. [23]

    Toward scalable cloud data center simulation using high‐level architecture

    Elahi B, Malik A W, Rahman A U, et al. Toward scalable cloud data center simulation using high‐level architecture. Software: Practice and Experience, 2020, 50(6): 827–843

  16. [24]

    Networkcloudsim: Modelling parallel applications in cloud simulations

    Garg S K, Buyya R. Networkcloudsim: Modelling parallel applications in cloud simulations. 2011 Fourth IEEE International Conference on Utility and Cloud Computing. IEEE, 2011: 105–113

  17. [25]

    GreenCloud: a packet-level simulator of energy-aware cloud computing data centers

    Kliazovich D, Bouvry P, Khan S U. GreenCloud: a packet-level simulator of energy-aware cloud computing data centers. The Journal of Supercomputing, 2012, 62(3): 1263–1283

  18. [26]

    iCanCloud: A Flexible and Scalable Cloud Infrastructure Simulator

    Núñez A, Vázquez-Poletti J L, Caminero A C, et al. iCanCloud: A Flexible and Scalable Cloud Infrastructure Simulator. Journal of Grid Computing, 2012, 10(1): 185–209

  19. [27]

    TeachCloud: a cloud computing educational toolkit

    Jararweh Y, Alshara Z, Jarrah M, et al. TeachCloud: a cloud computing educational toolkit. International Journal of Cloud Computing, 2013, 2(2/3): 237

  20. [28]

    COSCO: Container orchestration using co-simulation and gradient based optimization for fog computing environments

    Tuli S, Poojara S R, Srirama S N, et al. COSCO: Container orchestration using co-simulation and gradient based optimization for fog computing environments. IEEE Transactions on Parallel and Distributed Systems, IEEE, 2021, 33(1): 101–116

  21. [29]

    DeepJS: Job Scheduling Based on Deep Reinforcement Learning in Cloud Data Center

    Li F, Hu B. DeepJS: Job Scheduling Based on Deep Reinforcement Learning in Cloud Data Center. Proceedings of the 2019 4th International Conference on Big Data and Computing - ICBDC 2019. Guangzhou, China: ACM Press, 2019: 48–53

  22. [30]

    TensorFlow: a system for Large-Scale machine learning

    Abadi M, Barham P, Chen J, et al. TensorFlow: a system for Large-Scale machine learning. 12th USENIX symposium on operating systems design and implementation (OSDI 16). 2016: 265–283

  23. [31]

    Pytorch: An imperative style, high-performance deep learning library

    Paszke A, Gross S, Massa F, et al. Pytorch: An imperative style, high-performance deep learning library. Advances in neural information processing systems, 2019, 32

  24. [32]

    iFogSim: A toolkit for modeling and simulation of resource management techniques in the Internet of Things, Edge and Fog computing environments

    Gupta H, Vahid Dastjerdi A, Ghosh S K, et al. iFogSim: A toolkit for modeling and simulation of resource management techniques in the Internet of Things, Edge and Fog computing environments. Software: Practice and Experience, 2017, 47(9): 1275–1296

  25. [33]

    Network-aware container scheduling in multi-tenant data center

    Rodrigues L R, Pasin M, Alves O C, et al. Network-aware container scheduling in multi-tenant data center. 2019 IEEE Global Communications Conference (GLOBECOM). IEEE, 2019: 1–6

  26. [34]

    Diktyo: Network-aware scheduling in container-based clouds

    Santos J, Wang C, Wauters T, et al. Diktyo: Network-aware scheduling in container-based clouds. IEEE Transactions on Network and Service Management, IEEE, 2023

  27. [35]

    Draps: Dynamic and resource-aware placement scheme for docker containers in a heterogeneous cluster

    Mao Y, Oak J, Pompili A, et al. Draps: Dynamic and resource-aware placement scheme for docker containers in a heterogeneous cluster. 2017 IEEE 36th International Performance Computing and Communications Conference (IPCCC). IEEE, 2017: 1–8

  28. [36]

    First Fit bin packing: A tight analysis

    Dósa G, Sgall J. First Fit bin packing: A tight analysis. DROPS-IDN/v2/document/10.4230/LIPIcs.STACS.2013.538. Schloss Dagstuhl – Leibniz-Zentrum für Informatik, 2013

  29. [37]

    Docker Documentation

    Swarm mode overview. Docker Documentation. 2024-04-05. https://docs.docker.com/engine/swarm/

  30. [38]

    Communication-aware container placement and reassignment in large-scale internet data centers

    Lv L, Zhang Y, Li Y, et al. Communication-aware container placement and reassignment in large-scale internet data centers. IEEE Journal on Selected Areas in Communications, IEEE, 2019, 37(3): 540–555

  31. [39]

    Designing knowledge plane to optimize leaf and spine data center

    Sultan M, Imbuido D, Patel K, et al. Designing knowledge plane to optimize leaf and spine data center. 2020 IEEE 13th International Conference on Cloud Computing (CLOUD). 2020: 13–15

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.