[ih] Lessons to be learnt from Internet history

[Richard Bennett]

Well, yeah, it's hard to design future-proof systems but it can be done 
by building in hooks for the substitution of newer versions of things. 
My understanding of TCP/IP is the operating consensus in the early 80s 
was that TCP/IP was a temporary protocol that would someday be replaced 
wholesale with something better, probably OSI. But that didn't happen 
for a number of reasons and as a result we have this system that's very, 
very difficult to upgrade. The IPv6 "transition" shows just how hard it is.

Specifically, the IPv4 address could have had some sort of format/length 
indicator, but it doesn't because it was never meant to last.

Maybe it's just as well because a length byte in the header probably 
would have meant that some other vital piece of information would have 
to go.


On 2/19/2013 1:33 PM, Larry Sheldon wrote:
> On 2/19/2013 3:14 AM, Bob Hinden wrote:
> [Ed. note:  I don't who said what is quoted immediately below--"Ian"?]
>
>>> 1. Think long term.
>>>
>>> Plenty of examples discussed here (good and bad). We need to plan
>>> for an Internet that is around forever, not for a quick fix that
>>> patches an immediate problem while giving rise to longer term
>>> problems.
>
>> While this sounds good, I think in practice it has significant
>> problems.  Many of the problems we see now were understood when the
>> Internet was first developed, but we didn't have practical solutions
>> to them.  Had we insisted on solving everything, it's very likely
>> that nothing would have been done, or it would have been impractical
>> to deploy given the technology at the time.  Just because you
>> understand the problem, doesn't mean you can solve it.
>
> I think that may be the the most prevalent and at the same most poorly 
> understood in all of my experience with systems development.
>
> I was a grunt in several large-scale projects to mechanize the 
> production of telephone directories from the data on the service orders.
>
> The first one was to mechanize all directories--White Pages (delivered 
> to subscribers), information reprint (delivered to the Information 
> Operators monthly) and its supplement (delivered daily--an interesting 
> document printed on IBM 1403's with print trains make of letters lying 
> on their sides), Delivery Lists (arranged for the walking path of the 
> ring-and-flingers) and labels (for the ones that were mailed), and the 
> Yellow Pages.
>
> That one accomplished all but the last.  The Yellow Pages are, it 
> turns out a very different product from the White Pages and have 
> little in common with them once you get a few yards away from the 
> presses.
>
> The second one was a Bell Labs project that I was not a part of, but 
> since we were the only Operating Company with a functioning White 
> Pages system, we were selected as the trial company.
>
> The third one was back with us after Bell Labs gave up.
>
> Remember that I was a pretty small gear in each of these, but from my 
> perspective (both then and more maturely -- better aged -- now) the 
> single thing that killed the first two project were what we have here.
>
> In the first case, the designed system was required to be perfect in 
> every regard--an impossible task from the gitgo because the policies 
> and practices of the company's Northern Region were very different and 
> often contrary to those of the Southern Region. (Some of us realized 
> that the policies and practices of the Southern Region were more like 
> those of the "independent" company that had the franchise for most of 
> the land in the southern region.  My guess is that both we and the 
> "independent" had to use the same printer-contractor because the PUC 
> required that the listings be interfiled.)
>
> I think Bell Labs ran aground on a much bigger sand bar--trying to 
> develop a system for 21 or 22 operating companies.
>
> We finally succeeded by an undocumented practice of "settling" all 
> issues for 50% (or so) of what was wanted, then immediately filing a 
> change request for 100% of the balance.
>
>> I also note that "forever" is a very long time.  We aren't that good
>> at predicting the future to know what will be needed in 10 years,
>> much less a hundred years or more.
>
> Another aspect of the "forever" notion is that for any system with 
> more than a few variable, the number of permutations and combinations 
> quickly reaches an astronomical number.  Until you get into the Real 
> World™ there is know way to know which really exist--there were 
> uncounted "features" that cost a lot that were never exercised, and a 
> similar number of things that had not made the cut that were frequent 
> flyers. (I recall an incident where a program that ran daily in each 
> of the nine computer centers failed in several of them the same 
> night.  It turns out that the problem was a coding error that had been 
> made when the program was first coded a number of years before.
>
> There is a technical term that used to be popular for the idea that 
> everything has to be perfect for a thousand years before anything is 
> implemented--analysis paralysis.
>

-- 
Richard Bennett