4 ms·

Bachrach gave an account of writing the memo on Reddit: https://www.reddit.com/r/reddit.com/comments/1xz13/in_1974_xerox_parc_engineers_invented_ethernet/ https

Bachrach gave an account of writing the memo on Reddit: https://www.reddit.com/r/reddit.com/comments/1xz13/in_1974_xerox_parc_engineers_invented_ethernet/ https://www.reddit.com/r/reddit.com/comments/1xz13/in_1974_x... 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.

rusk 7y ago
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!
jcrawfordor 7y ago
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 7y ago
  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.
  - chaorace 7y ago
    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.
  - jcrawfordor 7y ago
    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 7y ago
      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 7y ago
        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 7y ago
        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%.
- RachelF 7y ago
  Nope, Ethernet was originally broadcast on co-ax, multi-drop, similar to today's WiFi. In the early days other architectures like token-ring were better in theory but not in practise. In the real world Ethernet won.
  - jcrawfordor 7y ago
    originally. As I said, modern use of Ethernet has completely abandoned multiple machines in a collision domain, and for good reasons.
- jcrawfordor 7y ago
  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.
- fulafel 7y ago
  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.
- Animats 7y ago
  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.
  - PhantomGremlin 7y ago
xenadu02 7y ago
It wasn't just that he suggested an improvement, it was a hardware feature he knew about from previous work (assuming his account is accurate). The tone is dismissive, which is the main problem with the memo.
Sniffnoy 7y ago
Note that you've linked to the thread containing the comment rather than the actual comment itself. The comment itself is here: https://www.reddit.com/r/reddit.com/comments/1xz13/in_1974_xerox_parc_engineers_invented_ethernet/c043yl0/ https://www.reddit.com/r/reddit.com/comments/1xz13/in_1974_x...

rusk 7y ago

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!

jcrawfordor 7y ago

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 7y ago
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.
- chaorace 7y ago
  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.
- jcrawfordor 7y ago
  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 7y ago
    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 7y ago
      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 7y ago
        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%.
RachelF 7y ago
Nope, Ethernet was originally broadcast on co-ax, multi-drop, similar to today's WiFi. In the early days other architectures like token-ring were better in theory but not in practise. In the real world Ethernet won.
- jcrawfordor 7y ago
  originally. As I said, modern use of Ethernet has completely abandoned multiple machines in a collision domain, and for good reasons.
jcrawfordor 7y ago
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.
fulafel 7y ago
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.
Animats 7y ago
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.
- PhantomGremlin 7y ago

xenadu02 7y ago

It wasn't just that he suggested an improvement, it was a hardware feature he knew about from previous work (assuming his account is accurate). The tone is dismissive, which is the main problem with the memo.

Sniffnoy 7y ago

Note that you've linked to the thread containing the comment rather than the actual comment itself. The comment itself is here: https://www.reddit.com/r/reddit.com/comments/1xz13/in_1974_xerox_parc_engineers_invented_ethernet/c043yl0/ https://www.reddit.com/r/reddit.com/comments/1xz13/in_1974_x...