iSCSI & Linked Commands

[julian_satran@il.ibm.com]

Santosh,

Sorry to interrupt this captivating thread. Why do you think linked
commands won't work?

Julo

Santosh Rao <santoshr@cup.hp.com> on 16/04/2001 20:13:04

Please respond to Santosh Rao <santoshr@cup.hp.com>

To:   Douglas Otis <dotis@sanlight.net>
cc:   Ips <ips@ece.cmu.edu>
Subject:  Re: iSCSI:flow control, acknowledgement, and a deterministic
      recovery




Doug,

You seem to be referring to linked commands as a case wherein the
approach of Abort Task will not flush stale PDUs.

Linked Commands cannot work the way SCSI implementations are defined
today, since linked commands require the initiator task tag (I_T_L_x
nexus identifier in SAM-2 Execute Command terminology) to be generated
by the SCSI ULP. However, in practice, the Initiator Task Tag (or the FC
OX_ID) is typically generated in the SCSI LLP (or in some cases in the
adapter firmware). IOW, there is no common reference handle like the
task tag sent down from the ULP that allows for association of multiple
commands to a task in several/most implementations today.

When this is fixed up to get linked commands to work [& there exist
examples of its usage], there is no reason connection allegiance could
not be applied to all the commands within the task.

I fail to see why you think Abort Task will not work with sequential
devices (?).

- Santosh



Douglas Otis wrote:
>
> Santosh,
>
> I see a few problems with this approach.  Tasks as defined in iSCSI do
not
> maintain connection allegiance.  The driver binds all SCSI commands to
their
> connection for the most resent association.  Although there are several
> places within the iSCSI proposal that make reference to a task having a
> connection allegiance, this is in error.  Commands and not tasks carry
such
> allegiance.  Your recovery scheme will not allow a satisfactory recovery
> with a sequential device.  In this case, repeating the command is not a
> solution.  As a result, one connection falter and it will become a
difficult
> situation.  In addition, you have no clue from iSCSI your delivery
status.
> You do not know if you are waiting for the target or if you are waiting
for
> the connection.  Some sequential devices have rather long time-outs with
> these complications of deducing status created by the multiple
connections.
>
> The application will not know about these connection allegiance problems.
> The iSCSI layer does not define interaction to provide additional
> application status to allow these applications to respond in a manner
that
> may aid this situation nor should such additional information be
required.
> With your scheme the SCSI driver must examine the content of these
commands
> to make a guess as to the connection allegiance assignments.  Now the
driver
> is expected to understand what the intended action is of this SCSI
> management command.  What signal is used to indicate a need for the iSCSI
> immediate treatment?  The only obvious seems to be the task attribute
> argument.  With the way iSCSI has defined iSCSI immediate, I would expect
> those commands to be treated in a LIFO rather than the normal FIFO
fashion.
>
> Doug
>
> > Douglas Otis wrote:
> > >
> > > With multiple connections, if you are not going to use a valid
> > > CmdSN, or in your case a null CmdSN for all commands, then there
> > > would be a need to include a timestamp to meet a timely delivery
> > > requirement in the same manner as used in FC encapsulation.  IP
> > > can deliver over any time period.  A command could arrive at any
> > > time with respect to other connections.  With all of your feedback
> > > now from just the SCSI layer, the SCSI layer is likely to have timed
> > > out and restarted and now stray commands finally make an appearance
> > > (the technician re-inserted the cable).  What did that do?  Yes,
> > > if this were on a single connection, then TCP could provide some
> > > assurances, (ignoring digests errors) but you must not make that
> > > assumption nor can you assume all disruptions are symmetric.
> >
> > Doug,
> >
> > The below snippet from my last mail answered your above concern. The
> > Abort Task is sent on the same connection as the command. (connection
> > allegiance applied to the abort task as well). The Abort task pushes
the
> > stale data PDUs. There is no need for a timestamp on iSCSI PDUs.
> >
> > > > As for your second concern regarding I/O timeouts, there is
> > no need for
> > > > any timestamp. An I/O timeout is dealt with by an Abort Task.
> > The abort
> > > > task response guarantees that the abort reached the target and
pushed
> > > > all intermediate stale frames. Failure to complete Abort Task leads
to
> > > > higher level error recovery (ex : Logout, or some higher form of
task
> > > > mgmt).
> >
> > - Santosh
 - santoshr.vcf