aboutsummaryrefslogtreecommitdiff
path: root/public/index.html
diff options
context:
space:
mode:
Diffstat (limited to 'public/index.html')
-rw-r--r--public/index.html28
1 files changed, 11 insertions, 17 deletions
diff --git a/public/index.html b/public/index.html
index f495317..5b9562e 100644
--- a/public/index.html
+++ b/public/index.html
@@ -718,32 +718,26 @@ This document describes the Encoding for Robust Immutable Storage (ERIS). ERIS i
<div class="paragraph">
<p>Both block sizes can be used to encode content of arbitrary size. The block size of 1KiB is an optimization towards smaller content.</p>
</div>
-<div class="exampleblock">
-<div class="content">
<div class="paragraph">
-<p>TODO: Content smaller than TODO SHOULD be encoded with block size 1KiB, content larger than TODO SHOULD be encoded with block size 32KiB.</p>
+<p>The block size is encoded in the read capability and the decoding process is capable of handling both cases.</p>
</div>
+<div class="paragraph">
+<p>Implementations MUST suppport encoding and decoding content with both block sizes (1KiB and 32KiB).</p>
</div>
+<div class="sect3">
+<h4 id="_recommendation_on_block_size_choice"><a class="anchor" href="#_recommendation_on_block_size_choice"></a>2.2.1. Recommendation on Block Size Choice</h4>
+<div class="paragraph">
+<p>Applications are RECOMMENDED to use a block size of 1KiB for content smaller than 16KiB and a block size of 32KiB for larger content.</p>
</div>
<div class="paragraph">
-<p>The block size is encoded in the read capability and the decoding process is capable of handling both cases.</p>
+<p>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 <a href="#_collect_reference_key_pairs_in_nodes">Section 2.4.3</a>). 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.</p>
</div>
-<div class="admonitionblock note">
-<table>
-<tr>
-<td class="icon">
-<div class="title">Note</div>
-</td>
-<td class="content">
<div class="paragraph">
-<p>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.</p>
+<p>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.</p>
</div>
<div class="paragraph">
-<p>On the other hand, using small block sizes increases the number of internal nodes that must be used to encode the content (see <a href="#_collect_reference_key_pairs_in_nodes">Section 2.4.3</a>). When encoding larger content it is more efficient to use a block size of 32KiB.</p>
+<p>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 <a href="#_streaming">Section 2.4.4</a>). In such cases applications should use appropriate heuristics.</p>
</div>
-</td>
-</tr>
-</table>
</div>
</div>
<div class="sect2">
@@ -2057,7 +2051,7 @@ ERIS-Decode(BLOCK-SIZE, LEVEL, ROOT-REFERENCE, ROOT-KEY):
</div>
<div id="footer">
<div id="footer-text">
-Last updated 2021-09-19 19:30:54 +0200
+Last updated 2021-09-27 10:40:36 +0200
</div>
</div>
</body>