[WIP] Askrene: add activation cost to channels#8543
[WIP] Askrene: add activation cost to channels#8543Lagrang3 wants to merge 1 commit intoElementsProject:masterfrom
Conversation
ec46c12 to
4fdd156
Compare
Add a base probability cost to simulate random channel outage and penalize for long paths or many routes solutions. Changelog-None Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
4fdd156 to
7e33340
Compare
|
Running some benchmarks I've realized that activation cost with this PR does tend to reduce the length of the path in the final solution but it was 0 effect on the number of parts. Let's see why: Activation costs does reduce path lengthLet's show this with two examples. Consider all arcs have the same activation cost of 1 and 0 proportional cost, and we wish to send F flow amounts from A to B. Solution 1.A---N1---N2---B In this case the cost of this solution is the sum of the activation cost for each arc Solution 2.A---N1---B In this case the cost of this solution is the sum of the activation cost for each arc Therefore solution 2 has less cost and thus it is preferred. Activation costs does reduce the number of partsLet's show this again with two examples. Consider all arcs have the same activation cost of 1 and 0 proportional cost, and we wish to send F flow amounts from A to B. Solution 1.A---N1---B In this case the cost of this solution is the sum of the cost for each part and the cost for each part is the sum of the activation costs for each arc involved Solution 2.A---N1---B In this case the cost of this solution is the cost of a single part which we compute by adding the activation costs for each arc involved Therefore solution 2 has less cost and thus it is preferred. Proportional cost does reduce path lengthLet's show this again with two examples. Consider all arcs have 0 activation cost and 1 of proportional cost, and we wish to send F flow amounts from A to B. Solution 1.A---N1---N2---B In this case the cost of this solution is the cost of sending each unit of flow along the given path Solution 2.A---N1---B In this case the cost of this solution is the cost of sending each unit of flow along the given path Therefore solution 2 has less cost and thus it is preferred. Proportional cost does NOT reduce the number of partsLet's show this again with two examples. Consider all arcs have 0 activation cost and 1 of proportional cost, and we wish to send F flow amounts from A to B. Solution 1.A---N1---B In this case the cost of this solution is the sum of the cost for each part and the cost for each part is the sum of the cost per unit of flow times the flow amount on the path Here we used the fact that F1+F2+F3 = F Solution 2.A---N1---B In this case the cost of this solution is the cost of a single part which we compute as the unit cost times the flow amount Therefore solution 1 and solution 2 have the same cost and thus a MCF solver will not prefer one over the other. In a proportinal-only flow problem the cost is the sum of the cost to send each unit of flow from A to B ConclusionActivation cost can be used to reduce path length and number of parts but if we had a solver that treat activation |
|
Closing this. We need a different computational approach to activation costs. |
With this PR we change the topology of the MCF problem to be able to add activation costs to channels.Use cases:- base fees,- constant probability of failure for channels,- reduction in the number of routes as well as their length,With this PR we add a simple approximation to channel activation cost by including a parameter
base_prob(in the range [0,1])that represents the probability of a channel being online and accepting forward requests.
The activation cost of the channel is linearized by simply assuming an extra cost per arc like:
where T is the total payment amount.
The smaller the value of
base_probthe less likely our solver will produce long paths or many routes solutions.Hence the caller can tune it to satisfy desired maxparts or maxlength constraints.
For this PR we borrowed the same methodology from renepay #7540.
It addresses one of the points raised in issue #8486.
base_probvalues