Ethernet at 40: Its daddy reveals its turbulent youth

Bob Metcalfe: How Token Ring and 'IBM's arrogance' nearly sank Big Blue

Beginner's guide to SSL certificates

Fighting IBM in the Token Ring wars

The Reg asked Metcalfe what it was that boosted Ethernet past its early competitors such as Token Ring and ARCnet, and he told us that despite what some said at the time, "They all worked. Various proponents claimed that the other thing didn't work, 'And therefore you should use mine.' That wasn't at all true. All these things worked."

Some of Ethernet's early detractors, he said, should hang their heads in shame. "In the dark days," he reminisced, "IBM was paying professors to write papers showing that Ethernet didn't really work – when it did work – and that Token Ring was better. Those professors should be ashamed of themselves."

Calling the papers that IBM had paid the professors to produce "clearly hatchet jobs," Metcalfe said that "it was really disheartening to watch IBM and these professors stooping to that shit."

Should you, aging Reg reader, recall one of the papers to which he was referring, Metcalfe has an explanation of what he claims the profs were up to. "What they would do was develop a model," he said, "a mathematical model ... They would then move the model into regions of absurd parameters. They would say, 'There's a million users, and they're sending full-time, all the time.'"

Those "absurd parameters" would cause the model to show that Ethernet would fail under those conditions. The papers would then conclude, "'See, that doesn't work here,'" Metcalfe said, adding, "But no system would ever be used 'here'. Duh."

IBM didn't play fair in other ways during the war between Ethernet and Token Ring, Metcalfe contends. "IBM always had 90 per cent market share in Token Ring, and some of it was cheating – they'd sprinkle SNA dust over their implementation," he said.

He also argues that IBM made it difficult for other vendors to get in on the Token Ring action. "3Com, my company, shipped Token Ring before IBM did," he said, shipping cards based on Texas Instruments chips. "That was because my board [of directors] would not allow me to 'risk the company' on this 'obsession' with Ethernet, and so we had to sell Token Ring."

That effort ran into problems. According to Metcalfe, when customers tried to plug their 3Com cards into IBM systems, they wouldn't work "because IBM had put some little thing in there that was particular to SNA," he said. "And eventually we'd figure it out, but we were always behind."

Metcalfe explained that IBM, being by far the dominant industry player in those far-away days, exploited its power. "IBM's arrogance was that they could make standards," he said. He recalled an old joke he he said he liked to tell that added a third type of standard beyond the familiar de facto – a standard by market acceptance – and de jure – one laid down by a standards-setting organization such as the IEEE.

"There was a third kind of standard in those days which I called 'de IBMo', which was a standard that was not in the market, and was not made by a legitimate standards body," he said. "IBM announced Token Ring – but they weren't shipping it, so it wasn't de facto, and it wasn't [a de jure] standard yet until they joined IEEE, so it was a de IBMo standard."

But IBM lost the power to create industry standards simply by announcing them during the mid-80s, he asserts – and from his point of view, Ethernet was the nail in the coffin of Big Blue's dominance. When we asked what exactly that nail was, he told us that "You can invent 20 or 30 answers to this question, including the superior technology of Ethernet," he laughed.

More to the point, however, was that Ethernet, as he put it, "understood its place," while the competition did not.

"Ethernet was developed in the context of the internet with its seven levels of the ISO reference model," he said. "So we had a job to do at level one and two, and we didn't burden Ethernet with all the other stuff that we knew would be above us. We didn't do security, we didn't do encryption, we didn't even do acknowledgements."

It's not that Ethernet was incapable of handling acknowledgements, Metcalfe said, it's just that he and his cohorts wanted to keep things simple. "Ethernet carried packets. Now, they could be acknowledgement packets, or not, whereas the other methods built some sort of elaborate acknowledgement scheme to boost reliability and so on."

As a result, "By virtue of knowing our place, we built something that turned out to be faster and cheaper."

And more scalable, he believes. With Token Ring, he said, "you do have to wait for that token to zip around, and of course the more places it's gotta visit, the probability of its breaking goes higher."

Another Token Ring failing, he said, was that "They never modeled what happens when you lose the token; they always assumed that the token was going to be there."

When we asked if there wasn't some method to store, check, and re-forward the token, he told us that there was. "There were a lot of mechanisms. They needed a mechanism to detect that the token hadn't been around for awhile. Then you need a mechanism for deciding who was in charge of putting the token back on the ring – and in that time the network's been down for a minute."

From Metcalfe's point of view, the Token Ring v Ethernet war began in the IEEE in 1980 and '81. One big break was when, in December of 1982, 19 different companies agreed to use a specific Ethernet spec, despite that it hadn't be approved by the IEEE and wouldn't be for few more years. "As soon as we shipped product – we shipped for the IBM PC using that standard – that was a big moment," he said. "But that wasn't the end of the war."

In those days Ethernet still required coax, albeit thin coax. "The twisted-pair came in the middle of the 80s – I'm not sure what the particular day was," Metcalfe said. "That was one of the advantages that Token Ring had, that it was twisted-pair, so coax was a negative. But as soon as we had twisted-pair," he laughed, "we were running faster at half the price.

That wasn't the end of the war, of course, but it marked the beginning of the end. "IBM struggled to prove that their 4 megabits per second was faster than our 10 megabits per second," he recalled. "They kept saying, 'Well, there are all these collisions.' No."

IBM then bumped Token Ring's speed up to 12 megabits per second when Ethernet was at 10 megabits per second, but doing so didn't halt Ethernet's adoption. "Twisted pair killed Token Ring," Metcalfe said, "plus the fact that it was expensive."

"I think it was Ethernet that finally brought IBM down in the mid-80s," he said.

Choosing a cloud hosting partner with confidence

More from The Register

next story
Fat fingered geo-block kept Aussies in the dark
NASA launches new climate model at SC14
75 days of supercomputing later ...
Yahoo! blames! MONSTER! email! OUTAGE! on! CUT! CABLE! bungle!
Weekend woe for BT as telco struggles to restore service
You think the CLOUD's insecure? It's BETTER than UK.GOV's DATA CENTRES
We don't even know where some of them ARE – Maude
Trio of XSS turns attackers into admins
Cloud unicorns are extinct so DiData cloud mess was YOUR fault
Applications need to be built to handle TITSUP incidents
BOFH: WHERE did this 'fax-enabled' printer UPGRADE come from?
Don't worry about that cable, it's part of the config
Astro-boffins start opening universe simulation data
Got a supercomputer? Want to simulate a universe? Here you go
prev story


Why cloud backup?
Combining the latest advancements in disk-based backup with secure, integrated, cloud technologies offer organizations fast and assured recovery of their critical enterprise data.
A strategic approach to identity relationship management
ForgeRock commissioned Forrester to evaluate companies’ IAM practices and requirements when it comes to customer-facing scenarios versus employee-facing ones.
5 critical considerations for enterprise cloud backup
Key considerations when evaluating cloud backup solutions to ensure adequate protection security and availability of enterprise data.
Reg Reader Research: SaaS based Email and Office Productivity Tools
Read this Reg reader report which provides advice and guidance for SMBs towards the use of SaaS based email and Office productivity tools.
Getting ahead of the compliance curve
Learn about new services that make it easy to discover and manage certificates across the enterprise and how to get ahead of the compliance curve.