Reed's views, was [e2e] Cannara's views

[Cannara]

John, thanks, I agree with you.  I was wrong to say "optimized" in reference
to 56k links, etc.  It was indeed an effort to look around and see what might
be done, given what was thought needed to do.  Xerox' attitude was indeed
unfortunate (as in so many things).  But interestingly enough, Noorda and his
main coder at Novell, adapted what Xerox would not share (or what Noorda
refused to be seen using) and at least solved the addressing problem early on.
So, in some instances, ideas were available to use that the Internet folks
avoided, whether because they had no interest in, or were biased against,
LANs, or because they were just focussed in a narrow problem space.  

By the way, using SNA or the telcos as straw men is very misleading -- SNA was
an extension of IBM's mainframe-controller-slave religion and the telcos were,
and still are, interested in fitting bits into standard frames and charging
for them -- remember ATM to the desktop, where they would own our wallplate
and the cable to it?  Fortunately desktop ATM collapsed of its own economic
weight and backbone ATM will as well.

Alex


John Day wrote:
> 
> Guys,  you are both right and both wrong.
> 
> If I had to describe the process and philosophy of the early protocol
> design efforts, I would have to say that there was distinctly an
> attempt to try to design more on general principle than on the
> specific needs of the moment.  There was also a distinct intent to
> stay away from certain solutions that were seen as "bad" mainly the
> examples of the phone company and SNA.  There was also some
> infatuation with some ideas over others.  (Some for the good, some
> probably not so.)  But remember, it was 1974/5.  The Net was still
> very small and we still had *very* limited experience with it.  We
> had not tried very many things and none of them in the large.  In
> some cases, our attempts to be "general" have turned out to be less
> so than we initially thought, in other case more prescient.
> Hindsight is always 20/20, it is less easy to be so at the time.  And
> as some have indicated, we had to make compromises with both what
> others wanted and what we could do and make work efficiently enough
> at the time.
> 
> There were 3 or 4 contenders for a transport protocol at the time:
> TCP, Delta-t (Watson), XNS, and Cyclades TS.  Cyclades TS was in
> Europe and very poorly known in the US.  XNS was taken out of
> consideration because Xerox would not make the specs public.  Delta-t
> had some very interesting properties especially in connection
> establishment and I often wonder if we couldn't have benefited from
> using some of it.  They were all debated quite heavily at the time.
> 
> (The octet sequencing is really a hold over from before the TCP/IP
> split.  In the original proposal, there was no IP; packets could be
> fragmented at gateways and so a sequence number was required to be
> assigned; with octet sequence numbers it could be easily done.  After
> IP was split off with its own fragmentation/reassembly mechanism, the
> method was retained for other less compelling reasons.)
> 
> Take care,
> John
> 
> At 22:54 -0700 4/14/01, Cannara wrote:
> >David, just a few comments on the pedantry front, since we're now into oracle
> >mode for the young ones...
> >
> >"David P. Reed" wrote:
> >  >
> >  > I changed the subject line because this has nothing to do with Outer Space.
> >  >
> >  > For the students and others that might actually find Cannara's views
> >  > plausible, let me offer another clear point of view.
> >  >
> >  > There are two things that Cannara says over and over.
> >  >
> >  > 1) The current internet protocol doesn't "optimize" the use of new
> >  > technologies (or incorporate those theoretical results that are closely
> >  > tied to the special properties of those cool new things).
> >  >
> >  > 2) New phenomena weren't anticipated in the original design.
> >  >
> >  > (1) is true.  The current internet protocol NEVER "optimized" the use of
> >  > any technology.  So what?  That was part of the design philosophy.  In
> >  > order to be flexible enough to incorporate heterogeneity and change, you
> >  > can't optimize for a particular technology.  More importantly, if you do,
> >  > you die at the next change.
> >
> >...Au contraire, TCP/IP was optimized for small MTU, 56kb/s, byte-oriented
> >transfers, implemented on 16-bit machines that could do 32-bit (double-word)
> >ops.  In other words, Telnet, RPC, FTP, etc.  TCP still counts bytes in
> >sequence #s.  When all 3GBytes of Beethoven's symphonies can be ATMed in
> >19sec, or OC48'd in 1 second, having a transport getting fooled by false
> >congestion positives and dropping out for a second or so doesn't really make
> >sense, no matter how many times we click our slippers and say: "I didn't
> >optimize", "I didn't optimize"...
> >  >
> >  > (2) is wholly false.  The original design philosophy was based on a
> >  > principle of humility - we KNEW we couldn't ever anticipate new apps or
> >  > patterns of use.  At the time, computer-computer connections over LANs were
> >  > thought to be important.  I had designed a protocol to "optimize" what we
> >  > thought might happen in those environments (as had PARC, with PUP).  Rather
> >  > than "fork" the design to pursue our own egotistical desires to demonstrate
> >  > genius in a narrow subset of networking, both groups ended up supporting
> >  > the incorporation of a couple of the important insights into a
> >  > far-from-optimal Internetworking approach.  And guess what?  It paid off.
> >
> >..."Wholly false" -- so all new technology was anticipated, but ignored?  Why,
> >because clairvoyance was assigned no value?  What do you know of the future
> >now that you're not telling us and that networking can safely ignore?  I can't
> >imagine this is what you mean by "wholly false".  It's interesting that a
> >networking system that, for instance, couldn't anticipate needing more than 32
> >bits for addressing all those machines the future held, when Xerox already had
> >implemented 80 in XNS, is somehow bestowing a "pay off".  It certainly has
> >paid off for all who make products and money plugging the holes and working
> >around the 'features' of TCP/IP these days.
> >
> >Alex
> >
> >[clip]