Large-Scale Network Utility Maximization via GPU-Accelerated Proximal Message Passing

Akshay Sreekumar; Anthony Degleris; Ram Rajagopal

REVIEW 3 major objections 5 minor 19 references

Large-Scale Network Utility Maximization via GPU-Accelerated Proximal Message Passing

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

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Proximal message passing on a GPU solves network utility maximization with tens of millions of variables, outpacing conic solvers by 4–20x.

desk verdict Solid ADMM-extension for GPU NUM with real performance claims, but the missing stopping tolerance and lack of solution-quality checks make the speedups unverifiable as reported. read the letter →

arxiv 2509.10722 v1 pith:VG3KO7UB submitted 2025-09-12 math.OC cs.NIcs.SYeess.SY

Akshay Sreekumar , Anthony Degleris , Ram Rajagopal This is my paper · ORCID

classification math.OCcs.NIcs.SYeess.SY MSC 90C2590C35

keywords networkutilitymaximizationproximalmessagepassingADMMGPUaccelerationproportionalfairnessresourceallocationlarge-scaleconvexoptimizationsparsematrix-vectorproducts

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

This paper claims that network utility maximization (NUM)—the problem of fairly allocating network resources across streams under link capacities—can be solved at unprecedented scale by recasting it as a bipartite graph and applying proximal message passing, an ADMM variant. The method needs only sparse matrix–vector multiplications with the link–route matrix and closed-form proximal updates, so every stream and link update is embarrassingly parallel and GPU-friendly. It handles both linear and logarithmic utilities (weighted proportional fairness) and does not require strict concavity. On a single A100 GPU, the authors report solving instances with 10 million links and 5 million streams in about half an hour, with 4–20x speedups over MOSEK, Clarabel, and CuClarabel, and success on problem sizes that exhaust the baselines' memory. If correct, this makes fair resource allocation tractable at Internet and transit-network scale.

What carries the argument

The bipartite-graph reformulation with terminal flows, and the closed-form proximal operators it enables. Each stream and slack stream owns a local copy of its terminal flows; each link enforces flow balance through an indicator function. ADMM on this consensus form reduces to proximal device updates and scaled price updates. The workhorse identities are the closed-form prox for logarithmic-utility streams, linear-utility streams, and slack streams, which turn the algorithm into sparse matrix–vector products and elementwise operations. Grouping streams by utility type and terminal count allows fully vectorized GPU updates.

What would settle it

Run the same benchmark suite on a real or realistic congested network with m≈2×10^5 links and dense rows (e.g., 50% of streams per congested link) and compare wall-clock time to CuClarabel and MOSEK at the same accuracy; if the speedup drops below 4x or the method fails to reach primal/dual residuals below 10^-4, the central scaling claim is contradicted.

Watch

Extended reading notes

Core claim

The central discovery is that the NUM problem, written with slack variables as a flow-balance system, becomes a separable ADMM problem when viewed as a bipartite graph of traffic streams, slack streams, and links joined by terminals. The resulting proximal message passing iterations consist of two operations: a proximal update for each stream—available in closed form for log utilities, linear utilities, and slack streams—and a scaled price update per link that is just an average of incident terminal flows. Because both operations are either elementwise or sparse matrix–vector products, the entire algorithm vectorizes across streams and links on a GPU. The authors implement this and show that

Load-bearing premise

The 4–20x speedup and memory-scaling results are demonstrated on randomly generated uncongested networks with an average of 10 links per stream; if realistic NUM instances have denser routes or significant congestion, convergence slows and the headline performance numbers may not hold.

Editorial extensions

If this is right

Logarithmic-utility NUM, previously a conic program with exponential cone constraints, can be solved with closed-form proximal updates and no interior-point linear algebra.
Instances with tens of millions of variables and constraints fit on a single GPU, whereas MOSEK, Clarabel, and CuClarabel run out of memory beyond about 5×10^5 links in these benchmarks.
Warm-starting from a previous allocation gives roughly 5x speedup under capacity degradation, and combining pruning with warm-start gives roughly 10x speedup when links fail.
The method supports heterogeneous utility functions beyond log and linear, as long as each has a simple proximal operator, so the same machinery covers other α-fair allocations.

Reading between the lines

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

Editorial inference: If the scaling claims transfer to real topologies, the practical bottleneck shifts from solving NUM to modeling it; operators could re-run proportional-fair allocations in near real time after network changes.
Editorial inference: The headline speedups are measured on uncongested synthetic networks with average 10 links per stream; on dense or heavily congested networks the sparse-matrix advantage shrinks and convergence slows, so the 4–20x range is likely an upper bound for real deployments.
Editorial inference: A natural next test is to benchmark against restarted PDHG solvers on the same log-utility problems once those solvers are extended to exponential cones; PMP's closed-form prox may retain an edge because it avoids cone projections.
Editorial inference: Because the proximal operators are elementwise, the method could be extended to streaming or online settings where rates are updated as network conditions change, rather than recomputed from scratch.

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.

Desk Editor's Note

read the letter

The thing to know: this is a legitimate extension of GPU-accelerated proximal message passing from DC-OPF to NUM, with correct proximal operator derivations and a sensible GPU implementation. The performance story is plausible but not fully supported, because the paper never states the absolute tolerance used in its stopping criterion and never reports objective values or feasibility violations at termination. The stress-test concern lands.

What is genuinely new: adapting the PMP framework of [17] to logarithmic and linear utilities, plus slack streams, is a useful step. The proximal updates in Section III.E are algebraically correct, and the vectorized scatter/gather implementation is a real engineering contribution. The transit case study is a nice illustration of how shadow prices explain allocations. The warm-start results under link degradation are also a practical plus.

The soft spots are specific and addressable. First, the termination rule in (17) depends on ε_abs, but the value of ε_abs is never given. Since the residual threshold scales with sqrt(|J|), a loose ε_abs can let the solver stop at materially infeasible or suboptimal points. The paper's own figure only shows residual trajectories for one uncongested instance; it does not establish what tolerance was used for the reported 4–20x speedups. Without solution-quality data, the claim that the method "solves" instances that exhaust baseline memory is not supported. Second, the benchmark compares against MOSEK and Clarabel at their default low-accuracy settings, but PMP's low-accuracy setting is not defined, so the comparison is not apples-to-apples. Third, the paper says the implementation is open-source but gives no repository or code, so Fig. 2 and the largest-instance numbers cannot be independently reproduced. These are not fatal flaws; they are missing details that a serious referee should require.

The reader's skepticism about the synthetic instance generator is fair but minor. The paper does describe how R is generated (average 10 links per stream) and congestion is modeled as dense rows. A robustness study across different sparsity and congestion patterns would strengthen the generality claims, but the central algorithm does not depend on a particular generator.

Who this is for: anyone working on large-scale NUM in networking or transit who needs a practical GPU solver. The algorithm is sound and the extension is valuable. With code, a stated ε_abs, and solution-quality verification, this could be a useful paper. I would send it to peer review and ask for those additions.

Referee Report

3 major / 5 minor

Summary. The paper presents a GPU-accelerated proximal message passing (PMP) algorithm for large-scale network utility maximization (NUM). The method is an ADMM variant that reformulates NUM as a bipartite graph of streams, links, and terminals, and solves it using closed-form proximal updates for logarithmic, linear, and slack utility streams. The authors implement the method in PyTorch and report speedups of 4x to 20x over MOSEK, Clarabel, and CuClarabel on synthetic uncongested instances with up to m=1e7 links and n=5e6 streams, as well as robustness to congestion, warm-starting under link degradation, and a time-expanded transit seat allocation case study.

Significance. If the empirical claims are substantiated, the paper would be a useful practical contribution: it adapts a recognized ADMM variant to NUM with logarithmic and linear utilities, provides closed-form proximal operators, and demonstrates that element-wise GPU operations and sparse matrix-vector products are sufficient to scale to tens of millions of variables and constraints. The algebraic derivations in Section III.E are correct, and the implementation strategy of grouping streams by type and scattering averages is sensible. However, the current empirical validation is not yet at the standard needed to support the headline speedup and memory-scaling claims, because the stopping tolerance is unspecified and no solution-quality metrics are reported.

major comments (3)

[Sec. III.F, Eq. (17); Sec. V.B] The termination criterion is epsilon_tol = epsilon_abs sqrt(|J|), but the value of epsilon_abs used in the experiments is never stated. For the m=1e7, n=5e6 instance, |J| is about 6e7, so sqrt(|J|) is about 7.7e3; even epsilon_abs=1e-6 permits a residual norm near 7.7e-3. No objective values, feasibility violations, or optimality gaps are reported for any benchmark, so the claims that PMP 'solves' instances that exhaust baseline memory and achieves 4x-20x speedups may be partly an artifact of early stopping. Please report epsilon_abs, final residual norms, and objective/feasibility compared with a reference solution for at least a subset of problems.
[Sec. V.B, Fig. 2] The baseline comparison is not apples-to-apples unless solver accuracy settings are specified. The text says all solvers are run with 'low-accuracy settings unless otherwise stated,' but gives no parameters for MOSEK, Clarabel, or CuClarabel. MOSEK returns NaN on three instances, which may reflect the chosen low-accuracy configuration. Without reporting exact solver tolerances and verifying the quality of baseline solutions, the speedup ratios in Fig. 2 are not interpretable. State the precise settings and report objective/feasibility for all returned solutions.
[Sec. V.B, V.C] The scaling results are based on a single synthetic, uncongested generator, described only as 'average stream is comprised of 10 links.' The distribution of route lengths, capacities, weights, and random seeds are not given, and each data point appears to be a single run. The congested experiments show slower convergence (Fig. 3) but report no wall-clock times or final tolerances. Thus the generality of the headline speedups and the robustness-to-congestion claim are not established. Provide a detailed generator, multiple instances or error bars, and results in a congested or dense regime using the same stopping criterion.

minor comments (5)

[Sec. IV.D] The implementation is described as open-source, but no repository URL or version is given. Please provide a link or state explicitly that code will be released upon acceptance.
[Sec. III.G] The acceleration parameters are fixed choices (alpha=1.6, gamma=1.1, mu=2, update period 50). A short sensitivity study or guidance for selecting these parameters would help reproducibility and practical use.
[Fig. 2] The caption does not define DNF/OOM markers or explain the two MOSEK curves. Please add definitions and state which curves use low vs. full accuracy.
[Sec. VI] The transit case study solves a continuous relaxation and 'rounds as needed.' For discrete seat allocation, describe the rounding procedure and its effect on feasibility and suboptimality.
[Sec. III.B, III.E] The notation 1_{|σ|} is used without definition; define it as the all-ones vector. Also, 'J' is used both as the set of terminals and as its cardinality; consider distinguishing them.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the PMP derivation is a standard ADMM specialization, and the performance claims are measured against external solvers; the self-citation [17] is an implementation vehicle, not a load-bearing premise.

full rationale

The paper's derivation chain starts from a standard NUM formulation (Problem 2/3), introduces a bipartite terminal graph, recasts the problem as consensus form (Problem 9), and then follows the well-known ADMM route of [16] and [19] to obtain proximal message passing updates. Each step is supported by explicit equations: the stream costs in (5)-(7) are defined directly from the original utilities, the link indicator in (8) encodes the flow-balance constraints, and the proximal updates in (14)-(16) are closed-form solutions of the corresponding ADMM subproblems, not quantities fitted to data. The acceleration techniques (residual balancing, over-relaxation) are standard ADMM heuristics and are not presented as predictions. The benchmark claims are measured against external solvers (MOSEK, Clarabel, CuClarabel), so the speedup numbers are not derived from the algorithm's own assumptions. The only self-citation is [17], which is used as a GPU implementation vehicle for the PMP framework; the NUM-specific derivation relies on the external references [16] and [19]. No predicted quantity is fitted from the benchmark data, no uniqueness theorem is imported from the authors' previous work, and no known result is renamed. The absence of a reported ε_abs value and of solution-quality verification for the largest instances is a reproducibility/correctness concern, but it does not show that any equation reduces to its own input by construction. Therefore, no significant circularity is present.

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

The central claim rests on standard ADMM convergence theory, a PMP-to-ADMM equivalence borrowed from [16], and a synthetic benchmark generator. The only hand-tuned numbers are ADMM acceleration parameters and test-instance sparsity choices; none are fitted to produce a specific stated result, so circularity burden is low.

free parameters (4)

over-relaxation parameter alpha = 1.6
Section III-G.b: 'In our experiments, we find that alpha = 1.6 works well.' Tunes convergence rate.
residual balancing parameters gamma, mu, update period = gamma=1.1, mu=2, every 50 iterations
Section III-G.a: 'We set mu=2 and gamma=1.1 and update rho every 50 iterations.' Tuned by hand to improve convergence.
instance generation average links per stream = 10
Section V-B: 'assign links to streams such that the average stream is comprised of 10 links.' Determines sparsity of test instances; speedups depend on this.
congestion pattern = 0.1% of links connected to ~10% of streams
Section V-C: 'randomly select 0.1% of links and connect each to approximately 10% of streams.'

assumptions (3)

standard math ADMM converges for convex problems with closed proper convex objectives (Boyd et al. [19])
Section III-F: 'Because PMP is a variant of ADMM, we refer the reader to [19] for additional details on ADMM's convergence.' The splitting in Problem 9 is convex.
domain assumption The proximal message passing updates (11)-(12) are equivalent to the ADMM iterations for the bipartite graph formulation
Section III-D: 'Following [16], we further simplify the ADMM iterations above into proximal message passing.' The equivalence is taken from prior work, not re-derived here.
domain assumption Utility functions are concave and twice differentiable with simple proximal operators
Section II and III-E. Log and linear utilities satisfy this; the framework assumes other utilities have cheap proxes.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Large-Scale Network Utility Maximization via GPU-Accelerated Proximal Message Passing." pith.science (2026). https://pith.science/paper/VG3KO7UB

@misc{pith2026250910722,
  author       = {Pith},
  title        = {Pith review of: Large-Scale Network Utility Maximization via GPU-Accelerated Proximal Message Passing},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/VG3KO7UB}},
  note         = {Machine review of arXiv:2509.10722}
}

read the original abstract

We present a GPU-accelerated proximal message passing algorithm for large-scale network utility maximization (NUM). NUM is a fundamental problem in resource allocation, where resources are allocated across various streams in a network to maximize total utility while respecting link capacity constraints. Our method, a variant of ADMM, requires only sparse matrix-vector multiplies with the link-route matrix and element-wise proximal operator evaluations, enabling fully parallel updates across streams and links. It also supports heterogeneous utility types, including logarithmic utilities common in NUM, and does not assume strict concavity. We implement our method in PyTorch and demonstrate its performance on problems with tens of millions of variables and constraints, achieving 4x to 20x speedups over existing CPU and GPU solvers and solving problem sizes that exhaust the memory of baseline methods. Additionally, we show that our algorithm is robust to congestion and link-capacity degradation. Finally, using a time-expanded transit seat allocation case study, we illustrate how our approach yields interpretable allocations in realistic networks.

Figures

Figures reproduced from arXiv: 2509.10722 by the authors.

**Figure 1.** shows the corresponding bipartite graph. Traffic Stream 1 Traffic Stream 2 Traffic Stream 3 Link 1 Link 2 Link 3 Slack Stream 1 Slack Stream 2 Slack Stream 3 s1 − c1 s2 − c2 s3 − c3 x1 x2 x2 x3 [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗

**Figure 2.** Scaling performance of solvers on various problem sizes [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗

**Figure 4.** (a) Uncongested route lengths. (b) Uncongested link utilization. (c) Congested link utilization. [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗

Figures from the paper (2 more)

**Figure 5.** Figure 5: Warm starting under link degradation and failure [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]

**Figure 6.** Figure 6: Flows and link prices for two routes departing at [PITH_FULL_IMAGE:figures/full_fig_p006_6.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

19 extracted references · 3 linked inside Pith

[17]

GPU Accelerated Secu- rity Constrained Optimal Power Flow,

A. Degleris, A. E. Gamal, and R. Rajagopal, “GPU Accelerated Secu- rity Constrained Optimal Power Flow,” Oct. 2024, arXiv:2410.17203

arXiv 2024
[1]

Rate control for communication networks: shadow prices, proportional fairness and stability,

F. P. Kelly, A. K. Maulloo, and D. K. H. Tan, “Rate control for communication networks: shadow prices, proportional fairness and stability,”Journal of the Operational Research Society, vol. 49, pp. 237–252, Mar. 1998

1998
[2]

Maximizing Network Utility of Rechargeable Sensor Networks With Spatiotem- porally Coupled Constraints,

R. Deng, Y . Zhang, S. He, J. Chen, and X. Shen, “Maximizing Network Utility of Rechargeable Sensor Networks With Spatiotem- porally Coupled Constraints,”IEEE Journal on Selected Areas in Communications, vol. 34, pp. 1307–1319, May 2016

2016
[3]

A utility optimization approach to network cache design,

M. Dehghan, L. Massoulie, D. Towsley, D. Menasche, and Y . C. Tay, “A utility optimization approach to network cache design,” inIEEE INFOCOM 2016 - The 35th Annual IEEE International Conference on Computer Communications, Apr. 2016, pp. 1–9

2016
[4]

Maximizing network utility while considering proportional fairness for rail transit sys- tems: Jointly optimizing passenger allocation and vehicle schedules,

Y . Yin, D. Li, Z. Han, X. Dong, and H. Liu, “Maximizing network utility while considering proportional fairness for rail transit sys- tems: Jointly optimizing passenger allocation and vehicle schedules,” Transportation Research Part C: Emerging Technologies, vol. 143, p. 103812, Oct. 2022

2022
[5]

Network Optimization and Control,

S. Shakkottai and R. Srikant, “Network Optimization and Control,” Foundations and Trends® in Networking, vol. 2, pp. 271–379, Jan. 2008

2008
[6]

An Interior-Point Method for Large Scale Network Utility Maximization,

S. Boyd, D. O. Neill, N. Trichakis, and A. Zymnis, “An Interior-Point Method for Large Scale Network Utility Maximization,” Sep. 2007

2007
[7]

A Distributed Newton Method for Network Utility Maximization–I: Algorithm,

E. Wei, A. Ozdaglar, and A. Jadbabaie, “A Distributed Newton Method for Network Utility Maximization–I: Algorithm,”IEEE Transactions on Automatic Control, vol. 58, pp. 2162–2175, Sep. 2013

2013

Show all 19 references

[8]

A tutorial on decomposition methods for network utility maximization,

D. Palomar and M. Chiang, “A tutorial on decomposition methods for network utility maximization,”IEEE Journal on Selected Areas in Communications, vol. 24, pp. 1439–1451, Aug. 2006

2006
[9]

Dis- tributed large scale network utility maximization,

D. Bickson, Y . Tock, A. Zymnis, S. P. Boyd, and D. Dolev, “Dis- tributed large scale network utility maximization,” in2009 IEEE International Symposium on Information Theory, Jun. 2009, pp. 829– 833, iSSN: 2157-8117

2009
[10]

MOSEK Optimizer API for Python,

M. ApS, “MOSEK Optimizer API for Python,” 2025

2025
[11]

CuClarabel: GPU Acceleration for a Conic Optimization Solver,

Y . Chen, D. Tse, P. Nobel, P. Goulart, and S. Boyd, “CuClarabel: GPU Acceleration for a Conic Optimization Solver,” Dec. 2024, arXiv:2412.19027

2024
[12]

Practical Large-Scale Linear Programming using Primal-Dual Hybrid Gradient,

D. Applegate, M. Diaz, O. Hinder, H. Lu, M. Lubin, B. O’ Donoghue, and W. Schudy, “Practical Large-Scale Linear Programming using Primal-Dual Hybrid Gradient,” inAdvances in Neural Information Processing Systems, vol. 34. Curran Associates, Inc., 2021, pp. 20 243–20 257

2021
[13]

cuPDLP.jl: A GPU Implementation of Restarted Primal-Dual Hybrid Gradient for Linear Programming in Julia,

H. Lu and J. Yang, “cuPDLP.jl: A GPU Implementation of Restarted Primal-Dual Hybrid Gradient for Linear Programming in Julia,” Jun. 2024, arXiv:2311.12180

2024 arXiv
[14]

MPAX: Mathematical Programming in JAX,

H. Lu, Z. Peng, and J. Yang, “MPAX: Mathematical Programming in JAX,” Feb. 2025, arXiv:2412.09734

2025
[15]

Solving Large Multicommodity Network Flow Problems on GPUs,

F. Zhang and S. Boyd, “Solving Large Multicommodity Network Flow Problems on GPUs,” Apr. 2025, arXiv:2501.17996

2025 arXiv
[16]

Dynamic Network Energy Management via Proximal Message Passing,

M. Kraning, E. Chu, J. Lavaei, and S. Boyd, “Dynamic Network Energy Management via Proximal Message Passing,”Foundations and Trends® in Optimization, vol. 1, pp. 73–126, Dec. 2013

2013
[18]

Fair end-to-end window-based congestion control,

J. Mo and J. Walrand, “Fair end-to-end window-based congestion control,” inPerformance and Control of Network Systems II, vol. 3530. SPIE, Oct. 1998, pp. 55–63

1998
[19]

Distributed Optimization and Statistical Learning via the Al- ternating Direction Method of Multipliers,

S. Boyd, “Distributed Optimization and Statistical Learning via the Al- ternating Direction Method of Multipliers,”Foundations and Trends® in Machine Learning, vol. 3, pp. 1–122, 2010

2010

Pith tools

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

[1] [17]

GPU Accelerated Secu- rity Constrained Optimal Power Flow,

A. Degleris, A. E. Gamal, and R. Rajagopal, “GPU Accelerated Secu- rity Constrained Optimal Power Flow,” Oct. 2024, arXiv:2410.17203

arXiv 2024

[2] [1]

Rate control for communication networks: shadow prices, proportional fairness and stability,

F. P. Kelly, A. K. Maulloo, and D. K. H. Tan, “Rate control for communication networks: shadow prices, proportional fairness and stability,”Journal of the Operational Research Society, vol. 49, pp. 237–252, Mar. 1998

1998

[3] [2]

Maximizing Network Utility of Rechargeable Sensor Networks With Spatiotem- porally Coupled Constraints,

R. Deng, Y . Zhang, S. He, J. Chen, and X. Shen, “Maximizing Network Utility of Rechargeable Sensor Networks With Spatiotem- porally Coupled Constraints,”IEEE Journal on Selected Areas in Communications, vol. 34, pp. 1307–1319, May 2016

2016

[4] [3]

A utility optimization approach to network cache design,

M. Dehghan, L. Massoulie, D. Towsley, D. Menasche, and Y . C. Tay, “A utility optimization approach to network cache design,” inIEEE INFOCOM 2016 - The 35th Annual IEEE International Conference on Computer Communications, Apr. 2016, pp. 1–9

2016

[5] [4]

Maximizing network utility while considering proportional fairness for rail transit sys- tems: Jointly optimizing passenger allocation and vehicle schedules,

Y . Yin, D. Li, Z. Han, X. Dong, and H. Liu, “Maximizing network utility while considering proportional fairness for rail transit sys- tems: Jointly optimizing passenger allocation and vehicle schedules,” Transportation Research Part C: Emerging Technologies, vol. 143, p. 103812, Oct. 2022

2022

[6] [5]

Network Optimization and Control,

S. Shakkottai and R. Srikant, “Network Optimization and Control,” Foundations and Trends® in Networking, vol. 2, pp. 271–379, Jan. 2008

2008

[7] [6]

An Interior-Point Method for Large Scale Network Utility Maximization,

S. Boyd, D. O. Neill, N. Trichakis, and A. Zymnis, “An Interior-Point Method for Large Scale Network Utility Maximization,” Sep. 2007

2007

[8] [7]

A Distributed Newton Method for Network Utility Maximization–I: Algorithm,

E. Wei, A. Ozdaglar, and A. Jadbabaie, “A Distributed Newton Method for Network Utility Maximization–I: Algorithm,”IEEE Transactions on Automatic Control, vol. 58, pp. 2162–2175, Sep. 2013

2013