RE: FC/IP vs. iSCSI

[Jim McGrath <Jim.McGrath@quantum.com>]

Actually, I don't really think there was an original intent on FC or TCP (I
remember early conversations on whether TCP or other transport protocols
should be used), just a "lets get a SCSI (block level) protocol working on
networks."

The T10 (SCSI) committee had a similar problem years ago with people pushing
for advancements on parallel SCSI, fibre channel, SSA (remember that?), and
1394 (Firewire) lower level protocols.  The result was an agreement that all
were worthy, all could be called SCSI (since there is a lot people have
invested in the name), but that each require different technical solutions
at some point.  These different solutions were often done by different
bodies, and SAM was created to make sure that the word "SCSI" meant
something at the end.

I'd advocate something similar here.  I see advocates for a full,
unrestricted Internet access model; for a bridge model (like FC to FC); for
an Intranet, or machine room only model; and perhaps others.  Encapsulated
FC may be right for one, TCP for another, FC over TCP for a third, etc...

Rather than argue over which one is the "real" iSCSI, I'd suggest spending
some time to cleanly identify these different potential application spaces.
At the end one technical solution may work for multiple spaces, but perhaps
there are good reasons for different solutions.  Even there it would be nice
if some leverage could be obtained.  The ultimate point of commonality is
SCSI and SAM.

Jim

PS even this thought may be too restrictive at some point - we earlier
discussed ATA (another block level protocol) over networks - given that
there are a lot more ATA drives than SCSI ones (relative shipment rates are
6:1), that may be of interest at some point.  But I'd focus on the SCSI
space first :-)


-----Original Message-----
From: meth@il.ibm.com [mailto:meth@il.ibm.com]
Sent: Friday, August 18, 2000 12:04 AM
To: ips@ece.cmu.edu
Subject: RE: FC/IP vs. iSCSI






Doug wrote:

"In reality, the iSCSI proposal was to a be a modification for a
Fibre-Channel
controller.  A complete and unaltered encapsulation is the most
straightforward approach and likely with the lowest overhead and risk."

This is not correct. The original iSCSI proposal was meant (at least by
some of the authors) to provide a SAM-2 compliant native transport for SCSI
over (specifically) TCP. The ultimate goal is to have a single network
infrastructure for regular internet traffic and for storage traffic; i.e.
the ultimate goal is to not need a separate Fibre-Channel infrastructure.
(Sorry Fibre-Channel fans ;-).) The same management tools and off-the-shelf
components can then be used for both ordinary internet infrastructure and
for remote storage infrastructure.

Now the IP Storage WG charter is broader than what iSCSI provides. There is
no need for iSCSI to provide a universal solution to all IP storage
problems. Let's develop the iSCSI protocol to do well what it was
originally designed for: native SCSI over TCP. We have to keep in mind,
however, that in order for iSCSI to be adopted, we will probably have to
provide some support for existing storage SAN infrastructure (i.e. Fibre
Channel) bridging. There is no need, however, to make that the primary
focus of the iSCSI protocol.

- Kalman