February 18, 1998

I was prompted to write this letter to the editor of Network World after reading a series of published articles about "Fast Token Ring," most notably, "Token Ring: Already built for gigabit speeds."  By the way -- although several of my previous letters had been published, the editors of Network World did not publish this one -- wonder why..."

    Readers new to Network World and many computer industry novices may actually start to believe Kevin Tolly’s misguided garbage about token ring! I think it is fair to say most of us acknowledge token ring as a has-been technology that most organizations would rather avoid, yet Tolly continues to find refuge in the pages of Network World, an otherwise honest and flawless trade publication that I have been reading for many years. This guy is peddling an agenda rather than practicing objective journalism, and you, my friends, are providing him with a soapbox. I have written to you before to refute Tolly’s claims in numerous articles about the fictional fast token ring. I am writing again to debunk the claims in his recent Network World article, "Token Ring: Already built for gigabit speeds."
    In the opening paragraphs of this piece Tolly reflects on the intentions of token ring’s creators - that they "[believed] Ethernet’s architecture to be flawed" and "deliberately designed their LAN to avoid such problems." In so doing those creators, to use Tolly’s own words, "over-engineered" the token ring architecture. In this article Tolly now attempts to turn this into an advantage for gigabit token ring (another non-existent technology, by the way). Token ring is so over-engineered and overly complicated that it requires several ancillary functions and backup mechanisms just to keep it running properly (i.e., Active Monitor, Standby Monitors, Neighbor Notification, Claim Token, and Beaconing -- which never seems to fix anything without human intervention - but I digress…). Because so many things can and do go wrong within the normal operations of the token ring network access method numerous mechanisms are implemented to ensure that the ring can recover when problems do occur. Furthermore, token ring requires every frame to pass through every length of cable and every potential point of failure in the entire token ring LAN (See illustration). Surely this cannot be considered a "good idea" -- not to mention the latency such a system imposes on the entire network.
    Tolly goes on to state that "Key elements of token ring’s architecture would not become meaningful, or exploitable at the original 4M bit/sec LAN speed. Without knowing it, the first architects were designing gigabit token ring." I supposed Tolly thinks these architects were either psychics or divinely inspired! I only resort to the absurd because Tolly went there first. His entire article is absurd. And who exactly were those "first architects" he speaks of with such admiration? How about a little chronological accuracy to illuminate just how visionary those first archtects were? Please correct me if I am mistaken, but as I recall, Proteon developed the first commercial token ring products in 1983. This is easier to present in a table (see below - all are token passing rings). Of all these efforts only the last two are still significant enough to warrant mentioning and they are quickly being eclipsed by newer, faster, and frequently cheaper products.
1981 Proteon ProNET/10 10 Mbps token passing ring 
1983 Proteon ProNET/80 80 Mbps token passing ring
1985 IBM IEEE 802.5  4 Mbps token passing ring 
1987 FDDI ANSI X3T9 100 Mbps token passing ring 
1988 IBM IEEE 802.5 16 Mbps token passing ring 

    In his next paragraph Tolly addresses the "unique set of challenges" presented by campus backbones. He ponders "how can gigabit pipes be used efficiently when, even using Ethernet’s largest possible frame size, some 80,000 frame/sec are needed to fill the pipe?" This is a meaningless red herring, what we in the trenches usually refer to as adult male bovine fecal material. Could Ethernet benefit by implementing a somewhat larger frame size? Even Ethernet’s inventor, Bob Metcalf, says yes - but what has this got to do with using gigabit pipes efficiently? Just because a network can support large frames does NOT mean the protocols or applications will use them! And more importantly, just because a network can support large frames does NOT mean it is a good idea!
    In mid-paragraph the author then jumps track to the issue of providing Quality of Service in a multi-switch backbone. While an interesting topic with several solutions underway, it has nothing to do with the topic at hand - the effect of frame size on network efficiency. Then he throws in another red herring by raising the question, "how can a mesh network be built with Layer 2 switches?" The short answer is that robust, reliable, fault tolerant mesh networks are not built with Layer 2 switches - we use routers, also known in some cases as Layer 3 switches. I realize that such a curt answer will meet with more than a few rebuttals, but again this is not the topic of this article.
    Later in the piece Tolly continues this frame fallacy when he states that "Larger frame sizes are a key factor in achieving full utilization of a high speed LAN." Tolly cites Ethernet’s current maximum frame size (1518 bytes) as being the source of an efficiency problem, but neglects to mention that larger frame sizes only benefit large file transfers and can even cause inefficiencies of their own! He makes the broad, and in my opinion, misleading if not erroneous claim that larger frames deliver better effective throughput, and then goes on to make a completely meaningless reference to the number of token ring frames required to fill a gigabit pipe. It’s as if Tolly thinks network architects (read: makers of LAN products) have any say whatsoever about what frame sizes a given application will require! Is it the applications which drive network efficiency (or inefficiency as is more often the case)! Telnet will still transmit one character of data at a time even though the LAN may be capable of supporting an 18k byte frame. The content of Web pages is usually kept small so that it can be retrieved rapidly over a variety of network connections. Databases usually generate relatively small queries and transfer individual records between clients and servers. Some databases may perform larger file transfers between servers or between clients and servers, but this should be kept to a minimum. And then there is video conferencing and voice over IP.
    Consider the following: ATM and voice over frame relay. The 53-byte cells used by ATM are the smallest transmission units used in any commercial network technology, yet ATM is capable of supporting high-speed data transfers as well as live, interactive (isochronous) video and voice sessions via its various service levels: AAL Levels 1-5. This seems to contradict Tolly's argument for big frames, but moreover, simply providing Quality of Service is not enough. Latency must be controlled, consistent, and low in order to efficiently support video and voice. ATM accomplishes this by keeping the maximum transmission unit small and fixed -- not big and variable!
    Vendors that sell voice over Frame Relay products accomplish this in much the same way by restricting the maximum transmission unit (MTU) to a very small size (64 - 128 bytes). Of course, this does mean sacrificing the efficiency of data transmissions to accommodate the more delay-sensitive video and voice sessions. The fact that many organizations are considering implementing voice and video over their data networks means that larger frames would be a detriment, NOT a benefit! Ergo, the entire premise of Tolly’s argument for larger frames is bogus. (Please correct me if you think I’m wrong - there’s no point in being wrong - and I hate being wrong…)
    Furthermore, if anyone actually implemented the ~18k byte frames supported by 16Mbps token ring it would surely have a negative impact on overall network performance. Larger frames mean greater inter-token latency (i.e., longer delays between free tokens). Therefore, not only would larger frames cause enough variable latency on the network to disrupt video and voice sessions, it would also impact the response time of some ordinary data transmissions! By the way --Tolly’s precious SNA systems rarely (if ever) require frames larger than those provided by Ethernet. And finally, most WAN services that I’ve seen use smaller frames. The Internet uses 576 byte frames (I think that's the magic number), and the process of segmenting large LAN frames into smaller chunks to be passed over the WAN adds latency at the router (or whatever edge device you choose to use)! Bigger is NOT always better!
    Tolly thinks traffic prioritization schemes such as token ring Priorities is a panacea - never mind that virtually no protocols or applications support it. Token Ring’s Priority bits are less than rarely used, they are a moot point. Virtually no one uses this feature because there are no applications or protocols that can make such a priority request. If I’m wrong, name 2 protocols or applications that do. In addition, it seems to me that by using token ring’s priority mechanism you negate the deterministic characteristics of the network. Furthermore, token ring’s deterministic nature cannot guarantee a constant bit rate as many people may assume, it only guarantees that the performance of all stations suffers and degrades equally.
    Again Tolly illuminates his misunderstanding of the subject as he attempts to defame the Spanning Tree Protocol in favor of Source Route Bridging. Spanning Tree was developed to provide fault tolerance between LAN segments - and it does this. Source Route Bridging does support multiple concurrent paths as the article states, but each established session is static and cannot change its path of rings and bridges once sessions are established. Source Route Bridging does not provide the fault tolerance Tolly claims it does.
    If a Source Route Bridge or one of its rings goes down, the sessions using that path also go down - even though there are other ring/bridge paths available -- SRB does not dynamically reroute sessions around the failure area. Furthermore, IEEE 802.1D Transparent Bridging (which is what this paragraph is really about) places the path processing burden on the bridges rather then the end stations, and it was designed to support token ring and FDDI as well as Ethernet. An 802.1D Bridge dynamically learns the MAC address of each station on each segment connected to it and builds and maintains its forwarding table automatically.
    A Source Route Bridge only knows its own Bridge ID and the Ring ID’s of the rings attached immediately to that bridge, and all of this has to be programmed by a person! This means administrative overhead. If the network changes, a person must reprogram all of the affected Source Route Bridges! Although Source Route Bridging places the processing burden on the end stations the end stations know nothing about the network beyond those rings and bridges they are currently using. Also, the Source Route Bridges know nothing about the end stations, other bridges, or other rings not directly attached to them. As such, Source Route Bridges cannot provide fault tolerance by rerouting sessions around failed areas of the network.
    Tolly’s distaste of layer 3 internetworking (i.e., routers) is always readily apparent, and in my opinion further illuminates his ignorance of how internetworking works on THIS planet. He refuses to acknowledge that as long as we use TCP/IP (and IPX, and DECnet, et al…) routers will be required. The only way to move an IP packet from one network or subnet to another is through a router (or layer 3 switch = usually the same thing). And finally, Layer 2 switches are great for managing LAN bandwidth and are an excellent complement to routers, but routers can provide certain capabilities that switches cannot. But alas, this has nothing to do with the topic of the article…
    The architectural superiority of token ring is an academic debate best conducted over many beers rather than the pages of this publication. Clearly, there is inadequate interest in the market to warrant the continued pursuit of this technology. Besides, we’ve had access to a form of fast token ring for over a decade now with FDDI. It has always been too expensive and still lacks in popularity after all these years even though it CAN provide fault tolerance!
    So I ask you, why does Network World continue to print the biased and erroneous information propagated by just this one person? Is there no one else in the entire industry who would take the same positions as Tolly? Clearly he has an agenda - and it is not objective reporting -- not when his company is being funded by the High Speed Token Ring Alliance!

Your pal,
    Buddy Shipley ;-}