SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: more on StatRN



    Costa,
    
    Although I had suggested a keep-alive recommendation several months ago,
    depending on the OS to detect TCP failure is not likely to provide timely
    detection.  Perhaps 3 lost echoes if no communication at 10 second intervals
    would establish a 40 second fail/recovery period.  A justification for
    statRN would be with respect to recovery on a different connection.  iSCSI
    transport layer on top of a TCP transport layer to support the SCSI
    transport layer.  (How does iSCSI work on a single connection without a
    command numbering?)  This iSCSI transport depends on command, data, and
    response numbering.  The difficult aspect of recovery is created with an
    command, data and response allegiance requirement on adapters.  Can a failed
    portion of a connection recover over a different adapter and thus violate
    adapter allegiance?
    
    Doug
    
    
    > > While I know the values for certain operating systems, I would
    > like to hear
    > > from
    > > people who can assert confidently that the TCP fail connection
    > time < SCSI
    > > command failure time.
    >
    > Prasenjit,
    >
    > You bring up a good point.
    >
    > However, iSCSI is the master of the TCP stack; it can abort the TCP
    > connection at any time for any reason. It doesn't need to wait for
    > TCP to fail; iSCSI can timeout and close the TCP connection.
    >
    > The question becomes then: what performance on the TCP virtual circuit
    > is so unacceptable that iSCSI should tear down the TCP connection
    > and try to establish a new one?
    >
    > As such, I don't believe the TCP-iSCSI interface has any effect on
    > the motivation for statRNs.
    >
    > -Costa
    >
    
    


Home

Last updated: Tue Sep 04 01:06:36 2001
6315 messages in chronological order