Re: Target Reset handling

[Stephen Bailey <steph@cs.uchicago.edu>]

> Is the C bit hidden in the CDB? We as a rule avoided examining the CDB
> (iSCSI never has to). If we can make it external then we are in wild
> agreement.

Clearly all these resets are forms of SCSI Task management, and unlike
FCP (and SST, in its imitation of FCP), iSCSI doesn't use the same PDU
for task management and command delivery.  Therefore, there's no CDB
involved in the reset process at all.  The big hammer (reset the
transport as well as the SCSI target) and little hammer (just reset
the SCSI target, or SCSI LUN) resets are just different task
management functions.  This seems to call for different task
management Function code, not a modifier bit.

Historically, having a big hammer reset is critical to making early
configurations work.  Realistically, the first iSCSI implementations
are going to range from broke to horribly broke.  ||SCSI and FCP had
the same problem (is it over yet?).  Both ||SCSI and FCP further
benefitted from a side-band reset signal (the reset LIPs in FCP on
FC-AL).  This was important in FCP because frequently targets (never
those fair-haired, golden child, initiators, of course) would become
stuck to the point where no credit would flow back to the initiator
with which to send an in-band reset request.  I've heard similar
stories from old line ||SCSI implementors.

The side-band reset is usually detected by the interface hardware,
which will pull a real hardware reset for the target.  This capability
is gone (without replacement, as far as I know) in FCP on fabric, but
by that time, the target logic had been pretty well shaken out under
FC-AL.  Implementation rules like `ya gotta empty your queues come
hell or high water' had mostly been successfully implemented by that
point.

The big hammer reset mechanisms were the difference between success
and failure in our early FCP deployments, and I believe that
they can still make the difference between a robust implementation and
a frail one.

I can't imagine a side-band reset mechanism for iSCSI (give it some
thought), but in lieu of that, a big hammer in-band reset should be
there.

On the subject of HOW transport connections are closed on a Target
Reset, note that FCP and iSCSI (and SST) necessarily diverge.  In FCP,
when a PDU is received outside of a connection, the end-point is
supposed to initiate the disconnect (logout) protocol.  That way, when
an end-point loses its mind (or is simply power cycled), and resets,
the far endpoint gets immediate feedback that this has happened.

TCP and ST define that anything received outside a valid connection
simply gets chucked (this is necessary for antialiasing to work).  On
a large network it can be a long time before a connection is closed as
a result of a simple timeout (as in, Web site found, waiting for
reply...).  Therefore, SST (and iSCSI, as far as I understand the
current draft) requires that an end-point always attempt the
connection close message protocol (with appropriate timeouts and
retries), before declaring the connection closed.  In the `common'
case, this gives zippy recovery of connection resources and
notification to the far endpoint.  In the worst case (e.g. target's
transmitter engine is stuck or power cycle), it all works out
eventually.  You can't do any better than that.

The ACK for a big hammer reset is the closing of the transport
connection.  Again, this can come as a result of a successful close
handshake or a timeout.

The current iSCSI draft seems to indicate that Target Reset is
transport and SCSI layer (big hammer) reset, and LUN reset is only a
SCSI layer reset.  That works for me.  On the other hand, if you want
to add an addition Target Reset (w/o transport reset) task management
function, knock yourself out.

Steph