RE: single vs multiple channels for iSCSI commands

[hufferd@us.ibm.com]

I as I said in Haifa, agree with one iSCSI session per TCP connection (at
least to start with, because it is simpler). However, I would not like this
to get in the way of our IETF deadlines.  As long as a Target can respond
to a Login Message -- that it can only take one TCP connection per iSCSI
session, then this may be an approprate subset.   I, therefore,  would like
to see that type of a target response included in our spec.  (The Initiator
can always just send one connection per session, but the target needs to
express its limits.)  With this capability, the folks that think that
multiple connections per session are most important for their boxes, can
ensure that they have all the problems solved with that approach, while the
others can go ahead with the simpler approach.

As I also said in Haifa, the only required "in order" action is on a single
(virtual perhaps) LU.  This applies equally to Disk as well as Tape.
Therefore, it is not required that any special commands be created for
tape.  It is just required that all the Commands that are needed to be
delivered in order, be sent on the same Session.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSD San Jose Ca
(408) 256-0403, Tie: 276-0403
Internet address: hufferd@us.ibm.com
Notes address: John Hufferd/San Jose/IBM @ IBMUS
VM address: hufferd at IBMUSM54


Jim McGrath <Jim.McGrath@quantum.com> on 06/28/2000 02:42:55 PM

To:   "'Costa Sapuntzakis'" <csapuntz@cisco.com>,
      scsi-tcp@external.cisco.com, ips@ece.cmu.edu
cc:
Subject:  RE: single vs multiple channels for iSCSI commands




The problem is that while such a solution may allow you to close on a
protocol faster, it does not insure that you get products to market faster.
Specifically, requiring the tape people to add new commands introduces more
development time, and perhaps more importantly creates a division of
interest.  That is, the people responsible for supporting tape commands are
not the same people doing iSCSI, so you might create a classic chicken and
egg problem (no tape support for iSCSI until it gets to be important - and
iSCSI market development is hindered by the lack of tape support).

Mind, I am not thrilled about the alternative either.  But solving the
problem by creating new work for people "not in the room" may result in a
pyrrhic victory.

Jim

PS in my opinion the only way to really solve this sort of problem is to
identify your application space (or spaces) to allow for a concrete
discussion of tradeoffs.  For instance, initially FC ignored tape, focusing
on disk, and got FC done more quickly - but eventually had to retrofit tape
support.  This may have been the best overall path, since the disk drive
application was more important to the market than the tape drive
application.  However, for iSCSI (especially operated over a WAN) tape may
be more important - this is the sort of conversation you have to have
before
making decisions that trade off the speed of adoption in different markets.

-----Original Message-----
From: Costa Sapuntzakis [mailto:csapuntz@cisco.com]
Sent: Tuesday, June 27, 2000 8:26 PM
To: scsi-tcp@external.cisco.com; ips@ece.cmu.edu
Subject: Re: single vs multiple channels for iSCSI commands



I would like to stake out a position against any approach that involves
using multiple simultaneous TCP connections per iSCSI session.

The design of iSCSI (and the hardware that implements it) becomes
significantly simpler when there is just 1 TCP connection/session.

Parallel paths in the network can still be exploited by setting up
multiple sessions with multiple TCP connections.

So far, I have heard of two applications that allegedly require strict
ordering: tape backup and remote asynchronous mirroring. New SCSI commands
or even higher-layer techniques can be used to satisfy these applications.

For example, I have heard that some high-bandwidth tape applications blast
self-describing blocks of data to tape, making the order in which data
gets read/written to tape less relevant.

For the case of high bandiwdth remote asynchronous mirroring, a special
SCSI remote asynchrnous mirroring command set could be introduced.
I believe remote asynchronous mirroring principally consists of one
command: WRITE, so the command set would probably be small.

Ditching multiple simultaneous connections/session would help convince us
of the correctness of iSCSI and allow us to move onto other important
issues and help the time to market.

-Costa

App A. Possible remote asynch mirroring command sets

1) 1 CDB: ORDERED WRITE

2) 3 CDBs:  WRITE UNCOMMITTED,  COMMIT, ABORT