Ethernet will never work (1974)
twitter.com
twitter.com
Not reading the follow-up and still criticising/laughing at the original memo is thoroughly unjust. I've submitted[2] the follow-up as a separate item if people want to comment on it.
[0] https://twitter.com/_space_train/status/1236373295429226496
[1] https://www.reddit.com/r/reddit.com/comments/1xz13/in_1974_x...
However, both the original memo, and the reddit update have the same sort of condescending/arrogant tone. That probably was as much a factor in why people jumped to conclusions as anything else.
According to his account, the original version of Ethernet had the problems he outlined in his memo, but in response the Ethernet designers made changes to account for them.
While his delivery is a bit harsh I think Bachrach's criticism was completely valid. As a matter which is perhaps more product than technical, Ethernet's downside resulting from collisions turned out to be an acceptable tradeoff for its other advantages (including simplicity and low cost compared to the non-collision systems of the time). However, it was indeed a significant limitation, and so continued development of Ethernet has had to find ways to eliminate the problem.
What I've seen with wireless stuff is simple algorithms can only get you to about 20% network utilization.
But how do you get dramatically better with collision avoidance? If you've allocated most of the available bandwidth to machines that are leaving it unused, utilization could well drop substantially below 20%.
Yes, WiFi can run some coordination function, but can't recall the details. Maybe it's called DCF/Distributed coordination function (same exam, I think 54 or 108MBit was the norm back then. So probably terribly outdated - but indeed: coordination isn't new for WiFi).
(Yes, I could look up everything, but don't have the time right now ;-)
As I understand it --- and this comes with the grain of salt that my detailed knowledge of network protocols tends to be out of historical interest and so intrinsically out of date --- WiFi does not use any collision avoidance tricks right now besides CSMA/CA which is only partially effective. There are plenty of papers you can find about improved systems but none of them seem to have been adopted, besides 802.11ax introducing OFDM and 'coloring' which mitigate but do not eliminate the problems with CSMA/CA. I only know a bit about this stuff but I think the hidden node problem makes collision avoidance fundamentally difficult and is very common for WiFi due to the short range and buildings interiors etc - which is why non-collision schemes like TDMA are used with WiFi, but generally only in more specialized situations where the network operator controls everything and can make certain guarantees about all devices being aware of each other.
So when I think about it more, saying that 'collision avoidance is strictly better than collision detection' is probably actually untrue in a situation where you have to cope with hidden nodes. At least that's my non-expert thinking.
In the early days other architectures like token-ring were better in theory but not in practise. In the real world Ethernet won.
*I always hesitate to apply OSI model labels to the IP suite, because IP was not designed according to the OSI model and does not comply with it. However, the OSI model labels are so common that it's hard not to. That said, the OSI model can quickly become more of a hindrance than a help when we start doing things like IP-over-IP.
I'm sure even today people would like to daisy chain the more expensive kinds of ethernet (100G or faster) in small lab or home networks, where switches are still expensive.
Except for a screwup by a vendor.
It was observed in the early 1980s that Ethernet throughput under load was lower than theory predicted, but no one knew why. Someone at PARC tried to find out. (I can't remember who it was, but there's a paper on this somewhere.) They found out that something was generating spikes during the "quiet time", resetting the quiet time timer (a low level hardware component), and preventing everyone on the cable from sending for a while. But they couldn't find out what device was doing it. All devices seemed to be doing it. They got a dual-channel digital oscilloscope with enough memory to store an entire packet from LeCroy. Today even low-end scopes can do this, but it was a rare and expensive piece of hardware back then. They got both ends of the PARC coax backbone into their office, and could see the signals on the cable from both ends. I was invited up to look at the scope, and there was that stupid spike, in the middle of quiet time. At a different place on the traces from both ends of the cable, indicating it wasn't coming from the sender of the packet. From speed of light lag, they could then locate the source.
It turned out that a manufacturer of Ethernet interface parts had made a mistake in the hardware state machine that controlled the transmitter. There was a state change during the quiet time which turned on the transmitter for a nanosecond or so between states. This put a spike on the cable during the quiet time. That forced the interface to back off. The effect was that back to back packets, intended to maximize throughput, never worked.
The unit that was doing this didn't have to be sending. It did this just connected to the cable when powered up. Several of that vendor's interfaces were on the cable, and as long as any of them had power, throughput suffered badly.
This is the source of the early 1980s claim that CSMA/CD didn't work. A lot of interface boards had to be replaced.
It wasn't 3Com, was it? The irony of that could make people's heads explode!
Coax Ethernet also suffered from basic electrical problems. It had a signal down to DC, so you couldn't decouple cable sections with a capacitor, like you can with cable TV coax. No problem in a room, but inter-building cable runs had grounding issues. The outside of most coax connectors is treated as a ground and bolted to the enclosure, but you can't do that with long runs of Ethernet. Ethernet cables evolved to have both sides isolated from ground, with special insulated connectors, but you had to ground somewhere for safety.
Signal loss was also a problem. The receiver must be able to detect a collision from the furthest node while the local node is sending. So the amount of loss allowed end to end is quite low. Thus the need for huge RG-8 coax and huge SO-239 coax connectors.
At the time, I was working at an aerospace company which built RF gear to communicate with satellites, and we had RF experts around. They were not impressed with Ethernet as a transmission system. They wanted something more like cable TV, with an RF carrier and multiple channels, which is what Internet via coax from cable TV vendors is now. With that, you can run miles of cable, put in booster amps, have lightning arrestors, and deal effectively with the real-world problems of outside plant.
Coax Ethernet was a minimum viable product. Good concept, but needed a complete electrical redesign to scale.
Ethernet over unshielded twisted pair ("10baseT" and up) is nice electrically. The cable is cheap and small. It's a differential signal, so it has good noise immunity to other signals and induced currents from power cables. 100m long runs of cable work. You need hubs and repeaters to go further. Those are tiny now, with custom silicon, but the first Ethernet repeaters for coax Ethernet were about a cubic foot of electronics. 1970s electronics needed a lot of parts to do anything.
The tone is dismissive, which is the main problem with the memo.
When I mentioned switched ethernet, he looked at me blankly and said something along the lines of (take some of it as hyperbole). "that's not ethernet? the whole point of ethernet is dealing with collisions. it's not ethernet without a medium where colluions can happen. heck, if we could have given everyone a private link, networking would have been easy"
To: Bob Metcalf and Dave Boggs
Date: March 5, 1979
From R.E. Bachrach
Location: PARC - Bldg. 31
Subect: Comments on "Draft Ethernet Overview"
Organization: GSL - 44
I have read with dismay your presentation "Draft Ethernet Overview". As I am sure you are aware, technically or conceptually there is nothing new in your proposal. Perhaps appropriately, you have chosen a coined jargon utilizing discredited scientific conceptual expression in which to frame your ideas. I find your analysis on the proposed interconnection lacking in technical credibility. Quantitative statistical analysis would show that your proposed system would be a failure. You have tried to adopt a scheme inappropriate to the intended engineering application. A random transmission scheme such as you propose, along with the quasi-de-randomizing hardware you invoke to patch the obvious deficiency, would place in fact an undo hardware, software, and scheduling problem on the individual stations.
You should seriously reconsider your basic premise and formulate fully and logically all the parameters necessary to evaluate the system. Your transmission medium or environment is not quantum noise limited. Simple analysis shows that imposing a poisson (i.e., random) statistics on message transmission drastically reduces the available effective bandwidth. Such a system is effective (reasonable) only in the limit of negligible average bit transmission rates. In fact you will want to maintain as high an effective transmission rate as possible. This requires a synchronized system. The fallacy in your conception is that the stations should be transmitting randomly. One possibility for a synchronized system would be time division multiplexing. You should seriously study how the telephone companies handle this problem. For example, the A.T.T Long lines T2 buried microwave link multiplexes close to 10^7 - 6 KHz channels.
Most importantly, you should fully define your engineering application before proceeding further. You specify an undefined message packet length, a 1 mile or 1 mile diameter look and 256 stations working ad 3Mbs rate. What is the nature of the station? How many bits transmitted does an activity require and what is the expected average rate that the 256 stations will be seeking use of the bus in the contemplated application? What is a tolerable dead time for a given station to acquire a full set of data? The worst case delay for your 1 mile loop is 2~ usec. what effect dos this have on far stations getting locked out, etc. . . ?
Robert Bachrach
Edit: Also, thank you for posting the text. I came to the comments hoping this had been done.
Imagine what they could've accomplished if they had empathy and were collegial with each other.
https://www.reddit.com/r/reddit.com/comments/1xz13/in_1974_x...
---
Appropriately, through a conversation with Comedian Wayne Cutter (http://www.waynecotter.com) about Xerox PARC, I became aware in a Google search that my March 4, 1974 private Xerox Confidential Memo to Bob Metcalf and Dave Boggs was floating around the Internet and a major subject on numerous blogs. Unfortunately the role of my memo in the development of Ethernet II is not understood.
Ethernet was the invention of Bob Metcalf and Dave Boggs as an outgrowth of Bob’s PhD thesis on the Aloha Net packet communications network. As is well documented, Xerox PARC from the beginning (1972-1974) was investigating distributed computing and several methods were in various stages of concept and feasibility development.
I joined the Xerox PARC General Sciences Laboratory from Bell Laboratories in the summer of 1973 where I had worked on the first commercialization of light emitting diodes. At PARC our group was participating in the founding of the Stanford Synchrotron Radiation Laboratory. The prototype equipment we developed is now in the Smithsonian Museum. Part of this equipment was an advanced computer aided data acquisition system I developed. Although I am a condensed matter physicist, I was very interested in computers and software. I often hung out with the guys in the Computer Science Lab (one of whom recently visited the space station) which is how I received the first draft of Bob Metcalf’s and Dave Bogg’s technical paper describing their networking concept. (The team by the way was somewhat like Jobs and Wozniak in their respective contributions.)
Our practice at the time, as it was at Bell Labs, was to have open and frank critique and internal review of technical papers before they were publicly released. It was in that spirit that I wrote my memo which only took on mythical proportions because CSL Lab Manager Bob Taylor chose to post it on his door.
CSL at that time was something of a “hippy commune” and meetings were held with everyone lying around on bean bags. The first draft of the Ethernet I paper was written accordingly in a hip style. At the time I considered the draft quite an unprofessional document in addition to my technical concerns. I also at the time did not like the idea of naming a major new networking innovation after a discredited physics concept, the “ether”. The ether doesn’t exist and this was a real network on a real baseband coaxial cable medium. At the time of Ethernet I, packet collision detection was done in software with a CRC check of each packet. Detection of damaged packets would trigger staged random backoff until the valid packet was received.
Following the “memo”, Bob Metcalf, Dave Boggs and I got together and had an extensive technical discussion of their paper on Ethernet I and its limitations. In that meeting I introduced them to the collision detection techniques used in pulse counting apparatus such as I used in my photon counting spectroscopic equipment at Bells Labs and at SSRL.1 Basically the receiver detection is an analogue to digital conversion and by suitable discrimination, one can distinguish between on and two pulse events. If two packets collided on the Ethernet cable at the tranceiver, then the receiver could determine that the pulse signal was wrong.
The outcome of this discussion was Ethernet II. The Ethernet II hardware collision detection incorporated into the transceiver resulted from this discussion and transformed the networking capability and resolved many of the concerns I raised in my memo. Hardware collision detection enables an Ethernet communication channel to achieve effective utilization while limiting the system overhead and paved the way for Ethernet’s future success as we know it today.
So to all the blogger’s out there, I was not a “Xerox Executive”, I was a member of the technical staff contributing to the fertile discussion in a very creative multi-disciplinary lab. I have grown to like the name Ethernet because of what has been accomplished. I don’t even mind all the other subsequent packet communication techniques that call themselves XXX-Ethernet and aren’t.
So you should now switch your attention to Liveboard, a PARC invention pioneered by John Seeley Brown. Liveboard in the mid ‘80’s envisioned large flat panel interactive networked computer displays which could be used for group meetings and networked meetings. Through my work at Applied Materials over the last 17 years, we have created the ability to cost effectively manufacture such large LCD flat panel displays. LCD-TV and Computer Displays of 65”, 75”, and 108” are now entering mass production by our customers. Soon they will be in homes, offices, class-rooms and enumerable public spaces. These Liveboard displays will now be connected by Ethernet and also be lit by light emitting diodes whose commercialization I also helped pioneer. Every time you look at your computer display, you are looking at technology I helped to create and enabled it’s volume manufacturing.
In case you didn’t know. LCD displays are enabled by amorphous silicon transistors, another technology pioneered at Xerox PARC and commercialized by Applied Materials manufacturing equipment..
R.Z. Bachrach, Memorial Day Weekend, 2008. CAnonymous@earthlink.net
R. Z. Bachrach, Rev. Sci. Inst., 43, 734 (1972), "A Photon Counting Apparatus for Kinetic and Spectral Measurements."An excerpt:
"Metcalfe: My mom used to say if you can’t say something nice about someone you should just hold your tongue. But Bachrach was a not nice person. Or is for that matter; he may still be around for all I know. He was sort of a grouchy physicist on another floor in another lab, and he read my memo. And this is a physicist. The phrase you didn’t catch in his now famous memo -- this memo’s posted all over the world because everyone thinks it’s a hoot that he wrote this memo -- he said the problem with Ethernet was that it was not quantum noise limited, which is a very physicist thing to say. Of course it’s not quantum noise limited! That wasn’t the point. But he resented the fact that we were not using every shred of bandwidth that was capable. I told you how we decided on the clock speed. There were gigabits per second of capacity on that cable, and we were using a pitiful few megabits of it. But he was concerned that it wasn’t... And he did a nasty thing, and it was sort of an early lesson in nastiness, which is he wrote a memo. He didn’t come see me. He didn’t say, “I just read your memo and I have a few questions about it”. He didn’t do that. He sent a memo to my boss’s boss accusing me of writing something that wasn’t new and it wasn’t quantum [noise limited], completely making an idiot of himself. But it didn’t feel that way at the time. It felt kind of nasty. The next thing I know I’m in my boss’s boss’s office having to explain how this guy’s an idiot. Which he is, or was. To put it more kindly, he was from a different universe. I was in a computer science universe, he was in a physics universe. We were solving different problems and he should have minded his own business. Or at least come talk to me before sending a memo to my boss’s boss, so maybe I could save him the embarrassment. There are many places where I go where that memo is on the wall, pinned to some cubicle -- “the old Bachrach memo” -- because it’s just such a great example. Now Bachrach, I ran into him a decade or two after that unfortunate memo, whereupon he was letting it be known that he’d helped invent Ethernet. How he got there I don’t quite know, but it had something to do with this memo being really instrumental in fixing some of the early problems with Ethernet, which is a complete hallucination."
http://archive.computerhistory.org/resources/text/Oral_Histo...
https://web.archive.org/web/20080528224324/http://bytecoder....
I didn’t get “Ethernet will never work” from this memo, I got “you have some serious flaws you need to fix first.”
Maybe it was the tone that made people jump on this. I can tell you, I appreciate the candor of someone willing to call you out like this before you go down the rabbit hole of mistakes you’re about to make.
It was, basically unusuable. We eventually switched our development network (8 machines) and customer network (25 machines) over to 10-base-2 Ethernet, and it was blazing in comparison. The Netware guy was sure it would be terrible because of the collisions.
This memo reminds me a bit of that: in theory the other network was better, but in the real world Ethernet worked pretty well.
Also, "undo" is a valid dictionary word.