commit 887c2c28be70606826175f403e52366ccd80e1af
parent 1c19f6363ff42d501bc2f85991ef84b1b1f86388
Author: Elias Summermatter <elias.summermatter@seccom.ch>
Date: Mon, 14 Jun 2021 10:18:12 +0200
Fixed some bug in the implementation
Diffstat:
1 file changed, 17 insertions(+), 21 deletions(-)
diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
@@ -1003,7 +1003,8 @@ hashSum | 0x0101 | 0x5151 | 0x5050 | 0x0000 |
that are missing from the active peer's set.
In this case the passive peer answers with <em><xref target="messages_offer" format="title" /></em> messages
which contain the SHA-512 hash of the requested element. If the passive peer does not have an element with
- a matching element ID, it MUST ignore the inquiry (in this case, a bucket was falsely classified as pure, decoding the IBF will eventually fail, and roles will be swapped). <!-- FIXME: should we not remember that this happened and FAIL if the other peer sends DONE instead of an IBF? @Christian this is not implemented should I add it to the RFC anyways? -->
+ a matching element ID, it MUST ignore the inquiry (in this case, a bucket was falsely classified as pure, decoding the IBF will eventually fail, and roles will be swapped).
+ T <!-- FIXME: should we not remember that this happened and FAIL if the other peer sends DONE instead of an IBF? @Christian this is not implemented should I add it to the RFC anyways? -->
If multiple elements match the 64 bit element ID, the passive
peer MUST send offers for all of the matching elements.
</dd>
@@ -1287,7 +1288,7 @@ hashSum | 0x0101 | 0x5151 | 0x5050 | 0x0000 |
<dt>IBF SIZE</dt>
<dd>
- is a 32-bit unsigned integer which signals the total number of buckets in the IBF. The minimal number of buckets is 79.
+ is a 32-bit unsigned integer which signals the total number of buckets in the IBF. The minimal number of buckets is 37.
</dd>
<dt>OFFSET</dt>
<dd>
@@ -1303,7 +1304,6 @@ hashSum | 0x0101 | 0x5151 | 0x5050 | 0x0000 |
is a 16-bit unsigned integer, which describes the number of bits that
are required to store a single counter. This is used for the unpacking function as described
in the <xref target="performance_counter_variable_size" format="title" /> section.
- <!-- @Christian changed this t o 16-bit to make it align better ist that oke or should i leave it 8-bit? -->
</dd>
<dt>IBF-SLICE</dt>
<dd>
@@ -1914,7 +1914,7 @@ hashSum | 0x0101 | 0x5151 | 0x5050 | 0x0000 |
described in <xref target="RFC1951"/> to improve performance. This can be recognized
by the different message type number from <xref target="gana" format="title" />.
</t>
- <section anchor="messages_se_structure" numbered="true" toc="default">
+ <section anchor="messages_sec_structure" numbered="true" toc="default">
<name>Structure</name>
<t>
The key difference between the compressed and the uncompressed Strata Estimator is that the
@@ -2022,14 +2022,10 @@ hashSum | 0x0101 | 0x5151 | 0x5050 | 0x0000 |
</t>
<t>
The constant IBF_BUCKET_NUMBER_FACTOR is always 2 and IBF_MIN_SIZE is 37.
- <!-- Above we wrote 79. What gives? @Christian79 is the static size for the SEs and 37 is the minimal size for an IBF//. Also, didn't your thesis somewhere conclude
- that the IBF FACTOR should be 2? @Christian Your right :-)) You also write 2 in the function below!
- Please cite exact parts of the thesis, not the entire document! -->
The method for deriving
this can be found in the IBF parameter study in Summermatter's work in section 4.5.2. <xref target="byzantine_fault_tolerant_set_reconciliation" format="default"/>
</t>
<figure anchor="performance_formulas_operationmode_code">
- <!-- Why use RTT_MIN_FULL=2, if the average is 2.25? @Christian this are just the minimum (RTT_MIN_FULL) round tips not an avg. -->
<artwork name="" type="" align="left" alt=""><