commit 665fd221f3bc1e15eb8cb678a401059381764dc8
parent ba17f27036edac9416753f41a3c26a09f12f1ada
Author: Elias Summermatter <elias.summermatter@seccom.ch>
Date: Thu, 10 Dec 2020 15:59:07 +0100
Added some more text
Diffstat:
1 file changed, 71 insertions(+), 19 deletions(-)
diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
@@ -34,7 +34,7 @@
</title>
<seriesInfo name="Internet-Draft" value="draft-summermatter-set-union-01"/>
<author fullname="Elias Summermatter" initials="E." surname="Summermatter">
- <organization>.</organization>
+ <organization>Seccom GmbH</organization>
<address>
<postal>
<street>Brunnmattstrasse 44</street>
@@ -72,7 +72,24 @@
<section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name>
<t>
- --- TEXT HERE ---
+ This document describes the Byzantine Fault Tolerant Set Reconciliation used to efficient and securely
+ synchronize two sets of elements in a peer-to-peer network. It provides strong cryptographic and
+ probabilistic proceedings to discover and ban dishonest and bad behaving peers.
+ </t>
+ <t>
+ The Byzantine Fault Tolerant Set Reconciliation can be used in a variety of different fields of application.
+ It is used in GNS to distribute revocations over the peer-to-peer network and it can be used as a central
+ component in distributed E-Voting systems to securely synchronize the votes between the peers.
+ </t>
+ <t>
+ The internal structure of the elements in the set is handheld by the application using the protocol and is not
+ described more in detail than known limitations.
+ </t>
+ <t>
+ The protocol has been designed to minimize network round-trips and bytes send over the network at the
+ expense of CPU operations and memory usage. Since CPU operations are much cheaper than network round trips.
+ Due to certain parameters the protocol decides whatever either sending the full set or just sending the elements
+ that differ is cheaper.
</t>
<t>
This document defines the normative wire format of resource records, resolution processes,
@@ -91,6 +108,16 @@
</t>
</section>
+ <section anchor="contributors" numbered="true" toc="default">
+ <name>Contributors</name>
+ <t>
+ The major original contributors of this documents have been Elias Summermatter and Christian Grothoff
+
+ The origianl GNU NET implementation of the Byzantine Fault Tolerant Set Reconciliation has been mainly
+ written by Florian Dold and Christian Grothoff
+ </t>
+ </section>
+
<section anchor="ibv" numbered="true" toc="default">
<name>Invertible Bloom Filter</name>
<section anchor="ibv_description" numbered="true" toc="default">
@@ -192,28 +219,54 @@
Depending on the state of the two sets there are different strategies or operation modes how to efficiently
determinate missing elements in two sets of two peers.
</t>
+ <t>
+ The initiating peer starts in the "Expect SE" state and the receiving peer starts in the "Expecting IBF" state.
+ In a first step of the protocol the initiating peer opens a connection to the receiving peer, requests a Strata
+ Estimator from the receiving peer. The receiving peer answers with the Strata Estimator.
+ After the initiating peer has received the Strata Estimator he decides which sync mode is optimal for the
+ the estimated set difference.
+ To ensure that ...... the difference is multiplied by 1.5 if there are more than 200 elements differences between the sets (WHY? line 1398).
+ The Full Synchronisation Mode is used if the flag to force full sync is set, the estimated difference between the two sets is bigger
+ than 25% or the set size of the receiving peer is zero. Otherwise the Individual Element Synchronisation Mode is used.
+
+
+ </t>
<section anchor="modeofoperation_full-sync-client-with-bigger-set" numbered="true" toc="default">
- <name>Full sync mode</name>
+ <name>Full Synchronisation Mode</name>
+
<t>
The simples mode is the full sync mode. The idea is that if the difference between the sets of the two
- peers exceeds a certain threshold the overhead of determinate which elements are different overweight's
- the overhead of sending the complete set. In this case its more efficient to just exchange the full set.
+ peers exceeds a certain threshold the overhead of determinate which elements are different overweight
+ the overhead of sending the complete set. In this case its more efficient to just exchange the full sets.
+ ############# IMAGE ##################
+ </t>
+ <t>
+ If the set of the initiating peer is bigger than the set of the receiving peer, the initiating
+ peer sends a "Request Full" message and change from "Expecting SE" in "Full Receiving" State.
+ In all other cases the initiating peer starts sending all set elements to the other peer
+ followed by the "Full Done" message and changes into "Full Sending" State.
+ </t>
+ <t>
+ <strong>Expecting IBF: </strong>
+ If a peer in the in state "Expecting IBF" receives a "Request Full" message from the other peer, the
+ peer starts sending all the elements of the set followed by a "Full Done" message and the change to the
+ "Full Sending" State. If the peer receives an "Full Element" the peer changes to the state "Full Receiving".
</t>
<t>
- After the initiating peer (Client) opened a connection to the other peer (Server) the Server answers
- with a SE(C) of his set and changes to the "Expecting IBF" state. When the client receives the SE(C)
- from the server and the client set size is smaller or equal to the set size of the server the client
- changes from the Expect SE State to Full Sending State and starts sending Full element requests containing the set
- of the client.
- If the set size of the client is larger than the servers set size the client changes into Full Receiving
- (HINT: EXPECT IBF in code) mode an sends a Request Full message to the server.
+ <strong>Full Sending: </strong>
+ While a peer is in "Full Sending" state the peer expects to continuously receiving elements from the other
+ peer. As soon as a the "Full Done" message is received the peer changes into "Finished" state
</t>
<t>
- If the Server receives
+ <strong>Full Receiving (In code: Expecting IBF): </strong>
+ While a peer is in "Full Receiving" state the peer expects to continuously receiving elements from the other
+ peer. As soon as a the "Full Done" message is received the peer starts sending his complete set to the other
+ peer followed by a full done. After sending the last message the peer changes into "Finished" state.
</t>
+
</section>
<section anchor="modeofoperation_individual-elements" numbered="true" toc="default">
- <name>Individual element sync mode</name>
+ <name>Individual Element Synchronisation Mode</name>
<t>--- TEXT HERE ---</t>
</section>
<section anchor="modeofoperation_combined-mode" numbered="true" toc="default">
@@ -261,8 +314,7 @@
</dd>
<dt>MSG TYPE</dt>
<dd>
- is a 16-bit unsigned integer of the GNUNET header which contains a message number
- in the GNUNET Protocol. For this message the number is 563.
+ is a 16-bit unsigned integer in network byte order (BIG ENDIAN) with the value as registered in GANA ########### HERE
</dd>
<dt>OPERATION TYPE</dt>
@@ -275,7 +327,7 @@
</dd>
<dt>APX</dt>
<dd>
- is 512bit GNUNET hashcode that identifies the application.
+ is SHA-512bit hash that identifies the application.
</dd>
</dl>
</section>
@@ -287,7 +339,7 @@
<section anchor="messages_ibf_description" numbered="true" toc="default">
<name>Description</name>
<t>
- This message is send in the peer2peer protocol to transmit the IBF to the other client
+ This message is send in the peer2peer protocol to transmit the IBF to the other client ### Wann, in welchem state übergange verschickt, was passiert wenn sie entfangen wird was passiert
</t>
</section>
<section anchor="messages_ibf_structure" numbered="true" toc="default">
@@ -467,7 +519,7 @@
</dd>
<dt>GNUNET HASH</dt>
<dd>
- is a 512-bit GNUNET Hash of the element that is requested with a inquiry message.
+ is a SHA-512bit hash of the element that is requested with a inquiry message.
</dd>
</dl>
</section>
