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



    John,
    
    "A lot of data" is relative.  The fastest TCP implementations available
    today
    don't come close to what will be required for iSCSI, since they peak out
    at about 200Mbps.  And the vast majority of applications are get much worse
    performance than that out of TCP--I would guess typically about 20Mbps max.
    
    iSCSI will use TCP like never before.  I believe FCP has flow control/
    command recovery mechanisms below SCSI.  Unlike iSCSI, FCP has the benefit
    of
    operating in a low latency environment (<10us).  To think iSCSI can do
    without
    it and still be able to function reliably is, well iffy at best from what I
    can 
    see.
    
    Regads,
    
    Josh
    
    -----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.
    
    .
    .
    .
    John L. Hufferd
    
    
    Joshua Tseng <jtseng@NishanSystems.com>@ece.cmu.edu on 09/08/2000 08:53:48
    PM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   John Hufferd/San Jose/IBM@IBMUS, Joshua Tseng
          <jtseng@NishanSystems.com>, Charles Monia <cmonia@NishanSystems.com>
    cc:   ips@ece.cmu.edu
    Subject:  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:26 2001
6315 messages in chronological order