RE: A Simple Question

[julian_satran@il.ibm.com]

Dear Mr. Cheng,

The whole discussion thread is based on the assumption that there will
be cases in which you will need several adapters (more than one) while you
keep assuming only one.

Julo

"Y P Cheng" <ycheng@advansys.com> on 14/09/2000 22:55:38

Please respond to "Y P Cheng" <ycheng@advansys.com>

To:   John Hufferd/San Jose/IBM@IBMUS
cc:   Julian Satran/Haifa/IBM@IBMIL, black_david@emc.com
Subject:  RE: A Simple Question




> From: John Hufferd/San Jose/IBM [mailto:hufferd@us.ibm.com]
> Sent: Wednesday, September 13, 2000 7:04 PM
>
> I was not sure what your HBA does, and what your Drivers do.  It sounded
> like you were combining the functions of SCSI, Wedge, iSCSI and TCP/IP
> driver, into a single Device Driver.  If so, that sounds like it
> might be a bit of a problem for various vendors storage controllers
> (they need their own Wedge Drivers).  And since most platforms
> has their own SCSI drivers, I hope you are not building another one.
> Therefore, the thing which I hope you are doing is just a good iSCSI
> Device Driver that works with one or more of your own NICs.
> If this is so, and as long as you handle the interoperability
> issues  (or 1 above) correctly, the things you said sound fine.

Thank you for taking time to write.  Our adapters follow the industry
standards and interoperate with the SCSI, 1394, and Fibre Channel devices
provided by the industries. It is our intent to add iSCSI function to our
adapter.  As long we send out the correct 48-byte iSCSI header and also
interpret received iSCSI header correctly, we will interoperate with
everyone.  Our adapter operates on all OS platforms.  They are programmed
to
support different protocols like FCP, IP, and VI, with iSCSI to be added.
Alacritec has an adapter that supports TCP in its microcode.

The main difference between my view and that of ips discussions is the
semantics on creating and interpreting the iSCSI headers.  The working
group
assumes the iSCSI in using TCP/IP will need several system calls: write
command, read/write data, and read status. Hence, iSCSI will have the
problem of interlocking.  The working group tries to solve the problem with
asymmetric and symmetric models.  However, if the group assumes a single
system call to send an iSCSI request, we can let the transport layer breaks
up iSCSI requests into PDUs of command, data, and status.  The asymmetric
model is no longer needed.

In our adapters, the transport layer builds a table for all data/status
transactions.  There is no queuing for them.  Like an asymmetric model, the
data/status transactions are serviced on demand.  The fibre channel adapter
uses class 3 delivery for FCP, which does not have an ACK.  The adapter
takes full responsibility of detecting and correcting bad transmission and
dropped frames efficiently.

Therefore, the real question is why solve the problems of some TCP/IP
implementation in iSCSI?  There are other transport mechanism in IP that
can
make reliable delivery.  The iSCSI task ID, RTT, status PDU, sense data,
and
SCSI tag-queue-depth, etc. are available to us to achieve a reliable
delivery.

Please don't mistake me.  I believe the working group is doing a great job.
All I am doing is to provide some additional information to the group.