<h1>Tradeoff: how much complexity</h1>
<p>
- Filler - summarize various options. Maybe a 2-d graph with:
-
- <pre>
- c |
- l |
- ^ i |
- e |
- i n |
- n t | multiple knobs,
- c | requires multiple
- r c | fallbacks, but a
- e o | non-SR solution works
- a m |
- s p |
- i l |
- n e |
- g x | require more uniformity,
- i | interop testing is easier,
- t | but writing correct server
- y | requires more effort
- +------------------------------------------------------
- > increasing server complexity
+ Tradeoffs in implementation complexity
+ <table id="border">
+ <tr>
+ <th style="width:8%;"></th>
+ <th>Lots of knobs in the NBD spec</th>
+ <th>Mandate all-or-none server implementation</th>
+ </tr>
+ <tr>
+ <td style="text-align:center;">Pro</td>
+ <td>
+ <ul>
+ <li>Implement as much or as little as convenient for the
+ server
+ <li>Matches reality that no one resize solution fits all
+ </ul>
+ </td>
+ <td>
+ <ul>
+ <li>Easier interoperability testing
+ <li>Client can rely on all servers giving same response
+ </ul>
+ </td>
+ </tr>
+ <tr>
+ <td style="text-align:center;">Con</td>
+ <td>
+ <ul>
+ <li>More combinations requires more testing
+ <li>Odd or untested combinations could produce weird
+ behaviors or even CVEs
+ <li>Clients must be prepared for more fallbacks
+ <li>NBD protocol tries to be as simple as possible
+ </ul>
+ </td>
+ <td>
+ <ul>
+ <li>Not all tradeoffs map easily to existing implementation
+ <li>Open-ended structured replies requires more efforts for
+ writing a compliant server
+ </ul>
+ </td>
+ </tr>
+ </table>
</p>