RE: a vote for asymmetric connections in a session

[Charles Monia <cmonia@NishanSystems.com>]

> -----Original Message-----
> From: John Hufferd/San Jose/IBM [mailto:hufferd@us.ibm.com]
> Sent: Saturday, September 09, 2000 12:05 AM
> To: Joshua Tseng
> Cc: ips@ece.cmu.edu
> Subject: RE: a vote for asymmetric connections in a session
> 
> 
> Joshua,
> I do not understand whether this is a real issue or not.  I 
> know of a lot
> of Client Server applications that ship a lot of data on 
> TCP/IP, and TCP/IP
> seems to be adequate.  Now I understand there are some differences in
> Direct Storage Access, but it is more like the other 
> applications then it
> is different.  If we can address Costa's Issue or have at least two
> Connection per Asymmetric Session, I am not sure anything 
> else is a real
> life problem.  But I can be convinced, however, I would like 
> to understand
> for each problem we come up with, why it is only a problem 
> for iSCSI and
> not for the other real world applications, and why the SCSI 
> layer can not
> handle the problem.
> 
>

Hi John:

Here's my stab at responding to your concerns (hopefully, this isn't
"swinging after the bell"): 

In my opinion, iSCSI, as a mapping of the SCSI device model, is
fundamentally different than other client-server protocols.  The difference
is that it allows a client (the initiator) to have many transactions
concurrently pending against a single object (the LUN). Other protocols, on
the other hand, typically allow only one. As I see it, the issues we've
talked about in this thread stem from this basic property.

In the case of SCSI, some of these transactions may be in flight while
others may be pending in the LUN waiting to be performed.  When the lun
receives new commands that can't be serviced for some reason, the SCSI layer
handles the problem by discarding them.  If the condition is corrected
spontaneously, as might happen if the problem was due to a temporary
resource shortage, the lun simply resumes command processing.

In my view, the question we should be addressing, then, is whether or not
that policy is valid in the global internet environment for which iSCSI is
targeted.

Over to you....

Charles

<remainder deleted>