routing+routerrpc: improve prob. estimation for untried connections by joostjager · Pull Request #3462 · lightningnetwork/lnd

joostjager · 2019-09-04T16:20:28Z

This PR changes mission control to partially base the estimated probability for untried connections on historical results obtained in previous payment attempts. This prevents the payment loop from getting stuck in an area of the network that is not of good quality. It also incentivizes routing nodes to keep all
of their channels in good shape.

The configuration parameter --routerrpc.aprioriweight is a value in the range [0, 1] that defines to what extent historical results should be extrapolated to untried connections. Setting it to 1 will completely ignore historical results and always assume the configured a priori probability for untried connections. A value of 0 will ignore the a priori probability completely and only base the probability on historical results, unless there are none available.

Using this parameter, senders can configure how aggressive nodes should be penalized. A low a priori weight will make mission control switch quickly to using a different node if a tried node doesn't perform well. The downside of this is that the sender may miss out on low fee channels that could possibly complete the payment successfully.

Indirectly, the collective of senders also shapes the network with their settings of this parameter. When senders start to demand a higher performance from routing nodes, routing nodes need to meet that expectation in order to keep generating revenue.

joostjager · 2019-09-06T07:19:41Z

Did a bit of performance testing with and without these changes. With a clean mission control history, there is no noticeable difference. This is expected, because there are hardly iterations in the loop inside GetNodeProbability. For the test call to QueryRoutes, 330 nodes were visited and 7661 edges expanded.

To see a performance effect, it is probably needed to have a fully loaded mission control history. It is a question how likely this situation is, especially on low-powered devices where pathfinding performance becomes important. There is also a default limit to the mission control history of 1000 past payments, although this can be changed.

I tried a simulation of a full mission control by inserting 10 fake results for every node visited, but didn't see an effect either. Db access during path finding is likely still where time is mainly spent.

I'd propose to not prematurely add optimizations like caching of the node probability in this pr and first see what feedback we get on it from users. I've added another commit that logs useful performance metrics.

halseth · 2019-09-18T08:45:27Z

it's not entirely obvious to me what this formula is doing... care to add a more detailed comment on how the factor is different from the weight?

explanation added

halseth · 2019-09-18T08:52:09Z

this is the critical change of this PR. Would be nice to have some examples on how the resulting probability will look like given a few results. Maybe the examples can be given as unit tests for this formula?

In particular I'm interested in the scenarios we talked about earlier:
A node having 100s of untried channels, and 1 tried channel (success/failure)
A node having 100s of untried channels, and X tried channels (success/failure), where X is about 2-5
A node having few channels, and some result (say 3 channels, 2 failures/successes).

Extracted probability estimation from mission control and added more unit tests.

The number of untried channels isn't a factor in the calculation at all, so I can't write a unit test for that. Probability estimates are only based on previous payment results.

Roasbeef

Completed an initial surface-level pass. Will do another one focusing on the core estimation changes to ensure I fully grok them. Overall I think this is a step in the right direction, but wonder how we can test these assumptions in the wild, and also if it's too early to make a change like this given that as we know it, node operators aren't very sophisticated yet.

Roasbeef · 2019-09-20T02:04:54Z

If we have A <-> B <-> C and B failed, the incoming is A -> B and outgoing is B -> C?

Yes. Added helper variables to make this clearer.

joostjager · 2019-09-20T11:23:07Z

Completed an initial surface-level pass. Will do another one focusing on the core estimation changes to ensure I fully grok them. Overall I think this is a step in the right direction, but wonder how we can test these assumptions in the wild, and also if it's too early to make a change like this given that as we know it, node operators aren't very sophisticated yet.

We can always set the default a priori weight quite high, so the effect of this will be light initially. Give some time for users and operators to become aware of the new scoring.

halseth

I like the simplicity and conceived impact of this PR! I'm down with the current approach, deemed that we test it a bit to make sure we don't have any obvious regressions.

In addition to logging performance metrics as now, should we consider logging more (on trace) how the probabilities are calculated? I think we now log the final probability found for a channel, but not how it was calculated. Could maybe be useful to log whether it was calculated from a previous success, failure or node level failure?

halseth · 2019-09-27T06:56:51Z

set success=false in pairResult for clarity?

If I remember correctly, there were comments in other prs about not adding redundant initializers. Not sure what you standard is here.

Personally I like adding them (exceptions being nil initializers perhaps), and in this case I feel it makes sense, since an empty struct is not obvious what it means.

halseth · 2019-09-27T07:03:39Z

same comment about setting success=false

joostjager · 2019-09-30T11:08:13Z

Moved new querymcprob call to #3556

halseth

LGTM, but would be nice IMO to set success: false to more clearly indicate failure 😄

halseth · 2019-09-30T10:29:16Z

Can use this in indexing above.

See ae91eb7#r326447064

halseth · 2019-09-30T10:52:43Z

don't you agree that just from looking at this call it is not obvious that we are recording a failure here?

I've added constructors to make it more obvious without adding redundant field initializers.

halseth · 2019-09-30T10:57:02Z

name suggestion: history?

Moved to #3556 and renamed

Roasbeef · 2019-10-09T01:32:40Z

Why don't we thread through the amount of the HTLC that resulted in this failure at this stage?

We don't need it for this PR. Here it is intentionally set to zero, because it should be a penalty to any amount, not just >= amt.

Roasbeef · 2019-10-09T01:38:34Z

Why do we need to reverse the pair here? If I'm following, then the intention is to fail A -> B, not B <- A.

Prior context (in case it's hidden):

If we have A <-> B <-> C and B failed, the incoming is A -> B and outgoing is B -> C?

We intent to penalize as much as we can for a node level failure, including future outgoing traffic for this connection. The pair as it is returned by getPair is directed towards the failed node. Therefore we first reverse the pair.

Added this as comment.

guggero

Nice, clean PR! I was able to follow the changes quite easily even though the subject matter is very new to me. Only found a few nits in the code.

Not scope of this PR, just thoughts in general:
The main thing I'm not sure about are the memory and CPU time implications of these changes when we get to a larger number of channels/peers. It would be very useful if we had something like the "1 million channel project" for lnd.

To make it explicit whether a failure or a success result is instantiated.

This commit changes the in-memory structure of the mission control state. It prepares for calculation of a node probability. For this we need to be able to efficiently look up the last results for all channels of a node.

This commit modifies the interpretation of node-level failures. Previously only the failing node was marked. With this commit, also the incoming and outgoing connections involved in the route are marked as failed. The change prepares for the removal of node-level failures in mission control probability estimation.

Probability estimates are amount dependent. Previously we assumed an amount, but that starts to make less sense when we make probability more dependent on amounts in the future.

This commit changes mission control to partially base the estimated probability for untried connections on historical results obtained in previous payment attempts. This incentivizes routing nodes to keep all of their channels in good shape.

Roasbeef

LGTM 🏹

joostjager requested review from Roasbeef and cfromknecht as code owners September 4, 2019 16:20

joostjager force-pushed the mc-extrapolate branch from 95a93c8 to 4d4e209 Compare September 4, 2019 16:23

joostjager added incomplete WIP PR, not fully finalized, but light review possible mission control payments Related to invoices/payments routing labels Sep 4, 2019

joostjager requested review from halseth and removed request for Roasbeef and cfromknecht September 4, 2019 16:28

joostjager force-pushed the mc-extrapolate branch 2 times, most recently from b93992e to d80f08c Compare September 6, 2019 06:50

joostjager removed the incomplete WIP PR, not fully finalized, but light review possible label Sep 6, 2019

joostjager force-pushed the mc-extrapolate branch from 03c6ad6 to 9614d33 Compare September 11, 2019 12:59

joostjager mentioned this pull request Sep 12, 2019

routing: track amt ranges in mission control #3493

Merged

halseth suggested changes Sep 18, 2019

View reviewed changes

joostjager commented Sep 18, 2019

View reviewed changes

Comment thread routing/missioncontrol.go Outdated

joostjager force-pushed the mc-extrapolate branch 5 times, most recently from ef1b2e9 to 9316e0f Compare September 18, 2019 14:54

joostjager requested a review from halseth September 18, 2019 15:00

joostjager force-pushed the mc-extrapolate branch from 9316e0f to 4c01b5a Compare September 18, 2019 15:04

joostjager requested a review from cfromknecht September 19, 2019 06:21

Roasbeef requested changes Sep 20, 2019

View reviewed changes

joostjager force-pushed the mc-extrapolate branch from 4c01b5a to c315ee3 Compare September 25, 2019 10:06

halseth approved these changes Sep 27, 2019

View reviewed changes

joostjager force-pushed the mc-extrapolate branch 4 times, most recently from 00b3271 to 07e1ad1 Compare September 30, 2019 11:07

joostjager mentioned this pull request Sep 30, 2019

routerrpc: add queryprob rpc #3556

Merged

halseth approved these changes Sep 30, 2019

View reviewed changes

joostjager force-pushed the mc-extrapolate branch from 07e1ad1 to ac28dd3 Compare September 30, 2019 17:55

halseth reviewed Oct 1, 2019

View reviewed changes

Comment thread routing/result_interpretation.go Outdated

Comment thread routing/missioncontrol.go Outdated

Comment thread routing/pathfind.go Outdated

joostjager force-pushed the mc-extrapolate branch from ac28dd3 to 414a5f1 Compare October 4, 2019 09:49

joostjager added the v0.9.0 label Oct 8, 2019

joostjager added this to the 0.9 milestone Oct 8, 2019

Roasbeef requested changes Oct 9, 2019

View reviewed changes

joostjager force-pushed the mc-extrapolate branch 3 times, most recently from ed598c0 to a0b76b6 Compare October 9, 2019 12:09

joostjager requested a review from Roasbeef October 9, 2019 12:10

joostjager force-pushed the mc-extrapolate branch from a0b76b6 to 24e3299 Compare October 9, 2019 12:16

joostjager requested a review from guggero October 21, 2019 09:13

guggero approved these changes Oct 22, 2019

View reviewed changes

Comment thread routing/missioncontrol.go Outdated

Comment thread routing/missioncontrol_test.go Outdated

Comment thread routing/probability_estimator.go Outdated

Comment thread routing/probability_estimator.go Outdated

Comment thread routing/probability_estimator_test.go Outdated

joostjager added 7 commits October 22, 2019 15:52

routing/test: extract mission control test parameters

37ef46b

routing: use pairResult constructors

aefbee7

To make it explicit whether a failure or a success result is instantiated.

routing: change representation of pair results in mc

a3f7dbc

This commit changes the in-memory structure of the mission control state. It prepares for calculation of a node probability. For this we need to be able to efficiently look up the last results for all channels of a node.

routing: create mc getWeight method

843c87a

routing+routerrpc: remove probability estimates from mc state snapshot

fab1390

Probability estimates are amount dependent. Previously we assumed an amount, but that starts to make less sense when we make probability more dependent on amounts in the future.

joostjager force-pushed the mc-extrapolate branch from 24e3299 to 1fac41d Compare October 22, 2019 13:52

Roasbeef approved these changes Oct 23, 2019

View reviewed changes

Roasbeef merged commit 8ed7583 into lightningnetwork:master Oct 23, 2019

Conversation

joostjager commented Sep 4, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

joostjager commented Sep 6, 2019

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Roasbeef left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

joostjager Sep 27, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

joostjager commented Sep 20, 2019

Uh oh!

halseth left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

joostjager commented Sep 30, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

halseth left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

joostjager Sep 30, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

joostjager commented Sep 4, 2019 •

edited

Loading

joostjager Sep 27, 2019 •

edited

Loading

joostjager commented Sep 30, 2019 •

edited

Loading

joostjager Sep 30, 2019 •

edited

Loading