RE: Asymmetric model

["Y P Cheng" <ycheng@advansys.com>]

> From: John Hufferd/San Jose/IBM [mailto:hufferd@us.ibm.com]
> Sent: Thursday, September 14, 2000 5:17 PM
>
> You can do what ever you want in your own adapter, however, if you are
> going to talk to a target that does not use your own adapter, then whether
> you use Symmetric, or Asymmetric, is of importance since the Target needs
> to support what you do.   So the Workgroup needs to decide, then you will
> need to follow that model.
> I do agree with you that if you have the capability to support
> "n" distinct instances of your adapter, such that the SCSI
> layer sees no different, the manor you use to get the commands and data
> onto the approprate adapter instance, is your and your iSCSI
> driver's business.  But how you interact (Symmetric, Asymmetric, etc.)
> determines how well you will work with IBM, EMC, et.al. Storage
Controllers.
>
> But every thing I said here is so fundamental,  it makes me believe that
> you must have meant something other then what came across to me.
> If I have misunderstood what you intended to say, please correct me.

Thank you for taking time to write.  I begin to realize that we are talking
two different layers: the mapping of a SCSI request to iSCSI PDUs and the
delivery of PDUs using a transport mechanism.  When we choose TCP/IP as a
delivery mechanism, the ordering of PDU's creates deadlock problem that must
be solved with asymmetric model unless we do just one SCSI request at a
time.  Of course, the asymmetric model allows parallelism and takes
advantage of multiple paths.

Instead of using the current TCP/IP implementation which establishes
multiple paths with multiple endpoints of (IP-Address, Port-Number), the new
INC card supporting fibre channel FCP has a different but very reliable
delivery mechanism.  It uses class 3 protocol which does not require ACKs
for datagrams.  This led me to state that we might not need TCP/IP for
delivery.  However, I do accept that many iSCSI implementations will use
TCP/IP as a delivery mechanism and apologize for bringing up an old topic
being discussed before.

I will repeat my statement that ACKs on a network with milliseconds of
latency can be very expensive unless we have a huge number of EE
(end-to-end) credits.  For example, a millisecond of latency on a gigabit
connection accomodates 67 1.5K-datagrams.  Taking advantage of the flow and
resource control of FCP and extending it to IP with long latency for a
reliable iSCSI delivery could be an interesting topic for the working group.