commit fce237fe18344e4ab1b2d2470b8be5a3e8b03940
parent c2158bc7297c12bd9c1440e498cb410af02a6bab
Author: Christian Grothoff <grothoff@gnunet.org>
Date: Sat, 26 Aug 2023 12:15:04 +0200
add version field to flags
Diffstat:
1 file changed, 29 insertions(+), 19 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -706,22 +706,22 @@ Connectivity | |Underlay| |Underlay| | Underlay | ...
While details on how the first connection is established <bcp14>MAY</bcp14>
depend on the specific implementation, this <bcp14>SHOULD</bcp14> usually be done
by an out-of-band exchange of the information from a <tt>HELLO</tt> block.
- Section <xref target="hello_url"/> specifies a URL format for encoding HELLO
- blocks as text strings which allow portable, human-readable, text-based serialization
+ <xref target="hello_url"/> specifies a URL format for encoding HELLO
+ blocks as text strings. The URL format thus provides a portable, human-readable, text-based serialization
format that can, for example, be encoded into a QR code for dissemination.
HELLO URLs <bcp14>SHOULD</bcp14> be supported by implementations for both import and export
of <tt>HELLO</tt>s.
</t>
<t>
To discover peers for its routing table, a peer will initiate <tt>GetMessage</tt> requests
- <xref target="p2p_get"/> asking for blocks of type <tt>HELLO</tt> using its own peer identity
+ (see <xref target="p2p_get"/>) asking for blocks of type <tt>HELLO</tt> using its own peer identity
in the <tt>QUERY_HASH</tt> field of the message.
The <tt>PEER_BF</tt> is initialized and set using the peers own peer identity as well as the identities
of all currently connected <em>neighbors</em>. <!-- note: we mean the identities here! FIX with terminology... -->
These requests <bcp14>MUST</bcp14> use the <tt>FindApproximate</tt> and <tt>DemultiplexEverywhere</tt>
flags. <tt>FindApproximate</tt> will ensure that other peers will reply
- with keys they merely consider close-enough, while <tt>DemultiplexEverywhere</tt>
- will cause each peer on the path to respond, which is likely to yield
+ with results where the keys are merely considered close-enough, while <tt>DemultiplexEverywhere</tt>
+ will cause each peer on the path to respond. The combination of these flags is thus likely to yield
<tt>HELLO</tt>s of peers that are useful somewhere in the routing table.
The <tt>RECOMMENDED</tt> replication level to be set in the <tt>REPL_LVL</tt> field is 4.
The size and format of the result filter is specified in <xref target="hello_block"/>.
@@ -735,12 +735,12 @@ Connectivity | |Underlay| |Underlay| | Underlay | ...
An implementation <bcp14>MUST</bcp14> advertise its addresses periodically to its
<em>neighbors</em> through <tt>HelloMessage</tt>s.
The advertisement interval and expiration should be configurable or chosen at the discretion
- of the implementation based on external factors such as DHCP leases.
+ of the implementation based on external factors such as expiration of DHCP leases.
The specific frequency of advertisements <bcp14>MAY</bcp14> depend on available bandwidth,
the set of already connected neighbors, the workload of the system and other factors which are at the discretion of
the developer, but <bcp14>SHOULD</bcp14> be a fraction of the expiration period.
Whenever a peer receives such a <tt>HELLO</tt> message from another peer that is
- already in the routing table, it must cache it as long as that peer is in its routing table
+ already in the routing table, it must cache it as long as that peer remains in its routing table
(or until the <tt>HELLO</tt> expires) and serve it in response to
<tt>GET</tt> requests for <tt>HELLO</tt> blocks (see <xref target="p2p_get_processing"/>).
This behaviour makes it unnecessary to initiate dedicated <tt>PutMessages</tt> containing
@@ -751,19 +751,19 @@ Connectivity | |Underlay| |Underlay| | Underlay | ...
<name>Peer Bloom Filter</name>
<t>
As DHT <tt>GetMessage</tt>s and <tt>PutMessage</tt>s traverse a random path through the network for the
- first <tt>L2NSE</tt> hops, it is essential that routing loops are avoided.
- This peer Bloom filter is constant in size at <tt>L=1024</tt> bits (128 bytes) and
- <tt>k=16</tt> bits set per element.
+ first <tt>L2NSE</tt> hops, a key design objective of R<sup>5</sup>N is to avoid routing loops.
The peer Bloom filter is part of the routing metadata in
- messages in order to prevent circular routes and is updated at each hop with the hops
- peer identity.
+ messages to prevent circular routes. It is updated at each hop where the hops
+ peer public key is added to it.
+ It is constant in size at <tt>L=1024</tt> bits (128 bytes) and
+ sets <tt>k=16</tt> bits per element.
For the next hop selection in both the random and the deterministic
- case, any peer which is in the Bloom filter for the respective message
- is not included in the peer selection process.
+ case, any peer which is in the peer Bloom filter for the respective message
+ is excluded from the peer selection process.
</t>
<t>
Any peer which is forwarding <tt>GetMessage</tt>s or <tt>PutMessage</tt>s
- (<xref target="p2p_messages"/>) adds its own peer public key to the
+ (<xref target="p2p_messages"/>) thus adds its own peer public key to the
peer Bloom filter.
This allows other peers to (probabilistically) exclude already
traversed peers when searching for the next hops in the routing table.
@@ -777,15 +777,17 @@ Connectivity | |Underlay| |Underlay| | Underlay | ...
<tt>M(e) -> SHA-512 (e) as uint32[]</tt>
</t>
<t>
- The element <tt>e</tt> is hashed using SHA-512.
- The resulting byte string is interpreted as a string of k=16
+ The element <tt>e</tt> is the peer public key which is hashed using SHA-512.
+ The resulting 512-bit peer identity is interpreted as an array of k=16
32-bit integers in network byte order which are used to set and check the bits
in <tt>B</tt> using <tt>BF-SET</tt> and <tt>BF-TEST</tt>.
</t>
<t>
We note that the peer Bloom filter may exclude peers due to false-postive
matches. This is acceptable as routing should nevertheless
- terminate (with high probability) in close vicinity of the key.
+ terminate (with high probability) in close vicinity of the key. Furthermore,
+ due to the randomization of the first L2NSE hops, it is possible that
+ false-positives will be different when a request is repeated.
</t>
</section>
<section anchor="routing_functions">
@@ -1000,13 +1002,21 @@ BEGIN
to enable checking of the next signature. This flag MUST never be set in
a query.
</dd>
- <dt>4-15: Reserved</dt>
+ <dt>4-7: Reserved</dt>
<dd>
The remaining bits are reserved for future use and
<bcp14>MUST</bcp14> be set to 0 when initiating an operation.
If non-zero bits are received, implementations <bcp14>MUST</bcp14>
preserve these bits when forwarding messages.
</dd>
+ <dt>8-15: Version</dt>
+ <dd>
+ These bits are used to encode the R<sup>5</sup>N DHT protocol
+ version. They <bcp14>MUST</bcp14> be set to 0. Future revisions
+ of the protocol <bcp14>MAY</bcp14> change the message format.
+ It is envisioned that other cryptographic primitives <bcp14>MAY</bcp14>
+ be introduced into the network protocol in the future via this mechanism.
+ </dd>
</dl>
</section>
<section anchor="p2p_pathelement">
