RE: iSCSI: more on StatRN

[julian_satran@il.ibm.com]

Recovery does not depend on numbering. This should be clear even from the
current draft if you care
to read it.

Julo

"Douglas Otis" <dotis@sanlight.net> on 23/10/2000 20:20:48

Please respond to "Douglas Otis" <dotis@sanlight.net>

To:   csapuntz@cisco.com, Prasenjit Sarkar/Almaden/IBM@IBMUS
cc:   ips@ece.cmu.edu
Subject:  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
>