[lsd0004] 02/02: More on connectivity management

[gnunet]

This is an automated email from the git hooks/post-receive script.

martin-schanzenbach pushed a commit to branch master
in repository lsd0004.

commit 4b01724fec786415ce232a0a8b18dc27b06c1902
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Sun Dec 25 22:08:55 2022 +0900

    More on connectivity management
---
 draft-schanzen-r5n.xml | 27 ++++++++++++++++++++++-----
 1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 60c5967..9495cbf 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -563,13 +563,10 @@ Connectivity | |Underlay|  |Underlay|
        information about its current set of neighbors.
         Upon receiving a connection notification from the Underlay through
         <tt>PEER_CONNECTED</tt>, information on the new neighbor
-        <bcp14>MUST</bcp14> be added.
+        <bcp14>MUST</bcp14> be added to the routing table.
         Similarly when a disconnect is indicated by the Underlay through
         <tt>PEER_DISCONNECTED</tt> messages for all addresses of the peer it
-        <bcp14>MUST</bcp14> be removed.
-        The implementation <bcp14>MAY</bcp14> try to re-establish connection
-        to the peer by issuing <tt>TRY_CONNECT</tt> requests on the Underlay
-        using valid HELLO caches.
+        <bcp14>MUST</bcp14> be removed from the routing table.
       </t>
       <t>
         In order to achieve O(log n) routing performance,
@@ -601,6 +598,8 @@ Connectivity | |Underlay|  |Underlay|
           <tt>PEER_CONNECTED</tt>), or the application/end-user providing at
           least one working HELLO which is then in turn used to call 
<tt>TRY_CONNECT</tt>
           on the Underlay.
+          This is commonly achieved through the configuration of hardcoded 
bootstrap peers
+          or bootstrap servers either for the Underlay or the R<sup>5</sup>N 
implementation.
           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 HELLO block.
@@ -627,6 +626,11 @@ Connectivity | |Underlay|  |Underlay|
           largest number of neighbors. The eviction strategy 
<bcp14>MUST</bcp14> be
           to drop the shortest-lived connections first.
         </t>
+        <t>
+          The implementation <bcp14>MAY</bcp14> cache valid HELLOs of 
disconnected
+          peers outside of the routing table and sporadically or periodically 
try to (re-)establish connection
+          to the peer by issuing <tt>TRY_CONNECT</tt> requests on the Underlay.
+        </t>
       </section>
       <section anchor="find_peer">
         <name>Peer Discovery</name>
@@ -1315,6 +1319,10 @@ BEGIN
             <li>
               The HELLO 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.
+              <!-- FIXME same problem as for HELLO blocks: We do not need to 
TRY_CONNECT here because we already have
+                   a connection, obviously. But we may want to TRY_CONNECT on 
the new addresses? Adding for now -->
+              The implementation <bcp14>MAY</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.
             </li>
             <li>
               <!-- We need a statement like this here. Should they? Can they? 
What if they are (not)? -->
@@ -1545,6 +1553,15 @@ BEGIN
              the local peer <bcp14>MUST</bcp14> try to establish a connection
              to the peer indicated in the HELLO block using the address 
information
               from the HELLO block and the Underlay function 
<tt>TRY_CONNECT</tt>.
+              <!-- FIXME: The above behaviour has a catch: If the 
implementation only connects to one
+                   address from the hello using TRY_CONNECT, the Underlay also 
knows only about that connection
+                   If that failes and PEER_DISCONNECT is called, this neighbor 
is dead.
+                   We could say here that the implementation SHOULD instruct 
to connect to ALL
+                   addresses or risk flaky connections. The choice of address 
is also unclear.
+                   R5N does not really know what the Underlay supports (maybe 
more than provided in
+                   own addresses) - Added this for now: -->
+              The implementation <bcp14>MAY</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.
               If 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.
              Note that the k-bucket <bcp14>MUST</bcp14> be determined by the

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.