commit 7f160e8da228f6149dc0ae95b8f4c9fed94d003e
parent 7ddd7d5bc134128abd39a397db8c819b4a22d9b4
Author: Christian Grothoff <grothoff@gnunet.org>
Date: Sun, 14 Jul 2024 18:49:10 +0200
clarify who configures and why
Diffstat:
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -939,10 +939,12 @@ Connectivity | |Underlay| |Underlay| | Underlay | ...
peer, and thus miss out on quality routing table entries. This
would degrade the performance of the DHT and <bcp14>SHOULD</bcp14>
thus be avoided by advertising updated <tt>HELLOs</tt> before the
- previous one expires. When using unreliable underlays, it
- <bcp14>MAY</bcp14> be a good idea to use an even higher frequency
+ previous one expires. When using unreliable underlays, the application
+ <bcp14>MAY</bcp14> want to use an even higher frequency and transmit
+ more <tt>HelloMessages</tt> within an expiration interval
to ensure that neighbours almost always have non-expired
- <tt>HelloMessages</tt> at their disposal.
+ <tt>HelloMessages</tt> at their disposal even if some messages
+ are lost.
</t>
<t>
Whenever a peer receives such a <tt>HelloMessage</tt>
@@ -1128,7 +1130,9 @@ BEGIN
the peer has encountered. To ensure that the peer does
not run out of memory, information about older requests
is discarded.
- The value of <tt>MAX_RECENT</tt> <bcp14>MAY</bcp14> be configurable.
+ The value of <tt>MAX_RECENT</tt> <bcp14>MAY</bcp14> be configurable
+ at the host level to use available memory resources without
+ conflicting with other system requirements and limitations.
<tt>MAX_RECENT</tt> <bcp14>SHOULD</bcp14>
be at least 128 * 10<sup>3</sup>.
If the pending table is smaller, the likelihood grows that a peer
