{"id":"eee63d2e-c90a-40b4-80be-60ce676b69ae","arxiv_id":"2411.13809","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"DCSim integrates Mininet network emulation with SimPy discrete-event simulation to create a container scheduling simulator for network-aware data center research.","lead":"DCSim is a new simulator for testing how container scheduling algorithms perform in data centers, and it models both computing power and the network between machines. It combines the SimPy discrete-event engine with Mininet network emulation, and the authors demonstrate the simulator's modules with functional and performance tests.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"DCSim's network-emulation advantage depends on an unspecified mapping between Mininet wall-clock ping/iperf measurements and SimPy event time; without that mapping, the Section 4 scheduling rankings are not supported.","rationale":"The reader's weakest_assumption is external validity: no comparison of Mininet emulation against real clusters or ns-3. I agree that is a real gap, but I see a more immediate load-bearing problem inside the paper. The discrete-event simulator and the real-time emulator must share a time base. The paper describes ping/iperf as the source of network truth (Section 3.4) and SimPy processes for communication (Section 3.6), yet it never states how long a communication event lasts in simulated time or how iperf's real-time completion is converted. Without that conversion, the two possible implementations have opposite consequences: (i) if SimPy waits on real iperf, DCSim is not a simulator but an emulator whose runtime is proportional to simulated communication, making Section 4.2's simulation-time results mislabeled and limiting scale; (ii) if SimPy uses a model, the measured network behavior is disconnected from the scheduler unless a specified conversion exists. In both cases, the algorithm rankings in Figures 5 and 8 cannot be attributed to dynamic network fidelity. I therefore set agreement_with_reader=partial: the missing validation is downstream of this time-model ambiguity. The proposed concrete test distinguishes these cases without requiring a testbed. If the authors provide the code and the conversion is explicit, then the remaining issue is exactly the external validation the reader conditions on; so the verdict stays CONDITIONAL (UNCHANGED). The critique is structural and specification-focused, not an attack on the authors.","tokens_in":12034,"tokens_out":5600,"duration_ms":55349,"concrete_test":"Obtain the simulator source and instrument a single container communication event: log the SimPy event start/end times and the wall-clock start/end of the corresponding iperf subprocess in Section 3.4. Then rerun the same 100-container workload with container runtimes scaled 10x. If wall-clock duration grows in lockstep with simulated duration (or iperf blocks the SimPy event loop), the simulator is real-time and the discrete-event claim fails; if not, report the exact conversion formula and verify that the Section 4.2 simulation-time curve is reproducible under that formula.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is that DCSim improves on static-bandwidth schedulers by exposing dynamic network state to scheduling (Abstract, Section 1). The mechanism in Section 3.4: Mininet hosts run ping to fill the delay_matrix and iperf to move container traffic; Section 3.6 schedules update_delay_matrix as a process. What is never defined is how wall-clock results from these Linux processes become SimPy simulated time. If a communication event's duration is the wall-clock time of a real iperf transfer, then the 'simulation' is a real-time emulation: simulated time advances at wall-clock speed during communication, and the Section 4.2 scaling results mostly measure process overhead, not a discrete-event model. If instead communication durations are computed from delay_matrix or a formula, the paper does not show that formula, and the measured iperf behavior is not load-bearing for scheduling. Either way, Figures 5 and 8, which rank JobGroup and Round under loss/bandwidth changes, are not interpretable. This is an internal correctness gap, not just missing external validation; it must be closed before the simulator's advertised advantage is established.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":12272,"tokens_out":4152,"duration_ms":37482,"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":[{"comment":"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.","section":"Section 3.4 and Section 3.6"},{"comment":"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.","section":"Section 4.1.2 and Section 4.1.3"},{"comment":"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.","section":"Section 3.3"}],"minor_comments":[{"comment":"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.","section":"Equation (1)"},{"comment":"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.","section":"Section 4.1.2 and Section 5"},{"comment":"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.","section":"Table 6"},{"comment":"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.","section":"Introduction and Table 1"},{"comment":"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.","section":"Figure 6 caption"}],"recommendation":"major_revision","confidential_remarks":"The manuscript contains several signs of insufficient proofreading (broken equation, repeated 'Reason: Improved clarity...' text, inconsistent figure captions) that should be addressed in revision. Additionally, the authors do not mention a public code repository; for a simulator paper, releasing the code would substantially strengthen reproducibility and trust in the functional claims."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: DCSim is a clean integration of Mininet and SimPy for container-scheduling simulation, and the paper is honest about what it built and tested. Its central promise—that dynamic network state changes scheduling outcomes—is undercut by a missing definition of how real iperf/ping measurements become SimPy event time.\n\nWhat's genuinely new: the three-tier job/task/container model with heterogeneous CPU/GPU FLOPS resources, the five modular components, and the five baseline scheduling algorithms. Table 1's comparison is a useful map of the simulator landscape. The functional tests show the modules actually execute and produce plausible curves, and the performance tests transparently document Mininet's memory and CPU overhead.\n\nThe soft spot is load-bearing. In Section 3.4, Mininet hosts run ping and iperf to measure latency and move container traffic. The paper never states how wall-clock durations from these Linux processes are converted into SimPy simulation time. If communication time is just the real iperf duration, the 'simulation' runs in real time during communication, and the Section 4.2 scaling numbers measure process overhead, not discrete-event scale. If instead communication durations come from bandwidth and delay_matrix, the formula is absent, so the measured iperf traffic is decorative. Either way, Figures 5 and 8—which rank JobGroup and Round under loss and bandwidth changes—are not interpretable as simulation results. That is an internal correctness gap, not merely a missing external validation.\n\nMinor issues: the CPU runtime model (run_at increments by GHz per second) is a simplified choice worth a sentence of justification; the artifact is not released; there are a few editorial artifacts in the text that should be cleaned up; and the citation for CloudSimPy appears to point to a different paper.\n\nWho this is for: researchers building network-aware container scheduling simulators will find the architecture a useful starting point. But before the results can be trusted, the authors need to define the SimPy/Mininet time mapping, add a comparison against a real cluster or an established simulator, and release the code. I would send it to peer review—the design is worth engaging—but I would expect major revision on the validation. Recommendation: engage, but as a significant revision; do not let the current Figures 5 and 8 carry the paper's thesis.","headline":"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.","tokens_in":12767,"tokens_out":2152,"would_cite":false,"duration_ms":19279,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"DCSim couples Mininet network emulation with SimPy event simulation so container scheduling experiments respond to live network dynamics.","keywords":["container scheduling","data center simulator","network-aware scheduling","Mininet","SimPy","discrete event simulation","heterogeneous computing","software-defined networking"],"falsifier":"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.","tokens_in":11858,"feed_emoji":"📡","tokens_out":7721,"duration_ms":61392,"temperature":0.7,"pith_summary":"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.","feed_headline":"Simulator adds live network dynamics to container scheduling tests","feed_subtitle":"Researchers can see how packet loss and bandwidth actually change which scheduling algorithm wins.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Supplies the Mininet network emulation: hosts, switches, links, ping-based latency measurement, and iperf traffic generation.","marker":"[12]"},{"why":"Supplies the SimPy discrete-event engine that drives container request, scheduling, execution, communication, migration, and completion events.","marker":"[15]"},{"why":"Provides the Alibaba GPU workload dataset used to configure realistic heterogeneous container requests.","marker":"[16]"},{"why":"CloudSim serves as the primary baseline simulator whose topology-based network modeling DCSim argues is insufficient.","marker":"[20]"},{"why":"ContainerCloudSim is the baseline container scheduling simulator that uses statically defined container network bandwidth, against which DCSim's dynamic network modeling is contrasted.","marker":"[3]"},{"why":"NetworkCloudSim provides the flow-model network approach as one alternative to packet-level simulation.","marker":"[24]"},{"why":"GreenCloud demonstrates packet-level network modeling via NS2, a comparison point for Mininet-based emulation.","marker":"[25]"},{"why":"CloudSimPy is the Python/SimPy-based scheduling simulator without network or heterogeneous computing modeling that DCSim extends.","marker":"[29]"},{"why":"DRAPS is the resource-aware placement strategy behind the OverloadMigrate and PerformanceFirst scheduling algorithms used in the evaluation.","marker":"[35]"},{"why":"Communication Aware Worst Fit Decreasing is the placement method behind the JobGroup algorithm that wins the communication-time comparisons.","marker":"[38]"}],"fun_headline_variants":["DCSim: container scheduling sim with live network dynamics","New simulator factors network loss and bandwidth into container scheduling","Network-aware DCSim shows packet loss changes container scheduler rankings","DCSim: network state is now a first-class input to container scheduling"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["DCSim: container scheduling sim with live network dynamics","New simulator factors network loss and bandwidth into container scheduling","Network-aware DCSim shows packet loss changes container scheduler rankings","DCSim: network state is now a first-class input to container scheduling"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000337,"raw_usage":{"total_tokens":1841,"prompt_tokens":899,"completion_tokens":942,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":515,"completion_tokens_details":{"reasoning_tokens":871}},"tokens_in":515,"tokens_out":942,"duration_ms":22125,"temperature":1.0,"reasoning_tokens":871,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T15:50:53.239404+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"/2024-04-05","cited_arxiv_id":null,"evidence_quote":"Supplies the Mininet network emulation: hosts, switches, links, ping-based latency measurement, and iperf traffic generation."},{"cited_title":"/2024-04-05","cited_arxiv_id":null,"evidence_quote":"Supplies the SimPy discrete-event engine that drives container request, scheduling, execution, communication, migration, and completion events."},{"cited_title":"/2024-04-05","cited_arxiv_id":null,"evidence_quote":"Provides the Alibaba GPU workload dataset used to configure realistic heterogeneous container requests."},{"cited_title":"CloudSim: a toolkit for modeling and simulation of cloud computing environments and evaluation of resource provisioning algorithms","cited_arxiv_id":null,"evidence_quote":"CloudSim serves as the primary baseline simulator whose topology-based network modeling DCSim argues is insufficient."},{"cited_title":"ContainerCloudSim: An environment for modeling and simulation of containers in cloud data centers","cited_arxiv_id":null,"evidence_quote":"ContainerCloudSim is the baseline container scheduling simulator that uses statically defined container network bandwidth, against which DCSim's dynamic network modeling is contrasted."},{"cited_title":"Networkcloudsim: Modelling parallel applications in cloud simulations","cited_arxiv_id":null,"evidence_quote":"NetworkCloudSim provides the flow-model network approach as one alternative to packet-level simulation."},{"cited_title":"GreenCloud: a packet-level simulator of energy-aware cloud computing data centers","cited_arxiv_id":null,"evidence_quote":"GreenCloud demonstrates packet-level network modeling via NS2, a comparison point for Mininet-based emulation."},{"cited_title":"DeepJS: Job Scheduling Based on Deep Reinforcement Learning in Cloud Data Center","cited_arxiv_id":null,"evidence_quote":"CloudSimPy is the Python/SimPy-based scheduling simulator without network or heterogeneous computing modeling that DCSim extends."},{"cited_title":"Draps: Dynamic and resource-aware placement scheme for docker containers in a heterogeneous cluster","cited_arxiv_id":null,"evidence_quote":"DRAPS is the resource-aware placement strategy behind the OverloadMigrate and PerformanceFirst scheduling algorithms used in the evaluation."},{"cited_title":"Communication-aware container placement and reassignment in large-scale internet data centers","cited_arxiv_id":null,"evidence_quote":"Communication Aware Worst Fit Decreasing is the placement method behind the JobGroup algorithm that wins the communication-time comparisons."}],"review_version":1}