[ih] Lessons to be learnt from Internet history

[Jack Haverty]

IIRC (it's been almost 35 years!), there was a *lot* of discussion
about the need to deal with two semi-conflicting issues: 1) the
evolution of the protocol, and 2) the need to have a stable snapshot
that could be used to build early real systems.  In the TCP2.x era,
usage was all in the form of demos and experiments.  To become real,
the technology needed to be usable as communications infrastructure -
out of the lab and into production as a service - The Internet.

I was one of the first round TCP implementors, who all did a series of
the early implementations, with identifiers like TCP2.5, TCP2.5+, etc.
 You couldn't distinguish these variants easily from packet contents -
you had to know what version the other guy was using.  That was OK for
demos and experiments.   I did the Unix TCP, Dave Clark did Multics,
Bill Plummer did Tenex, Bob Braden did IBM, Jim Mathis did MOS, Dave
Mills did Fuzzballs, etc. (Who did I forget...?  Sorry...)

That "stable snapshot" was intended to be created as TCP 3.  But days
after TCP 3 came out some problems were discovered, so TCP 4 was
quickly created and led through a lengthy process of documentation and
standardization.  The concrete set very hard.

BTW, TCP 3 is a good illustration of a mistake, i.e., a lesson
learned.  Every earlier TCP in the 2.x series was implemented before
it was documented formally.  The document captured what had been
proven to work.  TCP 3 was invented and documented before it was
implemented.  It didn't work.  TCP 4 was implemented, and then
documented and standardized.  It works.

There was a *lot* of discussion about what belonged in packet headers,
and especially how big fields should be.  We considered, and rejected,
larger addresses.  One major concern was efficiency.  Most network
packets at the time were short - often just a single byte of user data
from remote-login echoing from users typing at terminals.  Once you
put all the headers in front of that byte, you'd end up with a
*maximum* efficiency of use of the communications line of a few
percent.  That kind of characteristic of the technology could have
killed it, if the beancounters heard that the $$$$s being spent on
those expensive comm lines were 95+% overhead.  So we tried to keep
fields very small, and even invented "IP options" as a way to extend a
header to carry more stuff if you really needed it for some particular
application.

We knew that some of those header fields would be too small.  But we
didn't agree on which ones.  So we expected V4 to be replaced,
quickly, and a series of Vx++ to be the norm, as it had been in the
prior year or two.  We certainly didn't expect IPV4 to last for 30+
years!

In order to permit evolution, and to make it possible for software to
unambiguously determine which vintage of the protocol it was
receiving, the IPV4 header contained 4 bits of version number, which
had to be "4" for IPV4.  That 4 bits was consciously and explicitly
put at the beginning of the packet header.   Therefore any subsequent
version, e.g., V5, V6, etc., could do whatever it wanted with the rest
of the header - change address lengths, etc.  Any "old" V4
implementation could reliably detect that a V5+ packet was beyond its
capability, and reject it rather than doing something stupid with the
rest of the header as if it were V4.  (See RFC722 for the thoughts
behind this).

Basically, unless the first 4 bits of a packet contained the value 4,
an IPV4 implementation would throw the packet away.  If/when a V5, V6,
etc., was defined, they could define the rest of the packet header
however they liked.  This was the ultimate "hook" for evolution.

At every quarterly meeting, there was always a long (15-20 item) list
of "things we have to deal with later", such as "Expressway Routing"
or "Multi-homed Hosts".  So we knew there were longer term issues to
be solved, but if they didn't impact immediate needs, the current IP
version could be used to implement user systems.   So it was well
known that IPV4 was an interim solution.

In fact, given the prior experience with earlier versions of TCP/IP,
the protocol (including header formats, state machine, etc.) I think
we expected that the next version after IPV4 would occur after one or
two more meeting, e.g., in about 6 months max.    Of course it didn't
happen that way - IPV4 had its 30th birthday not long ago.

There *was* a general feeling that IP would be eventually superceded
by OSI/CCITT/ISO efforts, once they got their act together and
produced the "real" solution to all requirements.   Meanwhile, we just
kept writing code and deploying systems that used TCP/IP to interact.

In retrospect, I think that the documentation and standardization of
IPV4 was probably the critical event that caused the decades-long
extension of the IPV6 evolution.  V4 was a stable platform, and it
worked for a lot of the things that people wanted to do.  So it
quickly acquired a user base, and an installed base of equipment and
software.  With every new installation, it became more tedious to
change.  Also important, there was little if any pressure to advance.
Were there *any* applications that people wanted to do over the
Internet that couldn't be done because of IPV4 limitations?  Running
out of addresses is the only showstopper I can think of, and it's just
happening, probably, now.  Unless someone creates some new magic like
NAT.

IMHO, IPV6 has been around for quite a while but it hasn't been
technical reasons delaying its adoption.  It's more that there has
been little need to do so, as perceived from the users' vantage point.
 It's not been too hard, it's been not urgent enough to overcome
inertia.

Getting back to lessons learned...  I think the primary lesson is that
one should think long-term, but act short-term.   Going through a
series of rapid cycles of deploying and operating real systems
unearthed situations and problems that would not have been anticipated
by years of whiteboard-ware and thinking and meeting. You have to do
both.

/Jack Haverty


On Tue, Feb 19, 2013 at 3:54 PM, Richard Bennett <richard at bennett.com> wrote:
> 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
>