diff options
authorChristian Grothoff <>2022-02-23 23:19:24 +0100
committerChristian Grothoff <>2022-02-23 23:19:24 +0100
commitc18963a9dd4339f1fdfa850d16dc273522f1d4db (patch)
parente676368dafd3a2091c5c9e689da444546a18c713 (diff)
edit draft to be very clear on eviction strategy, remove duplication of text between routing table and security considerations; fixes #7141
1 files changed, 26 insertions, 23 deletions
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 4fbfd79..db465f7 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -671,12 +671,24 @@ Connectivity | |Underlay| |Underlay|
The routing table consists of an array of lists of connected peers.
The i-th list stores neighbours whose identifiers are between
- distance 2^i 2^(i+1) from the local peer.
- An implementation <bcp14>MAY</bcp14> choose an upper limit on the length of the
- lists, but <bcp14>SHOULD</bcp14> try to keep at least 5 entries per bucket.
- For example, in case of system constraints with respect to active
- connections, an implementation <bcp14>SHOULD</bcp14> evict peers in large buckets
- rather than peers from shallow ones.
+ distance 2^i and 2^(i+1) from the local peer.
+ System constraints will typically force an implementation to impose some
+ upper limit on the number of neighbours kept per k-bucket.
+ </t>
+ <t>
+ Implementations <bcp14>SHOULD</bcp14> try to keep at least
+ 5 entries per k-bucket. Embedded systems that cannot manage
+ this number of connections <bcp14>MAY</bcp14> use connection-level
+ signalling to indicate that they are merely a client utilizing a
+ DHT and not able to participate in routing. DHT peers receiving
+ such connections <bcp14>MUST NOT</bcp14> include connections to
+ such restricted systems when making routing decisions.
+ <t>
+ If a system hits constraints with respect to
+ the number of active connections, an implementation
+ <bcp14>MUST</bcp14> evict peers from those k-buckets with the
+ largest number of peers. The eviction strategy <bcp14>MUST</bcp14> be
+ to drop the shortest-lived connections first.
As the message traverses a random path through the network for the
@@ -1309,7 +1321,7 @@ Connectivity | |Underlay| |Underlay|
The payload <bcp14>MUST</bcp14> be considered for the local routing table by
trying to establish a connection to the peer using the information
from the HELLO block. If a connection can be established,
- the peer is added to the <tt>KBuckets</tt> routing table.
+ the peer is added to the k-buckets of the routing table.
If the sender peer of the message is already found in the
@@ -1322,7 +1334,7 @@ Connectivity | |Underlay| |Underlay|
are validated against the requested BTYPE using the respective
block type implementation of <tt>ValidateBlockReply</tt>.
If the approximate flag is set and the BTYPE allows the
- implementation to compute the key from the block it must match
+ implementation to compute the key from the block it must match
the QUERY_HASH. If the XQUERY is malformed, the message <bcp14>MUST</bcp14> be discarded.
<!-- FIXME: This should be reviewed.
<= approximate flag -->
@@ -1689,21 +1701,12 @@ gnunet+tcp:// \
does not have/require a trust anchor a priori. This is (again) in contrast
to RELOAD -->
- An implementation <bcp14>MAY</bcp14> limit the number the number of neighbours
- it stores is any k-bucket of the routing table.
- However, the lower bound <bcp14>MUST</bcp14> be adhered to. <!-- FIXME define somewhere-->
- If there is a limit to the maximum number of neighbours in a
- k-bucket, the implementation must be careful when choosing the
- which peers to replace:
- For example, a simple optimization of the peer selection algorithm may
- be to oder all peers within the k-bucket by distance and evict the
- peers which are the farthest away.
- However, this is not a good idea from a resilience perspective.
- It is much more important to preserve older connections than closer
- ones.
- Preferring long-term connections over close connections makes it more
- difficult for an attacker to execute a Sibyl attack as more resources
- need to be invested over time.
+ If an upper bound to the maximum number of neighbours in a
+ k-bucket is reached, the implementation <bcp14>MUST</bcp14>
+ prefer to preserve the oldest working connections instead of
+ new connections. This makes Sybil attacks less effective
+ as an adversary would have to invest more resources over time
+ to mount an effective attack.
<section anchor="iana" numbered="true" toc="default">