SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: a vote for asymmetric connections in a session



    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>
    
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:07:12 2001
6315 messages in chronological order