[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0004] branch master updated (2762d17 -> de76f48)
|
From: |
gnunet |
|
Subject: |
[lsd0004] branch master updated (2762d17 -> de76f48) |
|
Date: |
Tue, 27 Dec 2022 14:26:12 +0100 |
This is an automated email from the git hooks/post-receive script.
martin-schanzenbach pushed a change to branch master
in repository lsd0004.
from 2762d17 First set of changes after 1-on-1 review with CG
new d42a8a5 Handle most of the fixmes, add one more.
new de76f48 Update use of existing pending table concept.
The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
draft-schanzen-r5n.xml | 160 ++++++++++++++++++++++++-------------------------
1 file changed, 80 insertions(+), 80 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 9e7dd1a..54212c4 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
@@ -836,7 +829,7 @@ 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 and <bcp14>SHOULD</bcp14> be at least 128k.
+ configurable and <bcp14>SHOULD</bcp14> be at least 128 *
10<sup>3</sup>.
</t>
<t>
For each entry in the pending table, the DHT <bcp14>MUST</bcp14> track
@@ -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 a similar
<tt>GetRequest</tt> was answered previously
+ with a cached result message this request also matches (<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,22 +1728,32 @@ 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
the request to other peers.
</t>
</li>
+ <li>
+ <!-- FIXME: For how long? what exactly must be stored? -->
+ The implementation <tt>SHOULD</tt> create (or merge) an entry in
the pending table
+ <xref target="pending_table"/> for the query represented by this
<tt>GetMessage</tt>.
+ If the peer is unable to handle an additional entry in the
table, the message
+ <bcp14>MUST</bcp14> be discarded and processing ends.
+ </li>
<li>
Using the value in <tt>REPL_LVL</tt>, the number of peers to
forward to
<bcp14>MUST</bcp14> be calculated using
@@ -1951,8 +1964,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>.
@@ -1964,13 +1975,14 @@ BEGIN
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.
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>
+ the peer to be added to the respective k-bucket of the routing
table (<xref target="routing"/>).
+ </li>
+ <li>
+ If the <tt>QUERY_HASH</tt> of this <tt>ResultMessage</tt> does
not match an entry in the
+ pending table (<xref target="pending_table"/>), then the message
is discarded and processing ends.
+ Otherwise, processing continues for each entry in the table as
follows.
+ </li>
<li>
- <t>
- If the <tt>QUERY_HASH</tt> of this <tt>ResultMessage</tt> is
found in the
- list of pending local or remote queries, then
- for each matching pending query:
- </t>
<ol type="%c)">
<li>
If the <tt>FindApproximate</tt> flag was not set in the query
and the <tt>BTYPE</tt> allowed the
@@ -2004,24 +2016,25 @@ BEGIN
the <tt>GETPATH_L</tt> and <tt>PUTPATH_L</tt>
<bcp14>MUST</bcp14> be set to zero when forwarding the result.
</li>
+ <li>
+ If the result filter result is either <tt>FILTER_MORE</tt> or
<tt>FILTER_LAST</tt>,
+ the message is forwarded to the origin of the query as
defined in the entry
+ which may either be the local peer or a remote peer.
+ In case this is a query of the local peer the result may
have to be provided to
+ applications through the overlay API.
+ Otherwise, the result is forwarded using <tt>SEND(P,
ResultMessage')</tt> where
+ <tt>ResultMessage'</tt> is the now modified message.
+ If the result was <tt>FILTER_LAST</tt>, the query is removed
from the pending table.
+ </li>
</ol>
- <t>
- If the result is either <tt>FILTER_MORE</tt> or
<tt>FILTER_LAST</tt>,
- the message is forwarded to the origin of the query through
- either the overlay API or using <tt>SEND(P,
ResultMessage')</tt> where
- <tt>ResultMessage'</tt> is the now modified message.
- If the result was <tt>FILTER_LAST</tt>, the query is removed
from the list of pending
- queries.
- </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 +2304,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 +2537,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 +2599,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 +2608,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 +2701,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.
- [lsd0004] branch master updated (2762d17 -> de76f48),
gnunet <=