RE: iSCSI:flow control, acknowledgement, and a deterministic recovery

[julian_satran@il.ibm.com]

Doug,

I think I need a translation in plain English.

Julo

"Douglas Otis" <dotis@sanlight.net> on 08/04/2001 19:10:45

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

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI:flow control, acknowledgement, and a deterministic
      recovery




Julian,

If you do not reject commands pending within the sequencer, then you will
need to log these out of sequence events to ensure the command taken out of
sequence will not cause a hole later.  You could allow an exception for
window size but if you are attempting to issue many of these urgent
commands, then a single exception does not provide much flexibility.

Should you reject all prior commands within the sequencer, there is no
issue
regarding the logging of these out of sequence commands.  Should there be a
sequence of urgent commands, by flagging the first such command forces the
window to be cleared to allow these urgent commands their immediate
deployment.

This rejection technique also has the advantage of deleting command holes
without timeouts should there be a problem with a connection.  This
technique supplemented with SNACK appears to provide a rather immediate
recovery again without reliance on the SCSI layer.

As there should already be code ready to handle rejected commands, using
this mechanism does not add code and allows the transport to use this very
simple mechanism.  This also does not depend on the target within the SCSI
layer to handle these out of sequence events so there is less likelihood of
needing the SCSI layer tailored to use iSCSI.

While placing this immediate function into a flag ensures that such a
command is acknowledged eventually if rejection is not used and immediately
if commands are rejected, this flag however provides the vital information
of command placement to prevent such a command from applying after
subsequent commands for without this flag there is no assurance when such a
command is received.

Doug



> The main reason for selecting 0 and not a flag for immediate delivery was
> to enable immediate delivery even when the command window is closed.
>
> However we can achieve the same effect by using an immediate flag and
> ausing the current CmdSN without advancing it.  With this we get a
> reference to where in the stream the command where supposed to act if the
> stream order is important. All commands that reached the target having
> CmdSN less than the immediate CmdSN where sent before our command and all
> those with a number equal or higher where sent after. Immediate commands
> are the only ones that can have a CmdSN higher (by 1) that the allowed
> window.
>
> Julo
>
>
>