Looking back on a few tech trends that weren't

By Johnna Till Johnson
Network World, 01/21/02

Aregular New Year's ritual for me is to go through old files and archives, reviewing past issues and (one hopes) learning something from those experiences. This year I looked back over 10 years of carrier service technology developments, with an eye toward evaluating why certain promising technologies failed to arrive.

Here are a few of the tech trends that didn't pan out . . . and the reasons why:

Switched Multimegabit Data Service (SMDS). Anybody remember that? You may if you worked at Bellcore, which created it, or MCI, one of the few major service providers that deployed it. Developed roughly at the same time as ATM - and partially with the hope of circumventing ATM's Byzantine standards process - SMDS was envisioned as a high-speed, data-only public service that incorporated quality of service (QoS).

It wasn't a bad idea. There was a clear business need for this type of service, as witnessed by the contemporaneous success of frame relay. Why did frame make it while SMDS tanked? A huge part of the credit goes to the Frame Relay Forum, which did two things right: 1) created a concise, easy-to-understand, easy-to-implement standard, even at the expense of desirable features, such as QoS, which was added later; and, 2) gained a critical mass of vendor support early.

Ubiquitous ISDN. Granted, ISDN has had a second life as a back-up strategy for corporate frame networks, and a few hardy souls still use it for Internet access. But it failed to live up to its early-'90s hype as a one-size-fits-all converged infrastructure. What went wrong?

First was the lack of a "killer app" requiring voice and data connectivity across the same wire. Companies that needed to converge voice and data for cost reasons were perfectly happy with time-division multiplexing muxes, and for the rest of us, plain old telephone service was fine. Second, ISDN didn't offer enough bandwidth improvement over existing switched data services, particularly as 24K bit/sec and faster modems emerged. Finally, the painful deployment process alienated potential customers and gave the Bell companies a lasting black eye. Bottom line: Make sure you're solving a real user problem - and don't forget that the devil's in the execution.

IPv6. No look back would be complete without revisiting IPv6. Admittedly, the requirements of mobile data networks may yet drive the deployment of IPv6 services, so reports of its demise may be somewhat exaggerated. But IPv6 was supposed to be up and running long before now (the original goal was to supplant IPv4 entirely by 2001). What happened? Basically, IPv6 failed to offer a substantial enough improvement over IPv4. And, as with ISDN, not enough time and energy went into effecting a smooth deployment.

Not everyone missed this last point. "Deploying IPv6 is going to be an incredibly painful process, and it may not even succeed," said Dave Piscitello, former Internet Engineering Steering Group member - back in 1994. Nice call, Dave.