Re: iSCSI: Immediate Delivery Behavior

[julian_satran@il.ibm.com]

Charles,

There is an explicit statement that iSCSI uses TCP and this implies that on
any given connection nothing can be delivered out of order.

However if there is a hole in the iSCSI queue (e.g., due to a digest error)
immediate commands can still be delivered out of order.

In 7.3 there is description of how to handle task management to cover for
those cases.

Regards,
Julo

Charles Monia <cmonia@NishanSystems.com> on 25/04/2001 01:23:17

Please respond to Charles Monia <cmonia@NishanSystems.com>

To:   "Ips (E-mail)" <ips@ece.cmu.edu>
cc:   Charles Monia <cmonia@NishanSystems.com>
Subject:  iSCSI: Immediate Delivery Behavior




Hi:

The behavior for immediate commands seems ambiguous and possibly needlessly
complex.

Rev 06 says the following regarding ordered delivery to the SCSI layer:

   "Except for the commands marked for immediate delivery the iSCSI
   target layer MUST deliver the commands to the SCSI target layer in
   the order specified by CmdSN. Commands marked for immediate delivery
   may be handed over by the iSCSI target layer to the SCSI target layer
   as soon as detected. iSCSI may avoid delivering some command to the
   SCSI layer if so required by some prior SCSI or iSCSI action (e.g.,
   clear task set Task Management request received before all the
   commands it was supposed to act on)."

In a non-striped session consisting of one TCP/IP connection, the above
could be interpreted to allow the delivery of an immediate command before
other partly received commands that were previously issued. As a result, an
operation, such as an abort task, might bypass the command to be aborted --
even if both were sent on the same connection.

Assuming that's true, I believe a useful simplification is to require that
all traffic flowing over a given TCP/IP connection be delivered to the SCSI
layer in the order received over that connection.  In a striped session, an
immediate command might therefore leapfrog commands on other connections
but
would never bypass commands on the same connection.  In my opinion, that
simplifies the problem of properly purging commands and stale PDUs in the
wake of a task management operation.

Charles
Charles Monia
Senior Technology Consultant
Nishan Systems
email: cmonia@nishansystems.com
voice: (408) 519-3986
fax:   (408) 435-8385