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

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

Julian,

I am attempting to provide a name for a function within iSCSI.  iSCSI
requires sequential ordering of commands with the exception of those
commands indicated with zero or null serialization.  This server function is
being described as a PDU sequencer.  If a CmdSN is assigned to a command
that bypasses the sequencer using a flag rather than a null sequence, then
the function of the sequencer will either need to create a list to ensure
these commands are not waited for at a later time or reject all pending
commands to move the valid CmdSN window up to this bypassing command.

The rejection scheme does modify some initiator behavior but provides
greater control during an error.  The major concept is invalidating a
sequence range.  The reject status should include both a copy of the
ExpCmdSN at the point in time of the reject process together with the new
ExpCmdSN and bypass mode as a reason to allow this list to be determined.
These sequences are thus retired and, as such, a new CmdSN will need to be
assigned to reissue these rejected commands.  Limiting this bypass mode to a
single unacknowledged command is not desirable if more than one command is
required.

The advantage for rejection would be:
  1) No need to list any sequencer bypasses.
  2) Immediate opening of the window for urgent commands.
  3) Quick repairs for a connection problem avoiding timeouts.
  4) Immediate acknowledgement for all commands sent to the target.
  5) No need to trap iSCSI errors within the SCSI layer.

The advantage for using a flag would be:
  1) No late inadvertent applications due to null serialization.
  2) Acknowledgement of this critical function.
  3) Flow control still desired for deploying critical commands.

Doug

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