17 Jun
2018
17 Jun
'18
5:58 p.m.
From: "Theodore Y. Ts'o"
To be fair, it's really easy to be wise to after
the fact.
Right, which is why I added the caveat "seen to be such _at the time_ by some
people - who were not listened to".
failed protocols and designs that collapsed of their
own weight because
architects added too much "maybe it will be useful in the future"
And there are also designs which failed because their designers were too
un-ambitious! Converting to a new system has a cost, and if the _benefits_
(which more or less has to mean new capabilities) of the new thing don't
outweigh the costs of conversion, it too will be a failure.
Sometimes having architects being successful to add
their "vision" to a
product can be worst thing that ever happened
A successful architect has to pay _very_ close attention to both the 'here and
now' (it has to be viable for contemporary use, on contemporary hardware, with
contemporary resources), and also the future (it has to have 'room to grow').
It's a fine edge to balance on - but for an architecture to be a great
success, it _has_ to be done.
The problem is it's hard to figure out in advance
which is poor vision
versus brilliant engineering to cut down the design so that it is "as
simple as possible", but nevertheless, "as complex as necessary".
Absolutely. But it can be done. Let's look (as an example) at that IPv3->IPv4
addressing decision.
One of two things was going to be true of the 'Internet' (that name didn't
exist then, but it's a convenient tag): i) It was going to be a failure (in
which case, it probably didn't matter what was done, or ii) it was going to be
a success, in which case that 32-bit field was clearly going to be a crippling
problem.
With that in hand, there was no excuse for that decision.
I understand why they ripped out variable-length addresses (I was just about
to start writing router code, and I know how hard it would have been), but in
light of the analysis immediately above, there was no excuse for looking
_only_ at the here and now, and not _also_ looking to the future.
Noel
18 Jun
18 Jun
9:16 a.m.
New subject: core
On 17 Jun 2018, at 18:58, Noel Chiappa <jnc(a)mercury.lcs.mit.edu> wrote:
One of two things was going to be true of the 'Internet' (that name
didn't
exist then, but it's a convenient tag): i) It was going to be a failure (in
which case, it probably didn't matter what was done, or ii) it was going to be
a success, in which case that 32-bit field was clearly going to be a crippling
problem.
There's a third possibility: if implementation of the specification is too
complicated it will fail, while if the implementation is simple enough it may succeed, in
which case the specification which allowed the simple implementation will eventually
become a problem.
I don't know whether IP falls into that category, but I think a lot of things do.
--tim
3:33 p.m.
New subject: core
On 18 Jun 2018, at 15:33, Noel Chiappa
<jnc(a)mercury.lcs.mit.edu> wrote:
When you say "if implementation of the specification is too complicated it
will fail", I think you mean 'the specification is so complex that _any_
implementation must _necessarily_ be so complex that all the implementations,
and thus the specification itself, will fail'?
Yes, except that I don't think the specification itself has to be complex, it just
needs to require implementations be hard, computationally expensive, or both. For
instance a specification for integer arithmetic in a programming language which required
that (a/b)*b be a except where b is zero isn't complicated, I think, but it requires
implementations which are either hard, computationally-expensive or both.
And for "in which case the specification which allowed the simple
implementation will eventually become a problem", I think that's part of your
saying 'you get to pick your poison; either the spec is so complicated it
fails right away, or if it's simple enough to succeed in the short term, it
will neccessarily fail in the long term'?
Yes, with the above caveat about the spec not needing to be complicated, and I'd say
something like 'become limiting in the long term' rather than 'fail in the
long term'.
So I think your idea was that, if there's a choice between a do-the-right-thing,
future-proof (variable-length-address field) solution or a will-work-for-now,
implementationally-simpler (fixed-length) solution, then you should do the right thing,
because if the thing fails it makes no odds and if it succeeds then you will regret the
second solution. My caveat is that success (in the sense of wide adoption) is not
independent of which solution you pick, and in particular that will-work-for-now solutions
are much more likely to succeed than do-the-right-thing ones.
As I said, I don't know whether this applies to IP.
--tim
2139
days inactive
2140
days old
2 comments
2 participants
participants (2)
-
jnc＠mercury.lcs.mit.edu -
Tim Bradshaw