Discussion: Orchestrator Selection Optimisations

Nobody has claimed this yet.

**Abstract**
With the uptick of demand on the Livepeer network we get the ability to see how the network distributes work 'in the wild'. The recent addition of the Orchestrator performance leaderboard further gives us insight into which nodes are able to perform well. Recent observations indicate that nodes with similar performance metrics can earn a vastly different amount of fees due to the amount of stake they have.

In this thread I would like to kick off a discussion whether the current selection mechanism is sufficient and whether its goals need to be expanded.

**Current Mechanism**

To better understand which criteria the current selection mechanism prioritises let's give a quick overview (omitting some details that are not important for this discussion).

1. Broadcaster sends out a discovery request for orchestrator information (price, ticket parameters, ...) to all active orchestrators. Discard orchestrators that error out or that are too highly priced.
2. Broadcaster selects the `n` fastest responses (currently 8)
3. Broadcaster performs stake-weighted selection on the set of `n` Orchestrators from step 2
4. Broadcaster sends the segment to the select Orchestrator
5. If the Orchestrator can not transcode in realtime or errors out it will be removed from the set and another orchestrator from set will be selected
6. If the set of `n` orchestrators contains less than `n / 2` entries, select a new set of `n` orchestrators.

In order the selection criteria of this mechanism are as follows:
1. ping time
2. stake
3. transcode time (sub-realtime is sufficient)

This means that if you as an orchestrator have a consistently low ping time and a higher stake than most other orchestrators with low ping times you will win the most of the work as long as you're able to transcode in real-time as more work rolls in.

The goal of this mechanism is to prioritise performance.

**Additional Mechanism Goals**

The current selection mechanism actually accomplishes its goal very well of prioritising performance. The property of sticking with an orchestrator for the duration of a stream as long as it performs up to par is definitely desirable as it prevents unnecessary switching between orchestrators.

Stake weighted selection also seems desirable as it selects Orchestrators with skin in the game and is actually important for the token economics. If stake weren't a deciding factor the value proposition of staking LPT would diminish. On the flip side we also know that this can create a competitive hurdle that is hard for new Orchestrators with capable hardware to overcome.
In my opinion, the gist of the issue here is the **lack of alternative means of competition**.

One way for new entrants to compete on the network could be a more involved role for pricing in the selection mechanism. As less established nodes, they can build up a reputation by performing work at a lower cost which might attract more demand. While currently the Broadcaster sets a maximum price and selects discards orchestrators with higher pricing, it doesn't further optimise for cost.

Another less desirable selection criteria seems to be discovery ping times. While it is a way of avoiding selecting nodes that certainly aren't able to perform (e.g. time out , error, ...) its priority within the selection mechanism could for example be reconsidered.

**Alternatives**
There's also the question whether selection should be changed at all or if there's other things that can be done to distribute fees on the network a little more evenly since the network can still be considered in a bootstrapping phase and the current issues with selection might be temporary due to the fact that demand comes from one node and that stake distributions can significantly change over time as the network evolves.

The discussion names no files, tests, or implementation entry points. First clarify which orchestrator-selection goal or alternative should be pursued, then locate the relevant selection code and tests before defining measurable completion criteria.

Written by the indexing model from the issue text.