SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: Flow Control



    
    
    David,
    
    Suppose we have many TCP connections using the symmetric model and suppose
    that one of the commands is delayed because some packet was dropped.
    Suppose further that we want to maintain order of delivery (using the
    command reference numbers). Commands arrive on the other TCP connections
    and fill up the command queue while we are waiting for the missing comand.
    (Without using Pierre's suggestion) we don't know on which TCP connection
    the missing command will arrive, so we have to keep reading commands from
    the TCP connections in order to get to the missing command.
    
    Note that we only have to read a single command from each TCP connection
    until we find the missing command.
    
    - Kalman Meth
    
    
    
    David Robinson <David.Robinson@EBay.Sun.COM> on 21/09/2000 01:56:28
    
    Please respond to David Robinson <David.Robinson@EBay.Sun.COM>
    
    To:   ips@ece.cmu.edu
    cc:    (bcc: Kalman Meth/Haifa/IBM)
    Subject:  Re: iSCSI: Flow Control
    
    
    
    
    > > However, some have wanted to use the sliding window to solve a
    different
    > > problem.  They want to enable the target to advertise to the initiator
    how
    > > many commands the target is able to receive.  This apparently is not
    specified
    > > in SAM-2, and SAM-2 deals with overflowing the command queue in an ugly
    way
    -
    > > throw the commands away and enter an error state.
    > >
    > > The question here is whether iSCSI should attempt to solve the command
    queue
    > > overflow problem, or allow T10 to deal with it.  Other protocols (fibre
    > > channel) already deal with it in the "ugly" fashion - perhaps so should
    > > iSCSI.  What we need consensus on is whether or not iSCSI is going to
    deal
    > > with this.
    
    FC has a command queue overflow problem because it is a datagram protocol
    and cannot at the transport layer finely control the sender.  But
    with a reliable stream protocol I don't understand how you could
    ever get a command queue overflow.  If you command queue is full
    you simply stop reading from the TCP stream which will eventually
    cause the TCP input buffers to fill and the window to shrink to
    zero causing flow to stop. Short of a naive implementation that
    reads the TCP stream (thus keeping the window open) with no place
    to put the command it just read, I still don't see the problem.
    
         -David
    
    
    
    
    
    


Home

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