routing: process payment successes in mission control

[joostjager]

This PR modifies paymentLifecycle so that it not only feeds failures into mission control, but successes as well. This allows for more accurate probability estimates. Previously, the success probability for a successful pair and a pair with no history was equal. There was no force that pushed towards previously successful routes.

A fixed success probability is introduced for node pairs that proved to be successful on the previous payment attempt. This value could be exposed as a parameter in the future.

Furthermore the default a priori success probability (defines the probability for node pairs with no history) is lowered from 95% to a more realistic 60%. This wasn't possible before, because it would discourage longer routes too much. With the newly introduced "success success probability", only long routes consisting of unknown node pairs are avoided.

No database migration is needed, because we persist only the raw payment results and not the interpretation.

[wpaulino]

Changes LGTM, only have minor comments. My review is only of the relevant commit for this PR: b5ddcf8.

[joostjager]

Converted to parameterized tests and added one for incorrect payment details.

[wpaulino]

LGTM 💥

[wpaulino]

Currently failing travis though:

--- FAIL: TestMissionControl (0.01s)
missioncontrol_test.go:175: unexpected number of channels

[Roasbeef]

Only a few minor comments, and some brain storming for possible future directions. Dependent on another PR, so we'll need to wait until that goes in before we can proceed with this one.

[Roasbeef]

Shouldn't all nodes but the final have been marked as a success since they successfully forwarded?

[joostjager]

In case of ExpiryTooSoon, any of the nodes could have caused a delay triggering this failure.

[joostjager]

Currently failing travis though:

--- FAIL: TestMissionControl (0.01s)
missioncontrol_test.go:175: unexpected number of channels

Fixed

[joostjager]

Rebased after merge of #3256

[cfromknecht]

Changes LGTM ✅

Only thing that isn't immediately obvious is the constants, how much testing/validation has been done in the wild?

[joostjager]

Yes, valid concern. Those constants are set to something that looked reasonable to me, but there is no science behind it.

I spend quite some time to produce a test result that would show the benefit of the changes in this pr.

Approach:

• Try to pay to random (testnet) nodes with an unknown hash. The ones that reply with invalid_payment_details are logged in a file. I stopped when this file had 40 nodes in it. So those are nodes that I could pay to: the test set.
• Reset mission control
• Run a test where a unknown hash payment payment is made to each of those test set nodes. Payments are executed concurrently, but no more than 5 at the same time. This should really exercise mission control and provide path finding input.
• Count the number of payments attempts made by grepping on the lnd log. It took 66 attempts to complete the 40 payments.
• Repeat the same test on master. It needed 68 attempts.

No significant difference unfortunately. Intuitively I'd expect that accounting for successes should show up in the number of attempts needed, but with this test setup it doesn't. I tried with different amounts, but that didn't make much of a difference either.

My current theory is that there are not enough failures to make any improvement in mission control stand out. However, in other circumstances (mainnet, node connected to a bad cluster) it could make a difference. It isn't ideal though that I cannot demonstrate this.

One thing that I did get out of this test is that there apparently isn't a regression with the changes in this pr. Payment performance is about the same as before.

What I didn't test is the difference in performance over time. Because failures decay (and we need to decay them otherwise we may end up with an empty channel set), a mission control based on failures only will slowly forget everything it has seen. The decay speed can be tuned, but it remains a difficult parameter to pick. Success observations as they are introduced in this pr, do not decay. They keep the success probability of the channel high as long as no failure is observed. That means that this part of mission control's memory isn't forgetting. Therefore payment performance after a day (with default mission control half life time) could very well be noticably better for a successes-aware mission control.

[joostjager]

To validate that last hypothesis (performance over time), I did the following:

• Run the test as described above
• Re-running this test on master after a day would return the same score, because all mission control data would have decayed.
• With this pr, it should perform better because successes don't decay. To test this, I restarted lnd and set routerrpc.penaltyhalflife to 1 second. After lnd was started, I verified by running querymc that the failures were indeed decayed back to 60%. The success were still at 95%.
• I reran the test with mission control history from the first run of which the failures had decayed artificially fast.
• 42 payment attempts were needed, meaning every payment but two succeeded the first time.

So possibly the behavior over time is where the real win of this PR is.

[Roasbeef]

LGTM 🐲

[1043465747]

اريد بيانات وحسابات في البنوك المحليه والدولي والعالميه في السبت، ٢٤ أغسطس، ٢٠١٩ ٢:٣٣ ص Olaoluwa Osuntokun <notifications@github.com> كتب:

…

Merged #3372 <#3372> into master. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3372?email_source=notifications&email_token=AHZKIP6SYX2Y5KNBVB7VA2TQGBXU5A5CNFSM4IJIQ6WKYY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOTHL7OQA#event-2581067584>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHZKIP6YMLJAIRWQIE6ZI3LQGBXU5ANCNFSM4IJIQ6WA> .