In-Depth

Naming the iSCSI Standard

A protocol Without A Number

• By Jon William Toigo
• 03/27/2003

It strikes me as an interesting choice, to juxtapose “hubris” with “technology” in the dictionary. In ancient times (like when I was in grade school), when the teaching of the classics was more in vogue, the meaning of hubris was illustrated by re-telling the story of Icarus and Daedelus.

In the old story, Icarus was a Greek chap who wanted to fly like a bird, so he made himself a set of homemade wings out of old feathers and candle wax. He succeeded in getting into the air, but he ignored the practical warnings of Daedelus not to fly too high or too close to the hot sun. Of course, when Icarus, out of arrogance, failed to heed the advice, the wax holding his feathers together was melted, and he plummeted to his death. In mythology, the price paid for hubris was nearly always something pretty awful—sometimes even death.

Bundy’s cautionary quote updated the mythological reference: he warned about “technological hubris.” I’m not sure about the context of his quote, but it could be applied to any number of IT engineering efforts. Most recently, I found an example in reading through the message traffic that was being exchanged between engineers at the IP Storage Working Group, who are working to bring to final form a standard for operating SCSI, the language of storage, as an application across a TCP/IP network. (The IPSWG reflector makes interesting reading, by the way, if you like to know who dreams up all of this storage technology stuff. You can view the mail list in its full glory at http://www.pdl.cmu.edu/mailinglists/ips/.)

The message thread of particular interest for this column began with an innocent question about how the new iSCSI RFC (RFC—Request for Comment—is the Internet Engineering Task Force’s code phrase for standard) should be referenced. Bob Russell at the University of New Hampshire’s Interoperability Test Lab noted that version 20 of the iSCSI draft protocol had been accepted as the final version for the iSCSI RFC. He asked whether it would be appropriate to refer to the RFC as Version 1.0.

Such a simple question touched off a firestorm of responses. The engineers from some vendors wanted the RFC number to be Version 0.0, others were adamant that it had to be Version 1.0 to reflect a new version of the protocol separate and distinct from all the iterations of the draft standard—one that incorporated all of the final tweaks that had been made through draft 20.

It was difficult to understand the intensity of the debate over what seemed so minor an issue. That was when it dawned on me that there are still many iSCSI products coming to market that have not been updated to include all of the changes that have been made since draft 8 of the protocol.

Mallikarjun Chadalapaka of Hewlett-Packard made just this point when he argued that a Version 1.0 designator would help standards-compliant (Version 1.0) “iSCSI nodes [recognize and cope with functional differences] when they are talking with one of those ‘Early Access’ iSCSI devices in the field.”

Put another way, products that had been shipped to market and labeled “iSCSI compliant or iSCSI ready” over the past 11 months did not implement the final version of the protocol—only the functionality of an earlier draft version of the protocol. These vendors knew that there would be a reckoning someday and that they would have to bring their products into compliance with the final RFC, but they worried that naming the new RFC Version 1.0 would confuse their customers and, in the process, lose them the leadership position that they claimed was created by being the first kids on the block to support iSCSI nearly a year ago.

Engineers representing vendors that had shipped products based on earlier draft versions quickly shouted down the HP suggestion. The group sent hot missives back and forth arguing the merits and demerits of a new Version number.

One engineer supported Version 1.0 and said that the new number was required to facilitate interoperability testing—as a means to let the truly compliant product know when it was dealing with a not so truly compliant product. Another fellow argued that, “a final RFC version number would solidify the argument for non-interoperable implementations to be held [legally] accountable, [if they did not work.]” In other words, the consumer might be able to sue a vendor for fielding a product that said it was iSCSI compliant but really wasn’t.

Responding to these views, a contrary argument (and you've got to love this one) came from an engineer at Intel who wrote that he didn’t see the need for incrementing the version number even if there were multiple versions of the protocol floating around. Wrote the man, “I know VERY few customers with the sophistication to put a packet sniffer on their network and look at packet headers to determine [whether] there is a 0 [or a 1] there…”

In other words, if consumers were unaware of the differences that existed in the implementations made of iSCSI by different vendors, and these differences were being accommodated in plugfests and interoperability tests, the Intel fellow asserted that there was no reason to articulate a final RFC version of iSCSI that would determine which products actually complied with the standard.

That is the definition of hubris in a nutshell. In the end, a lone voice continued to cry out for a single universal standard even as the thread was moving on to other things. Andre Hedrick, of the LAD Storage Consulting Group, wrote: “The Storage Industry is the ultimate game of last man standing. Prior to iSCSI, the SAN was ruled by a few [vendors] and [Fibre Channel was a] splintered-broken protocol in terms of [its] failure to support interoperability. Keeping version 0 [of iSCSI] is just like craps in a bucket. Version 1 allows everyone to escape the bucket … I doubt there is anyone willing to step up and toe this line, but I will.”

So will we, Andre. All things considered, iSCSI will only compete with Fibre Channel if it can deliver the same or better service with less hassle. It takes the courage of convictions to raise a standard and to force everyone to test to it in order to certify the compliance of their products. Conversely, it is unbridled arrogance to argue that multiple implementations of a standard should be allowed to proliferate, introducing the real possibility of interoperability problems going forward, for as long as consumers are too stupid to know the difference.