Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How engineers at Digital Equipment Corp. saved Ethernet

spectrum.ieee.org

Post reply on HN
Print view View original

81–90 of 109 posts

Re: How engineers at Digital Equipment Corp. saved Ethernet

#81

Post by immibis »

themerone wrote: post #8
eej71 wrote: post #6

Earlier quoted context omitted.

I think the great architectural challenge would be - how does one add that byte to the IP header in a non-breaking way?

There's a surprising number of people who think you could magically expand the IPv4 address space in a backwards compatible manner.

There are semi-compatible ways. My favourite proposal (if we couldn't have IPv6) was recursive IP: you transmit a packet to 12.34.56.78 and inside that packet is a packet addressed to 192.168.1.5. If you have more layers of NAT, inside that can be a packet addressed to 10.1.2.3.

If both endpoints do this you can directly establish connections. If only one does it, fall back to NAT like before. Core internet routers don't have to be updated. Addresses at endpoints are effectively variable-length.

Re: How engineers at Digital Equipment Corp. saved Ethernet

#82

Post by wil421 »

jeramey wrote: post #5
gumby wrote: post #2

What a great story. The spanning tree algo is under appreciated: this allowed people who didn’t understand networking to plug networks together the way you would plug extension power cables together,* making networking simple ( or alternatively insanely broken, when people had 400 computers on a single LAN with a rat’s nest of bridges and hubs…but unlike the extension cord case, nothing would catch literal fire). * d…

Occasionally people don't understand how to plug extension power cables together, either, especially during times of high stress and low sleep. Once upon a time, when I was in IT support, I got a call from someone in a satellite office across town saying that their computer wouldn't turn on. A new production had begun and everyone was a bit frantic, so this was an urgent request. After asking them to hold the power s…

My Audio Video buddy has a very similar story. A school called because their newish PA system wasn’t working. Turns out the usual lady was out. The usual lady would rip the cord out of the wall every evening instead of pressing the power button. The stand in announcer was just trying to press the on off button like most normal people.

They ended up having to replace expensive equipment because the person wouldn’t stop ripping the cord out of the wall to turn it of.

Re: How engineers at Digital Equipment Corp. saved Ethernet

#83

Post by bluGill »

mixmastamyk wrote: post #15
bluGill wrote: post #12

Earlier quoted context omitted.

Unfortunately none of those people have explained how it could be done in enough detail that I could try it. Most walk away when pressed but a few press on telling me it is easy so shut up and do it .

Similar to how it has been done with phone numbers. I saw this done in Brazil for example. You add a digit to the front and put all existing address on 0.*. Short number dials are assumed to be 0.*. Update OS and hardware. Then you allocate across the new digit much later as time goes on. The thing with phone infrastructure though is that it is centralized. So may happen in a reasonably coordinated rollout. Global in…

> You add a digit to the front and put all existing address on 0.*

How do you do that? I have read the IPv4 protocol spec, there isn't any space to put that byte can still be IPv4. That is what I mean when nobody has proposed anything that I can implement: I have read the spec and it doesn't allow room for what you want to do. Sure conceptually you can describe any number of ideas - but they are not IPv4 and no existing computer or router will work with it - so we may as well go with IPv6 which many smart people spent who understand the real problems of the internet have a lot of effort creating to solve existing problems to the best of their ability.

Brazil didn't just add that leading 0. They planed this well in advance and forced everyone who connects to the phone system to update their systems to support it: you must apply a software update or buy new hardware; otherwise your phones stop working. Of course most of the software and hardware was controlled by the Brazil phone company (s?) and so they could ensure this was all done.

I first found out about Brazil doing this from your comment - yet I can say the above with all confidence because those are things that have to happen behind the scenes to make it work. (I have no doubt people who actually know something about what Brazil did can tell you things I didn't think about)

Re: How engineers at Digital Equipment Corp. saved Ethernet

#84

Post by tssva »

mannyv wrote: post #66

One side effect of the network switch was that you needed to buy switches. With the old way everyone could be on one wire. With the new way you needed one port per host. Switches also allowed for centralized management. Note that cable works on what essentially is token ring, at least conceptually; channel 0 (i believe, it's been a while) is the heartbeat.

Switches didn’t require one port per host. They required one port per layer-2 network segment. The original switches I deployed had a handful AUI ports to which we attached to 10BASE5 transceivers. Hosts still connected via 10BASE2 or 10BASE5 to the “single wire” of their layer-2 network segment.

Over the years the cost of switches lowered to the point where it became cost effective to directly connect hosts and reap the benefits of reducing layer-2 segments to a single host. In between there was also a time where most hosts connected to hubs which then connected to switches.

Re: How engineers at Digital Equipment Corp. saved Ethernet

#85

Post by thfuran »

panick21_ wrote: post #53

I always wondered why it took so long to go from 10 Mbit/s to 100Mbit/s. For sure in that time they invented things like Ethernet Switching. But still, it seems like that standard took forever to move on. And then once it did it went from 100Mbit/s to 1000Mbit/s per second pretty damn fast.

The really crazy thing is that the consumer space is still stuck on 1gbps nearly twenty years after 10G base-t.

Re: How engineers at Digital Equipment Corp. saved Ethernet

#86

Post by throw0101a »

mixmastamyk wrote: post #15
bluGill wrote: post #12

Earlier quoted context omitted.

Unfortunately none of those people have explained how it could be done in enough detail that I could try it. Most walk away when pressed but a few press on telling me it is easy so shut up and do it .

Similar to how it has been done with phone numbers. I saw this done in Brazil for example. You add a digit to the front and put all existing address on 0.*. Short number dials are assumed to be 0.*. Update OS and hardware. Then you allocate across the new digit much later as time goes on. The thing with phone infrastructure though is that it is centralized. So may happen in a reasonably coordinated rollout. Global in…

> Similar to how it has been done with phone numbers.

Phone number lengths are defined by ITU E.164:

* https://en.wikipedia.org/wiki/E.164

They can be up to 15 digits long: so as long as the format change that goes from length x to length x+1 doesn't break that limit, then no changes to code or equipment needs to be done. The routing just needs to be tweaked so that when a number is read the signal is sent to the correct destination.

This is different from IPv4 where the digit length needed to be changed. It would be like if telephones went from 15 digits to 20+ digits: all the telephone gear would have to be changed to deal with the larger numbers.

Re: How engineers at Digital Equipment Corp. saved Ethernet

#87

Post by andsoitis »

itemize wrote: post #65
beachy wrote: post #58

Earlier quoted context omitted.

Ha ha, it came from Wikipedia so possibly.

As a barely relevant point, Using google, I can't find references to the quote (or John Carmack) by searching 'Little tiny steps using local information winds up leading to all the best answers'. Other search engines seems to do a bit better on retrieving the Wiki article. What gives, is google really becoming worse?

> Using google, I can't find references to the quote (or John Carmack) by searching 'Little tiny steps using local information winds up leading to all the best answers'

Mr Carmack references "gradient descent" in interviews[1][2] and his own posts on X[3].

[1] https://dallasinnovates.com/exclusive-qa-john-carmacks-diffe...

[2] https://transcript.lol/read/youtube/@lexfridman/6522e9950331...

[3] https://twitter.com/ID_AA_Carmack/status/1773391295538442445

[3]

Re: How engineers at Digital Equipment Corp. saved Ethernet

#88

Post by adrianmonk »

rini17 wrote: post #14
themerone wrote: post #8

Earlier quoted context omitted.

There's a surprising number of people who think you could magically expand the IPv4 address space in a backwards compatible manner.

But this was what literally happened. All routers today support NAT and most of them actively use it. Isn't it a magical form of extended IPv4 address space? Could have been easily done in less band-aid fashion instead of chasing IPv6.

No, it's not a magical form of extended address space. It's a magical (clever) way of extending the networking without extending the address space.

Re: How engineers at Digital Equipment Corp. saved Ethernet

#89

Post by nyrikki »

mannyv wrote: post #66

One side effect of the network switch was that you needed to buy switches. With the old way everyone could be on one wire. With the new way you needed one port per host. Switches also allowed for centralized management. Note that cable works on what essentially is token ring, at least conceptually; channel 0 (i believe, it's been a while) is the heartbeat.

When switches first arrived, most of them were unmanaged, or only had basic snmp counters, but they solved the collision problem.

I remember my first Internet company, where after getting an ARN for free. Coordinated with uunet over IRC to get them to pull routes from me, turning up our second T1.

The second traffic started to flow the collision light on the 24 port 3com fast Ethernet hub went solid.

I thought I had routed the Internet over my link.... but no, two T1s through an Alta Vista firewall running on a DecStation was enough to do it with a basic three their web app while backups were running.

I had lots of experience with 10base2/5 with more traffic, but the stocastic nature of web traffic was problematic.

If you lived through the growth of the Cisco chassis switches, the ASIC improvements that allowed for management was quite obvious.

I remember fighting with packet engine engineers, advocating for jumbo frames as default. They wanted to support gig-e hubs, which would have never been useful due to collisions.

History proved me right there, nothing simpler than a store and forward bridge made it to mass market for Gig-e

Re: How engineers at Digital Equipment Corp. saved Ethernet

#90

Post by EricE »

Waterluvian wrote: post #4
gumby wrote: post #2

What a great story. The spanning tree algo is under appreciated: this allowed people who didn’t understand networking to plug networks together the way you would plug extension power cables together,* making networking simple ( or alternatively insanely broken, when people had 400 computers on a single LAN with a rat’s nest of bridges and hubs…but unlike the extension cord case, nothing would catch literal fire). * d…

> but unlike the extension cord case, nothing would catch literal fire Somewhere, out there, is a story of an overburdened network setup literally catching fire, and it’s hopefully making its way to us.

Seen more than my fair share of magic smoke from lightning or near lightning strikes.

Also fried more than a few ports on devices when passive POE used to be more prevalent :p

Post reply on HN