Feature request: channel prefrence when there are parallel channels

[lnd-routing]

It would be useful for managing liquidity if there was a way to prefer a certain channel when routing payments to a peer with 2 or more in parallel. There are times we would like to deplete a smaller one prior to closing it when replacing with a larger channel, or when using private channels in order to avoid channel churn with nodes that tend to drain liquidity.

[lnd-routing]

Reading some of the htlcswitch code, the simplest way to add this may be to add a prefer-private/public option and a prefer-smaller/larger option, instead of picking a random link. destination := destinations[rand.Intn(len(destinations))] in switch.go.

[C-Otto]

I'd love to see this feature. Right now I have six channels to bfx-lnd0. While I think some of this is caused by imperfect channel management on my side, in general I see the need to have (and, eventually, close) parallel channels.

For a routing node I think that channels either are long-lived (and we don't need to think about optimizing balance distribution because it doesn't really matter), or that channels need to be closed once they are drained (so that the peer at the other side gets on-chain access to the funds).

Based on these thoughts I see at least four additional options:

1. prefer sending through private channels so that these can be opened/closed without anyone noticing, benefiting from the age and public gossip knowledge of the (single) public channel
2. prefer sending through younger channels (similar to above: keep old channels around because they are well known)
3. prefer sending through older channels (because they may use older features, and require lots of DB storage (see channel.db is over 1.5gb after DeleteAllPayments and recompacting! Can I do anything else? #5705 (comment)))
4. prefer sending through channel with lowest local liquidity (so that closing channels can be done faster)
5. random (status quo)

This is somewhat related to #5972 as it touches the same part of the code.

Configuring this in a meaningful way without cluttering the config file and introducing lots of branches in the code may be tricky, though. I think a global option, possibly with overrides for each peer/pubkey, would help a lot.

[alexbosworth]

Another option could be to allow for reallocating liquidity between channels in a negotiation with your peer

[C-Otto]

Oh that would be absolutely perfect. However, I believe some kind of protocol extension would be necessary for this. I'll raise an issue in the spec repository, so that we approach this issue from two sides. Thank you a lot for the suggestion!