summaryrefslogtreecommitdiff
path: root/draft-schanzen-r5n.xml
diff options
context:
space:
mode:
Diffstat (limited to 'draft-schanzen-r5n.xml')
-rw-r--r--draft-schanzen-r5n.xml48
1 files changed, 21 insertions, 27 deletions
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 489d2bb..aeaee50 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -1576,10 +1576,6 @@ BEGIN
1576 <dd> 1576 <dd>
1577 the variable-length extended query. Optional. 1577 the variable-length extended query. Optional.
1578 </dd> 1578 </dd>
1579 <dt>MUTATOR</dt>
1580 <dd>
1581 The 32-bit mutator for the result filter.
1582 </dd>
1583 </dl> 1579 </dl>
1584 </section> 1580 </section>
1585 <section anchor="result_filter"> 1581 <section anchor="result_filter">
@@ -1602,30 +1598,9 @@ BEGIN
1602 it is possible that a desireable result is filtered by a result 1598 it is possible that a desireable result is filtered by a result
1603 filter because of a false-positive test. 1599 filter because of a false-positive test.
1604 </t> 1600 </t>
1605 <t> 1601 <t>
1606 To address this problem, R<sup>5</sup>N uses a <tt>MUTATOR</tt> value
1607 which allows block implemenations that use probabilistic data
1608 structures for result filters to additionally "randomize" the
1609 computation of a probabilistic data structure while remaining
1610 deterministic across peers. The 32-bit <tt>MUTATOR</tt>
1611 value is set by the peer initiating the GET request, and changed
1612 every time the GET request is repeated by the initiator. Peers
1613 forwarding GET requests <bcp14>MUST</bcp14> not change the
1614 mutator value included in the <tt>GetMessage</tt> as they might not
1615 be able to recalculate the result filter with a different <tt>MUTATOR</tt>
1616 value.
1617 </t>
1618 <t>
1619 By properly including the <tt>MUTATOR</tt> value in a probabilistic process, repeated
1620 requests have statistically independent probabilities of creating
1621 false-positives in a result filter. Thus, even if for one request
1622 a result filter may exclude a result as a false-positive
1623 match, subsequent requests are likely to not have the same
1624 false-positives.
1625 </t>
1626 <t>
1627 How exactly a block result is added to a result filter 1602 How exactly a block result is added to a result filter
1628 (together with the <tt>MUTATOR</tt>) <bcp14>MUST</bcp14> be 1603 <bcp14>MUST</bcp14> be
1629 specified as part of the definition of a block type. 1604 specified as part of the definition of a block type.
1630 </t> 1605 </t>
1631 </section> 1606 </section>
@@ -2208,6 +2183,25 @@ gnunet+tcp://12.3.4.5/ \
2208 array. In particular, <tt>K</tt> is never transmitted. 2183 array. In particular, <tt>K</tt> is never transmitted.
2209 </dd> 2184 </dd>
2210 </dl> 2185 </dl>
2186<t>
2187 R<sup>5</sup>N HELLO blocks use a <tt>MUTATOR</tt> value
2188 to additionally "randomize" the computation of the bloom filter while remaining
2189 deterministic across peers. The 32-bit <tt>MUTATOR</tt>
2190 value is set by the peer initiating the GET request, and changed
2191 every time the GET request is repeated by the initiator. Peers
2192 forwarding GET requests <bcp14>MUST</bcp14> not change the
2193 mutator value included in the <tt>RESULT_FILTER</tt> as they might not
2194 be able to recalculate the result filter with a different <tt>MUTATOR</tt>
2195 value.
2196 </t>
2197 <t>
2198 Consequently, repeated
2199 requests have statistically independent probabilities of creating
2200 false-positives in a result filter. Thus, even if for one request
2201 a result filter may exclude a result as a false-positive
2202 match, subsequent requests are likely to not have the same
2203 false-positives.
2204 </t>
2211 2205
2212 <t> 2206 <t>
2213 To filter results of HELLO blocks using the Bloom filter, the 2207 To filter results of HELLO blocks using the Bloom filter, the