Highly unbalanced Kademlia routing table

Question

In the Kademlia paper, the last paragraph of section 2.4 states that in order to properly handle highly unbalanced trees...

Kademlia nodes keep all va

Answer 1

However, the previous section of the paper seem to state that if a k-bucket already has k elements, that any further additions in to that k-bucket require removing the stalest node (pinging it first to see if its alive) or otherwise caching the addition until a slot becomes available in that k-bucket.

That is how a bucket is maintained whenever there is a node contact to insert but the bucket is not eligible for splitting.

Under what conditions should a k-bucket be split and why?

As a first approximation: Split a bucket whenever a new node cannot be inserted and the bucket's ID-space covers your node ID.

This is necessary to maintain full awareness of your neighborhood while having only vague awareness of remote keyspace portions. I.e. for locality.

To cover the unbalanced-tree case - which may happen either if node IDs aren't (pseudo-)random or, at least in leaf buckets, due to statistical flukes when they are assigning at random - the approach has to be relaxed as follows:

When

• attempting to insert a new contact C in the routing table
• the bucket into which C belongs is full
• C is closer to your node ID than the K^th-closest node in your routing table, where K is the bucket size

then split the bucket.

In practice this has to be modified a little further so that relaxed splitting is used for responses while unsolicited requests should only use strict splitting, otherwise you could get some strangely distorted routing table when the relaxed splitting happens early during startup when the table isn't populated yet.