Measure DHT Resource Consumption

[iand]

ETA: 2023-08-31

Description: Currently when the Bitswap ProviderSearchDelay is set to 0, the Time To First Byte is worse than when the ProviderSearchDelay is set to 1 second, which doesn’t make sense from a protocol perspective. When the ProviderSearchDelay is set to 0, all requests go through the DHT (compared with only 5% when the ProviderSearchDelay is set to 1 second). One theory that could explain these strange results, is that the DHT implementation is slowing down Kubo.

We need to investigate around parallel requests in the DHT, and try to understand any resource limitation that the implementation may have. The DHT is much less chatty than Bitswap, hence there must be a way to have a more efficient use of resources (even tough the DHT opens more new connections than Bitswap).

Upon completion

Once we are satisfied with the DHT performances, we can set the Bitswap ProviderSearchDelay to 0 (unless we encounter new problems). This is a good step to get rid of Bitswap dumb broadcast!

References

• Optimizing (or remove) the provider delay interval for DHT lookups used by Bitswap ipfs/kubo#8807
• feat: set Bitswap.ProviderSearchDelay to 0s ipfs/kubo#9530