dnwiebe
commented
2 years ago Suggestion: When we begin receiving from or transmitting to a Node, we could start a timer; when the transaction is complete, we could stop the timer. Then we could calculate bytes per second for the transaction and use these measures to establish a performance measure for the Node.
Maybe something similar could be done to measure the time it takes to open a connection to the Node.
Performance banning is what we do to Nodes that in some way provide us with lower performance than we expect. This is so that we can maximize Network performance.
Characteristics of performance bans:
Performance bans are gradualist and “analog,” not binary on/off. The performance ban amounts to an aggregate score of all the performance problems (high latency, failure to respond) we experience from a Node. Some problems will score higher than others. The performance-ban number should be combined with the route price and the Node-not-used-since intervals to direct the Router when it generates routes.
The fact that we have performance-banned a Node should not affect our willingness to send it Gossip or to accept Gossip from it. It has not demonstrated malicious intent, merely incapacity.
Performance bans are keyed by IP address if possible, or node public key if not. A Node’s performance problems are not likely to be affected by stopping and restarting it; therefore if we can identify it by IP address, we can continue to draw value from its ban even if it is restarted.
Performance bans are transient: they should not survive from session to session. Once we restart, every Node in the nearby network gets another chance to establish its performance reputation.
Performance bans are reversible: if an underperforming Node is nonetheless chosen for routing because its prices have been reduced or because it hasn’t been used for a long time or because other Nodes have gotten even worse, and this time it performs well, that should positively affect its performance value.
Note: This card should probably be split.
Acceptance Criteria
Given I am a node When a node becomes unreliable Then I should ban it by storing its pub key
Given I am a node When another node is added to my blacklist Then I exclude it from my neighborhood for building future routes
Given I am a node When another node in my neighborhood is blacklisted Then I should exclude it from any current routes being used
Given I am a node When a reversal-mode CORES package arrives back at the Origin Node Then I will check the signature on the error report and immediately ban the failed node from the Neighborhood database (A separate card could probably be created to take care of verifying the failure report.)