RE: a vote for asymmetric connections in a session

["GUPTA,SOMESH (HP-Cupertino,ex1)" <somesh_gupta@am.exch.hp.com>]

Let me use an abstract example to illustrate why differences in
underlying transports may be important.

Let us assme protocol layer A uses services provided by Protocol
layer B. There is an understanding of the functionality as well
as other characteristics (like latency or implicit ordering that
may be implicit) of the service that B provides to A.

When you end up using another protocol layer C instead of B with
different characteristics, then there needs to be a convergence
so that users of layer A remain umimpacted. This could be achieved
by providing the required convergence in C, or in A.

I think it is better to address those convergence issues in C (iSCSI)
than in A. Most of these are brought about by the desire to operate
at full speed in the face of increased latency (without increasing
frequency of events which even though theoretically possible in
parallel SCSI or FC rarely happen and users may not account for as
a normal operating mode).

Somesh

-----Original Message-----
From: John Hufferd/San Jose/IBM [mailto:hufferd@us.ibm.com]
Sent: Saturday, September 16, 2000 8:50 PM
To: Charles Monia
Cc: ips@ece.cmu.edu
Subject: RE: a vote for asymmetric connections in a session



Charles,
I have had a number of Network Client/Server apps that used TCP/IP and had
multiple conversations/connections from the same Client Host to the same
Data Base target (plus other Client Host that also had multiple
conversations/connections).  This is perhaps even normal.  We also had to
make sure that there was adequate memory space in the application (Database
or Client) to support the thruput (both requests and responses) needed.
They of course needed a method to coordinate its memory needs with the
various client threads.  None of this had anything to do with what was done
by TCP/IP.  We expected TCP/IP to work out its own problems, we did not
expect the application to do anything special to help TCP/IP --  and guess
what -- TCP/IP worked just fine.

There is no important difference here between normal Client Server
applications and SCSI.

.
.
.
John L. Hufferd


Charles Monia <cmonia@NishanSystems.com> on 09/16/2000 07:12:46 PM

To:   John Hufferd/San Jose/IBM@IBMUS, Joshua Tseng
      <jtseng@NishanSystems.com>
cc:   ips@ece.cmu.edu
Subject:  RE: a vote for asymmetric connections in a session





> -----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>