resource manager trait and impl#4409
Conversation
|
👋 Thanks for assigning @carlaKC as a reviewer! |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4409 +/- ##
==========================================
+ Coverage 86.03% 86.20% +0.17%
==========================================
Files 156 157 +1
Lines 103091 104983 +1892
Branches 103091 104983 +1892
==========================================
+ Hits 88690 90500 +1810
- Misses 11891 11933 +42
- Partials 2510 2550 +40
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
carlaKC
left a comment
carlaKC
left a comment
There was a problem hiding this comment.
Really great job on this! Done an overly-specific first review round for something that's in draft because I've taken a look at previous versions of this code before when we wrote simulations. Also haven't looked at the tests in detail yet, but coverage is looking ✨ great ✨ .
I think that taking a look at tracking slot usage in GeneralBucket with a single source of truth is worth taking a look at, seems like it could clean up a few places where we need to two hashmap lookups one after the other.
In the interest of one day fuzzing this, I think it could also use some validation that enforces our protocol assumptions (eg, number of slots <= 483).
|
👋 The first review has been submitted! Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer. |
|
think I have addressed most of the comments code-wise. Still need to add some requested comments/docs changes. |
|
pushed more fixups addressing requests for adding docs/comments, lmk if those look good |
lightning/src/ln/resource_manager.rs
Outdated
| /// Tracks the occupancy of HTLC slots in the bucket. | ||
| slots_occupied: Vec<bool>, | ||
|
|
||
| /// SCID -> (slots assigned, salt) | ||
| /// Maps short channel IDs to an array of tuples with the slots that the channel is allowed | ||
| /// to use and the current usage state for each slot. It also stores the salt used to | ||
| /// generate the slots for the channel. This is used to deterministically generate the | ||
| /// slots for each channel on restarts. | ||
| channels_slots: HashMap<u64, (Vec<(u16, bool)>, [u8; 32])>, |
There was a problem hiding this comment.
this shouldn't accidentally double-assign them.
Yeah it shouldn't (provided we don't have bugs), but tracking the same information (whether a slot is occupied) in multiple places is a design that allows for inconsistency / the possibility of bugs. If we have a single source of truth, we move from "shouldn't double assign" to "can't double assign".
Gave it a shot here, lmk what you think!
| let general_liquidity_allocation = | ||
| liquidity_allocated * general_slot_allocation as u64 / slots_allocated as u64; |
There was a problem hiding this comment.
Error if slots_allocated is zero otherwise we'll panic? Could happen with really small max in flight + general not given that much space?
| } | ||
|
|
||
| let elapsed_secs = (timestamp_unix_secs - self.last_updated_unix_secs) as f64; | ||
| self.value = (self.value as f64 * self.decay_rate.powf(elapsed_secs)).round() as i64; |
There was a problem hiding this comment.
Would it help some of our borrow checker awkwardness (needing mut incoming and outgoing channel) if we didn't update our value here? We could make this &self and return the new value but not actually mutate the state?
|
First of all not sure why all your commit messages are line-wrapped at 40 chars, but you can use like 60 or 70 lol. |
TheBlueMatt
left a comment
TheBlueMatt
left a comment
There was a problem hiding this comment.
A few comments, I think the design is fine, but startup resync may be annoying.
| } | ||
| } | ||
|
|
||
| /// Tracks an average value over multiple rolling windows to smooth out volatility. |
There was a problem hiding this comment.
I'm kinda confused by this struct. First of all, the docs here are wrong - we aren't tracking "multiple windows" we're tracking a rolling average over one window of window * window_count. The only difference between this and DecayingAverage is it tries to compensate for if we don't have enough data to actually go back window_count * window. Why shouldn't we just have DecayingAverage do that instead of having a separate struct here?
There was a problem hiding this comment.
I think it makes sense to keep separate because the use of DecayingAverage for reputation differs from AggregatedWindowAverage when tracking revenue. For reputation, we want the DecayingAverage over the full window (24 weeks). For revenue, using AggregatedWindowAverage, we track the decaying average over the same window (24 weeks) but divide by window_count because we want the revenue for 2 weeks.
| struct DecayingAverage { | ||
| value: i64, | ||
| last_updated_unix_secs: u64, | ||
| window: Duration, |
There was a problem hiding this comment.
You don't actually use window (only decay_rate) so we can drop it here.
There was a problem hiding this comment.
yeah, I was keeping window for the decay_rate when reading back here https://github.com/elnosh/rust-lightning/blob/90943195bee498f34247f65a68a8511d57997aae/lightning/src/ln/resource_manager.rs#L1042-L1045
| // We are not concerned with the rounding precision loss for this value because it is | ||
| // negligible when dealing with a long rolling average. | ||
| Ok((self.aggregated_revenue_decaying.value_at_timestamp(timestamp_unix_secs)? as f64 | ||
| / window_divisor) |
There was a problem hiding this comment.
I don't buy this? Let's say our windows_tracked is 4 and we have some data for the last 3 windows. On average, those 3 windows worth of data data will have been multiplied by 0.62175 (https://www.wolframalpha.com/input?i=%28integral+from+0+to+3+%280.5+%5E+0.5%29+%5E+x%29+%2F+3) but then we divide it by three. Whereas if we only have data for a single-window, that data will multiplied by, on average, 0.845111 (https://www.wolframalpha.com/input?i=%28integral+from+0+to+1+%280.5+%5E+0.5%29+%5E+x%29+%2F+1), and then we'll divide by one. We have to factor in the decrease in the data from the decay as well as just the increased amount of data here.
lightning/src/ln/resource_manager.rs
Outdated
| /// Tracks the occupancy of HTLC slots in the bucket. | ||
| slots_occupied: Vec<bool>, | ||
|
|
||
| /// SCID -> (slots assigned, salt) | ||
| /// Maps short channel IDs to an array of tuples with the slots that the channel is allowed | ||
| /// to use and the current usage state for each slot. It also stores the salt used to | ||
| /// generate the slots for the channel. This is used to deterministically generate the | ||
| /// slots for each channel on restarts. | ||
| channels_slots: HashMap<u64, (Vec<(u16, bool)>, [u8; 32])>, |
There was a problem hiding this comment.
Does the protection algorithm break if slots are allocated probabilistically? We could reduce implementation complexity a good bit if we just drop channel_slots entirely and generate the list of slots the channel can occupy any time we need it and allow two channels to occupy the same slot (presumably leading to some extra HTLC failures in that case?). This feels very much like a bloom filter problem where we should be able to reduce FPs somehow, though maybe it isn't quite the same because we actually do want conflicts to be "common".
lightning/src/ln/resource_manager.rs
Outdated
| } | ||
| } | ||
|
|
||
| impl Readable for DefaultResourceManager { |
There was a problem hiding this comment.
Hmmmmmmmmmmmmmmmmmmm. Reconciliation on startup is gonna be tricky here. What happens if we accept an HTLC then restart and actually it never made it to disk in the ChannelMonitor? Theoretically this can be persisted as a part of ChannelManager and it should be consistent-ish, but Val is hard at work making it so that we don't have to persist ChannelManager at all.
Instead, I wonder how easy we can make it to rebuild this from HTLC information. It would require some additional integration into "LDK core" but hopefully not much. If we have some HTLCSlotUsage struct that we return from add_htlc in the ForwardingOutcome::Forward case, we could presumably shove that into the HTLCSource (as the lots are "on" the inbound channel) and rebuild the resource manager very cheaply.
There was a problem hiding this comment.
What happens if we accept an HTLC then restart and actually it never made it to disk in the
ChannelMonitor? Theoretically this can be persisted as a part ofChannelManagerand it should be consistent-ish, but Val is hard at work making it so that we don't have to persistChannelManagerat all.
hmmmm yeah I thought about that but was operating under the assumption that by persisting along with the ChannelManager it should stay consistent.
In a world where we don't persist the ChannelManager I was exploring your suggestion to rebuild the resource manager from HTLC data we have on startup and came up with the approach here: elnosh@cdd0bf8 With some caveats, I think we can replay HTLCs by calling add_htlc on the ResourceManager so we would only need general HTLC information and no need to shove bucket/resourcemanager specific information into HTLCSource. We would basically need this HTLC info on startup. I added 2 helper methods in channel.rs and the replay on the ChannelManager could look like this https://github.com/elnosh/rust-lightning/blob/cdd0bf80cb200d370995c4f859645c0a54b3a798/lightning/src/ln/channelmanager.rs#L19303-L19366
With this, I was able to restart a node with pending HTLCs and replayed them fine in the resource manager using Channel data. The only field I would need to add to HTLCSource is incoming_accountable
The caveat is that reputation and in-flight-risk when replaying the HTLCs might be somewhat (slightly) different if the shutdown time was long because the current timestamp is different.
Another approach would be to store the specific bucket usage in the HTLCSource so we replay HTLCs and add them directly to the bucket they were before shutdown. I went with previous approach mentioned since I think that will be less intrusive in the channel manager and would require less resourcemanager-specific information to leak into the channel manager. Let me know what you think
There was a problem hiding this comment.
My only question there is what the performance cost is. If we have 500 channels and have to replay a hundred HTLCs per channel how bad does it get?
There was a problem hiding this comment.
I'd have to run it but, indeed, it is not optimal because for each outbound HTLC in each channel it needs to lookup the inbound htlc on the incoming channel. It could store the missing fields in the HTLCSource as well to avoid the inbound htlc lookup.
Implements a decaying average over a rolling window. It will be used in upcoming commits by the resource manager to track reputation and revenue of channels.
The RevenueAverage implemented here will be used in upcoming commits to track the incoming revenue that channels have generated through HTLC forwards.
Resources available in the channel will be divided into general, congestion and protected resources. Here we implement the general bucket with basic denial of service protections. Co-authored-by: Carla Kirk-Cohen <kirkcohenc@gmail.com>
Resources available in the channel will be divided into general, congestion and protected resources. Here we implement the bucket resources that will be used for congestion and protected.
The Channel struct introduced here has the core information that will be used by the resource manager to make forwarding decisions on HTLCs: - Reputation that this channel has accrued as an outgoing link in HTLC forwards. - Revenue (forwarding fees) that the channel has earned us as an incoming link. - Pending HTLCs this channel is currently holding as an outgoing link. - Bucket resources that are currently in use in general, congestion and protected.
Trait that will be used by the `ChannelManager` to mitigate slow jamming. Core responsibility will be to track resource usage to evaluate HTLC forwarding decisions.
Introduces the DefaultResourceManager struct. The core of methods that will be used to inform the HTLC forward decisions are add/resolve_htlc. - add_htlc: Based on resource availability and reputation, it evaluates whehther to forward or fail the HTLC. - resolve_htlc: Releases the bucket resources used from a HTLC previously added and updates the channel's reputation based on HTLC fees and resolution times.
Adds write and read implementations to persist the DefaultResourceManager.
|
I have pushed changes for majority of comments from last round - diff here. The most notable things are:
|
4 participants
Part of #4384
This PR introduces a
ResourceManagertrait andDefaultResourceManagerimplementation of that trait which is based on the proposed mitigation in lightning/bolts#1280.It only covers the standalone implementation of the mitigation. I have done some testing with integrating it into the
ChannelManagerbut that can be done separately. As mentioned in the issue, the resource manager trait defines these 4 methods to be called from the channel manager:add_channelremove_channeladd_htlcresolve_htlcIntegrating into the
ChannelManagerThe
ResourceManageris intended to be internal to theChannelManagerrather than users instantiating their own and passing it to aChannelManagerconstructor.add/remove_channelshould be called when channels are opened/closed.add_htlc: When processing HTLCs, the channel manager would calladd_htlcwhich returns aForwardingOutcometelling it whether to forward or fail the HTLC along with the accountable signal to use in case that it should be forwarded. For the initial "read-only" mode, the channel manager would log the results but not actually fail the HTLC if it was told to do so. A bit more specific on where it would be called: I think it will be when processing theforward_htlcsbefore we queue theadd_htlcto the outgoing channelrust-lightning/lightning/src/ln/channelmanager.rs
Line 7650 in caf0aac
resolve_htlc: Used to tell back theResourceManagerthe resolution of an HTLC. It will be used to release bucket resources and update reputation/revenue values internally.This could have more tests but opening early to get thoughts on design if possible
cc @carlaKC