
Ethernet will never work (1974) - pmarin
https://twitter.com/aka_pugs/status/1236356815626981376
======
ColinWright
From the middle of that thread[0] we discover that the original author of the
original memo commented on it in 2008[1]. That follow-up is definitely worth
reading to better understand the context of the memo.

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](https://twitter.com/_space_train/status/1236373295429226496)

[1]
[https://www.reddit.com/r/reddit.com/comments/1xz13/in_1974_x...](https://www.reddit.com/r/reddit.com/comments/1xz13/in_1974_xerox_parc_engineers_invented_ethernet/c043yl0/)

[2]
[https://news.ycombinator.com/item?id=22517640](https://news.ycombinator.com/item?id=22517640)

~~~
tyingq
That's certainly helpful.

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.

~~~
throw7337
Original memo gives good pointers, references, and ways to improve. It is also
very short. I would love this critisizm on my work.

~~~
tyingq
Would you love it arriving as a letter to your boss's boss, with no prior
discussion? Also, it includes quite a lot of unneeded pejorative rhetoric that
adds no value.

------
QuesnayJr
Bachrach gave an account of writing the memo on Reddit:
[https://www.reddit.com/r/reddit.com/comments/1xz13/in_1974_x...](https://www.reddit.com/r/reddit.com/comments/1xz13/in_1974_xerox_parc_engineers_invented_ethernet/)

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.

~~~
jcrawfordor
Bachrach was also, basically, correct. The collision contention issue with
Ethernet did limit the effective throughput of networks, which is why we now
exclusively use Ethernet in configurations in which there is no collision
contention (star topology, full duplex links).

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.

~~~
kortex
Except wireless internet used/uses a similar backoff trick, since a wireless
channel is just like a hub. I'm not hip on the latest tech, but I think they
use things like collision avoidance now.

~~~
jcrawfordor
This is exactly why Ethernet behaved that way - Metcalfe credits the idea to
ALOHA, an early wireless network protocol. However, that doesn't by any means
make collision detection _ideal_. Collision avoidance is strictly better for
performance, it was just judged infeasible for Ethernet at the time - this
turned out to be a good call as Ethernet would almost certainly not be as
popular as it was today had it used a collision avoidance scheme like most of
its competition. However, times change, and Ethernet has been collision-free
in the vast majority of applications for a couple of decades while wireless
protocols are also gaining collision avoidance across the board.

~~~
rwallace
Now I'm curious. I thought collision avoidance generally meant giving each
machine a more or less constant allocation of 1/N of the total bandwidth,
efficient when every machine wants to transmit all the time, but in the usual
case where traffic is unpredictably bursty and most machines are idle most of
the time, collision detection is in practice better. But you say collision
avoidance is _strictly_ better. Why?

~~~
Gibbon1
One issue you have is it's difficult for everyone to see the same line
condition. There is always a small chance you'll see a collision anyways. When
the network gets busy that small chance becomes no longer small. And every
time you have a collision you have a retransmission. Eventually the network
begins to thrash.

What I've seen with wireless stuff is simple algorithms can only get you to
about 20% network utilization.

~~~
rwallace
There is some theorem that says network utilization with collision detection
can be as low as 1/e^2, though in practice it rarely approaches that. 20%
sounds like a plausible bad case if the network is heavily loaded and the
stars are not lining up right.

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%.

~~~
Gibbon1
If you look at token ring, idle machines just pass the token on if they don't
have a packet to send. Other systems have central coordination and assign
'channels'. I think Bluetooth tries to do that for audio. (unsure)

~~~
archi42
BT channel-hops 1600 times/second - at least that's what it did years ago when
I memorized this for an exam. I don't recall audio getting some special
handling, but it was only SBC and maybe AptX back then.

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 ;-)

------
compsciphd
I remember having a conversation with my dead 1-2 decades ago about switched
ethernet. he was involved in network protocol development back in the 70s and
was very familiar with AlohaNet and how ethernet borrowed from it. but had
moved in a different direction in the decades since

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"

------
elcomet
Here's the text transcript for those who have a hard time reading this blurry
document:

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

~~~
jeffadotio
The article seems to miss the concept of criticizing an idea without
criticizing the individual. This approach is ineffective as a means of
communication. It just looks like mud-slinging and it always comes off as a
defense mechanism. Even when one is genuinely interested in addressing the
issue this obscures that intent.

Edit: Also, thank you for posting the text. I came to the comments hoping this
had been done.

~~~
justin66
Seventies-era Xerox PARC cultivated a deliberately confrontational environment
for its researchers. They managed to accomplish some great things.

~~~
kondro
"They managed to accomplish some great things" in spite of being jerks to each
other.

Imagine what they could've accomplished if they had empathy and were collegial
with each other.

~~~
Gibbon1
When you consider, other people took their ideas and build companies worth
hundreds of billions out of them, but they themselves didn't. hmmm...

------
timthorn
Should be read in conjunction with
[https://web.archive.org/web/20080528221818/https://www.bytec...](https://web.archive.org/web/20080528221818/https://www.bytecoder.com/2008/05/25/xerox-1974-ethernet-
would-be-a-failure-robert-bachrach-response/)

------
tyingq
There's an interesting interview where Metcalf shares his memory of the memo.

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...](http://archive.computerhistory.org/resources/text/Oral_History/Metcalfe_Robert_1/Metcalfe_Robert_1_2.oral_history.2006.7.102657995.pdf)

------
jmartrican
I think the issue with this memo is not the technical concerns, but the
insulting adjectives used in it. I cant imagine communicating with colleagues
like that now a days. If you got technical concerns just point them out in a
bullet list and leave the negative remarks out.

~~~
melq
I understand where you’re coming from regarding the tone of the memo, but I
think it’s important to keep in mind that this was not a public critique. The
author mentions in a reddit post that this was originally a confidential
internal document, and written in the context of a very small group of like
minded coworkers who knew each other personally. I have certainly said or
written things to coworkers of mine, who I count as respected friends and
confidants, that if taken out of context and published for all to read would
sound obnoxious if not reprehensible. The author had no idea that this private
critique would be read by the general public 40 years later.

~~~
distances
Check the comment from the original presentation's author too. Apparently
Bachrach didn't send this memo to him, but to the _boss of his boss_. I'm
happy I've never had to work in an environment as hostile as that.

------
willis936
A human readable copy:

[https://web.archive.org/web/20080528224324/http://bytecoder....](https://web.archive.org/web/20080528224324/http://bytecoder.com/2006/09/28/xerox-1974-ethernet-
would-be-a-failure/)

------
justin66
The funniest part about these tone police comments is that people are
concerned about somebody hurting _Bob Metcalfe 's_ feelings.

------
newshorts
Sounds like he knew what he was talking about...

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.

------
linsomniac
Back in the early '90s I used some network that ran over CAT-3 copper, and
they had some sort of time slot so there were no collisions. I wish I could
remember the name. Our Netware admin swore by it, because no collisions! IIRC,
the throughput was 200kbps.

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.

------
himinlomax
Note that what we now call Ethernet does not work like this (CSMA/CD) any
more, now that we exclusively use switches instead of passive hubs. Wifi does,
though.

------
agoodthrowaway
So crazy that so many things came out of particle physics experiments:
Ethernet, WWW, ... kind of crazy

------
tedunangst
Oh, wow, he misspelled undue. What a freaking moron!

~~~
asveikau
When I read old text I frequently note that this sort of typo seems more
common in the 70s. There was likely nothing checking the spelling. And
certainly no editors putting squigglies. No place to Google your spelling
doubts. And annoying to correct typewriter mistakes.

Also, "undo" is a valid dictionary word.

