RE: single vs multiple channels for iSCSI commands

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

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