Pith. sign in

REVIEW 4 major objections 5 minor 81 references

Arcturus: A Cloud Overlay Network for Global Accelerator with Enhanced Performance and Stability

T0 review · 4 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

Pith's one-line read A self-managed multi-cloud overlay network of cheap VMs can match or beat commercial global accelerators while cutting cost by 71 percent.

desk verdict Arcturus is a real, deployed multi-cloud accelerator with useful measurements, but the headline 1.7X and million-RPS claims are not backed by the experiments as written. read the letter →

arxiv 2507.10928 v1 pith:Q66VEIBN submitted 2025-07-15 cs.NI cs.DC

classification cs.NIcs.DC
keywords globalacceleratoroverlaynetworkmulti-cloudLyapunovoptimizationmaximumflowwithconflictssegmentroutingcontextualbanditcostefficiency
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

Arcturus is a self-managed global accelerator built from low-cost, heterogeneous cloud VMs instead of one provider's premium infrastructure. The paper's central claim is that such an overlay can match or beat commercial accelerators while remaining stable and cheap: in measurements it reports roughly 40 percent lower transfer time than GCP Global Load Balancing and about 35 percent lower than AWS Global Accelerator, about 71 percent lower cost, and resource efficiency above 80 percent. The design splits into a forwarding plane that reduces per-request CPU through TCP connection pooling, stream multiplexing, packet merging, and online parameter tuning, and a scheduling plane that separates last-mile from middle-mile decisions. The last-mile uses a Lyapunov drift-plus-penalty formulation over virtual CPU-load queues, while the middle-mile maximizes path diversity by solving a maximum-flow-with-conflicts problem. If the paper is right, budget-sensitive or large-scale deployments no longer need a single cloud provider's accelerator to get low-latency, reliable global routing.

What carries the argument

The machinery that carries the argument is the two-plane architecture. In the forwarding plane, the central objects are the tunable proxying parameters—multiplexing sessions $S_p$, concurrency $C_p$, and packet-merge timeout $T_p$—optimized online by the LinUCB contextual bandit, plus a segment-routing header that gives each packet a hop list for path-level control. In the scheduling plane, the central object is a virtual CPU-load queue $Q_k(t)$ per proxy node, tracking cumulative deviation of CPU utilization from a threshold; the Lyapunov drift-plus-penalty objective combines this stability backlog with expected latency and is solved by the Big Process Rearrangement heuristic. For the middle mile, the central object is a network representation in which each node becomes a virtual edge with admission capacity, turning constrained multi-path selection into a maximum-flow-with-conflicts problem solved by Carousel Greedy. Backup paths, fast rerouting, place-holder backlog initialization, and a 5-second control cycle with KNN-based metric compression tie the system together.

What would settle it

Deploy the full 50-node Arcturus system and run a progressively heavier synthetic workload while measuring aggregate RPS, per-node CPU, and control-plane synchronization load. If aggregate throughput per VM falls measurably as the node count grows from 10 to 50, or if total throughput saturates well below one million RPS before latency degrades, the linear-scaling premise fails even if the single-node measurements are correct.

Watch

Extended reading notes

Core claim

On its own terms, Arcturus claims that the Global Accelerator model can be decoupled from provider-specific infrastructure and rebuilt on cheap tier-2/3 cloud instances, because GA workloads are connection-intensive rather than bandwidth-intensive: average transfer size is about 512 bytes, so CPU handling of connections, not throughput, is the bottleneck. The paper's discovery is that a custom forwarding stack—TCP connection pooling, stream multiplexing, packet merging, with LinUCB choosing the multiplexing session count, concurrency, and merge timeout—can hold a single 8C16G VM near 25,000 RPS at up to 80 percent CPU, and that two-tier scheduling keeps the proxy group stable under these loads. Last-mile scheduling treats each node's deviation from a 60 percent CPU threshold as a virtual queue and minimizes a weighted drift-plus-penalty objective; middle-mile routing converts the constrained multi-path selection into a maximum-flow-with-conflicts problem and solves it with Carousel Greedy. The result, as reported, is better transfer times than two commercial accelerators on most tested paths, a 71 percent cost reduction, and a scale path to one million RPS from 50 nodes, though the detailed performance comparison reports up to 40 percent and about 35 percent improvements over GCP and AWS respectively.

Load-bearing premise

The million-requests-per-second claim rests on extrapolating one 8C16G VM's measured throughput of about 25,000 RPS linearly to 50 VMs, assuming no coordination overhead, no synchronization bottleneck, and no uneven regional load; that linear behavior has not been demonstrated end to end.

Editorial extensions

If this is right

  • A 50-node deployment of low-cost VMs costs about $6.6 per hour in compute and under $0.01 per GB in bandwidth, making global acceleration affordable for test environments and budget-sensitive or large-scale services.
  • Dense placement of low-spec edge nodes can cut end-to-end latency by roughly 50 percent over the public Internet on average, and specifically helps underserved regions such as the Middle East and the Southern Hemisphere where single-provider POP coverage is thin.
  • Stability-aware scheduling can keep resource utilization above 80 percent while absorbing request spikes, so capacity can be provisioned close to actual demand instead of over-provisioned for peak.
  • A public acceleration platform built this way can cover its daily infrastructure costs with fewer than 300 paying users, after which margins come from bandwidth and operational fees.
  • The scheduling algorithms complete within the 5-second control cycle—under 100 milliseconds at 50 nodes and under about 600 milliseconds at 100 nodes—so route optimization does not become a centralized bottleneck as the overlay grows.

Reading between the lines

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

  • Editorial: If the linear per-node scaling survives larger deployments, capacity can be added in small VM increments rather than in provider-sized chunks; a staged 10-to-50-to-100-node load test would show where coordination overhead begins to bite.
  • Editorial: The Lyapunov queue formulation is not specific to accelerators; the same drift-plus-penalty with outlier-redistribution could stabilize other compute-bound, connection-heavy overlays such as WebRTC relay farms or signaling gateways running on heterogeneous clouds.
  • Editorial: Because the paper's performance edge over commercial GAs is largest where a single provider's point-of-presence coverage is thinnest, the advantage looks like last-mile coverage density rather than superior backbone; a competitor that densifies those regions could close the gap.
  • Editorial: Arcturus runs its own control-plane synchronization over its acceleration service, so the overlay is load-bearing for the very loop that repairs it; a deliberately induced control-plane outage would show whether the system can recover when its own transport is impaired.
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

4 major / 5 minor

Summary. Arcturus is a self-managed multi-cloud overlay network for global acceleration. The paper argues that low-cost heterogeneous cloud VMs from tier-2/3 providers can serve as a competitive alternative to commercial global accelerator (GA) services. The forwarding plane uses TCP connection pooling, stream multiplexing, packet merging with LinUCB-based parameter tuning, and segment routing; the scheduling plane separates last-mile Lyapunov drift-plus-penalty optimization (solved with a BPR heuristic) from middle-mile max-flow-with-conflicts path selection (Carousel Greedy). Resilience mechanisms include backup paths, fast recovery, and place-holder backlogs. The evaluation reports latency comparisons against direct Internet, GCP Global Load Balancing, and AWS Global Accelerator on a 50-VM global deployment, single-node throughput benchmarks up to roughly 25,000 RPS, scheduling algorithm comparisons, failover case studies, and a cost analysis. The paper claims up to 1.7X acceleration improvement, 71% cost reduction, over 80% resource efficiency, and operation under millions of RPS.

Significance. If fully substantiated, Arcturus would make a useful contribution: it would demonstrate a low-cost, multi-cloud path to commercial-grade GA, backed by an open-source implementation (15K+ lines of code) and a real 50-VM deployment. The comparisons against commercial services and the public Internet are concrete strengths. However, the headline scale and performance claims are not directly supported by the measurements in Section 7; the manuscript needs either substantial additional evidence or an honest reframing of those claims. The central architecture and scheduling ideas may be sound, but the evaluation currently overstates what is shown.

major comments (4)
  1. [Abstract/Conclusion vs. Section 7.2] The abstract and conclusion claim that Arcturus outperforms commercial GA services by up to 1.7X and that evaluations were run under millions of RPS. Section 7.2 reports at most 'up to 40%' improvement over GCP Global Load Balancing and 'around 35%' over AWS Global Accelerator, and no figure or table in the paper yields a 1.7X number. The only throughput experiment in Section 7.3 is a single-VM benchmark reaching roughly 25,000 RPS. The 1.7X figure and the 'millions of RPS' evaluation claim should either be tied to concrete measurements or removed from the abstract and conclusion.
  2. [Section 7.3] The inference that '50 such VMs can collectively serve over one million RPS' is a linear extrapolation from one 8C16G Vultr Los Angeles VM. The deployment described in Section 7.1 is heterogeneous (4C8G to 16C32G, with 80% being 8C16G), and nodes are assigned to different roles with a 5-second etcd control loop and regional master election. Linear scaling assumes identical dedicated user-facing nodes, zero coordination overhead, no scheduler bottleneck, and perfect global load balance, none of which are demonstrated. At millions of RPS, a 5-second control interval moves millions of requests per slot, a regime not represented by the single-node test with δreq = 100–300. A system-level scale test, or at minimum a scaling analysis that measures overhead and imbalance, is required before the million-RPS claim can stand.
  3. [Section 7.3, Fig. 11] The text gives the fitted model as δcpu = 340 × δreq − 1300 for CPU ∈ [60%,70%] and δcpu = 250 × δreq + 5000 for CPU ∈ (70%,80%], but Figure 11 plots RPS against CPU usage with fits y = 340.46x − 1313.14 and y = 250.47x + 5049.06. The notation conflates request increments with absolute values, and the second equation has a positive intercept that is not meaningful for an increment relationship. Since this model is used as f_k in the Lyapunov scheduler (Eq. (1), Section 5.1.1), the discrepancy must be resolved and the fitted model validated on held-out data.
  4. [Section 5.1, Theorem 2 and Appendix B] The paper states that problem P1 is 'equivalently transformed' into P2, but the proof in Lemma 1 (Eq. B-5) only shows that the drift-plus-penalty objective is bounded above by B plus the P2 objective. Minimizing an upper bound is not an equivalent reformulation of the original minimization problem. If the intended contribution is the standard Lyapunov drift-plus-penalty relaxation, the terminology and proof should be corrected, and the approximation gap should be discussed. As written, the equivalence claim in Theorem 2 is formally incorrect.
minor comments (5)
  1. [Section 2, Table 1] The table header contains the typo 'Bussiness' and the caption 'The Average Bw of Requests for Diff Businesses' should be polished for grammar and consistency.
  2. [Section 7.3] The sentence 'Beyond this point, we fitted f_k for CPU utilization levels within the 60–70% and 70–80% bands' is confusing, because those bands are below the stated 80% stability limit; please reword to clarify what 'beyond this point' refers to.
  3. [Section 7.6] The claim that 'fewer than 300 registered users' can cover daily infrastructure costs is not supported by an explicit per-user traffic model or revenue calculation; please provide the arithmetic used to derive this number.
  4. [Section 7.4] The statement that the scheduling algorithm 'converges within 100ms' is attributed to 'simulations' that are not described; please specify the simulation setup, including workload and topology generation.
  5. [Section 5.1, Eq. (1)] The virtual queue Q_k is defined as an accumulator of CPU utilization deviations, which has unusual units (percentage points); please state the units explicitly and explain why this choice preserves the intended mean-rate-stability interpretation.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity; the central performance and cost claims are benchmarked against external systems, and the million-RPS figure is a support/extrapolation concern rather than a circular derivation.

full rationale

The paper's central claims are checked against external benchmarks: the public Internet, GCP Global Load Balancing, and AWS Global Accelerator in Section 7.2, and provider pricing in Section 7.6. The Lyapunov-based last-mile scheduler (Section 5.1) applies standard drift-plus-penalty theory; the fitted piecewise CPU model f_k in Section 7.3 is an input to the scheduler, not the quantity that the paper presents as its predicted result. No equation in the paper reduces the headline latency improvement, cost reduction, or resource-efficiency number to the paper's own fitted parameters or to a definition of the claim. The 25,000 RPS per VM to 50 VMs to 1,000,000 RPS statement in Section 7.3 is a linear extrapolation and a completeness/support weakness, but it is not circular because the per-node measurement is external evidence. Likewise, the abstract/body wording around 1.7X versus 40% and 35% is a presentation matter, not a circular step. Self-citations such as [21], [50], and [69] appear in background or algorithmic contexts and are not load-bearing; no uniqueness theorem or ansatz is imported from the authors' prior work to force the design choice. Omitted or deferred stability proofs and the assumption in Appendix C are correctness risks, not circularity.

Assumptions & free parameters 7 free parameters · 5 assumptions · 0 invented entities

All domain-specific scheduling knobs are either chosen by hand (theta=60%, V unspecified, p=1/2), tuned by grid search (alpha=2, beta=70%), or fitted to stress tests (f_k). The central cost and performance claims also depend on the assumption that a single 25k RPS VM scales linearly to 50 VMs, which is an extrapolation rather than a measured result.

free parameters (7)
  • CPU response model f_k piecewise slopes = 340 and -1300 for CPU in [60,70%]; 250 and 5000 for CPU in (70,80%]
    Fitted to stress tests on one 8C16G Vultr Los Angeles VM in Section 7.3 and used in the DPP scheduling objective (Eq. 8).
  • Lyapunov weight V = not specified
    V balances drift and latency in Eq. (5) and Eq. (8); no value is given in the paper, so the reported stability and latency trade-off is under-specified.
  • CPU stability threshold theta = 60%
    Set in Section 5.1.1 as the common upper limit for balancing utilization and stability; changes the virtual queue definition.
  • BPR redistribution ratio p = 1/2 or descending {1/2, 1/4, 1/8, ...}
    Chosen in Section 7.4 based on node capacity similarity; used in Algorithm 1 line 6.
  • Carousel Greedy alpha and beta = alpha=2, beta=70%
    Selected by grid search in Table 2 for the 50-node deployment; the headline routing performance depends on this tuning.
  • Middle-mile admission and path bounds = theta_a, theta_L, K unspecified
    Eq. (9) depends on admissibility threshold theta_a, latency bound theta_L, and input flow K, but no default values are provided.
  • LinUCB parameter ranges Sp, Cp, Tp = Sp=1..10, Cp=50..200, Tp=1..5 ms
    Selected from stress-testing experience in Section 4.1; defines the bandit arm space for dynamic proxy tuning.
assumptions (5)
  • domain assumption CPU utilization is the only bottleneck; memory, bandwidth, and I/O are ignored.
    Stated in Section 2 ('this paper excludes the impact of memory, bandwidth, I/O, and other factors...'). The scheduler's virtual queue is defined on CPU load alone; if memory or I/O becomes a bottleneck, the stability guarantee and resource-efficiency claim do not transfer.
  • standard math Mean-rate queue stability follows from the stated Lyapunov drift condition.
    Theorem 1 and Appendix C use standard Lyapunov queue-stability theory from Neely [56]; the proof, however, has a gap in the derivation of the drift bound.
  • domain assumption LSTM-based CPU predictors and the piecewise empirical model f_k predict next-slot CPU with sufficient accuracy.
    The DPP scheduler in Eq. (8) uses estimated CPU change. The paper claims over 95% prediction accuracy (Fig. 19), but if prediction error is large, drift-plus-penalty decisions may not stabilize the queues.
  • domain assumption The GCP Tokyo and Vultr Melbourne anomalies can be filtered out for stability analysis.
    Section 2 filters two anomaly nodes before reporting latency variance; the paper does not test how sensitive the stability conclusion is to those exclusions.
  • ad hoc to paper Place-holder backlog initialization Q_k(0)=Qplace improves stability.
    Introduced in Section 6 and demonstrated in Section 7.5 without a formal derivation; Qplace is set to the median queue log in the evaluation.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Arcturus: A Cloud Overlay Network for Global Accelerator with Enhanced Performance and Stability." pith.science (2026). https://pith.science/paper/Q66VEIBN

@misc{pith2026250710928,
  author       = {Pith},
  title        = {Pith review of: Arcturus: A Cloud Overlay Network for Global Accelerator with Enhanced Performance and Stability},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/Q66VEIBN}},
  note         = {Machine review of arXiv:2507.10928}
}
read the original abstract

Global Accelerator (GA) services play a vital role in ensuring low-latency, high-reliability communication for real-time interactive applications. However, existing GA offerings are tightly bound to specific cloud providers, resulting in high costs, rigid deployment, and limited flexibility, especially for large-scale or budget-sensitive deployments. Arcturus is a cloud-native GA framework that revisits the design of GA systems by leveraging low-cost, heterogeneous cloud resources across multiple providers. Rather than relying on fixed, high-end infrastructure, Arcturus dynamically constructs its acceleration network and balances performance, stability, and resource efficiency. To achieve this, Arcturus introduces a two-plane design: a forwarding plane that builds a proxy network with adaptive control, and a scheduling plane that coordinates load and routing through lightweight, quantitative optimization. Evaluations under millions of RPS show that Arcturus outperforms commercial GA services by up to 1.7X in acceleration performance, reduces cost by 71%, and maintains over 80% resource efficiency--demonstrating efficient use of cloud resources at scale.

Figures

Figures reproduced from arXiv: 2507.10928 by the authors.

Figure 1
Figure 1. The RPS Distribution of GA in a certain region over several consecutive days. In the graph, clear distribu￾tion anomalies can be observed, along with spikes occurring during both peak and non-peak hours [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Resource usage profile (CPU and memory) of small￾file acceleration services. and highly unstable, placing heavy pressure on system oper￾ations. As a result, real-world system scheduling strategies must focus on ensuring responsive acceleration and maintain￾ing robust service quality. From a business perspective, GA functions as a connection￾intensive application, which can be viewed as a lightweight form of compute-… view at source ↗
Figure 4
Figure 4. Benchmarking Cloud Server Performance: Load [PITH_FULL_IMAGE:figures/full_fig_p003_4.png] view at source ↗
Figures from the paper (14 more)
Figure 6
Figure 6. Figure 6: Scheduling Architecture. The controllers integrate global performance and stability data, compress the results, and synchronize the summary across all nodes. This allows both the controller and proxy nodes to contribute to schedul￾ing decisions. path switching. Traditi…
Figure 5
Figure 5. Figure 5: Forwarding Architecture. TCP connection pooling at the protocol layer and eBPF [32] at the kernel layer, offer limited flexibility. For instance, support￾ing advanced protocols like QUIC [45], which demand high CPU resources, poses a significant challenge for resource￾…
Figure 7
Figure 7. Figure 7: Segment Routing Header. and wART represent the weights for RQPTnorm and ARTnorm, respectively, with sum 1 and initial values 0.5. It is important to note that the reward function does not account for stability feedback. This is because when parame￾ter adjustments cause…
Figure 8
Figure 8. Figure 8: The Logic Diagram of the Carousel Greedy. Algorithm 2: Carousel Greedy for the MFPC Input: Original graph G = (V,A); source node s; sink node t; α and β parameters. Output: Solution S ∗ . 1 Init: S ← ⟨⟩; Gf ← residual graph of G; 2 Greedily select P (s → t) satisfying …
Figure 9
Figure 9. Figure 9: , we have provisioned 50 VMs across diverse regions and cloud providers worldwide. The VMs span configura￾tions from 4C8G to 16C32G, 80% of which are provisioned as 8C16G, primarily because this configuration offers a favor￾able trade-off between performance and resour…
Figure 10
Figure 10. Figure 10: (a) Direct vs. Arcturus; (b, c) Arcturus vs. commercial GA services. developing areas. Fig. 10c also shows that Arcturus generally surpasses AWS Global Accelerator by around 35%. While this per-request improvement may seem modest, at a scale of millions of RPS it tran…
Figure 11
Figure 11. Figure 11: Proxy RPS Benchmark and ˆfk Fitting on 8C16G VM. 0 10000 20000 30000 Requests Per Second 0 10 20 30 40 50 CPU Usage (%) (a) Tunnel CPU Overhead 8 10 12 14 ART 15k 20k 25k 30k 35k 40k RQPT Baseline Optimized (b) Tunnel Optimization [PITH_FULL_IMAGE:figures/full_fig_p0…
Figure 12
Figure 12. Figure 12: Tunnel Benchmark between 8C16G VMs. and δcpu¯ = 250×δreq+5000 for cpu ∈ (70%,80%]. Enhancing Overlay Tunnel Performance. Arcturus lever￾ages three key techniques—TCP connection pooling, stream multiplexing, and packet merging—to optimize connection management, thereby…
Figure 14
Figure 14. Figure 14: Evaluating Middle-Mile Scheduling Strategies [PITH_FULL_IMAGE:figures/full_fig_p011_14.png]
Figure 15
Figure 15. Figure 15: Path Failover and Recovery (Tokyo→New Jersey). conducted experiments at node scales of 50 (real deployment), 70, and 100 to evaluate Arcturus’s routing algorithm (with arc density d fixed at 0.4 in all cases.). The results demon￾strate that, with average path latency …
Figure 16
Figure 16. Figure 16: Stabilizing VM Addition with Place-Holder. stabilized, traffic automatically reverted to the original opti￾mal path—showcasing Arcturus’s rapid failover and real-time recovery capabilities. Case Study 2: Adding a VM to the Proxy Group. We in￾troduce the place-holder t…
Figure 17
Figure 17. Figure 17: Data Compression in Europe and the US East. 15:00 15:10 15:20 15:30 15:40 15:50 16:00 Time (UTC+9) 50 75 100 125 150 175 200 225 250 Latency (ms) Network Outage Vultr-New Jersey Vultr-Melbourne AWS-Oregon AWS-Virginia Vultr-Singapore Vultr-London [PITH_FULL_IMAGE:fig…
Figure 18
Figure 18. Figure 18: Probing Data Display for the GCP-Tokyo Node [PITH_FULL_IMAGE:figures/full_fig_p019_18.png]
Figure 19
Figure 19. Figure 19: LSTM-Driven CPU Forecasting. 19 [PITH_FULL_IMAGE:figures/full_fig_p019_19.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

81 extracted references · 79 canonical work pages

  1. [1]

    https://www.coursera.org/, Accessed:2025-04-20

    Coursera. https://www.coursera.org/, Accessed:2025-04-20

  2. [2]

    https://www.envoyproxy.io/, Accessed:2025-04-20

    Envoy. https://www.envoyproxy.io/, Accessed:2025-04-20

  3. [3]

    https://etcd.io/, Accessed:2025-04-20

    Etcd. https://etcd.io/, Accessed:2025-04-20

  4. [4]

    https://www.haproxy.org/, Accessed:2025-04-20

    Haproxy. https://www.haproxy.org/, Accessed:2025-04-20

  5. [5]

    https://nginx.org/, Accessed:2025-04-20

    Nginx. https://nginx.org/, Accessed:2025-04-20

  6. [6]

    https://www.segment-routing

    Segment-routing. https://www.segment-routing. net/, Accessed:2025-04-20

  7. [7]

    https://github.com/xtaci/smux, Accessed:2025-04-20

    Smux. https://github.com/xtaci/smux, Accessed:2025-04-20

  8. [8]

    https://www.tiktok.com/, Accessed:2025- 04-20

    Tiktok. https://www.tiktok.com/, Accessed:2025- 04-20

Show all 81 references
  1. [9]

    https://traefik.io/traefik/, Accessed:2025-04-20

    Traefik. https://traefik.io/traefik/, Accessed:2025-04-20

  2. [10]

    Network entitle- ment: contract-based network sharing with agility and slo guarantees

    Satyajeet Singh Ahuja, Vinayak Dangui, Kirtesh Patil, Manikandan Somasundaram, Varun Gupta, Mario Sanchez, Guanqing Yan, Max Noormohammadpour, Alaleh Razmjoo, Grace Smith, Hao Zhong, Abhinav Triguna, Soshant Bali, Yuxiang Xiang, Yilun Chen, Prab- hakaran Ganesan, Mikel Jimenez...

  3. [11]

    Capacity-efficient and uncertainty-resilient backbone network planning with hose

    Satyajeet Singh Ahuja, Varun Gupta, Vinayak Dangui, Soshant Bali, Abishek Gopalan, Hao Zhong, Petr La- pukhov, Yiting Xia, and Ying Zhang. Capacity-efficient and uncertainty-resilient backbone network planning with hose. In Proceedings of the ACM SIGCOMM Conference, page 547–5...

  4. [12]

    Rao, Bruno Ribeiro, and Mohit Tawarmalani

    Abd AlRhman AlQiam, Yuanjun Yao, Zhaodong Wang, Satyajeet Singh Ahuja, Ying Zhang, Sanjay G. Rao, Bruno Ribeiro, and Mohit Tawarmalani. Transferable neural wan te for changing topologies. InProceedings of the ACM SIGCOMM Conference, pages 86–102, New York, NY , USA, 2024. Asso...

  5. [13]

    Global accelerator

    Amazon Web Services. Global accelerator. https://aws.amazon.com/global-accelerator/ ?nc1=h_ls, Accessed:2025-04-20

  6. [14]

    Amazon ec2

    Amazon Web Services. Amazon ec2. https://aws. amazon.com/ec2/, Accessed:2025-04-24

  7. [15]

    Global accelerator pricing

    Amazon Web Services. Global accelerator pricing. https://aws.amazon.com/global-accelerator/ pricing/, Accessed:2025-04-24

  8. [16]

    Resilient overlay networks

    David Andersen, Hari Balakrishnan, Frans Kaashoek, and Robert Morris. Resilient overlay networks. ACM SIGOPS Operating Systems Review, 2001

  9. [17]

    Rfc 5036: Ldp specification, 2007

    L Andersson, I Minei, and B Thomas. Rfc 5036: Ldp specification, 2007

  10. [18]

    Dissecting last-mile latency character- istics

    Vaibhav Bajpai, Steffie Jacob Eravuchira, and Jürgen Schönwälder. Dissecting last-mile latency character- istics. ACM SIGCOMM Computer Communication Review, 47(5):25–34, 2017

  11. [19]

    Software-defined networking (sdn): a survey

    Kamal Benzekki, Abdeslam El Fergougui, and Abdel- baki Elbelrhiti Elalaoui. Software-defined networking (sdn): a survey. Security and communication networks, 9(18):5803–5833, 2016

  12. [20]

    Hybridizing carousel greedy and kernel search: A new approach for the maximum flow problem with conflict constraints

    F Carrabs, R Cerulli, R Mansini, D Serra, and C Sor- gente. Hybridizing carousel greedy and kernel search: A new approach for the maximum flow problem with conflict constraints. European Journal of Operational Research, 2025

  13. [21]

    Olpart: Online learning based re- source partitioning for colocating multiple latency- critical jobs on commodity computers

    Ruobing Chen, Haosen Shi, Yusen Li, Xiaoguang Liu, and Gang Wang. Olpart: Online learning based re- source partitioning for colocating multiple latency- critical jobs on commodity computers. In Proceedings of the Eighteenth European Conference on Computer Systems, pages 347–364, 2023

  14. [22]

    Characterizing roles of front-end servers in end-to-end performance of dynamic con- tent distribution

    Yingying Chen, Sourabh Jain, Vijay Kumar Adhikari, and Zhi-Li Zhang. Characterizing roles of front-end servers in end-to-end performance of dynamic con- tent distribution. In ACM SIGCOMM conference on Internet measurement conference, pages 559–568, 2011

  15. [23]

    To- toro: A scalable federated learning engine for the edge

    Cheng-Wei Ching, Xin Chen, Taehwan Kim, Bo Ji, Qingyang Wang, Dilma Da Silva, and Liting Hu. To- toro: A scalable federated learning engine for the edge. In Proceedings of the Nineteenth European Conference on Computer Systems, pages 182–199, New York, NY , USA, 2024

  16. [24]

    Argo-smart-routing

    Cloudflare. Argo-smart-routing. https://developers.cloudflare.com/ argo-smart-routing/, Accessed:2025-04-20

  17. [25]

    Spectrum

    Cloudflare. Spectrum. https://developers. cloudflare.com/spectrum/, Accessed:2025-04-20

  18. [26]

    Converge: Qoe- driven multipath video conferencing over webrtc

    Sandesh Dhawaskar Sathyanarayana, Kyunghan Lee, Dirk Grunwald, and Sangtae Ha. Converge: Qoe- driven multipath video conferencing over webrtc. In 13 Proceedings of the ACM SIGCOMM 2023 Conference, pages 637–653, New York, NY , USA, 2023

  19. [27]

    Droplets

    DigitalOcean. Droplets. https://cloud. digitalocean.com/droplets?i=8f55d5, Accessed:2025-04-20

  20. [28]

    Finding the k shortest paths

    David Eppstein. Finding the k shortest paths. SIAM Journal on computing, 28(2):652–673, 1998

  21. [29]

    Andrew D. Ferguson, Steve Gribble, Chi-Yao Hong, Charles Killian, Waqar Mohsin, Henrik Muehe, Joon Ong, Leon Poutievski, Arjun Singh, Lorenzo Vicisano, Richard Alimi, Shawn Shuoshuo Chen, Mike Conley, Subhasree Mandal, Karthik Nagaraj, Kondapa Naidu Bollineni, Amr Sabaa, Shido...

  22. [30]

    Fleischer

    L.K. Fleischer. Approximating fractional multicommod- ity flow independent of the number of commodities. In 40th Annual Symposium on Foundations of Computer Science (Cat. No.99CB37039), pages 24–31, 1999

  23. [31]

    An efficient local search with noising strategy for google machine reassignment problem

    Haris Gavranovi´c and Mirsad Buljubaši´c. An efficient local search with noising strategy for google machine reassignment problem. Annals of Operations Research, 242:19–31, 2016

  24. [32]

    The ebpf runtime in the linux kernel

    Bolaji Gbadamosi, Luigi Leonardi, Tobias Pulls, Toke Høiland-Jørgensen, Simone Ferlin-Reiter, Simo Sorce, and Anna Brunström. The ebpf runtime in the linux kernel. ArXiv, abs/2410.00026, 2024

  25. [33]

    Load-balancing

    GCP. Load-balancing. https://cloud.google.com/ load-balancing, Accessed:2025-04-20

  26. [34]

    Global load balancing pricing

    GCP. Global load balancing pricing. https: //cloud.google.com/vpc/network-pricing/, Accessed:2025-04-24

  27. [35]

    Integrated electrical propulsion system for us navy ddg 1000 destroyers

    GE Gevernova. Integrated electrical propulsion system for us navy ddg 1000 destroyers. https://www. gevernova.com/power-conversion/case-study/ integrated-electrical-propulsion-system-for/ /-us-navy-ddg-1000-destroyers , Accessed:2025- 04-24

  28. [36]

    Vm instances

    Google Cloud Platform. Vm instances. https:// console.cloud.google.com/compute/instances, Accessed:2025-04-20

  29. [37]

    Redte: Mitigating subsec- ond traffic bursts with real-time and distributed traffic engineering

    Fei Gui, Songtao Wang, Dan Li, Li Chen, Kaihui Gao, Congcong Min, and Yi Wang. Redte: Mitigating subsec- ond traffic bursts with real-time and distributed traffic engineering. In Proceedings of the ACM SIGCOMM Conference, pages 71–85, New York, NY , USA, 2024

  30. [38]

    Knn model-based approach in clas- sification

    Gongde Guo, Hui Wang, David Bell, Yaxin Bi, and Kieran Greer. Knn model-based approach in clas- sification. In On The Move to Meaningful Internet Systems 2003: CoopIS, DOA, and ODBASE: OTM Confederated International Conferences, CoopIS, DOA, and ODBASE 2003, Catania, Sicily, I...

  31. [39]

    Patil, Joseph E

    Paras Jain, Sam Kumar, Sarah Wooders, Shishir G. Patil, Joseph E. Gonzalez, and Ion Stoica. Skyplane: Opti- mizing transfer cost and throughput using Cloud-Aware overlays. In 20th USENIX Symposium on Networked Systems Design and Implementation, pages 1375–1389, Boston, MA, April 2023

  32. [40]

    Measuring congestion in High-Performance dat- acenter interconnects

    Saurabh Jha, Archit Patke, Jim Brandt, Ann Gentile, Benjamin Lim, Mike Showerman, Greg Bauer, Larry Ka- plan, Zbigniew Kalbarczyk, William Kramer, and Ravi Iyer. Measuring congestion in High-Performance dat- acenter interconnects. In 17th USENIX Symposium on Networked Systems ...

  33. [41]

    Cost optimizing cloud based docker application deploy- ment with cloudfront and global accelerator in aws cloud

    Shanmukh Sai Kataru, Rohith Gude, Shoaib Shaik, Lalithesh VNSS Sathvik Kota, Balajee RM, et al. Cost optimizing cloud based docker application deploy- ment with cloudfront and global accelerator in aws cloud. In 2023 International Conference on Sustainable Communication Networ...

  34. [42]

    Algorithm design

    Jon Kleinberg and Eva Tardos. Algorithm design. Pear- son Education India, 2006

  35. [43]

    OneW AN is better than two: Unifying a split WAN architecture

    Umesh Krishnaswamy, Rachee Singh, Paul Mattes, Paul- Andre C Bissonnette, Nikolaj Bjørner, Zahira Nasrin, Sonal Kothari, Prabhakar Reddy, John Abeln, Srikanth Kandula, Himanshu Raj, Luis Irun-Briz, Jamie Gaudette, and Erica Lan. OneW AN is better than two: Unifying a split WAN...

  36. [44]

    Sitaraman

    Dhruv Kumar, Sohaib Ahmad, Abhishek Chandra, and Ramesh K. Sitaraman. Aggnet: Cost-aware aggrega- tion networks for geo-distributed streaming analytics. In IEEE/ACM Symposium on Edge Computing (SEC), pages 297–311, 2021

  37. [45]

    14 The quic transport protocol: Design and internet-scale deployment

    Adam Langley, Alistair Riddoch, Alyssa Wilk, Anto- nio Vicente, Charles Krasic, Dan Zhang, Fan Yang, Fe- dor Kouranov, Ian Swett, Janardhan Iyengar, Jeff Bailey, Jeremy Dorfman, Jim Roskind, Joanna Kulik, Patrik Westin, Raman Tenneti, Robbie Shade, Ryan Hamil- ton, Victor Vasi...

  38. [46]

    Uniform- cost multi-path routing for reconfigurable data center networks

    Jialong Li, Haotian Gong, Federico De Marchi, Aoyu Gong, Yiming Lei, Wei Bai, and Yiting Xia. Uniform- cost multi-path routing for reconfigurable data center networks. In Proceedings of the ACM SIGCOMM Conference, pages 433–448, New York, NY , USA, 2024

  39. [47]

    Livenet: a low-latency video transport network for large-scale live streaming

    Jinyang Li, Zhenyu Li, Ri Lu, Kai Xiao, Songlin Li, Jufeng Chen, Jingyu Yang, Chunli Zong, Aiyun Chen, Qinghua Wu, Chen Sun, Gareth Tyson, and Hongqiang Harry Liu. Livenet: a low-latency video transport network for large-scale live streaming. pages 812–825, 2022

  40. [48]

    AlNiCo: SmartNIC-accelerated contention-aware request scheduling for transaction pro- cessing

    Junru Li, Youyou Lu, Qing Wang, Jiazhen Lin, Zhe Yang, and Jiwu Shu. AlNiCo: SmartNIC-accelerated contention-aware request scheduling for transaction pro- cessing. In USENIX Annual Technical Conference (USENIX ATC), pages 951–966, Carlsbad, CA, July 2022

  41. [49]

    Triton: A flexible hardware offloading architec- ture for accelerating apsara vswitch in alibaba cloud

    Xing Li, Xiaochong Jiang, Ye Yang, Lilong Chen, Yi Wang, Chao Wang, Chao Xu, Yilong Lv, Bowen Yang, Taotao Wu, Haifeng Gao, Zikang Chen, Yisong Qiao, Hongwei Ding, Yijian Dong, Hang Yang, Jian- ming Song, Jianyuan Lu, Pengyu Zhang, Chengkun Wei, Zihui Zhang, Wenzhi Chen, Qinmi...

  42. [50]

    A large-scale measurement and optimization of mobile live streaming services

    Zhenyu Li, Jinyang Li, Qinghua Wu, Gareth Tyson, and Gaogang Xie. A large-scale measurement and optimization of mobile live streaming services. IEEE Transactions on Mobile Computing, 22(12):7294–7309, 2023

  43. [51]

    Gso-simulcast: global stream orchestration in simulcast video con- ferencing systems

    Xianshang Lin, Yunfei Ma, Junshao Zhang, Yao Cui, Jing Li, Shi Bai, Ziyue Zhang, Dennis Cai, Hongqiang Harry Liu, and Ming Zhang. Gso-simulcast: global stream orchestration in simulcast video con- ferencing systems. In Proceedings of the ACM SIGCOMM Conference, pages 826–839, ...

  44. [52]

    Janus: A unified distributed training framework for sparse mixture-of-experts models

    Juncai Liu, Jessie Hui Wang, and Yimin Jiang. Janus: A unified distributed training framework for sparse mixture-of-experts models. In Proceedings of the ACM SIGCOMM Conference, pages 486–498, New York, NY , USA, 2023. Association for Computing Machinery

  45. [53]

    Megate: Ex- tending wan traffic engineering to millions of end- points in virtualized cloud

    Congcong Miao, Zhizhen Zhong, Yunming Xiao, Feng Yang, Senkuo Zhang, Yinan Jiang, Zizhuo Bai, Chaodong Lu, Jingyi Geng, Zekun He, Yachen Wang, Xianneng Zou, and Chuanchuan Yang. Megate: Ex- tending wan traffic engineering to millions of end- points in virtualized cloud. In Pro...

  46. [54]

    Microsoft-365

    Microsoft. Microsoft-365. https://www.microsoft. com/en-sg/microsoft-365/mobile, Accessed:2025- 04-20

  47. [55]

    Virtual machines

    Microsoft Azure. Virtual machines. https: //portal.azure.com/#browse/Microsoft. Compute%2FVirtualMachines, Accessed:2025- 04-20

  48. [56]

    Stochastic network optimization with application to communication and queueing systems

    Michael Neely. Stochastic network optimization with application to communication and queueing systems. Morgan & Claypool Publishers, 2010

  49. [57]

    Opportunism, backpressure, and stochastic optimization with the wire- less broadcast advantage

    Michael J Neely and Rahul Urgaonkar. Opportunism, backpressure, and stochastic optimization with the wire- less broadcast advantage. In 2008 42nd Asilomar Conference on Signals, Systems and Computers, pages 2152–2158. IEEE, 2008

  50. [58]

    Sitaraman, and Jennifer Sun

    Erik Nygren, Ramesh K. Sitaraman, and Jennifer Sun. The akamai network: a platform for high- performance internet applications. ACM SIGOPS Operating Systems Review, 44:2–19, 2010

  51. [59]

    Angela Wang, Cheng Huang, Al- bert Greenberg, Y

    Abhinav Pathak, Y . Angela Wang, Cheng Huang, Al- bert Greenberg, Y . Charlie Hu, Randy Kern, Jin Li, and Keith W. Ross. Measuring and evaluating tcp splitting for cloud services. In Passive and Active Measurement, pages 41–50, Berlin, Heidelberg, 2010

  52. [60]

    Recent trends in mpls networks: technologies, applications and challenges

    Mohammad Azmi Ridwan, Nurul Asyikin Mohamed Radzi, Wan Siti Halimatul Munirah Wan Ahmad, Fairuz Abdullah, Md Zaini Jamaludin, and Mohd Nasim Za- karia. Recent trends in mpls networks: technologies, applications and challenges. IET Communications, 14(2):177–185, 2020

  53. [61]

    A survey of contextual optimization methods for decision-making under uncertainty

    Utsav Sadana, Abhilash Chenreddy, Erick Delage, Alexandre Forel, Emma Frejinger, and Thibaut Vi- dal. A survey of contextual optimization methods for decision-making under uncertainty. European Journal of Operational Research, 320(2):271–289, 2025

  54. [62]

    Energy efficient edge com- puting: When lyapunov meets distributed reinforcement learning

    Mohamed Sana, Mattia Merluzzi, Nicola di Pietro, and Emilio Calvanese Strinati. Energy efficient edge com- puting: When lyapunov meets distributed reinforcement learning. In 2021 IEEE International Conference on Communications Workshops (ICC Workshops), pages 1–6, 2021. 15

  55. [63]

    Internet performance from facebook’s edge

    Brandon Schlinker, Italo Cunha, Yi Ching Chiu, Srikanth Sundaresan, and Ethan Katz-Bassett. Internet performance from facebook’s edge. 2019

  56. [64]

    Engineering egress with edge fabric: Steering oceans of content to the world

    Brandon Carl Schlinker, Hyojeong Kim, Timothy Cui, Ethan B Katz-Bassett, Harsha V Madhyastha, xcd, Talo S Cunha, James Quinn, Saif Hasan, and Petr La- pukhov. Engineering egress with edge fabric: Steering oceans of content to the world. 2017

  57. [65]

    A distribution- ally robust optimization approach for stochastic elec- tive surgery scheduling with limited intensive care unit capacity

    Karmel S Shehadeh and Rema Padman. A distribution- ally robust optimization approach for stochastic elec- tive surgery scheduling with limited intensive care unit capacity. European Journal of Operational Research, 290(3):901–913, 2021

  58. [66]

    Shehadeh and Rema Padman

    Karmel S. Shehadeh and Rema Padman. Stochastic optimization approaches for elective surgery scheduling with downstream capacity constraints: Models, chal- lenges, and opportunities. Computers & Operations Research, 137:105523, 2022

  59. [67]

    Cost-effective cloud edge traffic en- gineering with cascara

    Rachee Singh, Sharad Agarwal, Matt Calder, and Paramvir Bahl. Cost-effective cloud edge traffic en- gineering with cascara. In 18th USENIX Symposium on Networked Systems Design and Implementation (NSDI 21), pages 201–216, 2021

  60. [68]

    Submarine cable map

    TeleGeography. Submarine cable map. https://www. submarinecablemap.com/, Accessed:2025-04-24

  61. [69]

    Cost-saving stream- ing: Unlocking the potential of alternative edge node re- sources

    Yu Tian, Zhenyu Li, Matthew Yang Liu, Jian Mao, Gareth Tyson, and Gaogang Xie. Cost-saving stream- ing: Unlocking the potential of alternative edge node re- sources. In ACM on Internet Measurement Conference, pages 580–587, New York, NY , USA, 2024

  62. [70]

    Alexandru Uta, Alexandru Custura, Dmitry Duplyakin, Ivo Jimenez, Jan Rellermeyer, Carlos Maltzahn, Robert Ricci, and Alexandru Iosup. Is big data performance reproducible in modern cloud networks? InProceedings of the 17th Usenix Conference on Networked Systems Design and Impl...

  63. [71]

    A review on the long short-term mem- ory model

    Greg Van Houdt, Carlos Mosquera, and Gonzalo Nápoles. A review on the long short-term mem- ory model. Artificial Intelligence Review, 53(8):5929– 5955, 2020

  64. [72]

    Cloud compute

    Vultr. Cloud compute. https://www.vultr.com/, Accessed:2025-04-20

  65. [73]

    Swarm: Cost-efficient video content distribution with a peer-to-peer system, 2024

    Dehui Wei, Jiao Zhang, Haozhe Li, Zhichen Xue, Yajie Peng, Xiaofei Pang, Rui Han, Yan Ma, and Jialin Li. Swarm: Cost-efficient video content distribution with a peer-to-peer system, 2024

  66. [74]

    Gonzalez, Vincent Liu, and Ion Stoica

    Sarah Wooders, Shu Liu, Paras Jain, Xiangxi Mo, Joseph E. Gonzalez, Vincent Liu, and Ion Stoica. Cloud- cast: High-Throughput, Cost-Aware overlay multicast in the cloud. In 21st USENIX Symposium on Networked Systems Design and Implementation, pages 281–296, Santa Clara, CA, April 2024

  67. [75]

    Xron: A hybrid elastic cloud overlay network for video conferencing at plan- etary scale

    Bingyang Wu, Kun Qian, Bo Li, Yunfei Ma, Qi Zhang, Zhigang Jiang, Jiayu Zhao, Dennis Cai, Ennan Zhai, Xuanzhe Liu, and Xin Jin. Xron: A hybrid elastic cloud overlay network for video conferencing at plan- etary scale. In Proceedings of the ACM SIGCOMM Conference, pages 696–709...

  68. [76]

    Can’t be late: Optimizing spot instance savings under deadlines

    Zhanghao Wu, Wei-Lin Chiang, Ziming Mao, Zongheng Yang, Eric Friedman, Scott Shenker, and Ion Stoica. Can’t be late: Optimizing spot instance savings under deadlines. In 21st USENIX Symposium on Networked Systems Design and Implementation, pages 185–203, Santa Clara, CA, April 2024

  69. [77]

    Cloud gaming

    Xbox. Cloud gaming. https://www.xbox.com/ en-US/cloud-gaming, Accessed:2025-04-24

  70. [78]

    Using overlay cloud net- work to accelerate global communications

    Zhaogui Xu, Ran Ju, Liang Gu, Weiguang Wang, Jin Li, Feng Li, and Lei Han. Using overlay cloud net- work to accelerate global communications. In IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), pages 139–144, 2019

  71. [79]

    Snape: Reliable and low-cost computing with mixture of spot and on-demand vms

    Fangkai Yang, Lu Wang, Zhenyu Xu, Jue Zhang, Liqun Li, Bo Qiao, Camille Couturier, Chetan Bansal, Soumya Ram, Si Qin, Zhen Ma, Íñigo Goiri, Eli Cortez, Terry Yang, Victor Rühle, Saravan Rajmohan, Qingwei Lin, and Dongmei Zhang. Snape: Reliable and low-cost computing with mixtu...

  72. [80]

    Enhanc- ing resource management of the world’s largest PCDN system for On-Demand video streaming

    Rui-Xiao Zhang, Haiping Wang, Shu Shi, Xiaofei Pang, Yajie Peng, Zhichen Xue, and Jiangchuan Liu. Enhanc- ing resource management of the world’s largest PCDN system for On-Demand video streaming. In USENIX Annual Technical Conference (USENIX ATC), pages 951–965, Santa Clara, C...

  73. [81]

    Coin: Cost-efficient traffic engineering with various pricing schemes in clouds

    Gongming Zhao, Jingzhou Wang, Hongli Xu, Zhuolong Yu, and Chunming Qiao. Coin: Cost-efficient traffic engineering with various pricing schemes in clouds. In IEEE INFOCOM 2023-IEEE Conference on Computer Communications, pages 1–10. IEEE, 2023. 16 A Lyapunov Drift is Upper Bound...

Pith tools

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