kad: clarify bootstrap process

[guillaumemichel]

• Note that the bootstrap process description is just a suggestion

The below is one possible algorithm to bootstrap. Implementations may diverge from this base algorithm as long as they adhere to the wire format and keep their routing table up-to-date, especially with peers
closest to themselves.

• Update default bootstrap interval to 10 minutes (go-libp2p-kad-dht, IPFS doc)
• Replace a random peer ID with a random peer ID for every non-empty routing table's k-bucket.
  • The random peer ID has a very low probability to land in a bucket close to the node, hence the close buckets (with a high bucket ID), will (statistically) never be refreshed.
  • Taking a random peer ID falling in every non-empty k-bucket makes sure to refresh all populated buckets.
• Remove the mention of QueryCount since it isn't mentioned anywhere else in the document, and it isn't necessary to perform this operation multiple times since all buckets are refreshed by the described process.

cc: @stormshield-frb

[sukunrt]

If the k-bucket is full before the query, how do we decide which peers to ultimately keep in the bucket?

[guillaumemichel]

If the k-bucket is full before the query, how do we decide which peers to ultimately keep in the bucket?

This is implementation specific, here is how it works for the Amino DHT

[MarcoPolo]

For reference, can you point to what we do in go-libp2p-kad-dht @guillaumemichel ?

[guillaumemichel]

That is the function responsible for refreshing the routing table in go-libp2p-kad-dht. It is more complicated than the provided example since go-libp2p-kad-dht also uses timings to decide whether a bucket should be refreshed. It also does some poorly documented optimizations.

I wouldn't link to the code in the spec, since the spec only states a simple example, we don't want to rely on a single implementation, and the code is constantly evolving.