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



    Hi John,
    
    >I could be mistaken here but I think you, and some others have been
    >addressing issues with the Storage Controller having the right amount of
    >buffer space in the controllers for the commands, after they are delivered
    >by iSCSI.  I think this is a SCSI issue and not a iSCSI/TCP flow control
    >problem.
    
    Yes, you are right that this is precisely the problem I'm addressing.  Maybe
    I'm missing something here, but I still think there is an issue.  Yes,
    as James described earlier SCSI has a mechanism for dealing with this, but
    is it sufficient for iSCSI/TCP?  IP has distinctly different characteristics
    than parallel SCSI and FC.  
    
    For one thing, latencies in the IP world are much higher.  I'm assuming
    parallel
    SCSI latencies are next to nothing, while FC are in the <10us range.  If
    iSCSI is going over the WAN, at least 50ms latencies are to be expected for
    coast-to-coast US.  Over the Public Internet, we're talking about 80 to
    250ms
    or even more (RT).  Much of this latency is caused by the speed of light,
    the rest
    by the serialization process for WAN transport.  This works out to be
    a huge amount of latency compared to FC.  How much can happen in the 30ms
    before
    the SCSI QUEUE FULL and BUSY messages finally get back to the initiator.
    Are you
    sure leaving it to SCSI or TCP will be okay?
    
    >With respect to the Asymmetric approach,  the issues change, and we are no
    >longer trying to solve the problem of missing commands that occur  because
    >of a broken connection.  Therefore, I think we can dump the sliding window
    >and leave the flow control -- and recovery  of lost commands,  --  up to
    >TCP.  Yes, the SCSI layers on each end need to have their own buffer
    >management under control, but I do not think this is a transport issue.
    
    I agree dumping the sliding window is a good thing.  But my question is
    should
    iSCSI replace it with something else.  I believe the issue James brought up
    with
    multiple initiators needs to be considered.  Or even with a single
    initiator,
    how do you flow control the oncoming commands from the initiator(s)?  Is the
    SCSI mechanisms sufficient given the latencies that iSCSI must be designed
    to support?
    
    BTW, I don't think that TCP has any role in addressing this issue.  If iSCSI
    and
    TCP operate independently at different layers, then TCP won't flow control
    iSCSI commands any more than it flow controls any other PDU's, because it
    can't
    tell the difference between them.
    
    Josh
    
    


Home

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