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



    
    
    
    A note of caution. The most serious dead-lock sitaution we are aware of
    steams from a mix of RTT (or should we call it R2T to accommodate Doug
    Ottis?) and unsolicited/immediate data.
    If channels are full with unsolicited data and the target requests
    something else
    - that something else will not get through. This dead-lock, as far as I can
    tell exists in all
    transports. A target should be able to detect it and iSCSI has provided for
    the target
    to be able to drop data and reclaim them later with R2T.
    To minimize the chances for it we are also not providing for switching
    between operating modes (R2T mandatory or not).
    
    Julo
    
    "John Hufferd/San Jose/IBM" <hufferd@us.ibm.com> on 08/09/2000 18:42:12
    
    Please respond to "John Hufferd/San Jose/IBM" <hufferd@us.ibm.com>
    
    To:   "Randall R. Stewart" <randall@stewart.chicago.il.us>
    cc:   ips@ece.cmu.edu (bcc: Julian Satran/Haifa/IBM)
    Subject:  Re: a vote for asymmetric connections in a session
    
    
    
    
    
    Randall,
    Your head-of-line blockage statement, is of course true, but you say it
    like it is a bad thing.  I am not sure it is.
    
    In the Asymmetric configuration, there is a different TCP/IP connections
    from each Host to a Storage Controller to handle the Commands from that
    Host to the Storage Controller (or at least that Storage Controller's
    Port).  Each Host has SCSI commands that are not related to the commands in
    other hosts flowing to the same Storage Controller (port) but on separate
    TCP/IP connections.  They expect to have their commands handled in some
    "fair" allocation method, with respect to, the other Hosts.  Nothing is
    blocking its "line" except its own Commands.  So TCP/IP has delivered, or
    brought up to be delivered, each Hosts commands independently.  Now it is
    up to the Target SCSI layer to chose which port/interface from which to
    bring additional commands into its buffers.  I do not see this as an
    important problem, and is the way things have worked regardless of the
    storage connections, for as long as we have had storage connections.  It
    was true on the SCSI buss, and it was even true on the Old IBM 360s (and
    continues to this day on the mainframes).  There will always be back
    pressure and sooner or later it causes the Initiator to stop sending new
    packets, since they are not being acknowledged, this will either occur at
    the TCP/IP layer or at the SCSI layer.
    
    I am not sure that this is a bad thing, especially since we are not talking
    about dead locks.
    
    
    
    .
    .
    .
    John L. Hufferd
    
    
    
    "Randall R. Stewart" <randall@stewart.chicago.il.us>@ece.cmu.edu on
    09/08/2000 04:58:06 AM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   Charles Monia <cmonia@NishanSystems.com>
    cc:   Matt Wakeley <matt_wakeley@agilent.com>, ips@ece.cmu.edu
    Subject:  Re: a vote for asymmetric connections in a session
    
    
    
    Charles Monia wrote:
    <snip....snip>
    > I'm not sure what is meant by "congestion."  If we're talking about
    > congestion in the TCP/IP transport, I'm in agreement.  However, I thought
    we
    > were referring to the sort of congestion that  the application on top of
    > iSCSI might see if it received more commands than it had room for.
    >
    > Unless I misunderstood your point, threfore, I think there might be an
    > issue. The only way I can see flow control in the tranport layer being
    used
    > to avoid dropping commands is if higher layer congestion results in back
    > pressure to the iSCSI pipe.  I believe that behavior is undesirable
    because
    > it introduces "head-of-line" blocking, with the following consequences:
    >
    
    Any time you get ANY retransmissions in TCP you will create a
    "head-of-line"
    blocking scenario. This does not matter if it is from flow control as
    you state or network congestion where a packet is dropped by a router.
    You will have situations where the TCP is holding data waiting for the
    retransmissions of an earlier packet... this is one of the reasons
    that sigtran developed SCTP...
    
    
    > a) It effectively shuts down the flow of commands to all logical units.
    >
    > b) It blocks the flow of task management commands (Abort Task, Clear task
    > set, etc).
    >
    > <snip...snip>
    >
    > Charles Monia
    > Senior Technology Consultant
    > Nishan Systems Corporation
    > email: cmonia@nishansystems.com
    > voice: (408) 519-3986
    > fax:   (408) 435-8385
    
    --
    Randall R. Stewart
    randall@stewart.chicago.il.us or rrs@cisco.com
    815-342-5222 (cell) 815-477-2127 (work)
    
    
    
    
    
    
    


Home

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