Prefer peers with better routing tables

[Stebalien]

If we ask a peer in our routing table for closer peers to query and they give us "bad peers", we should hold demote this peer and consider replacing them in the future (like we do for peers that are slow to respond).

A "bad" response is one of:

1. A response with many undialable peers.
2. A response with no peers at least one bit closer to the target and we learn that such peers exist (this means their routing table isn't as full as it should be).

[bertrandfalguiere]

I wonder about the onboarding of new peers in the network. This could be critical for short-lived deamons such as browser. In the second case above, the remote peer will have the behaviour of a typical well-behaved but "young" peer. If it is constantly rejected by older peers with more complete RT, won't we have segregation between some old peers well connected among themselves, and badly connected peers which are only connected among themselves because the first category keep rejecting them? This will result in tiered network, or at least slow the "onboarding" of new peers.

If this is correct, I see several possible mitigations. Some may already be in place:

1. In the second point, the mature peer should inform the rookie about the better peer it found.
2. The mature peers should let a fraction of their RT open to well-behaved but "young" peers. Maybe via a probabilistic eviction of bad peers, rather than starting by evicting the worst first.
3. Include the time for a fresh node to fill its RT as a metric when testing the network . A Typical Onboarding Time indicator.
4. Set the default settings to be "onboarding of rookies friendly" (a lot of peer exchange, grace period before eviction, etc) and let a performance oriented profile for users who needs it. They could even advertise their profile for short-lived nodes to prefer "mentor nodes" rather than "self performance nodes".

While writing this, I realise it may belong in ipfs/notes.

[Stebalien]

This will result in tiered network, or at least slow the "onboarding" of new peers.

This is exactly what we want. We want longer-lived, known-good peers to serve as the backbone of the network to improve reliability and make it harder to attack the network with new peers.

New peers will still be able to join, make requests, and store records on behalf of the network. However, they'll only be queried towards the end of queries, instead of being used to service long hops.

The mature peers should let a fraction of their RT open to well-behaved but "young" peers.

The new release tries to do this by marking "slow" peers as candidates for eviction. That means that any old and overloaded peers will slowly be replaced by less overloaded peers. It'll still take a while for new peers to work their way into routing tables, but again, that's desired.

[bertrandfalguiere]

Ok, got it.

What about peer exchange upon eviction? This would still be helpful for new peer to become useful sooner (by filling their RT). Consecutive PX-then-eviction should help them quickly find their correct tier and be at the optimum spot for their capabilities. I guess this will slightly increase cost for old nodes, but can save a lot of peer discovery traffic and connection establishing overall, I guess.

And what about the bullet 3: the mean time for a fresh node to fill x% of its table? Is it something that is mesured?

[Stebalien]

Ah, I don't think we're quite on the same page here:

1. Routing tables are not symmetric. New nodes will immediately fill their routing table with nodes they find in the DHT. It's just that these nodes they find won't add them back to their routing tables for a while.
2. New DHT server nodes will always end up in the routing tables of their closest peers because closer peers will end up in higher, more sparsely filled buckets.

[bertrandfalguiere]

Ack. I thought it was symmetric. It makes much more sense to me now!