Contract resource usage management

[sanity]

Goal

Peers attempt to relay contracts that they’re likely to receive requests for. Relaying means that the peer subscribes to contract updates and can then respond to requests for that contract immediately rather than forwarding the request.

Due to the small world network topology, peers are generally more likely to receive requests for contracts close to them.

Overview

• Peers track resource usage per-contract
• Resources include storage, bandwidth, CPU usage, memory
• Cost computed from resources according to cost function
• Peers advertise contracts they are relaying to neighbors, who may decide to relay them too

Cost function

A simple cost function that looks at each resource as a proportion of the total available to the peer and takes the maximum of these proportions:

$cost = max(storage_c /storage_t, bandwidth_c/bandwidth_t, cpu_c/cpu_t, memory_c/memory_t)$

• $resource_c$ = contract resource usage
• $resource_t$ = total resource availability

Relay decision

The peer's goal is to relay the contracts that maximize $requestRate / cost$, where $requestRate$ is the average number of requests per time interval.

New contracts will have an unknown $requestRate$, for these we use an isotonic regression to estimate the $requestRate$ for a given distance between the peer and the contract, assuming that the rate will be higher for closer contracts.

If the peer is exposed to a contract with an estimated $requestRate / cost$ higher than the worst currently related contract, the new contract replaces the existing one.

Related Issues

• While this mechanism tracks and managed resource usage per-contract, Peer resource usage balancing #4 describes a parallel mechanism that tracks and manages resource usage per-peer

[iduartgomez]

Re-prioritized since this involves modifying the network layer which we are not touching now until we have a more solid foundation on the contract API.

[sanity]

Should the total available include the proportion of that resource already used?

If not, then Locutus will be more concerned about resources that are constrained than those that aren't, which seems desirable but may have unintended consequences. It does mean that the requestRate/cost for each contract will need to be periodically recomputed and the contracts re-sorted, but that's probably necessary anyway.

[github-actions]

Pivotal Tracker story: https://www.pivotaltracker.com/story/show/184058031