The following is meant to be used for demonstration purposes.
It is meant for any and all to make reference to in discussions where
"16 bits" may come into play.
(I anticipate sending out something soon which does just that. ;-))
What's 16 Bits Between Friends?
In any discussion about protocols, where an object is sized as N bits,
there will inevitably come a discussion about specific values for N.
There may be tendencies to make values of N divisible evenly by 4, 8,
16, or even 32.
Similarly, this may occur for choices for constituent parts, where there
is a trade-off between size of the object component, and the number of
objects that might be seen.
So, what is the case against something having an "extra" 16 bits,
meaning 16 bits more than is likely necessary even in the most extreme
of high-ball predictions for need?
That's where a simple example can illustrate what an "extra" 16 bits
really looks like.
Consider a physical object, something that is itself quite common: the
rest-room key for a coffee shop.
The key itself has no intrinsic value, but the lack of a key can have
dire consequences (at least to the prospective user of the rest-room.)
Accordingly, common practice is to attach the key to a suitably sized
object, small enough to be carried, but large enough so that it does not
fit in a pocket.
One common object is the hub-cap of an automobile's wheel (sans wheel
and automobile, of course!). A hubcap is approximately 1 square foot, or
0.1 m^2 in area.
The key is not bolted directly on, but instead typically attached by a
short cord or chain, usually about 4 inches (0.1m).
So, what happens if we enlarge either the hubcap, or the chain, by 16
bits? It becomes 65536 times the size.
The hubcap grows to the size of the deck of an aircraft carrier.
The chain or cord, becomes 6.5km long.
I would argue, then, that 16 bits too much, is *way* too much, in pretty
much any situation. The example makes this, one would hope, self-evident.
(The presumption must be maintained, however, that the underlying object
is appropriately sized to begin with, otherwise the analogy fails.)
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
