discovery - [feature]: implement bandwidth based, daemon wide gossip rate limiting. #8902
Labels
brainstorming
Long term ideas/discussion/requests for feedback
enhancement
Improvements to existing features / behaviour
gossip
Is your feature request related to a problem? Please describe.
Today we rate limit based on the the number of messages a peer sends, within the syncer:
lnd/discovery/syncer.go
Lines 392 to 396 in 3526f82
With this, we're able to rate limit the messages sent during the interactive sync/reconciliation protocol, but not also what we'll send/recv from peers as a part of the normal gossip trickle.
We also rate limit based on the number of channel updates sent/recv'd:
lnd/discovery/gossiper.go
Lines 484 to 491 in 3526f82
These values were set long ago, and not properly tuned before settling in a value. These values also don't give users precise control w.r.t exactly how much bandwidth we'll dedicate to gossip data. By using more precise, yet global rate limiting, we'd also be able to give node operators first-class telemetry w.r.t how much bandwidth is actually being used for gossip.
This is a brainstorming issue to explore switching all the gossip related rate limiting to a stricter/simpler bandwidth based approach.
Describe the solution you'd like
Simplify and unify rate limiting, using Go's token bucket rate limiter. In other areas we set the limit based on the number of messages. Instead, I propose we set the limit based on a bytes/second target.
Implementation wise, we may want to have this closer to the peer, occupying the role of the current msg queue into the gossiper. we'll want to take care that we avoid unnecessary blocking and also compromising the uptime of an existing channel based on bandwidth based rate limiting.
The text was updated successfully, but these errors were encountered: