Would you please give your opinion on storage over IP, and why you think it will or won't work? Additionally, would you mind sharing your thoughts about the best way to do TCP/IP offload, specifically for network storage applications? I tend to think that offloading the entire stack in software is the better solution, rather than doing basic dataplane offload using an ASIC.

    Requires Free Membership to View

    Login

I believe that the very existence of the protocol demonstrates that, with respect to Fibre Channel SANs, the "emperor has no clothes." That is to say, switch interoperability issues and high deployment costs impede the deployment of enterprise wide (and extra enterprise) FC SAN solutions. Companies must turn instead to Cisco Systems, Nishan and other Storage over IP vendors for a kludge that will enable the cobbling together of little FC SAN islands using GigE/IP nets. That's just bad architecture.

Will it work? Sure it will. But I firmly believe that as iSCSI matures, FC SANs generally will be relegated to a niche.

Don't know how much space I have for your second question, but I'll give it a try. I had a chat with my fellow Floridians at DataCore Software and discussed your question. Here was their view:

"On IP offload, the software approach should better leverage existing hardware, so it's likely to have early traction. Once mature, and the many legacy SCSI issues have been addressed, then the ASIC route will make more sense. As with many of these projections, commercial reasons rather than technical ones will drive the adoption of SCSI over IP."

I agree with DataCore up to a point. Frankly, however, I see HBAs enabled with TCP stack offload chips already being prepared by numerous manufacturers. This is old technology really. I remember writing white papers for Cisco around a similar approach used to offload IBM mainframe IP stack processing (the mainframe IP stack software was terrible in those days) to a router blade in the 1992 timeframe. Doing stack offload in silicon is much more efficient and less prone to failure than software approaches.

Hope it helps.


This was first published in March 2001

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.
    Back to top