Lessons From the LAN

I recently came across another article raising the question: “Will Ethernet kill Sonet?” (See Stitt: Sonet's Even More Dead.) This got me thinking about the similar battle between Token Ring and Ethernet LAN technologies in the late 1980s and 1990s, which could make for an interesting comparison.

The over-simplistic case is that Ethernet won in the LAN, therefore it will win in the WAN. But it’s more complicated than that. While I do believe that history often repeats itself, we should understand what really happened before applying the lesson. And the lessons of Ethernet vs. Token Ring are a study in competitive and strategic moves by technology vendors.

Ethernet was the first LAN technology to gain wide acceptance. In its initial form, Ethernet wiring was unstructured, the protocol itself had few tools for problem management, and it had few mechanisms to avoid traffic congestion and ensure fairness. Token Ring, championed primarily by IBM Corp. (NYSE: IBM), was designed to bring many of the qualities of Sonet rings to the LAN. It could automatically detect and isolate failures, support priority traffic, ensure fairness of access, and provide capability to carry synchronous traffic. Because of Token Ring’s robustness, it became a favorite for banks, large enterprises, and mission-critical networks. Ethernet, on the other hand, was relatively cheap, which made it popular for the masses.

Sound familiar? It gets even better. Ethernet in the LAN began to evolve. With the advent of Ethernet over twisted pair came intelligent Ethernet wiring concentrators, which allowed Ethernet LANs to provide many of the reliability features of Token Ring (sounds a little bit like RPR). On the other hand, Token Ring PC card prices dropped by 75 percent in a few short years. As the costs of both technologies continued to drop, Token Ring narrowed the price gap from 5:1 to 2:1 or less. Still sound familiar?

Unfortunately, the advances in Ethernet made even those reduced price differences hard to justify. Most LANs never took advantage of Token Ring’s priority and traffic synchronization features (VOIP came 10 years too late). While Token Ring held onto existing customers and a few applications that could justify the price difference, intelligent hubs and switches made Ethernet more ubiquitous, and it gained critical mass. The moral of the story is that Ethernet replaced Token Ring because it evolved – with perhaps a slight edge in price.

But before the RPR and carrier-grade Ethernet vendors start uncorking the champagne, let’s consider the differences in the case of Sonet versus Ethernet. First, Ethernet is not an incumbent technology, as it was in the LAN. This sets the bar higher in terms of the need to cover the technological migration cost. In addition, in the service-provider world, there exist applications that require some of the extra bells and whistles that Sonet provides (like voice and video).

Perhaps the most interesting difference is not a difference at all, but a little known fact about the true technology cost difference between Token Ring and Ethernet.

It turns out that Ethernet may have edged out Token Ring in the market place, not because it was inherently cheaper, but because of some marketing missteps by IBM. IBM engineers did their magic to reduce the cost of Token Ring chips, reducing the difference in chipset costs between Token Ring and Ethernet to an almost insignificant level. So why did the gap in Token Ring-Ethernet pricing remain substantial?

In my opinion, there were two primary reasons. First, IBM’s overhead structure prohibited small commodity products from being price competitive, even when manufacturing was outsourced. Smaller vendors, which could be more competitive, did not enjoy the benefit of IBM’s lower technology costs. Perhaps more importantly, IBM’s networking division didn’t consider LANs to be strategic and were therefore unwilling to sacrifice cashflow to protect market share. Ethernet vendors cannot assume that these conditions will translate into the Sonet world.

If the lessons of the LAN hold true, competition between Sonet and carrier-grade Ethernet may have little to do with the intrinsic cost advantage of Ethernet technology itself. The issues facing the Sonet vendors have more to do with their will and commitment. Will they have the drive and expertise to continue to decrease their product costs? Has manufacturing outsourcing resulted in a low enough overhead for them to stay competitive with smaller companies? What margins are they willing to accept to protect their market positions? Will they learn the lessons of Token Ring?

For the Ethernet vendors, what will happen to their product costs as they add the functions necessary to compete with Sonet? Will the low cost of Ethernet chips, driven primarily by LAN volumes, translate into the same low costs for WAN chips, which are likely to be very different? Can they win if the Sonet vendors can drive the costs and pricing differences to a reasonable level? Do they recognize that their advantage does not depend on Ethernet itself, but their ability to innovate faster and compete harder than the larger vendors? Can they avoid listening to their own hype?

Put the corks back in the bottles, and get ready for a real fight.

— Doug Green is founder and principal of the Bradam Group LLC, a telecommunications consultancy located in Raleigh, N.C. He previously spent 13 years at IBM, primarily in PBX and LAN R&D. He can be reached at [email protected].

For more on this topic, check out:

For further education, visit the archives of related Light Reading Webinars:

Page 1 / 8   >   >>
BlueWater66 12/5/2012 | 1:19:13 AM
re: Lessons From the LAN Actually, the article "lesson from the Lan" made me think of IBM's push for Infiniband. I agree with the Ethernet vs. Token Ring comments ....

The market is currenly facing an apples-to-apples equivalent again with IBM on Infiniband. The latency and HPC performance of Infiniband are great, but PCI-Express (maybe with AS Switching) and plain old Ethernet are going to kill it. This is the "exact" story repeated again.

douggreen 12/5/2012 | 1:19:06 AM
re: Lessons From the LAN Mr Zippy,

I agree with your observations with a couple of exceptions:

The original Ethernet (coax, tree structured) was horrible when it came to reliability and servicability, especially in larger networks. This actually made Token Ring much cheaper to install and maintain, which accounted for some of its early success. This was a real advantage (versus those features that nobody needed, as you pointed out). This advantage disappeared with the advent of intelligent UTP hubs and structured wiring for Ethernet.

A second reason was that initially, you couldn't get Ethernet adapters for traditional mainframe controllers. A lot of PCs in large enterprises had critical dependencies on mainframes. Once again, this changed as Ethernet adapters became available for more traditional IBM products.

Token Ring did have some real advantages, but these were significantly reduced over time.

Regarding your observation on a $400 TR adapter and a $100 Ethernet adapter. What if the TR adapter had been only $120? What if I told you that the difference in the chipset costs would have easily allowed that kind of price difference?
mr zippy 12/5/2012 | 1:19:06 AM
re: Lessons From the LAN I think Token Ring tried to be the "ideal" technology for everybody, which lead to prioritisation, synchronous traffic etc., being added.

The problem was most users of LANs in those days didn't care for those features, and therefore didn't really want to pay for them. At the time of the Ethernet vs TR battle, the only applications most LAN users were using were "file transfer" type applications. Throughput was the primary requirement for a LAN at the time, and relatively cheap 10Mpbs ethernet was in practice better than significantly more expensive 4Mbps TR at providing that, in the average and common cases.

I think the people who invested in TR probably did so for two reasons. Firstly, although it was starting to fade out, there was still a common attitude of "nobody gets fired for buying IBM". There were still a lot of "IBM shops" around. Secondly, it is very easy to fall into the "best technology" trap, overlooking the realities of costs verses "actually useful" features.

There is a unix design tenet which is "optimise for the common case'. I don't think TR was optimised for the common case at the time, and when the "non-optimisations" came at a 300% or 400% premium (I remember a 10Mbps ethernet NIC costing around AU$100 verses a 4Mbps TR NIC cosing around AU$400), it's not a wonder that most people were willing to accept the "ineffectivness" of ethernet. "Good enough" again won over theoretical "best".

sgan201 12/5/2012 | 1:19:05 AM
re: Lessons From the LAN Hi,
I thought that AS Switching of PCI Express = Infiniband.. Am I wrong???

krbabu 12/5/2012 | 1:19:01 AM
re: Lessons From the LAN The possibility of implementing Ethernet in bandwidth-friendly manner on a SONET infrastructure - see, for example, http://www.lightreading.com/do... - tends to improve the longevity of SONET in the marketplace. In the long run, however, extremely unrelenting isochronous requirements would be needed to ensure SONET's continued presence.
Sisyphus 12/5/2012 | 1:18:58 AM
re: Lessons From the LAN
To a certain degree, this is a bit of a "best of breed" versus "good enough" discussion. One thing I find amusing in networking with certain regularity is that the winning recipe most of the time seems to be one consisting of merely good-enough technology wrapped in a best-of-breed marketing package. This means it is price competitive -since not truly engineered to be best of breed- yet the market quickly perceives it to be equal or superior technology... I mean, customers can't be wrong, can they? :-) Meanwhile, we spend a lot of time discussing the absolute benefits of technology concepts based on a quest for the perfect solution. We preach religion where users merely want an everyday tool to solve some problem.

As networking engineers, we regularly tend to fall in love with technology concepts so much that we forget the fact that historically users have not been willing to pay hefty premiums for clearly superior technology. Token Ring on paper seemed the more elegant and thought-through solution. So did Betamax. Alas, the competing technologies had a cost advantage and were good enough.

How this applies to the Sonet vs Ethernet battle remains to be seen. We'll always be smarter once we have the benefit of 20-20 vision abd afterthought. :-)
douggreen 12/5/2012 | 1:18:56 AM
re: Lessons From the LAN Sisyphus,

Excellent points. The carriers ask for the maximum function at the minium cost, which is not achievable. If someone delivers the function they ask for, they loose because it cost too much. If someone meets the price point, they loose because the function is not good enough.

Whoever delivers the cheapest ACCEPTABLE level of function wins. Figuring out what is really acceptable is the hard part because the carriers won't always tell you, and may not have given it much thought.

As Ethernet approaches the carriers acceptability level in terms of reliability and function, SONET has to get cheaper or it will loose. What remains to be seen is how cheap SONET can get. It doesn't have to match Ethernet, only to be close enough to make it hard to overcome the switching costs.

As I stated in the article, my feeling is that SONETs ability to get cheap enough is not a function of the inhernent cost of SONET, but of two things:

1.Do the SONET vendors have the will and engineering expertise to drive it as low as it can go? They are not historically oriented towards being low-cost producers (with the possible exception of Fujitsu).
2.If the technology reaches a low enough cost point, will the SONET vendors be willing to accept gross margins at the same level of the Ethernet vendors. In the case of Token Ring, the technology cost got there, but IBM was not willing to give up the margins to compete.

The human element, i.e. who will execute better, is always the hardest to call.

One last point: I made the arguement that Ethernet has to evolve to meet reliability and functionality requirements. It is only fair to point out that SONET also has to evolve (and is evolving) to be more efficient at carrying data, as one previous poster pointed out.
NetworkMercenary 12/5/2012 | 1:18:55 AM
re: Lessons From the LAN Dern it, my cute little iceberg diagram didn't transfer properly (must be a L3 iceberg...cough cough) - but just use that vivid imagination to expand the iceberg out *wink* - NM
NetworkMercenary 12/5/2012 | 1:18:55 AM
re: Lessons From the LAN Quite frankly, I think that many network architects (primarily layer 3 folk) get it all messed up. What do I really mean? Well, when planning a network design, the majority of L3 folk that I have interacted with (extremely large enterprise + service provider personnel) focus on the capex requirements for purchasing a particular technology and don't pay much attention to the opex requirements..."it's not that hard to manage L3 networks efficiently". However, having a clear focus on TCO, or total cost of ownership, I believe to be the best balance when making strategic network decisions. TCO=capex+opex.

Most that I've encountered say that an ATM port is much more expensive than an Ethernet port. Well, technically they are correct...if one is only focusing on the capex portion of TCO. However, the investment associated with opex is significantly higher in the long term.

So for illustration, every network that has a L3 component for the transport functionality has significantly more people resources associated with managing that particular network than a L2 or L1 component for transport. I've not seen one network that provide the streamlined efficiency and reliability when using L3 for transport.

Perhaps that's just my opinion...well, actually it is just mine and I'm trusting others as well, but L3 boxes have a control and hardware plane that is quite unreliable, as compared with a SONET or ATM solution (WAN/Transport). So my simple diagram below shows it best I believe...in my humble opinion. The illustration shows the "iceberg theory". The capex requirement is the small portion above the water that you can actually see and the opex requirement is the huge portion that you can't see (personnel to manage, provision and operate, outages with large SLA paybacks to your loyal customers, etc)...but trust me, you'll experience it while floating blissfully through the water in your L3 boat. Eventually the boat will crash and the opex requirements will far exceed the wise upfront investment in a true transport architecture.

/ \ Capex
/ \
/ \ Opex
/ \
/ \
/ \
/ Iceberg \

Just my thoughts :) - NM
pro zack 12/5/2012 | 1:18:54 AM
re: Lessons From the LAN ItGÇÖs funny how people compare/mention Ethernet and SONET in the same sentence. These are two fundamentally different technologies designed for two different applications. BTW, just for fun, SONETGÇÖs management network uses Ethernet and 10G Ethernet uses SONET framer. Present SONET is based on GFP/VCAT that is more efficient than Ethernet in data throughputGǪ No wonder the system design jobs have to be outsourced.
Page 1 / 8   >   >>
Sign In