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. . . ?
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.
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 ove...
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.
I had a feeling that this wasn’t just some dummy prig (of which we are so accustomed nowadays)... I was curious reading through his critique how these issues were actually addressed or mitigated given the fact that ethernet ended up actually succeeding so well!
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.
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.
IIRC, newer wireless tech uses MIMO to work around the problem. Multiple radios operating on multiple wavelengths with devices taking turns round-robin style. Basically, and somewhat ironically, we've gone back full circle to time division multiplexing.
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.
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?
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.
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%.
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)
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 ;-)
While simple or naive TDMA is the most obvious solution to collision avoidance (every node gets a fixed-length turn), there are more efficient methods available. Typically this takes the form of some sort of "channel reservation" scheme where each node gets a turn not to transmit, but to report whether or not it wants to transmit (and perhaps how much). Then either a coordinating point or a distributed algorithm decides how to allocate transmission time to the nodes who want it. This is often called "dynamic TDMA" and is used in various real wireless networks. There are also tricks you can pull with CDMA, OFDMA, and other flavors of multiple access. I suspect there's some mathematical upper bound on the efficiency of these schemes but I'm not sure what it is.
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.
I'm going to reply to myself to expand on this with an interesting topic... The fact that Ethernet was originally designed to behave similarly to a wireless system (specifically ALOHA) has important implications on the actual protocol. Essentially, layer 2* addressing in Ethernet only exists because of this design. In today's Ethernet networks, layer 2 addressing is unnecessary and it's quite possible to use only the layer 3 addresses - we could call "layer 3 switching," which is now a standard feature on commercial managed switches, an example of doing so. However, the L2/L3 addressing split has turned out to be very useful in some situations (mostly wireless networks, on which Ethernet is based!). However, it also has a lot of disadvantages, and introduces almost comically unnecessary complications to some software-defined networking (e.g. for many VXLAN setups we need to assign pretend MAC addresses to all our peers so that we can use the kernel's bridge plumbing). This is a very clear case of the now-gone history of the protocol having a huge impact on shaping how we use it today. At the same time, there exist devices that still communicate directly over Ethernet frames, something that wouldn't even be meaningfully possible had Ethernet not been designed to run on one shared media. Fortunately these devices aren't very common, because they're a real headache in a world of equipment designed to handle IP.
*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.
Wired ethernet had a lot of other reasons to move to star topology. Basically switches and cables became cheap + diagnosing daisy chain connectivity probs is not fun with more than a few nodes.
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.
Collision detection in the original Ethernet really hurt throughput, because you had to send the entire message before you detected a collision. Once hardware detection went in, collisions were detected as soon as what the transmitter was sending didn't match what the receiver was receiving. Transmission was immediately terminated, rather than sending a full packet. Which also meant the random backoff could start with a smaller value. Also, the hardware would check for a quiet period before even starting to send, so once a packet got through the sync-up sequence, nobody else on the cable would start sending until the cable went quiet again. This pretty much solved the collision detection problem. This is what "CSMA/CD" is at the hardware level.
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.
No, a lower-level part. Can't find the obscure paper where that was written up.
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.
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.
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.
The reply is certainly less abrasive than the original memo. I still feel the undertones, but that's my opinion and subjective. I feel it's still self aggrandizing and dismissive of Metcalf's work.
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.
This sort of thing is endemic to computing culture. Somebody says that a design is too inefficient or poorly thought out, then a practitioner comes along and crows, of course it works, all we had to do was overdesign it by a factor of ten.
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.
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.
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.
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"
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.
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.
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.
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."
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.
57 comments
[ 4.3 ms ] story [ 112 ms ] threadhttps://web.archive.org/web/20080528224324/http://bytecoder....
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 ove...
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.
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...
[2] https://news.ycombinator.com/item?id=22517640
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.
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"
Also, "undo" is a valid dictionary word.
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.
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.
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...