|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: more on StatRNCosta, 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 |