aboutsummaryrefslogtreecommitdiff
path: root/spec/eris.adoc
diff options
context:
space:
mode:
Diffstat (limited to 'spec/eris.adoc')
-rw-r--r--spec/eris.adoc19
1 files changed, 9 insertions, 10 deletions
diff --git a/spec/eris.adoc b/spec/eris.adoc
index 42d9417..c3b43e4 100644
--- a/spec/eris.adoc
+++ b/spec/eris.adoc
@@ -112,20 +112,19 @@ ERIS uses two block sizes: 1KiB (1024 bytes) and 32KiB (32768 bytes). The block
Both block sizes can be used to encode content of arbitrary size. The block size of 1KiB is an optimization towards smaller content.
-[TODO]
-====
-TODO: Content smaller than TODO SHOULD be encoded with block size 1KiB, content larger than TODO SHOULD be encoded with block size 32KiB.
-====
-
The block size is encoded in the read capability and the decoding process is capable of handling both cases.
-[NOTE]
-====
-When using block size 32KiB to encode content smaller than 1KiB, the content will be encoded in a 32KiB block. This is a storage overhead of over 3100%. When encoding very many pieces of small content (e.g. short messages or cartographic nodes) this overhead is not acceptable.
+Implementations MUST suppport encoding and decoding content with both block sizes (1KiB and 32KiB).
-On the other hand, using small block sizes increases the number of internal nodes that must be used to encode the content (see <<_collect_reference_key_pairs_in_nodes>>). When encoding larger content it is more efficient to use a block size of 32KiB.
-====
+==== Recommendation on Block Size Choice
+
+Applications are RECOMMENDED to use a block size of 1KiB for content smaller than 16KiB and a block size of 32KiB for larger content.
+
+When using block size 32KiB to encode content smaller than 1KiB, the content will be encoded in a 32KiB block. This is a storage overhead of over 3100%. When encoding very many pieces of small content (e.g. short messages or cartographic nodes) this overhead might not be acceptable. On the other hand, using block size 1KiB to encode large content is also not efficient, as the content is split into many small 1KiB blocks and must be reassembled using internal nodes (see <<_collect_reference_key_pairs_in_nodes>>). When encoding larger content it is more efficient to use a block size of 32KiB. Using 16KiB as a breaking point is reasonable for most applications.
+
+Note that the best choice of block size may depend on other factors such as number of round-trips to the storage layer. Content larger than 1KiB encoded with block size 1KiB will always be encoded in multiple levels, requiring multiple calls to a storage layer. For certain applications it might be better to minizmize the number of calls to the storage layer at the cost of higher storage overhead.
+In other applications the size of the content to be encoded might not be known when encoding starts and block size must be chosen (see <<_streaming>>). In such cases applications should use appropriate heuristics.
=== Convergence Secret