RE: a vote for asymmetric connections in a session

[Charles Monia <cmonia@NishanSystems.com>]

Hi John:

I agree that there is no issue with TCP/IP, per se.

What I've been trying to call attention to is the ULP policy specified in
SAM for handling the stream of commands and task management functions after
they emerge from the TCP/IP pipe.

As I've stated below, the issue that ought to be discussed is whether or not
SAM's policy is adequate in an environment where the pipeline delays and
hence the amount of in-flight traffic may significantly exceed the norms for
other SCSI interconnct environments.  This, or course, has nothing to do
with TCP/IP but is an inherent property of some network environments in
which TCP/IP operates.

Charles

> -----Original Message-----
> From: John Hufferd/San Jose/IBM [mailto:hufferd@us.ibm.com]
> Sent: Saturday, September 16, 2000 8:14 PM
> To: Charles Monia
> 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>
> 
> 
> 
> 
> 
>