routing: track amt ranges in mission control

[joostjager]

Previously we tracked the last result for a node connection only. This could lead to the situation where a meaningful observation would be overwritten by a far less meaningful one. For example: a failure for 100.000 sats is overwritten by a success for 100 sats.

Besides better route selection in general, this also helps with building the bos node score list.

Probing with minimal amounts in particular will likely wipe out useful history for more representative amounts.

This PR changes mission control to track both that the success and the last failure. This creates three amount ranges for which probabilities are calculated differently:

• <=successAmt: return a high probability (default 0.95)
• successAmt+1 to failAmt-1: in this range, we don't have much information. Return the a priori (default 0.6)
• >=failAmt: penalize the connection and decay over time back to the a priori

[halseth]

Shouldn't SuccessTIme be used here,, similar to how FailTIme.IsZero is checked below?

[joostjager]

The condition can actually be removed. If there is no success recorded (or pushed down by an amt independent failure), successAmt will be zero and amt is always greater than zero.

[Roasbeef]

Can be rebased now that the dependent PR is merged.

[carlaKC]

Is this the amount that most recently failed, as in attempted to be forwarded= failed? Not clear from the comment what this represents, but I'm lacking a bit of context on this one.

[joostjager]

Not sure what you mean with 'attempted to be forwarded= failed'. But this is (usually) the amount of the last failure.

Comments fixed to explain this better.

[joostjager]

Ah, now seeing that this refers to the first commit. Removed the "(attempted to be)" part. It may not be that helpful, because there is also a success boolean in this struct.

[carlaKC]

nit: does this need a newline?

[joostjager]

which newline exactly do you mean?

[carlaKC]

All the params can fit on one line within 80 char limit
m.setLastPairResult(pair.From, pair.To, result.timeReply, &pairResult)

[joostjager]

Also with our standard tab size 8?

[carlaKC]

Is there an argument that scaling down the success amount makes sense, since larger success amounts may deplete the outgoing capacity on a channel? As is, a single large payment "vouches" for all amounts below it succeeding, even though we may not necessarily be seeing payments of this magnitude.

[joostjager]

Imo we should stay away from that kind of inference. There may be private channels that shadow a single public channel, which interferes with assumptions of that kind.

[carlaKC]

Happy with the logic as is, but I think it's worth adding a comment on TimedPairResult's SuccessTime to explicitly indicate that it is not necessarily matched with the SuccessAmount.

[halseth]

Mostly some questions and nits, nothing really blocking. Agree that adding some comments to TimedPairResult would be useful. Good PR :)

[halseth]

LGTM 💯