COMMENT ⊗   VALID 00005 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	∂17-Apr-80  0110	Mark Crispin <Admin.MRC at SU-SCORE> 	PUP software on SCORE 
C00006 00003	∂18-Apr-80  2255	ADMIN.JKS at SU-SCORE 	the battle continues...    
C00024 00004	∂19-Apr-80  2353	Mark Crispin <Admin.MRC at SU-SCORE> 	the flames continue...
C00029 00005	∂20-Apr-80  2135	Mark Crispin <Admin.MRC at SU-SCORE> 	paper available for comments    
C00032 ENDMK
C⊗;
∂17-Apr-80  0110	Mark Crispin <Admin.MRC at SU-SCORE> 	PUP software on SCORE 
Date: 17 Apr 1980 0103-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: PUP software on SCORE
To: CSD.Mogul at SU-SCORE
cc: [SU-SCORE]<SU-NET>SU-NET.DIS.3: ;

     In my opinion, any time spent on programming PUP for a 1200
baud asynchronous line between SCORE and SHASTA would be wasteful
to the point of being ludicrous; of equal value to, say, writing
a BASIC interpreter for the ALTOs.  Also, I do not believe that
we will ultimately want to use PUPs in our local network.  They
lose in many ways, the most important being the addressing
limitations and incompatability from what the rest of the world
is doing.

     I envision PUPs eventually as being "the old crufty protocol
you need to use to talk to ALTOs" -- not the production protocol.
We should consider TCP -- or possibly MIT Chaosnet protocol,
which has the advantage that a lot of the modern technology
software (MM, XMAILR, my TELNET...) already handles Chaosnet and
a Chaosnet/TCP gateway is being worked on.  Why should we program
today for yesterday's technology and protocols when we need to
serve tommorrow's needs?  Just because Xerox wrote this software
some years ago, and BBN hacked it to work on the -20?

     There is another reason for this; very little user software
uses PUPs - mostly the old MAXC TENEX software.  Much better
software exists, and support for many of the facilities we will
need in our local network already exists using DECnet.  My
intended implementation will look like a DECnet to user software,
(allowing all the nice remote station, etc. stuff to work) and
will be completely different internally.  All we need is some
mode to be able to talk to the Dover and the IFS.

     For this reason, and others, I like the idea of doing SAIL
first.  SAIL can get the quick and dirty PUP-only implementation
that will serve the needs of getting the ARPANET and our local
network connected.  This will free up time to design and
implement a well thought out network service on SCORE.

-- Mark --
-------

∂18-Apr-80  2255	ADMIN.JKS at SU-SCORE 	the battle continues...    
Date: 18 Apr 1980 2242-PST
From: ADMIN.JKS at SU-SCORE
Subject: the battle continues...
To: [SU-SCORE]<SU-NET>SU-NET.DIS.3:

For those of you who don't know what's going on by now
flush this message and get on to something more important...
For those of you who want to know what's going on please keep these
conventions in mind:  <1> This message is a response to a reply
to an opinion of a comment on a proposal.  <2> Excerpts from my
opinion appear as indented one-liners, Mr. Crispins reply as text delineated
with ";;;", and my reply as left-justified text.  Good luck..
----------------------------------------------------------------------

;;;  I disagree with your message on several points, and I think
;;; that this we are going to have several conflicts about this.
;;;  I would like to prefix my answer with the hope that these
;;; conflicts remain confined to the professional issue of design
;;; and do not become personal conflicts.
;;;  With this, let me answer your points:

I disagree with your response on all points, and I think we are having
a conflict about this.  I would like to preface my message with a
reminder that I never take professional issues personally. 

    I DO NOT believe that Pup will be abandoned at ANY time in
    the future.
;;;  I did not say abandoned.  I don't think it makes any sense to
;;; reprogram the Altos, including the IFS and the Dover.  So we
;;; will need PUP for this.

What you said was: "the old crufty protocol you need to use to talk
to the ALTOs -- not the production protocol".  Since Ethernet will
be the production network, and there can really only be one production
protocol on the network, I take this to mean you plan to abandon Pup.

    This decision has already been made and I see no
    point in arguing any further.
;;;  I disagree.  Ralph wants us to be able to use some of the
;;; capabilities of the DECnet software, for example.  Of course,
;;; I consider DDCMP to be even more of a dead end than PUPs.

Ralph has never said anything to me about using DECnet software.
Besides, DEC is abandoning DECnet anyway (the Xerox, Intel, DEC conspiracy)
so why worry about it??

    TCP and Arpanet compatibility are
    clearly not in our interests given the direction and expected lifetime
    of the Arpanet.
;;;             ****** NO!!!!!!!!!!!!!!!! ******
;;;  I cannot express myself stronger about this.  Not only is
;;; this in our interests, but it is essential that we move in
;;; these directions.  While ARPANET is not forever some form
;;; of a national research network is.  The whole purpose behind
;;; the TCP development is to make moving away from the ARPANET
;;; practical.
;;;  Our local network - I didn't say our Ethernet - must have
;;; internetwork capability.  It would be a mistake of enormous
;;; magnitude not to plan for this.  If Ethernet hardware
;;; technology is going to make up our local network, we must
;;; make whatever changes are necessary to adapt Ethernet for
;;; tommorrow's needs.
;;;  Even given the ultimate demise of ARPANET, there is no sign
;;; of ARPANET going away at all soon, and I have been assured on
;;; several occasions that there is no plan on dismantling
;;; ARPANET without something better to take its place.  Clearly
;;; what is going on is that nobody is seriously planning
;;; dismantling the ARPANET at the present time, as it is a tool
;;; which currently has no acceptable replacement.

I don't think the Arpanet is going away either.  But I think our
dependence on it is!  There is also no truth to the rumor that
the Pup architecture in not capable of internetwork communication.
To quote the Pup paper [ifs:<pup>PupPaper.press]:

"Pup is the name of an internet packet format, a hierarchy of protocols,
and a style of internetwork communication.  ...  This work serves as
the basis for a functioning internetwork system that provides service
to about 1000 computers, on 25 networks of 5 different types, using
20 internetwork gateways."

One of those 5 types is the Arpanet itself.  As far as the Ethernet
not being able to support tomorrows needs I like the following point
Bob Metcalfe makes:  Most people think the Ethernet runs at 3 megabits
per second.  In reality, it runs at 2.94 Mbits/sec.  Small difference
right?  Wrong!  That difference is greater than the entire bandwidth
of the Arpanet.  Enough said..

    There has never been any studies that show preference
    of the TCP protocols over the Pup architecture.
;;;  I am not a fan of TCP.  Never was, never will be.  But it
;;; does address the problem of multiple-network traffic, and we
;;; will soon come under great pressure to implement TCP.
;;; Translate that to mean "MRC will soon come under great
;;; pressure to implement TCP" and you will see why MRC does not
;;; want any decisions made now that will make it impossible for
;;; him to implement TCP when the word comes down from on high.
;;;  I believe that protocol conversion and circuit-building are
;;; a more immediately practical means of network addressing than
;;; multi-network packet switching.  However, no matter what
;;; happens, it is ESSENTIAL THAT WE BE ABLE TO TALK TO THE REST
;;; OF THE WORLD NOW AND IN THE FUTURE.

Pup handles multiple network traffic just fine.  Maybe not the way
you would like it to, but it does handle it nonetheless.  As far as
TCP implementation goes I haven't even heard any talk about it yet.
But I DO hear everyone screaming for Ethernet/Pup connections.
I think we should be able to talk to the rest of the world too.
But remember, this is Stanford University, we CREATE the future.
We are expected to be revolutionary, not evolutionary.

    In particular, I
    know of no addressing limitations or other operational problems with
    Pup that make it unusable.
;;;  PUP has a 16 bit address space.  Even Internet's inadequate
;;; address space has double the bandwidth.  PUP has 32 bits of
;;; contact ID; only equal to that of ARPANET NCP.  Anybody who
;;; believes this is adequate address space should go and read
;;; the past several years of ARPANET and Internet memoranda.
;;;  With these address space limitations, it will be impossible
;;; to communicate with several existing ARPANET hosts from the
;;; Ethernet unless you TELNET to SCORE, log in there, and TELNET
;;; to the destination.  If the Stanford Department of Computer
;;; Science thinks this is a satisfactory way of doing things, it
;;; is greatly lacking in vision.
;;;  Even given the 16 bit "Ethernet" address space, the truly
;;; damning thing is the 32 bit contact id.  Anything you could
;;; have done to get around the 16 bit problem is ruined by the
;;; lack of contact id bandwidth -- because some hackers almost
;;; 10 years ago thought it would be cute to use ARPANET
;;; NCP-style "well-known socket NUMBERS" (ugh!).

OK folks, here I go again with my address cover speech.  The Pup
architecture has a LOCAL address cover of 16 bits.  This means
you may only have 255 hosts connected to a single piece of coax.
This is due primarily to electrical limitations.  Any of those
hosts can be a gateway and connect multiple Ethernets.  The
INTERNET address cover is 48 bits (255 nets + 255 hosts/net +
4 billion sockets/host).  If you use the 32 bit socket number
as an Arpanet contact id you lose.  Naturally, Pup doesn't attempt
to use socket numbers in this manner.  I'll agree that 255 networks
may be a limitation in the future but don't forget: Gateways may
transparently encapsulate packets with as many internet address
bits as they want!

    The magnitude and wide range of software
    and software specifications Xerox has provided us far out weighs the
    time spent implementing Score MM and Telnet.
;;;  I do not call CHAT, EFTP, and FTP a "wide range of software".
;;; I have seen Xerox's Ethernet software for the PDP-10 and am
;;; not impressed.  It was fine and great - back when the world
;;; was Tenex and nothing better existed.
;;;  Others that I have talked with - mostly people at MIT whose
;;; opinions I have good reason to respect - agree with me, except
;;; perhaps they are harsher in condemning the Ethernet software.

I don't call Chat, EFTP, and FTP a "wide range of software" either.
This is what I call a wide range of software:

Level 0:  Packet transport mechanisms for Ethernet, MCA, Arpanet,
	  leased lines, and packet radio.

Level 1:  Internetwork datagram support (addressing and routing)
	  for Altos, Dorados, D-series machines, Nova/Eclispe,
	  PDP-11/VAX, and PDP-10/-20. 

Level 2:  Interprocess communication primitives including:
	  Telnet, Gateway-Info, FTP, Misc-Services, Echo,
	  RTP, BSP, Mail, EFTP, Ears, Statistics, CopyDisk,
	  EventReport, PrinterReport, Juniper, RPCP,
	  Clearinghouse, Librarian, WIFS, Leaf, TeleSwat,
	  WFS, Spruce, Peek/DMT, and StarTrek protocols.

Level 3:  Conventions for data structuring and process interaction:
	  EFTP, FTP/Telnet, Chat, Empress (document printing),
	  Woodstock (remote file service), Misc-Services (date/time,
	  mail, name lookup, booting, user authentication, etc.).

Level 4:  Application-defined protocols...

And these are only the things Xerox has made public!  The criticisms
about the complexity of the software are justified.  The Alto/BCPL
environment is certainly not state-of-the-art.  But Pup is
implemented independently of the underlying architecture.  
My Unix 'C' implementation of RTP/BSP Telnet was made in a few
weeks by simply starting with the 4 page protocol specifications;
not by hacking away at the BCPL version of Chat.

    Let's be realistic
    folks, Pup is going to be with us forever.
;;;  Not forever.  For as long as the Dover and I guess the IFS
;;; are useful tools.  The Altos are relatively unimportant.  I
;;; would say the lifetime of the XGP is a good example.

The Altos are incredibly important.  They are the first wave from
an ocean of new computing environments.  Someday, very soon, we can
throw out all our 10's, 20's, and past prejudices and get on
with the business of designing the future.

    Side note:  perhaps the management of this establishment should take
    more time in assuring a consistent sense
    of direction among its' employees.
;;;  I think that the management of this establishment would be
;;; wise to encourage as much dissent and debate on this as
;;; possible, or this establishment is heading for a disaster.
;;;  Perhaps some things are going on that I don't know about.
;;; Perhaps there is a local network project going on that is not
;;; using Ethernet technology, but instead is using something
;;; completely new designed here.  People at MIT are sure
;;; surprised that I don't believe there is any such project
;;; here.  If that is the case, then I am wrong - Ethernet will
;;; only be used for talking to the Altos and sending stuff to
;;; the Dover and there isn't any need to waste any time in
;;; designing software for it.

I think this establishment is heading for a disaster too, but for
different reasons..  Perhaps we should be doing something else while
waiting for our respective disasters to arrive...

John
-------

∂19-Apr-80  2353	Mark Crispin <Admin.MRC at SU-SCORE> 	the flames continue...
Date: 19 Apr 1980 2343-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: the flames continue...
To: ADMIN.JKS at SU-SCORE
cc: [SU-SCORE]<SU-NET>SU-NET.DIS.3: ;
In-Reply-To: Your message of 18-Apr-80 2247-PST

John -

     First, I do not see any reason why Ethernet hardware has to
be tied in with Ethernet software.  The two are completely
separate and distinct issues.  Yes, I believe that PUP will be
abandoned eventually.  It cannot be abandoned yet, because an
important tool - the Dover - requires it and it is a waste of
time to reprogram it.

     I think you are over-generalizing by saying that DEC is
abandoning DECnet.  It is pretty certain that they are abandoning
some of the technology that they are using.  What I was talking
about is the high-level software, which much active development
is being done on.

     As for talking about the bandwidth difference between the
Ethernet and the ARPANET - come on!  You are confusing hardware
issues with software issues.  Sure the Ethernet hardware is fast
enough.  It's the Ethernet software and protocols which are
lacking.

     To quote you: "But remember, this is Stanford University, we
CREATE the future.  We are expected to be revolutionary, not
evolutionary."  Why then, are you saying that protocols designed
in the early 70's are the way of the future?  I do not believe in
needlessly limiting ourselves to one narrow mode, while the rest
of the world passes us by.

     I believe you are misunderstanding my point.  My goal is to
be able to talk to everything, everyplace, and do it in the best
manner possible.  I have seen enough "Flag Days" already -
ARPANET leader lengths, DECsystem-10 dates,... to pass over the
limitations offered by PUP without protest.  I can't sit idly by
and hear the argument that an 8 bit network plus an 8 bit host
plus a 32 bit socket specification is enough bandwidth!  This is
1980, not 1970!  The present Internet format is 8 bit network (a
mistake) plus a 24 bit host - not including the contact id which
is all a socket really is.

     We will have to talk PUP on our local network if it is an
Ethernet.  That was never a question.  I feel that we should also
talk TCP, since it has been established as the standard.  We will
talk the old protocol because it's there and we can use it.  I
feel we should also expand beyond its limitations for the future.
That future will soon be upon us.

     As for the importance of the Altos, I predict that we will
be "throwing away" the Altos before we throw away the 10's, 20's,
or VAXen.  The bulk of the Alto usage still seems to be game
playing.  You are, of course, quite right that the Altos are the
first wave of the future.  But they by themselves are not the
future; the Altos are too slow.  I have yet to hear of any
Stanford computer design project on the level of the Lisp Machine
or CM*, unless you count the S-1.

-- Mark --
-------

∂20-Apr-80  2135	Mark Crispin <Admin.MRC at SU-SCORE> 	paper available for comments    
Date: 20 Apr 1980 2129-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: paper available for comments
To: [SU-SCORE]<SU-NET>SU-NET.DIS.3: ;

I have given some more thought to the issues which I have raised
and John's objections.  I conclude that there is in fact no real
disagreement on what needs to be done now; rather, we disagree on
the needs of the future.

I have written a paper which expouses - in a hopefully non-flaming
manner - my beliefs on the issue.  It is 7 text pages long, and is
available online at SU-SCORE as <SU-NET>PROTOCOL.TXT.

While it is prejudiced towards my side, it is also a plea for
compromise.  Immoderate words such as "disaster" have been used by
both sides; PUP is not a disaster and neither is designing a local
superprotocol - DECnet perhaps is a disaster but nobody's talking
about that.  My feeling is that if things are done the way my paper
proposes, no matter what happens we'd end up winning.  If we stick
with PUP, the worst that happened is that I wasted some of my time
(although strictly modular code is a good idea for other reasons).
If we switch, however, a great deal of groundwork would have been
laid to do so and we won't have to rewrite massive amounts of code.

-- Mark --
-------