[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0004] 01/02: Handle most of the fixmes, add one more.
|
From: |
gnunet |
|
Subject: |
[lsd0004] 01/02: Handle most of the fixmes, add one more. |
|
Date: |
Tue, 27 Dec 2022 14:26:13 +0100 |
This is an automated email from the git hooks/post-receive script.
martin-schanzenbach pushed a commit to branch master
in repository lsd0004.
commit d42a8a5f8cb64ec103598b981eeafd0533662ff9
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Tue Dec 27 16:22:03 2022 +0900
Handle most of the fixmes, add one more.
---
draft-schanzen-r5n.xml | 123 +++++++++++++++++++++++--------------------------
1 file changed, 58 insertions(+), 65 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 9e7dd1a..200f28d 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -19,6 +19,7 @@
<!ENTITY RFC8032 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8032.xml";>
<!ENTITY RFC8126 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml";>
<!ENTITY RFC8174 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml";>
+<!ENTITY RFC8324 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8324.xml";>
<!ENTITY I-D.schanzen-gns PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.schanzen-gns.xml";>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
@@ -445,7 +446,6 @@ Connectivity | |Underlay| |Underlay|
When the connection attempt is successful, information on the new
peer is offered through the <tt>PEER_CONNECTED</tt> signal.
</dd>
- If PEER_CONNECT and put in routing table, then HOLD -->
<dt>
<tt>HOLD(P)</tt>
</dt>
@@ -641,14 +641,6 @@ Connectivity | |Underlay| |Underlay|
of <tt>HELLO</tt>s.
</t>
<t>
- <!-- FIXME REPL_LVL unclear, RF_SIZE unclear. Sections like this
make me wonder how
- we can avoid using prose to specify message creation.
- REPL_LVL: For hello it is 4 => RECOMMENDED to 4
- RF_SIZE: Specified in HELLO block as connected peers = |E|.
- RF: All peers I am already connected to should be included in
the RF BF
- XQUERY: => nil
- Flags? FindApproximate
- -->
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 address as
<tt>QUERY_HASH</tt>.
@@ -678,12 +670,13 @@ Connectivity | |Underlay| |Underlay|
already in the routing table, it must cache it as long as that peer
is in its routing table
(or until the <tt>HELLO</tt> expires) and serve it in response to
GET requests for <tt>HELLO</tt> blocks (see <xref
target="p2p_get_processing"/>).
+ This behaviour makes it unnecessary to initiate dedicated
<tt>PutMessages</tt> containing
+ <tt>HELLO</tt> blocks by the implementation.
</t>
</section>
<section anchor="routing_bloomfilter">
<name>Peer Bloom Filter</name>
<t>
- <!-- FIXME HArdcoded to 128 bytes = L/8 -->
As DHT <tt>GetMessage</tt>s and <tt>PutMessage</tt>s traverse a
random path through the network for the
first N hops, it is essential that routing loops are avoided.
This peer Bloom filter is constant in size at <tt>L=1024</tt>
buckets (128 bytes) and
@@ -1302,8 +1295,11 @@ BEGIN
is in the future. If the signature is invalid, the message is
discarded.
</li>
<li>
- The <tt>HELLO</tt> information is cached in the routing table
until it expires,
- the peer is removed from the routing table, or the information
is replaced by another message from the peer.
+ The information contained in the <tt>HelloMessage</tt> can be
used to synthesize a
+ block of type <tt>HELLO</tt> (<xref target="hello_block"/>).
+ The block is cached in the routing table until it expires,
+ the peer is removed from the routing table, or the information
is replaced by another message
+ from the peer.
The implementation <bcp14>SHOULD</bcp14> instruct the Underlay
to connect to all now available addresses
using <tt>TRY_CONNECT</tt> in order to make the underlay aware
of alternative addresses for this connection and
to maintain optimal connectivity.
@@ -1510,8 +1506,10 @@ BEGIN
<li>
If the local peer is the closest peer
(cf. <tt>IsClosestPeer(SELF, BLOCK_KEY, PeerFilter)</tt>) or the
<tt>DemultiplexEverywhere</tt>
- flag ist set, the message <bcp14>MUST</bcp14>
+ flag ist set, the message <bcp14>SHOULD</bcp14>
be stored locally in the block storage if possible.
+ The implementation <tt>MAY</tt> choose not store the block if
external factors or configurations
+ prevent this, such as limited (alottted) disk space.
</li>
<li>
If the <tt>BTYPE</tt> of the message indicates a <tt>HELLO</tt>
block, the
@@ -1522,8 +1520,9 @@ BEGIN
connection to the peer indicated in the <tt>HELLO</tt> block
using
the address information
from the <tt>HELLO</tt> block and the Underlay function
<tt>TRY_CONNECT</tt>.
- The implementation <bcp14>MUST</bcp14> instruct the Underlay to
connect to all provided addresses
- using <tt>TRY_CONNECT</tt> in order to make the underlay aware
of multiple addresses for this connection.
+ The implementation <bcp14>MUST</bcp14> instruct the Underlay to
try to connect to all
+ provided addresses using <tt>TRY_CONNECT</tt> in order to make
the underlay aware of
+ multiple addresses for this connection.
When a connection is established, the signal
<tt>PEER_CONNECTED</tt> will cause
the peer to be added to the respective k-bucket of the routing
table (<xref target="routing"/>).
</li>
@@ -1700,21 +1699,25 @@ BEGIN
</li>
<li>
<t>
- If the local peer is the closest peer
- (cf. <tt>IsClosestPeer (SELF, QueryHash, PeerFilter)</tt>) or
the
- <tt>DemultiplexEverywhere</tt> flag is set, a reply
- <bcp14>MUST</bcp14> be produced (if one is available) using
the following
+ The local peer <bcp14>MUST</bcp14> try to produce a reply in
any of the following cases:
+ (1) If the local peer is the closest peer
+ (cf. <tt>IsClosestPeer (SELF, QueryHash, PeerFilter)</tt>, or
(2)
+ if the <tt>DemultiplexEverywhere</tt> flag is set, or (3)
+ if the local peer is not the closest and the
<tt>GetRequest</tt> was answered previously
+ resulting in a cached reply (<xref
target="p2p_result_processing"/>).
+ </t>
+ <t>
+ The reply is produced (if one is available) using the following
steps:
</t>
<ol type="%c)">
- <!-- FIXME it seems to me as if some blocks need to be
"synthesized", e.g.
- HELLOs from HelloMessages... this needs to be
specified.-->
<li>
If the <tt>BTYPE</tt> does not indicate a request for a
<tt>HELLO</tt> block or
<tt>ANY</tt>,
- the implementation <bcp14>MUST</bcp14> only consider blocks
in the local block storage.
- Otherwise, the implementation <bcp14>MUST</bcp14> only
consider its own <tt>HELLO</tt> and
- the <tt>HELLO</tt>s it has cached for the peers in its
routing table as blocks.
+ the implementation <bcp14>MUST</bcp14> only consider blocks
in the local block storage
+ and previously cached <tt>ResultMessage</tt>s.
+ Otherwise, the implementation <bcp14>MUST</bcp14> only
consider its own addresses and
+ the addresses it has cached for the peers in its routing
table.
</li>
<li>
If <tt>FLAGS</tt> indicate a <tt>FindApproximate</tt>
request,
@@ -1725,16 +1728,19 @@ BEGIN
with a <tt>BLOCK_KEY</tt> that matches the
<tt>QUERY_HASH</tt> exactly and that is
not filtered by the <tt>RESULT_BF</tt>.
</li>
+ <li>
+ Any resulting (synthesized) block <bcp14>MUST</bcp14> be
encapsulated in a
+ <tt>ResultMessage</tt>.
+ The cached or created <tt>ResultMessage</tt>
<bcp14>SHOULD</bcp14> be transmitted to the
+ neighbor from which the request was received.
+ </li>
</ol>
<t>
- The resulting block, if any, <bcp14>MUST</bcp14> be
encapsulated in a
- <tt>ResultMessage</tt> and <bcp14>SHOULD</bcp14> be transmitted
to the
- neighbor from which the request was received.
- Implementations <bcp14>MAY</bcp14> drop messages if they are
resource-constrained.
- However, <tt>ResultMessage</tt>s <bcp14>MUST</bcp14> be given the
- highest priority among competing transmissions.
+ Implementations <bcp14>MAY</bcp14> not to reply if they are
resource-constrained.
+ However, <tt>ResultMessage</tt>s <bcp14>MUST</bcp14> be given
the
+ highest priority among competing transmissions.
</t>
- <t>
+ <t>
If the <tt>BTYPE</tt> is supported and
<tt>ValidateBlockReply</tt> for the given
query has yielded a status of <tt>FILTER_LAST</tt>, processing
<bcp14>MUST</bcp14> end and not continue with forwarding of
@@ -1756,6 +1762,9 @@ BEGIN
to, <tt>SEND(P, GetMessageP)</tt> is called. Here,
<tt>GetMessageP</tt>
is the original message with the updated fields for
<tt>HOPCOUNT</tt> (incremented
by 1), <tt>PEER_BF</tt> and <tt>RESULT_FILTER</tt>.
+ <!-- FIXME: For how long? what exactly must be stored? -->
+ The implementation <tt>MUST</tt> cache the originator peer
address and the
+ <tt>GetMessage</tt> in order to correctly process any
<tt>ResultMessage</tt>s.
</li>
</ol>
</section>
@@ -1951,8 +1960,6 @@ BEGIN
does not have to match the <tt>QUERY_HASH</tt>.
</li>
<li>
- <!-- FIXME: Discuss: Changed from MUST to SHOULD --
- same change as above - MSC -->
If the <tt>BTYPE</tt> of the message indicates a <tt>HELLO</tt>
block, the
peer <bcp14>SHOULD</bcp14> be considered for the local routing
table by using the peer address computed from the block
using<tt>DeriveBlockKey</tt>.
@@ -2015,13 +2022,12 @@ BEGIN
</t>
</li>
<li>
- <!-- FIXME: If that is the case, then this also needs to be in
the
- processing of GetMessage: I think we shoul dmove this to
some
- performance considerations instead.
- => same formulation as for PUT to store if possible (MUST)
- usr 1-to-1-->
- Finally, the implementation <bcp14>MAY</bcp14> choose to
- cache data from <tt>ResultMessage</tt>s.
+ Finally, the implementation <bcp14>SHOULD</bcp14> cache
+ <tt>ResultMessage</tt>s in order to provide already seen replies
to
+ future <tt>GetMessage</tt>s.
+ The implementation <bcp14>MAY</bcp14> choose not no cache any or
+ a limited number of <tt>ResultMessage</tt>s for reasons such as
resource
+ limitations.
</li>
</ol>
</section>
@@ -2291,26 +2297,12 @@ BEGIN
<dt>SetupResultFilter(FilterSize, Mutator) -> RF</dt>
<dd>
<t>
- <!-- FIXME: I do not understand this. Isn't the element set E known
- for <tt>HELLO</tt> blocks? Isn't it H_ADDRS XOR MUTATOR?
- E => conected peers in routing table
- K => is 16
- -->
The RESULT_FILTER for <tt>HELLO</tt> blocks is implemented using a
Bloom filter following the definition from <xref
target="bloom_filters"/>
and consists of a variable number of buckets <tt>L</tt>.
- <tt>L</tt> depends on the number of elements <tt>|E|</tt> known to
be filtered at the
- initiator.
- <!-- FIXME: Minimum space for used for what? There is no example
given anywhere in the
- spec how this becomes relevant. Again, this is not some
abstract block,
- but specifically a <tt>HELLO</tt> (see above).
- E is the number of currently connected peers (neighbors)!
- E is no really ever 0 so the following sentence should be
amended.
- -->
- If <tt>|E|</tt> is zero, the size <tt>L</tt> is set to 32 bits to
provide some minimum
- space (to be used by peers when forwarding the request after
- returning local results).
- Otherwise, <tt>L</tt> is set to the minimum of
+ <tt>L</tt> depends on the number of connected peers <tt>|E|</tt>
known to
+ the peer creating a <tt>HELLO</tt> block from its own addresses:
+ <tt>L</tt> is set to the minimum of
2<sup>18</sup> bits (2<sup>15</sup> bytes) and the lowest power
of 2 that is strictly larger than <tt>2*K*|E|</tt> bits
(<tt>K*|E|/4</tt> bytes).
</t>
@@ -2538,12 +2530,12 @@ BEGIN
control such as <xref target="RFC6940"/> which, like R<sup>5</sup>N,
provides
a peer-to-peer (P2P) signaling protocol with extensible routing and
topology
mechanisms.
- <!-- FIXME: Can we give examples here?
- Centralization DNS roots fixed through GNS.
- -->
- Some decentralized applications require a more open system that
- enables ad-hoc participation and other means to prevent common
attacks
- on P2P overlays.
+ Some decentralized applications such as the GNU Name System (<xref
target="I-D.schanzen-gns"/>)
+ require a more open system that enables ad-hoc participation and
other means to prevent common
+ attacks on P2P overlays.
+ GNS, for example, would be in conflict with its goals of providing a
solution to the issues of a
+ "Single Hierarchy with a Centrally Controlled Root" and
"Distribution and Management of Root Servers"
+ in DNS as raised in <xref target="RFC8324"/>.
</t>
</section>
</section>
@@ -2600,7 +2592,7 @@ BEGIN
Served", as described in <xref target="RFC8126"/>.
GANA created the registry as follows:
</t>
- <!-- FIXME changed GNS Reference to This.I-D because we either need to
define it here
+ <!-- NOTE: changed GNS Reference to This.I-D because we either need to
define it here
or in the GNS RFC. And I think here is better or in a separate
document
=> not in here. Use separate document for NAMERECORD draft.
-MSC -->
@@ -2609,8 +2601,8 @@ BEGIN
Number| Name | References | Description
------+----------------+------------+-------------------------
0 ANY [This.I-D] Reserved
-11 GNS_NAMERECORD [This.I-D] Block for GNS records
13 DHT_HELLO [This.I-D] Address data for a peer
+
Contact: r5n-registry@gnunet.org
]]></artwork>
</figure>
@@ -2702,6 +2694,7 @@ Type | Name | References | Description
&RFC6940;
&RFC8126;
&RFC8174;
+ &RFC8324;
&I-D.schanzen-gns;
<reference anchor="ed25519"
target="http://link.springer.com/chapter/10.1007/978-3-642-23951-9_9";><front><title>High-Speed
High-Security Signatures</title><author initials="D." surname="Bernstein"
fullname="Daniel Bernstein"><organization>University of Illinois at
Chicago</organization></author><author initials="N." surname="Duif"
fullname="Niels Duif"><organization>Technische Universiteit
Eindhoven</organization></author><author initials="T." surname="Lange"
fullname="Tanja Lange" [...]
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.