In-Depth

iSCSI: The Best Darn Protocol You’ll Probably Never Use

Nearly three years overdue, the new iSCSI protocol lets SCSI operate as an application across a TCP/IP network. Is it too little too late?

• By Jon William Toigo
• 02/27/2003

Advocates of the iSCSI protocol, of which I was one, lauded the burgeoning standard as the enabler for next generation storage area networks (SANs) – or, if you will, the first real SAN, since, unlike Fibre Channel-mapped SCSI, iSCSI was designed to ride over a “real” network in the Open Systems Interconnect definition of the term.

Those of us who warmed to iSCSI were quickly squelched by the Fibre Channel Industry Association (FCIA), a collection of vendors peddling half-baked solutions for interconnecting servers and storage arrays into a half-baked and error-prone switched fabric. FCIA began with a barrage of falsehoods and doublespeak that persists to this day, suggesting that TCP/IP is incapable of supporting a chatty protocol like SCSI with anything like the speeds and feeds required for high-end storage IO.

FCIA paid good money to articulate their view of the world. In private, vendor members of the FCIA would agree, off-the-record, that FC was not really designed for creating SANs at all. To do SANs, the Fibre Channel Protocol (FCP) needed additional “services”—in fact, those very same IP stack-like functions that had been deliberately omitted from the protocol when it was first written at IBM. These services, supporting in-band management, security, and other important applications, were needed before FCP could really do the end user any good. Without them, FCP delivered nothing but switched, server-attached storage architecture whose expense and interoperability headaches have become legend.

In the end, the FCP-based SAN became—to the technically savvy—a veritable poster child for an idiotic approach where pseudo standards are substituted for open standards and plug fests are substituted for standards-based compliance testing.

Publicly, however, these very same vendors held press events where they proclaimed FCP SANs to be the solution to the world’s storage problems. During a demo, when two machines wouldn’t stay awake on the same fabric, the vendors took the Wizard of Oz approach and sent someone behind the curtain to manually flip the chassis LEDs off and on to give the appearance of a working solution.

Most of the press (and a lot of IT decision-makers) were dazzled. Those who chose not to heed the guidance that we should “pay no attention to the man behind the curtain” were subtly (and sometimes not so subtly) warned that our questions about the integrity and reliability of FCP SANs would “marginalize” us from the mainstream, reducing our income as we wrote articles no one would ever publish. Like it or not, the FCP SAN had become a “movement.”

Only FCP never really went mainstream. There were never enough FCP SANs deployed to really change anything. A year ago, one estimate held that only about 11,000 of the things had been sold and fewer than 50 percent had total storage capacities totaling more than 360GB. That’s a far cry from the “mainstream data center penetration” that FCIA was boasting for its favorite technology.

In the final analysis, the FCIA vendor members almost universally took a hit in February 2001 when the bottom fell out of their supposedly unshakeable FCP SAN market.

It was false then, and it is false today. But a falsehood told often enough sometimes gains the credibility of self-evident truth. This is the case in the market today. The new open network storage protocol standard, iSCSI, is being dismissed as unimportant, and even Cisco is helping in the hatchet job.

Today, economic conditions are driving once-stalwart IP bigots, including Cisco, to soft-peddle iSCSI advantages over FCP. They are towing a twisted line that contends that iSCSI may not play well in the data center, and may be better suited to the periphery of an FCP SAN. In other words, iSCSI may provide a mechanism for transporting “slow moving, latency insensitive” data across an inexpensive IP WAN for backups, or to connect less-important servers outside the company data center to a mission-critical Fibre Channel fabric inside the glass house.

Under their breath, some one-time advocates may continue to hold out hope for iSCSI to become dominant and say that this will happen once 10-speed GigE networks become the backbone nets of Corporate America. At the current backbone bandwidths of 10/100 and GigE, however, iSCSI just doesn’t go as fast as FCP.

So many vendors have changed their contentious “iSCSI rules, FCP drools” rhetoric for the kinder and gentler “can’t we all just get along” mantra. Many folks are probably wondering why they would ever need iSCSI. FCIA has an answer to this question: there is absolutely no reason. By the time that 10X GigE becomes available, you won’t need to run iSCSI. The same wire will be able to run FCP. Little old iSCSI will just become another worthless protocol in a growing pile of protocols from IETF that delivered too little too late.

Fact is, however, for FCP to come to full fruition and to deliver on the promise of SANs from the standpoint of management and security services, the protocol will need to become—you guessed it—much more like iSCSI. It won’t be called that, of course. It will be called something like the I-Told-U-So (ITUS) protocol, just so the FCIA can maintain bragging rights. This would also have the benefit of covering the rear ends of all those IT decision-makers who bought into the FCIA hype and spent a ton of money on a bleeding edge FCP SAN.

In the final analysis, iSCSI may be the best little protocol that you will never get the chance to use.