RE: iSCSI: more on StatRN

["Douglas Otis" <dotis@sanlight.net>]

Julo,

Except from iSCSI spec.
"The recovery involves the following steps:
 -abort offending TCP connection(s) (target & initiator) and
   recover at target all unacknowledged read-data
 -create one or more new TCP connections (within the same ses-
   sion) and associate all outstanding commands from the failed
   connection to the new connection at both initiator and target.
 -the initiator will reissue all outstanding commands with their
  original Initiator Task Tag and their original CmdRN if they
  are not acknowledged yet or a new CmdRN if they where ack-
  nowledged; in any case the retry (X) flag in the command PDU
  will be set
 -upon receiving the new/retry commands the target will resume
  command execution; for write commands it means requesting data
  retransmission through RTT, for reads retransmitting recovered
  data and for "terminated" commands retransmitting the status &
  sense while retaining the original StatRN. If data recovery is
  not possible the target will either provide data from the
  media or redo the operation (if the operation is not idempo-
  tent the device server may fail the operation)."

Reliance on a replay of the initiator tag to re-establish original status
and sense does not explain if adapter allegiance is handled.  Also without
CmdRN, how is communication buffer closing prevented especially on a single
connection?  By depending on the OS to detect the TCP failure, there is no
deterministic timeouts at the target for the nebulous term "short time".

Doug

>
> 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
> >
>
>
>
>