"GeoDNS" without 3rd party centralized providers

[AuthorityNull]

Is your feature request related to a problem? Please describe. A lot of Orchestrators use 3rd part providers like AWS and Cloudflare to route streams to transcoders with the lowest latency.

Describe the solution you'd like Ideally, we should not be relying on providers like Amazon to support our infrastructure. A discussion in the discord opened up about how it may be possible to register multiple IP addresses on chain under the master orch address and have streams routed based on which IP responds the fastest. What would something like this take to integrate into Livepeer?

Describe alternatives you've considered There was also a discussion about ENS being able to incorporate similar features, but I think we're a few years away from seeing a stable solution there.

[Titan-Node]

I'd like to second this issue. Trying to add new nodes to the pool is quite difficult because I am optimizing for GEO-DNS routing for Livepeer Inc broadcaster only. Also the support for AWS latency based Geo location is poor in many regions, such as Africa.

I think the fix would look something like this:

1) Allow an O the provide a list of 100 endpoints as the on chain service URI. (I think there should be a cap to reduce spam/load) Maybe as a JSON or comma delineated list.

2) During the initial startup of the Broadcaster (or during the initial selection process) the B would ping all listed endpoints of each Orch. Of the returned results, the fastest endpoint would be the primary endpoint for that Orch (kept in memory to speed up future requests)

Some research that would be good to evaluate would be to test the load of getting 10,000 endpoints. Since 100 Os can list 100 endpoints. Possibly trying to get all 10,000 endpoint data at the same time in one pipe will cause inaccurate results?

In conclusion: This mainly came up because of requests of getting Livepeer services in Japan. As a pool I want to provide a much larger area of service to Bs and utilizing AWS for a piece of this stack seems unnecessary.

Let's decentralize and expand the footprint of Livepeer 😄

[Titan-Node]

Another option would be to use a Router on the Orchestrator side.

After speaking with @0xb79 he pointed me to a post @yondonfu made about a year ago about the development of the Livepeer Router, although it seems it wont be able to replace GeoDNS in it's current state we could modify/re-create it to do the following:

1) Set up a Master Router - This node would receive all requests from Bs as the listed serviceURI endpoint and respond with the nearest O node for the requesting B. It would do this by keeping a database of all the response times of each O. If a B's ip address is new or has no results it would send a request to all Router nodes and ask for a ping response to save.

2) Set up a Router on each O machine - A Router node would ping each B that the master node requests and send back it's results.

In doing so we can completely avoid the need for GeoDNS providers and set up nodes anywhere. We also can avoid altering the B side of the selection process and keep it light.

One issue might be the response time of the Master Router to the B. We would want to ensure that the B wouldn't consider the latency to the Mater Router itself.

Any thoughts on this would be greatly appreciated!

[iameli]

One way you could do this today with no changes to the node software would be to run Consul on all of your nodes and point your DNS resolver to Consul DNS. I've not used it extensively but it should allow you to automatically route incoming connections to the nearest IP address, etc.

[eliteprox]

One option would be to modify the onchain serviceAddr to support a limited # of service addresses for the orchestrator. The broadcaster implementation would need to be modified to check latency each of the O service addresses and the discovery would need to ensure that the # of service addresses within a single orchestrator doesn't change the probability of selection.

• Onchain serviceAddr updated to support mutliple service addresses (with a proposed limit of maybe ~10 to prevent exploits)
• Broadcaster discovery would get the service addresses, complete the regular "scoring check" that it currently does, for each service address.
• B selects one service address for the Orchestrator after scoring and keeps it for future connections.
• The broadcaster discovery loop would perhaps passively re-check these while it is running/streaming.
• This could be kept in memory or a sqlite file could be developed to aid the broadcaster in caching this data, but the serviceAddresses should be regularly scored/checked the same as they are today for eligibility to receive work

In it's most basic design, we are just updating serviceAddr on-chain and broadening the discovery loop to find the best serviceAddr of the collection returned by the onchain query of serviceAddr.

I think this is a simpler solution than routing everything from a central process. Storing it on-chain avoids the excessive RPC communication between B/O/T, and ensures the most expensive connections are made only to the nearest O.

However, this could introduce a breaking change to the network/protocol by changing the format of serviceAddr stored on-chain, and may require dev work on a testnet to develop the new service address field on-chain.

The other downside is, if there are Livepeer broadcasting implementations in other languages, a protocol change like this would introduce breaking changes to those projects, requiring additional dev work.

[Titan-Node]

In addition to @eliteprox the Orchestrator Selection process done by the Broadcaster already takes into account other variables such as Price Per Pixel, performance history etc. If we go with the Broadcaster upgrade to run through a list of endpoints per Orchestrator these metrics will be considered by default. Maybe a router would not?

[Titan-Node]

One way you could do this today with no changes to the node software would be to run Consul on all of your nodes and point your DNS resolver to Consul DNS. I've not used it extensively but it should allow you to automatically route incoming connections to the nearest IP address, etc.

Is this using a third party service? Had a hard time navigating their docs. I think it would be best if Livepeer routed it's own traffic. Also if it was a default feature it would improve the network as a whole rather than just a few Orchs who run this extra layer of software.