*BSD News Article 33587


Return to BSD News archive

Xref: sserve comp.os.386bsd.misc:2918 comp.os.linux.misc:20611
Newsgroups: comp.os.386bsd.misc,comp.os.linux.misc
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!library.ucla.edu!csulb.edu!nic-nac.CSU.net!charnel.ecst.csuchico.edu!olivea!decwrl!decwrl!netcomsv!calcite!vjs
From: vjs@calcite.rhyolite.com (Vernon Schryver)
Subject: Re: source of TCP/IP (was I hope this wont ignite a major flame ...)
Message-ID: <CtqrFJ.IM5@calcite.rhyolite.com>
Organization: Rhyolite Software
Date: Sat, 30 Jul 1994 06:59:43 GMT
References: <3163r7$440@quagga.ru.ac.za> <CtMp4G.7Ap@calcite.rhyolite.com> <31bl91$3b9@cesdis1.gsfc.nasa.gov>
Lines: 86

In article <31bl91$3b9@cesdis1.gsfc.nasa.gov> becker@cesdis.gsfc.nasa.gov (Donald Becker) writes:

> ...
>The BSD code is good, but the primary reason it's considered the best
>available is the BSD implementation, rather than the RFCs, is considered the
>definition of correct behavior.

The nice thing about standards is that there so many to choose from.
I.e. only religious dogmatists care more about the imprimature on the
standard than whether the computers interoperate.  The new dogmatism
about TCP/IP RFC's would be funny given TCP's history, if it were not
such a sad sign of the death of TCP/IP.  Yes, TCP/IP is dead.  IPv4 will
be the last generation.  TCP will be fondly remembered as a legacy
protocol on a few million systems in 5-10 years, with just as much 
life as the OSI protocols.  Ah, well.  It was great while it lived.


>Regarding the comments (not just yours, Vernon) about the Linux network
>code: yes, there *was* a good reason for writing the networking code from
>scratch.  Doesn't anyone remember the USL lawsuit?  At the time everyone was
>shaking in their sandals, afraid that USL would lay claim to every piece of
>code that Microsoft didn't already own.  I remember arguing that we
>shouldn't let the VJ slip header compression code, the one piece of BSD code
>in the networking section, into the kernel distribution.  SLIP header
>compression was independent of Net-[12], but there was still the possibility
>that it would be considered to be derived from some Bell Labs seed.
> ...

I've been corresponding privately on this subject recently, and I've
been convinced by arguments to the contrary that you guys were suffering
the NIH syndrome.

No one in their right minds was worried about the USL nonsense affecting
the TCP code.  A lot of the kernel was plausibly at issue, but not the
network code.  To have worried about Van Jacobson's code, you would have
to have been literally out of your gords.  For crying out loud--look at
the source in the Postscript version of RFC-1144!

The only people with reason to worry about the USL nonsense at all were
people with money involved, such as BSDI.  Doesn't Linux have Finish
roots?  Wouldn't you expect Linux to be as safe from USL as from the
U.S. Dept. of Comm, DOD, and NSA?

Not-Invented-Here is a strange syndrome.  I know, having suffered it
myself.  The suffers are often unable to preceive or admit their
affliction.  They discover compelling reasons for rewriting interesting
code, but only the interesting stuff.  The boring stuff like `cat` is
bought, borrowed, stolen, or, if absolutely necessary, hacked out over
a weekend.  Sometimes the reasons for rewriting are valid and almost
sufficient.  Sometimes, as in "USL is going to take back BSD TCP/IP",
they're just plain silly.  I've always been boggled by the number of
people who have been compelled to re-invent TCP code.  I've long asked
people at router vendors, real-time-operating system houses, and so on
why they didn't even consider at the BSD code.  Before the USL suit, I
heard "mbufs are too hard," "splnet is too hard and messy," "UNIX is
too big and slow", and the ever popular "the BSD TCP is implemented
wrong."  All of those have grains of truth, but none of them were suffient
or the real reason.

Maybe I ought to start a 7-step group for NIH suffers.  The first step
is admitting you have a problem.  Too bad I don't know the other steps.


> ...
>follow the RFCs when such a problem has been revealed.  Now the point:
>what about ATM?  People are afraid of changing their protocols stacks, and
>the one other example of a non-BSD stack (Solaris 2) has also gotten a
>similarly bad reputation.  Unless there is a dramatic revolution (IPNG?
>OSI:->?) who will be willing to risk fielding ATM on the desktop in this
>environment? 

That's strange.  The main bad things I've heard about the new Sun code
is that it wasn't as fast as it should have been (note the past tense),
and that they were both aggressive and not quite right about MTU path
discovery.

I think you're entirely wrong about ATM.  ATM maybe ok for WAN links
and may do well there, but it is technically wrong from start to end
for LAN's and will never make it on the desktop.  The ATM LAN buzz is
already fading.  The only question is what the trade rags, seminar
salescritters, and other clue-free Technology mavens will be pushing
next.  Multi-media, FDDI, AI, pen-computing, PDA's and object-oriented
are all played out.  My bet is on <<Mobile Computing>>.


Vernon Schryver    vjs@rhyolite.com