RE: iSCSI: more on StatRN

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

Julo,

From the iSCSI specification:
"3.10.5.  Packet numbering (CmdRN and StatRN)

     On both inbound and outbound data the source may decide to number
     (sequence) the data packets to enable shorter recovery on connec-
     tion failure.  In case the source numbers data packets the destina-
     tion is required to acknowledge them the same way it does with com-
     mand and status packets - i.e. specifying the next expected packet."

Perhaps in your description of connection recovery, you could add as an
alternative to re-play of commands with a retry flag, as sending ExpStatRN
within a NOP PDU.  This would allow sending missing status picking up from
where the connection was lost.  For commands still without a response, a
command re-play would then be made as it could be assumed these commands
were never delivered or are still pending completion.

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