From 67574d22540f0e3b2615208ad363851bb67a1e92 Mon Sep 17 00:00:00 2001
From: Christian Grothoff <grothoff@gnunet.org>
Date: Sun, 13 Mar 2022 02:02:59 +0100
Subject: add pending table description

---
 draft-schanzen-r5n.xml | 45 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 0c11b50..06e3f13 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -959,6 +959,51 @@ bchar = *(ALPHA / DIGIT)
           </dd>
         </dl>
       </section>
+      <section anchor="pending_table">
+        <name>Pending Table</name>
+	<t>
+	  R<sup>5</sup>N performs stateful routing where the messages
+	  only carry the query hash and do not encode the ultimate
+	  source or destination of the request.  Routing a request
+	  towards the key is doing hop-by-hop using the routing table and the
+	  query hash.  The pending table is used to route responses
+	  back to the originator.  In the pending table each peer
+	  primarily associates a query hash with the associated
+	  originator of the request.  The pending table <bcp14>MUST</bcp14>
+	  store entries for the last <tt>MAX_RECENT</tt> requests
+	  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.
+	</t>
+	<t>
+	  For each entry in the pending table, the DHT <bcp14>MUST</bcp14> track
+	  not only the query key and the origin, but also the
+	  extended query, requested block type and flags, and the
+	  result Bloom filter.  If the query did not provide
+	  a result Bloom filter, a fresh result Bloom filter
+	  <bcp14>MUST</bcp14> still be created to filter duplicate replies.
+	</t>
+	<t>
+	  When a second query from the same origin for the
+	  same query hash is received, the DHT <bcp14>MUST</bcp14>
+	  attempt to merge the new request with the state for
+	  the old request.  In particular, this means that if
+	  the result Bloom filters have the same size and
+	  mutator, they <bcp14>MUST</bcp14> be combined.  If
+	  the result Bloom fitlers meta data differs, the
+	  existing result Bloom filter <bcp14>MUST</bcp14> be
+	  discarded and replaced with the incoming result
+	  Bloom filter.
+	<t>
+	  We note that for local applications, a fixed limit on
+	  the number of concurrent requests may be problematic.
+	  Hence, it is <bcp14>RECOMMENDED</bcp14> that implementations
+	  track requests from local applications separately and
+	  preserve the information until the application explicitly
+	  stops the request.
+	</t>	 
+      </section>
     </section>
     <section anchor="p2p_messages" numbered="true" toc="default">
       <name>Message Processing</name>
-- 
cgit v1.2.3