Promoting Optimistic Provide from experimental to production ready

[dennis-tra]

Context

With Kubo 0.20.0 we released the experimental flag to enable Optimistic Provide. A technique that can dramatically accelerate DHT PUT performance. Recently, we measured sub-second provide latencies from North America and central Europe for >90% percent of the provide operations that we performed (N > 10k) while reducing networking overhead by >40% without compromising record availability.

This is a tracking issue to discuss when and if we should promote it to a production-ready feature.

Outreach/Adoption

I reached out to a couple of projects to gather feedback:

• NuNet:
  • _PR:_https://gitlab.com/nunet/device-management-service/-/issues/215
  • Status: blocked on another issue in go-libp2p-kad-dht but has signalled interest
• vocdoni:
  • PR: Improved Performance in go-libp2p-kad-dht: New Feature Reduces PUT/Provide Latencies to <1s vocdoni/vocdoni-node#989
  • Status: plans to enable the option in this PR but want to have monitoring in place before merging
• Mintter:
  • PR: Improved Performance in go-libp2p-kad-dht: New Feature Reduces PUT/Provide Latencies to <1s seed-hypermedia/mintter#1397
  • Status: n/a
• pocket:
  • PR: Improved Performance in go-libp2p-kad-dht: New Feature Reduces PUT/Provide Latencies to <1s pokt-network/pocket#819
  • Status: signaled interest but also stumbled upon other issues
• WeAreAmaze:
  • PR: Improved Performance in go-libp2p-kad-dht: New Feature Reduces PUT/Provide Latencies to <1s WeAreAmaze/amc#40
  • Status: n/a
• Shutter:
  • PR: Improved Performance in go-libp2p-kad-dht: New Feature Reduces PUT/Provide Latencies to <1s shutter-network/rolling-shutter#378
  • Status: n/a
• Indra:
  • PR: Improved Performance in go-libp2p-kad-dht: New Feature Reduces PUT/Provide Latencies to <1s indra-labs/indra#4
  • Status: @l0k18 from indra-labs has given promising feedback.
• kubeedge:
  • PR: Improved Performance in go-libp2p-kad-dht: New Feature Reduces PUT/Provide Latencies to <1s kubeedge/kubeedge#4820
  • Status: n/a
• dymint:
  • PR: Improved Performance in go-libp2p-kad-dht: New Feature Reduces PUT/Provide Latencies to <1s dymensionxyz/dymint#350
  • Status: signaled interest
• b7s:
  • PR: Improved Performance in go-libp2p-kad-dht: New Feature Reduces PUT/Provide Latencies to <1s blessnetwork/b7s#90
  • Status: signaled interest

Production-Ready Criteria

TBD

Kubo

At the moment, the feature is a global flag that enables the technique for every provide operation. Given the specific trade-offs of the mechanism, I would rather apply it for specific use-cases only.

For example, non-time-sensitive operations like re-provides don't necessarily need to use it. On the other hand, if users add files to Kubo, I'd argue that they will expect them to be immediately available in the network.

Next Steps

Right now, you can only enable Optimistic Provide globally. This means you either provide content to the Amino DHT using the classic or the optimistic approach. I think it would be better if users could decide which strategy to use based on the use-case.

There are some paths that could benefit from providing optimistically and others where the benefits are debatable:

1. Where providing optimistically makes sense because I believe users expect content to be available immediately:

   • Running ipfs add .../ipfs dag put and the likes
   • Drag & drop a file into IPFS Desktop/Companion
   • Importing a file into IPFS Desktop/Companion

   These golden paths could be crucial for users to adopt IPFS. If they don't have immediate feedback that it works, the chances are high that they bounce.

2. Where it makes sense to keep the classic approach:

   • Reproviding, because you could argue that it's not time critical and you really want to make sure to find the actual 20 closest peers.

   Preferably, reproviding would even use something like Reprovide Sweep.

The challenge is that the current routing interface doesn't have an API to pass context information further down the stack. This means we cannot indicate which strategy we prefer to use.

[Jorropo]

If this is production ready, shouldn't this change be made in go-libp2p-kad-dht ?