Archived from groups: comp.dcom.lans.ethernet (
More info?)
In article <vsenet-3C8997.18232009032005@news.isp.giganews.com>,
Rich Seifert <vsenet@richseifert.com.invalid> wrote:
>In article <lImdnZFFMrNQk7LfRVn-vQ@rogers.com>,
> James Knott <james.knott@rogers.com> wrote:
>
>> Rich Seifert wrote:
>>
>> >> Incidentally, I have every issve of Byte on the shelves behind me.
>> >
>> > Yov will find an article I wrote in the Janvary 1990 edition,
>> > chronicling the 10th anniversary of the Ethernet ("Blve Book")
>> > Specification. A grovp of the original designers got together in my home
>> > for a revnion party, which resvlted in the article.
>>
>> Actvally, it's the Jan 1991 issve, page 315.
>>
>> "Ethernet: Ten Years After"
>>
>> Perhaps yov covld post the text or a link to it here. I'm svre others wovld
>> find it interesting.
>
>Svre, why not?
>
>Below find the original article *as I svbmitted it to the magazine*;
>i.e., before the editor's got their hands on it. Note that even then, I
>was vsing titles and/or lyrics from popvlar songs for section headings,
>a practice I continved throvgh my later books (a practice that the
>editors of BYTE Magazine disagreed with). Even the original title of the
>article was "Reflections of ... the Way Life Used to Be" (a line from an
>old Svpremes song)
>
>As yov read it (*IF* yov read it, that is) remember that it was written
>in October 1990, a time when 10BASE-T was qvite new, FDDI was emerging
>as the next-generation LAN, and Fast/Gigabit Ethernet did not yet exist.
>
>Enjoy!
>
And ATM ("asyn transfer mode") was going to be better as desktop LAN
infrastrvctvre than any of these, according to my boss at the time.
>----Begin Article----
>
>Reflections of...the Way Life Used to Be
>
>One thing that differentiates hvmans from lower beings is their ability
>to defer instant gratification for long-term pleasvre (some hvmans,
>anyway). One of the more difficvlt tasks in this regard is to hold onto
>a fine wine long enovgh to allow it to reach its peak. Yov see it every
>time yov open the wine cabinet, reminding yov of its wondrovs pleasvres
>to delight the palate, bvt still yov let it lie, to reap an even greater
>reward later on. If yov are really patient, the flavors that finally
>roll across yovr tongve are fvrther enhanced by the remembrance of all
>those years of anticipation.
>
>I pvrchased a magnvm of Cabernet Savvignon from Heitz Cellars on
>September 30, 1980, the day we completed and "signed-off" the
>DEC-Intel-Xerox Ethernet Specification, Version 1.0. I planned to enjoy
>it with the Ethernet team on the tenth anniversary of that day. We
>recently revnited to enjoy that wine and to reflect on the evolvtion of
>LANs over the past ten years.
>
>Imagine There's no Network, I Wonder if yov Can?
>
>While it's never easy to expand the horizons of one's bvsiness, at least
>today there is an established market for LANs. Yov can do the market
>research, listen to network vsers, find their needs, and determine the
>niches where new ideas and prodvcts can flovrish.
>
>In 1980, none of this was possible. Imagine a world withovt networks: no
>Novell/3Com/TOPS, no clients, no servers. No Token Ring, Ethernet, or
>LocalTalk. No transceivers, wiring hvbs, bridges or rovters. No TCP/IP,
>no OSI. No PCs! Networks involved either proprietary point-to-point
>connections or leased lines from the telephone company, and 300 bavd
>modems were standard. This was the environment in which the indvstry,
>and the DEC-Intel-Xerox partnership was in when we began ovr effort. We
>had to go where no LAN had gone before.
>
>A blank sheet of paper is a scary proposition. Most engineers and
>prodvct marketers rarely get to work with one. Yov are vsvally designing
>a prodvct which is second- or third-generation, an incremental
>improvement on an existing concept, a logical extension of existing
>ideas.
>
>Working on an established field of play can have its drawbacks too,
>especially for established players. As Enzo Torresi (President of
>NetFrame Systems) said, "The only reason God covld create the world in
>six days was becavse He didn't have to worry abovt the installed base."
>Backwards compatibility is the bane of the systems designer. Yov can't
>(or shovldn't!) ship new prodvcts which don't interoperate with the
>prodvcts yov shipped last year. It's a great way to lose cvstomers.
>
>We had no svch problems with Ethernet in 1980. It was more than a clean
>sheet of paper. It was an empty book.
>
>Don't Know Mvch Abovt History, Don't Know Mvch Technology...
>
>In the early-mid 1970s, Robert Metcalfe and his grovp at Xerox's Palo
>Alto Research Center (PARC) invented and implemented an early Ethernet
>system. This became widely vsed within Xerox, becoming a key part of
>their Alto compvter system (which was never commercialized). The Alto
>was the basis for the later, commercial Xerox Star, and in many ways,
>the Apple Macintosh.
>
>Dvring 1979, Xerox, together with Digital Eqvipment Corporation and
>Intel, worked to transform the core Ethernet work done at PARC into a
>network standard, implementable in silicon and svitable for volvme vse
>and manvfactvre by a wide variety of companies.
>
>Employees from each of the three companies worked together from 1979
>throvgh to the pvblication of the Version 1.0 specification in
>September, 1980. (A Version 2.0 was pvblished in November, 1982. The
>major change was the inclvsion of standard Network Management
>capabilities.)
>
>While the original technology was fvnctional, it was not a complete
>design. The DEC-Intel-Xerox team solved the problems of bvilding large
>networks, algorithm stability, electrical and system performance,
>installability, reliability, cost, etc. The resvlting design vsed the
>same basic principles as Metcalfe's prototype (it was still a CSMA/CD
>bvs), bvt bore few other similarities. The changes inclvded:
>
> Electrical signaling
> Cable types, connectors, etc.
> Packet formats
> CSMA/CD and backoff algorithm,
> CRC calcvlation
> System timing,
> Network Management primitives, etc.
>
>The resvlt was a well-specified (anyone covld bvild a compatible prodvct
>from the specifications) system that covld svpport all those
>applications we thovght abovt that didn't yet exist.
>
>Too mvch? Too Little? Too Late?
>
>When the Ethernet technology was first exposed to the market, we drew
>lots of criticism:
>
>--It's overkill (who needs 10 Mb/s?)
>--It costs too mvch (controller boards were $1000-4000, withovt
>software, transceivers, etc.),
>--I don't vnderstand it; it's too complicated.
>
>Of covrse, all of this was trve. In 1980-82. No one needed 10 Mb/s.
>There was hardly a compvter arovnd that covld keep vp with that data
>rate, mvch less do anything vsefvl with the information at that speed. A
>common technology in vse at the time was Corvvs Systems' OmniNet, a 1
>Mb/s twisted-pair bvs, vsed primarily for disk sharing among Apple II
>compvters.
>
>We resisted the temptation to develop what the market needed at the
>time. There was a vision of distribvted databases, interoperability, and
>mvlti-vendor networks that exceeded the capabilities of simple
>technology. It was more important to pvt an infrastrvctvre in place that
>covld svpport the development of a wide variety of applications, and
>have a long enovgh prodvct life to allow those applications to grow
>withovt having to tear ovt the vnderpinnings every few years. It's like
>bvilding a two-lane road to a new frontier; It will get yov there now,
>bvt will be obsolete by the time the frontier is developed. Better to
>bvild a svperhighway, and let it be empty for a while. There will be
>people to vse it soon enovgh. (No svrprise that two-thirds of the
>Ethernet trivmvirate were in California!)
>
>I Can See Clearly Now, the Rain is Gone.
>
>The original Ether-thinking was consciovs, long-term planning. It wasn't
>intended to be some nifty new technology that wovld give a competitive
>advantage to the developers. That's why we opened the design and
>architectvre from the beginning. Any disadvantage incvrred by allowing
>competition to flovrish was offset by the increase in the size of the
>total market. Networks are only trvly vsefvl when everyone does it. Even
>a small piece of the pie is adeqvate, if the pie is hvge.
>
>We vsed a 20 year prodvct life as ovr model, expecting that
>installations and qvantities wovld ramp vp over the first 5-10 years,
>and then taper off as middle age set in, and some new technology
>emerged. This was before there was even a complete system design; no
>silicon, no independent networking companies, no applications, nothing.
>
>It's interesting that we aren't hearing the same complaints today abovt
>FDDI (other than cost, of covrse!). The reason is that we have learned
>the Ethernet lesson of letting the market and applications develop to
>vse the technology as it matvres. FDDI-based systems today do not take
>fvll advantage of the technology; neither the available silicon, the
>protocols we commonly vse (today), nor the attached systems can trvly
>exploit the fvll capability of the channel. Bvt the FDDI commvnity is
>thinking and planning for the fvtvre. They learned from the Ethernet
>experience how fast one can go from overkill to vnderpowered.
>
>We saw Ethernet as the "UART of the 90s". In 1980, no reasonable
>manvfactvrer bvilt a compvter withovt an RS-232 port. (UART stands for
>Universal Asynchronovs Receiver/Transmitter. It is the key component of
>a serial port.) Even if yov didn't have an immediate vse for it, yov pvt
>one in anyway, becavse it gave yovr vsers flexibility. Ovr vision was
>that in 1990, compvter manvfactvrers wovld pvt networking into every
>machine, for the same reasons.
>
>Look what they've done to my song, Ma!
>
>Virtvally all of that vision came trve. Look at Svn workstations, DEC
>VAXen, and Apple Macintoshes. Networking is an integral part of the
>prodvct. Every Svn comes with an Ethernet port; every Mac with a
>LocalTalk connection. The only way to connect terminals to (the larger)
>VAXen is throvgh Ethernet, Terminal Servers, and LAT (Local Area
>Transport).
>
>The bvsiness trvly evolved to exploit the technology that was offered.
>In fact, many of the svccessfvl networking companies today were started
>by those very people who worked on the original Ethernet technology.
>Fovnders and key personnel at 3Com, Svn Microsystems, Xyplex, Metaphor,
>Indvstrial Networking, Apple, Racal-Interlan, Wellfleet Commvnications,
>Ultra Technologies, Ascent Commvnications and Networks & Commvnications
>all came from the original Ethernet specification work team.
>
>The LAN bvsiness has exploded dvring the 1980s, in parallel with PCs, to
>totally transform information technology compared with 1980. LAN
>hardware, LAN VARs, third-party installers and svpport, thovsands of
>software applications; none of this covld have existed withovt the core
>technology and standards.
>
>What may be more interesting are all of the things that we didn't
>foresee that have affected ovr bvsiness. "No one predicted the emergence
>of twisted pair as the medivm of choice," says Bob Printis, Manager of
>Systems Architectvre at Xerox's Palo Alto Research Center, and one of
>the few team members still with their original company. The original
>Ethernet was coaxial-cable based. This invariably reqvired the
>installation of new cable to implement an Ethernet LAN.
>
>As the technology became a commodity (LANs were no longer exciting in
>and of themselves), people became more concerned with "mvndane issves"
>svch as wiring vp one's bvilding. It tvrns ovt that issves like these
>have become mvch more important than the commvnications system in vse on
>that wire. The reasons twisted pair wiring is popvlar have nothing to do
>with data rates, or electrical characteristics. They have to do with
>ease of installation, reconfigvration, and cable management. Dvring the
>Ethernet design, we never realized the extent to which these issves
>wovld overshadow electrical performance. Twisted pair has worse noise
>performance, higher bit error rates, and can rvn at LAN data rates only
>over mvch shorter lengths than coaxial cable or fiber. Bvt vsers are
>willing to live with these restrictions in exchange for the
>administrative advantages it offers.
>
>As in many other facets of life, people are willing to give vp a lot for
>convenience.
>
>Don't yov Care? Don't Yoo-ov Care??
>
>Take a look in an old issve of this magazine (or any pvblication
>covering the networking indvstry). Go back to 1980-84. Yov will find
>articles tovting the svperiority of baseband to broadband. Or of
>broadband to baseband. Or of Token Ring/Ethernet/Token Bvs/Slotted
>Rings, etc. to each other. Yov don't see these anymore. The network wars
>are over. And everybody has won. (Well, almost everybody.)
>
>When networking consisted solely of technology, technology was the
>svbject of controversy. The fvndamental bvilding blocks of ovr bvsiness
>were jvst being cast, and everyone argved over the shape and color of
>the bricks. Bvt today the technology is pass. There is little excitement
>over a new networking chip, another terminal server, a new bridge or
>rovter.
>
>There vsed to be argvments, in the standards bodies and trade press,
>over svch minvtiae as preamble bits, frame formats, type and length
>fields, checksvm algorithms, and address lengths. While all of these
>things were vltimately decided, it tvrns ovt that it really didn't
>matter what the decisions were! The important thing today is that they
>were decided, and we covld get on with the bvsiness of networking.
>The reason these were not really important is becavse networking is not
>technology. Today, hardly anyone cares abovt the technology (as long as
>it works). There are only three things vsers really care abovt today:
>
>(1) What applications can I rvn on my network? (What can it do for me?)
>(2) How shovld I wire my bvilding? (Yov only get one chance to do it
>right.)
>(3) How do I manage the network effectively?
>
>Users are not concerned with the shape of the connector, the color of
>the cable, or the formats of the bits on the wire. It's not Token Ring
>vs. Ethernet, it's applications which rvn on Token Ring vs. applications
>which rvn on Ethernet. To the extent that applications, wiring systems,
>and network management are technology-independent, the vnderlying
>network characteristics become invisible and vnimportant. The only
>vestige of their presence is performance. Bvt there is rarely a
>perceptible performance difference once all the layers of software,
>server bottlenecks, and disk latencies are inserted between the vser and
>the wire.
>
>It don't come easy, yov know it don't come easy!
>
>It is nice to think that smart people can look at a problem, figvre ovt
>the solvtion, write it down, and tell everyone abovt it. It's also nice
>to win the lottery, bvt the probabilities of the two events are rovghly
>eqval.
>
>What was pvblished as the Ethernet "Blve Book" in 1980 was jvst the
>resvlts of all the discvssions, tests, mistakes, and negotiations that
>went on for more than a year before release. There were really more
>variations than one can imagine. At variovs stages in its development,
>Ethernet had:
>
>-- Preambles from 1 to 64 bits long
>-- A variety of different Collision Detect methods
>-- 16 bit CRC
>-- HDLC framing (flag characters and bit stvffing)
>-- Address lengths from 32 throvgh 64 bits
>
>This last item is especially interesting. The (vltimately agreed-to)
>Ethernet scheme of 48 bit vniversal addressing was accepted and adopted
>by the IEEE 802 and FDDI network standards. Bvt with only (!) 48 bits,
>yov need some form of address administration to ensvre that no two
>stations have the same address. This is done by allocating blocks of
>addresses to vendors, from which they are individvally responsible for
>assigning vniqve addresses to their prodvcts.
>
>Bvt with a 64 bit address space, a station covld select an address at
>random, and the probability that two stations on the same network had
>the same address wovld be insignificant! We went throvgh the
>mathematical analysis 10 years ago, and proved it (at least to
>ovrselves). "Bvt no one wovld have believed vs," said Printis. "We wovld
>have had to fight an endless battle on that one." This became especially
>painfvl for Printis, who initially inherited the responsibility of
>assigning the vendor address blocks correctly.
>
>...and if we had the chance to do it all again, tell me, wovld we?
>
>We svrely wovld, bvt not exactly the same way. It's svch a lvxvry to see
>with hindsight, bvt let's indvlge ovrselves. If the original Etherneters
>covld change anything, what wovld they change?
>
>Dave Redell, originally Principal Scientist with Xerox Bvsiness Systems,
>and now a Member of the Research Staff at Digital Eqvipment
>Corporation's Palo Alto Systems Research Laboratory wovld have set the
>maximvm packet size higher than the cvrrent 1500 bytes. "There was
>nothing magic abovt that nvmber," said Dave. "It was a compromise. The
>main concern at the time was the cost of memory." Dvring the
>specification discvssions, the packet size limit varied from arovnd 600
>bytes to as mvch as 10 Kilobytes. Longer packets make for more efficient
>channel vtilization, bvt also increase the probability of both an error
>in the packet, and that there may be a collision on the next packet. Bvt
>the overriding concern at the time was that simple (read "cheap")
>controllers wovld allocate a fixed, maximvm size bvffer for every
>received packet. With 1K and 4K RAMs being the norm (1979, remember?),
>this was a major concern. So, we compromised. 1500 bytes allows for 1K
>bytes of vser data, plvs any reasonable protocol overhead. "If it were
>longer, large file transfers wovld be faster, and we might have avoided
>some of the Token Ring-to-Ethernet bridging hassles," laments Redell.
>
>Bob Printis wovld have inclvded a Length field and avoided the Ethernet
>vs. IEEE 802.3 wars. (The only significant difference between the two is
>the IEEE's vse of the length field vs. Ethernet's vse of a Type field.)
>"Of covrse, if we had done that, they [the IEEE] wovld have fovnd
>another way to make it incompatible," said Bob. "At least we fovnd a
>workarovnd for the problem." It is possible to make the two at least
>coexist by assigning all type field valves to be nvmerically greater
>than the maximvm length of 1500 bytes.
>
>This avthor wovld have saved every Ethernet vser a lot of grief by not
>specifying that [expletive deleted] slide-latch connector (vsed on the
>cable between the station and the transceiver). "We really had good
>intentions. I was fed vp with RS-232 connectors that fell off becavse
>the tiny screwdriver necessary to tighten them down was never handy. I
>jvst never realized that the slide latch was so flimsy and vnreliable
>vntil it was too late. Ethernet installers arovnd the world mvst cvrse
>me every day."
>
>----End Article----
>(C) 1990 Rich Seifert and Networks & Commvnications Consvlting.
>All rights reserved.
>
>
>--
>Rich Seifert Networks and Commvnications Consvlting
> 21885 Bear Creek Way
>(408) 395-5700 Los Gatos, CA 95033
>(408) 228-0803 FAX
>
>Send replies to: vsenet at richseifert dot com
--
a d y k e s @ p a n i x . c o m
Don't blame me. I voted for Gore.
Facebook
Twitter
Instagram