{"id":"b94aa0a7-83ff-49e4-bab8-3c4c45b72fd9","arxiv_id":"2506.04117","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":5,"one_line_summary":"LinTS uses linear programming to schedule and scale inter-datacenter data transfers to low-carbon time windows, cutting simulated carbon emissions by up to 15% versus heuristics.","lead":"This paper introduces LinTS, a linear-programming scheduler that shifts inter-datacenter data transfers to times when the electricity grid is greener and scales transfer threads to cut carbon. In simulations, LinTS reduces transfer carbon emissions by up to 15% over common heuristics and up to 66% over a worst-case schedule, while meeting transfer deadlines.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Equation 8 omits the per-slot baseline power term, so LinTS's LP objective is not the simulator's emissions metric; the headline savings may reflect this mismatch rather than real schedule quality.","rationale":"I read the paper as claiming that LinTS's scheduling and thread-scaling decisions reduce carbon emissions under deadline constraints. For this to hold, the LP's objective must match the emissions estimator. Eq 8's algebraic drop of the Pmin·(#slots) term breaks that link: the simulator charges baseline power per active slot, while the optimizer ignores it. This is a concrete, falsifiable flaw, not a disagreement with consensus. The evaluation's use of the same power model for optimization and simulation makes the reported savings non-independent; a corrected objective or an ablation could restore the claim. The heuristic baselines are not the issue. This supports the reader's CONDITIONAL verdict: the approach is plausible but the central evidence is currently inconclusive.","tokens_in":106,"tokens_out":5906,"duration_ms":116553,"concrete_test":"Construct a one-job, two-slot instance: slot 1 and slot 2 have equal low carbon intensity, slot 3 has high intensity; job size is L·Δt so it can finish in one slot at rate L or in two slots at L/2. Solve the §III-B LP and compute emissions with the simulator's Eq 3 (Pmin=88W, ΔP=12W). If the LP selects the two-slot plan and its simulated emissions exceed the one-slot plan, Eq 8 is not minimizing the reported metric. As a quantitative check, re-run the §IV 200-job comparison with an LP objective that includes PminΣ_j c_ij per job, or with a constraint limiting active slots, and see whether LinTS's 10-15% advantage over FCFS/ST/DT persists.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Equation 7 defines per-slot power as P(ρ)=ΔP/L·ρ+Pmin. Substituting into the carbon objective for job i gives Σ_j c_ij P(ρ_ij) = (ΔP/L)Σ_j c_ij ρ_ij + Pmin Σ_j c_ij, where the sum runs over slots used by job i. Eq 8 writes this as (ΔP/L)c_i^Tρ + pmin, replacing PminΣ_j c_ij by a constant. The number of active slots is a free decision variable because the deadline constraint is an inequality, so the LP can spread a transfer over many low-carbon slots and pay Pmin each time. With Pmin=88W and ΔP=12W, baseline power is about 88% of the per-slot total, so the omitted term dominates. The paper's statement that Eq 8 does not capture the fact that slower transfers take longer, and that linear constraints account for it, is incorrect: the constraints only guarantee byte completion by the deadline; they do not penalize the number of active slots. Hence the optimization objective is not the metric computed by the simulator (Eq 3), and the reported 10-15% savings over heuristics could be an artifact of this internal inconsistency.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper introduces LinTS, a linear-programming-based scheduler for inter-datacenter data transfers. LinTS chooses per-slot throughput (converted to thread counts) to minimize the carbon-weighted throughput over a job's allowed slots, subject to a byte-completion deadline, a per-slot bandwidth cap, and throughput bounds. The authors evaluate LinTS in simulation against FCFS, EDF, single-threshold, double-threshold, and worst-case schedules, using Electricity Maps carbon-intensity traces and a fitted CPU power model, and report carbon savings of up to 66% over the worst case and about 10-15% over the heuristics.","tokens_in":1671,"tokens_out":1607,"duration_ms":72636,"significance":"The underlying idea is timely and practical: inter-datacenter transfers are delay-tolerant, and temporal carbon-intensity variation can be exploited with a lightweight optimizer that also makes thread-scaling decisions. If the optimization objective were faithful to the emissions metric, the 10-15% improvement over common heuristics would be a useful contribution. The machine-checkable LP formulation and the inclusion of a real carbon-intensity trace evaluation are also positive features. However, the central quantitative claim is undermined by an objective mismatch between the LP and the simulator's emissions calculation, so the reported savings cannot currently be taken at face value.","major_comments":[{"comment":"The LP objective omits the per-active-slot baseline power Pmin, so LinTS does not minimize the emissions metric that the simulator computes. Equation (7) gives P(rho)=DeltaP/L*rho+Pmin, and the actual carbon cost of a job using active slots is sum_j c_j (DeltaP/L*rho_j + Pmin) = (DeltaP/L) sum_j c_j rho_j + Pmin * sum_j c_j. The LP in Section III-B minimizes only the first term. Because the deadline constraint J_i <= sum_j t_i,j rho_i,j is an inequality and the number of active slots is not otherwise penalized, the LP can spread a transfer over many low-carbon slots at low throughput; the simulator then charges Pmin for each such slot. With Pmin=88W and DeltaP=12W, the omitted baseline term is about 88% of the per-slot power, so it dominates. The paper's claim that linear constraints account for the cost of slower transfers is incorrect: those constraints guarantee only that enough bytes are transferred by the deadline, not that the number of active slots is minimized. Thus the optimization objective in Section III-B is not the evaluation metric in Tables II and III, and the reported savings may be an artifact of this mismatch.","section":"Section III-A, Eq. (8), and Section III-B LP"},{"comment":"The linearization from Eq. (6) to Eq. (7) is asserted without an error bound, and Eq. (4) appears to contain a typo. The inverse of the throughput model in Eq. (1) is theta(rho) = rho/(s_rho L (L-rho)), not the expression with s_P given in Eq. (4). With the stated parameters (s_rho=1/24, s_P=1/50, DeltaP=12W, L=0.25/0.5/0.75 Gbps), the constant K in Eq. (5) is not 1, so P(rho)=DeltaP/L*rho+Pmin is not exact. The LP objective uses the linearized form while the simulator evaluates emissions from the nonlinear Eq. (3); the authors need either an approximation guarantee or a demonstration that the error is negligible over the feasible range for the actual parameters.","section":"Section III-A, Eqs. (4)-(7)"},{"comment":"The line 'bub <- -8 * data size vec' is unexplained. The slot length is 15 minutes (72 hours divided into 288 slots) and the data sizes are in GB, so the hard-coded constant 8 does not obviously follow from any defined unit conversion. This constant directly changes the byte-completion constraint and therefore affects every plan generated by LinTS. It must be documented and justified, or the algorithm pseudocode and the reproducible implementation must be corrected.","section":"Section III-C, Algorithm 1, line 20"},{"comment":"The evaluation is self-consistent rather than validated: the LP's power model and the simulator's emissions calculation both use Eq. (3) with parameters fitted on a single Chameleon Cloud path, and the authors assume all nodes along a multi-hop path have the same power behavior. Because the heuristics are also evaluated on the same model, the ranking may be a property of the model rather than of real transfer energy consumption. A sensitivity analysis varying Pmin, DeltaP, s_rho, s_P, and the functional form of P(rho), plus a real-world transfer experiment measuring actual CPU power and carbon intensity across a path, would be needed to support the quantitative claims in the abstract and Section IV-B.","section":"Section IV-A and Section IV-B"}],"minor_comments":[{"comment":"Equation (4) should use s_rho in place of s_P when inverting Eq. (1); as written, the two equations are not inverses of each other.","section":"Eq. (4)"},{"comment":"The caption says '25%, 50%, and 40% of the first-hop bandwidth' but the text and Table III indicate the third level is 75%.","section":"Table II caption"},{"comment":"The vector p in Eq. (8) is not defined, and pmin is written as a scalar where the omitted term should be Pmin times a sum over active slots; this notation contributed to the objective mismatch discussed above.","section":"Section III-A, Eq. (8)"},{"comment":"The loop bound 'for n from 0 to num jobs' is ambiguous: if exactly num jobs iterations are intended, the upper bound should be num_jobs-1; otherwise the byte constraint may have an off-by-one error.","section":"Section III-C, Algorithm 1, line 8"},{"comment":"The background-traffic experiment in Figure 4 is only descriptive; the paper does not quantify how the measured throughput variability would degrade LinTS schedules, despite identifying this as a limitation.","section":"Section IV-C"}],"recommendation":"major_revision","confidential_remarks":"The objective mismatch between the LP and the simulator is a load-bearing problem, and the hard-coded '-8' in Algorithm 1 raises reproducibility concerns. These issues are fixable in principle by reformulating the objective with per-active-slot fixed costs (e.g., with binary variables or an explicit span cost) and by re-running the evaluation with consistent power models. I would not rely on the reported percentages until that is done."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nLinTS takes a known trick—temporal shifting of delay-tolerant workloads to low-carbon windows—and applies it to inter-datacenter transfers with thread scaling, formulating the schedule as an LP. That specific LP formulation, with path-level carbon intensities and throughput-to-thread conversion, is new in this space, and the paper is nicely placed against CarbonScaler, WaitAwhile, and the authors' own energy-aware transfer work. The simulation results are consistent across three bandwidth limits and two noise levels, and the paper is honest about its limitations (no online replanning, no congestion handling).\n\nThe soft spots are real, though. The LP objective minimizes Σ c_ij ρ_ij, which omits the baseline power Pmin that dominates the simulator's emission metric (Pmin=88W vs ΔP=12W). Because the byte constraint is an inequality, the LP has no incentive to avoid spreading a transfer across extra low-carbon slots—each pays Pmin in the simulator. That alone could distort the reported 10–15% savings. The linearization from Eq 6 to Eq 7 is also asserted without an error bound; at typical parameter values (K≈5.8–23), the linear model underestimates mid-range power by several watts out of a 12W range, so the LP is optimizing a different curve than the one the simulator evaluates. There is also an unexplained '-8' in Algorithm 1 and no code or data with the submission, which makes the results hard to check.\n\nThat said, the central idea is sound and worth pursuing. The problem is real, the framing is clear, and the authors engage with the right literature. The paper needs a revision where the objective matches the metric—either by adding Pmin appropriately or by arguing why it is constant—and where the linearization is justified or replaced with a piecewise-linear approximation of the actual power curve. A referee should also ask for the code and a detailed explanation of Algorithm 1.\n\nVerdict: major revision, and I'd take a second look at the revised version. The paper deserves a serious referee, but not in its current form.","headline":"A plausible carbon-aware transfer scheduler whose LP objective doesn't match its own simulator's emission metric; worth a major-revision referee, not a desk reject.","tokens_in":13838,"tokens_out":9039,"would_cite":false,"duration_ms":89107,"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":"LinTS, a linear-programming scheduler, cuts inter-datacenter transfer carbon by up to 66% versus worst case and up to 15% versus heuristics, while meeting all deadlines.","keywords":["carbon-aware scheduling","temporal shifting","data transfers","cloud datacenters","linear programming","carbon intensity","thread scaling","deadline constraints"],"falsifier":"Run LinTS's schedule and a naive earliest-deadline schedule on the same real transfer path, with the same files and deadlines, while metering total node power; if the measured energy difference is much smaller than the 10-15% that the simulator predicts, the linear power model is what failed.","tokens_in":12803,"feed_emoji":"🌱","tokens_out":10603,"duration_ms":86167,"temperature":0.7,"pith_summary":"This paper tries to establish that the carbon cost of moving data between cloud datacenters can be cut substantially, without missing deadlines, by choosing both when each transfer runs and how many threads it uses. Its scheduler, LinTS, casts the problem as a linear program that minimizes carbon-intensity-weighted throughput over time slots, subject to per-request completion, deadline, and bandwidth constraints. In simulations with 2024 US grid carbon traces and 200 transfers, LinTS beats first-come-first-serve and threshold-based heuristics by roughly 10-15% and the constructed worst case by up to 66%, while meeting every deadline. The result matters because inter-datacenter traffic is large, growing, and largely delay-tolerant, so temporal shifting is an available lever for cutting cloud emissions.","feed_headline":"Carbon-aware scheduler cuts transfer emissions up to 66%","feed_subtitle":"LinTS shifts inter-datacenter transfers to low-carbon hours and scales threads, beating common heuristics.","key_machinery":"The load-bearing object is the linear program itself, built on a linearized power model $P(\\rho)=\\frac{\\Delta P}{L}\\rho+P_{\\min}$ that ties CPU power draw to transfer throughput $\\rho$. The LP encodes deadlines through the dimension of the throughput vector, completion through byte-sum constraints, and link sharing through per-slot bandwidth constraints; its objective is the carbon-weighted throughput sum. A separate throughput-to-threads model $\\rho(\\theta)=L(1-\\frac{1}{s_\\rho L\\theta+1})$ and its inverse let LinTS turn the continuous LP solution into a concrete thread-scaling plan.","core_discovery":"LinTS's central claim is that a linear-programming scheduler can produce lower-carbon transfer plans than the heuristics used in current transfer services. Each request has a file size and a hard deadline; the path's carbon intensity per 15-minute slot is the sum of regional intensities along the path. The LP minimizes $\\sum_{i,j} c_{i,j}\\rho_{i,j}$, the carbon-weighted throughput, under constraints that each request's bytes complete by its deadline, that total allocated bandwidth in any slot stays under the bottleneck $L$, and that each request's throughput is between 0 and $L$. The solver returns a throughput plan, which LinTS converts into a thread plan using the inverse of its throughput-versus-threads model. Over 200 simulated requests of 10-50 GB with 48-71 hour deadlines on an 8-node path, with 5% and 15% noise added to Electricity Maps traces, the paper reports up to 66% lower emissions than the worst case and up to 15% lower than the comparison heuristics while satisfying all deadlines.","pith_inferences":["Our inference: the LP minimizes a proxy that omits the constant idle-power term $P_{\\min}$; if real nodes draw mostly fixed power regardless of throughput, the true energy gap between schedules will be smaller than simulated. Re-running the evaluation with a stepped or state-based power model would bound this effect.","Our inference: the simulator charges no energy to slots with no threads, but routers and switches along a path consume power continuously; adding per-node idle power would reduce the absolute savings even if the ranking of schedules stays the same.","Our inference: combining LinTS's temporal decisions with spatial replica placement (choosing a greener source region) could compound the savings; the paper does not evaluate that combination.","Our inference: the comparison baseline is a deliberately constructed worst case, so the 66% figure is an upper bound on improvement; benchmarking against production transfer logs with realistic arrival patterns would show how the savings generalize."],"forward_implications":["Providers can deploy LinTS as a library or REST endpoint for delay-tolerant replication and backup traffic, cutting transfer carbon by roughly 10-15% without changing file sizes or deadlines.","Thread scaling adds a second lever: because power is modeled as rising with throughput, the scheduler slows transfers in dirty hours and speeds them up in clean hours, rather than always running at maximum threads.","The LP formulation is extensible: adding constraints would enable spatiotemporal scheduling, and multi-objective solvers could trade off carbon against cost or latency, as the paper notes.","The size of the saving depends on how much carbon intensity varies over time; with flatter or greener grids the scheduling advantage narrows."],"supporting_citations":[{"why":"Supplies the historical US carbon intensity traces used in the simulations.","marker":"[15]"},{"why":"Introduces the thread-scaling idea for carbon efficiency that LinTS extends to network transfers.","marker":"[17]"},{"why":"Provides the defer-and-resume temporal scheduling concept LinTS builds on.","marker":"[26]"},{"why":"Source for the linear power-consumption model and energy-aware transfer algorithms that motivate the LP objective.","marker":"[45]"},{"why":"Chameleon Cloud testbed where throughput and power measurements were taken to fit Equations 1 and 3.","marker":"[46]"},{"why":"SciPy's linprog solver that executes the LP optimization and produces the throughput plan.","marker":"[47]"},{"why":"Defines the heuristic algorithms (FCFS, EDF, single/double threshold) used as baselines.","marker":"[48]"}],"fun_headline_variants":["LinTS cuts inter-datacenter transfer carbon by 66%","Carbon-aware LinTS trims cloud transfer emissions up to 66%","Scheduling transfers in low-carbon hours cuts CO2 66%","LinTS: 66% lower carbon for inter-datacenter data moves"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The whole saving rests on the assumption that every node's CPU power draw rises linearly with transfer throughput, so that running slower in greener hours actually burns less carbon; if real network equipment draws mostly fixed power regardless of throughput, the predicted savings would shrink or disappear.","fun_headline_variants_meta":{"raw":{"variants":["LinTS cuts inter-datacenter transfer carbon by 66%","Carbon-aware LinTS trims cloud transfer emissions up to 66%","Scheduling transfers in low-carbon hours cuts CO2 66%","LinTS: 66% lower carbon for inter-datacenter data moves"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001556,"raw_usage":{"total_tokens":6177,"prompt_tokens":860,"completion_tokens":5317,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":476,"completion_tokens_details":{"reasoning_tokens":5237}},"tokens_in":476,"tokens_out":5317,"duration_ms":32920,"temperature":1.0,"reasoning_tokens":5237,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T10:48:06.626819+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run LinTS's schedule and a naive earliest-deadline schedule on the same real transfer path, with the same files and deadlines, while metering total node power; if the measured energy difference is much smaller than the 10-15% that the simulator predicts, the linear power model is what failed.","supporting_citations":[{"cited_title":"Electricity Maps,","cited_arxiv_id":null,"evidence_quote":"Supplies the historical US carbon intensity traces used in the simulations."},{"cited_title":"Carbon- Scaler: Leveraging Cloud Workload Elasticity for Optimizing Carbon- Efficiency,","cited_arxiv_id":null,"evidence_quote":"Introduces the thread-scaling idea for carbon efficiency that LinTS extends to network transfers."},{"cited_title":"Energy-aware data transfer al- gorithms,","cited_arxiv_id":null,"evidence_quote":"Source for the linear power-consumption model and energy-aware transfer algorithms that motivate the LP objective."},{"cited_title":"Lessons learned from the chameleon testbed,","cited_arxiv_id":null,"evidence_quote":"Chameleon Cloud testbed where throughput and power measurements were taken to fit Equations 1 and 3."},{"cited_title":"linprog; SciPy v1.15.2 Manual — docs.scipy.org,","cited_arxiv_id":null,"evidence_quote":"SciPy's linprog solver that executes the LP optimization and produces the throughput plan."},{"cited_title":"Data-driven algorithm selection for carbon-aware scheduling,","cited_arxiv_id":null,"evidence_quote":"Defines the heuristic algorithms (FCFS, EDF, single/double threshold) used as baselines."}],"review_version":1}