-
Notifications
You must be signed in to change notification settings - Fork 942
Askrene: add Goldberg-Tarjan's MCF solver #8314
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Askrene: add Goldberg-Tarjan's MCF solver #8314
Conversation
Add log information about the runtime of getroutes. Changelog-None: askrene: add runtime of getroutes to the logs Signed-off-by: Lagrang3 <[email protected]>
Move the feature tuning algorithm to mcf.c, ie. the loops for searching a good mu and delay_feefactor to satisfy the problem constraints. We are looking to set the stage for an execution logic that allows for multiple choices of routing algorithms, mainly for experimenting without breaking the default working code. Changelog-None Signed-off-by: Lagrang3 <[email protected]>
Prefer the following programming pattern: do_getroutes(){ do_something1(); do_something2(); do_something3(); } rather than get_routes(){ do_something1(); do_something2(); } do_getroutes(){ get_routes(); do_something3(); } Changelog-None Signed-off-by: Lagrang3 <[email protected]>
Changelog-None Signed-off-by: Lagrang3 <[email protected]>
Refactor MCF solver: remove structs linear_network and residual_network. Prefer passing raw data to the helper functions. Changelog-None Signed-off-by: Lagrang3 <[email protected]>
The single path solver uses the same probability cost and fee cost estimation of minflow. Single path routes computed this way are suboptimal with respect to the MCF solution but still are optimal among any other single path. Computationally is way faster than MCF, therefore for some trivial payments it should be prefered. Changelog-None. Signed-off-by: Lagrang3 <[email protected]>
Changelog-Added: askrene: an optimal single-path solver has been added, it can be called using the developer option --dev_algorithm=single-path or by adding the layer "auto.no_mpp_support" Signed-off-by: Lagrang3 <[email protected]>
Changelog-None. Signed-off-by: Lagrang3 <[email protected]>
Changelog-None Signed-off-by: Lagrang3 <[email protected]>
Changelog-None Signed-off-by: Lagrang3 <[email protected]>
Pruning the network for a payment of 1M sats on the compressed gossmap To compute a payment route for 1M sats from node 3301 to the first 1000 nodes, it takes an average The average doesn't seem to match the plot shown, that's because there is a long tail of outliers |
Constraint the number of flow units to 1M and prune arcs that are provably not used in the MCF computation. Changelog-None. Signed-off-by: Lagrang3 <[email protected]>
56f81f4
to
35e1428
Compare
Changelog-None Signed-off-by: Lagrang3 <[email protected]>
729c253
to
4c0f508
Compare
Changelog-EXPERIMENTAL: askrene: add developer-only switch to compute optimal MCF routing using Goldberg-Tarjan's Cost Scaling algorithm. Signed-off-by: Lagrang3 <[email protected]>
4c0f508
to
43e2639
Compare
Very interesting change @Lagrang3 , I'm not sure I grasp all of the consequences though. Specifically approximating and pruning at the 1M size, does that have an impact on payments smaller than 1Msats? Or am I just not understanding the impact of this optimization? Also, should we mark this as a draft until we have experimented and proven the alternative approaches to be more performant? |
Hi @cdecker. Yes, let's make this a draft for the moment. The 1M magic number is the number of units the payment will be split at most. Some Min. Cost Flow algorithms do not care about how many flow units we use, but the default Why does it matter? I am trying to stabilize the solver's runtime by first limiting U, |
I think it would be better to split this PR in two. |
With this PR I want to make an algorithmic improvement to the MCF solve in askrene.
First: I would like to constrain the number of flow units to 1M by setting the accuracy of the solver
to the total payment amount divided by 1M. Some MCF algorithms like "successive shortest path" (SSP)
have theoretical complexity bounds that depend on that number.
Second: I would like to prune the set of arcs in the network. I can achieve this by setting a limit to the sum
of the arc capacities that correspond to the same channel to 1M, which is the maximum number of flow units
that we send from the source to the destination. Notice that due to the piece-wise linearization of the channel
cost function, one channel becomes several arcs in the MCF network, therefore we can discard the higher cost
arcs of a channel linearization if the lower cost arcs already sum up to 1M in flow capacity.
Third: I would like to add an experimental option to switch the algorithm of the MCF solver to the well
known and highly efficient "Cost Scaling" solution by Goldberg-Tarjan 1990 [1] with heuristics [2].
To use it you would add the parameter
dev_algorithm=goldberg-tarjan
, for example:Depends on #8299
[1] Finding Minimum-Cost Circulation by Successive Approximation. Goldberg and Tarjan. Mathematics of Operations Research, Vol. 15, No. 3 (1990), pp. 430--466.
[2] An efficient Implementation of a Scaling Minimum-Cost Flow Algorithm. Goldberg. Journal of Algorithms 22, 1--29 (1997).