Re: iSCSI : More problems with Status SNACK !

[julian_satran@il.ibm.com]

IF StatSN is going to become optional a negative response to SNACK while
keeping up counters for compliance
could be a good enough solution for a good enough target.

But I am still not sure that this is the way to go.

Julo

Santosh Rao <santoshr@cup.hp.com> on 18/04/2001 00:36:21

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

To:   IPS Reflector <ips@ece.cmu.edu>
cc:
Subject:  Re: iSCSI : More problems with Status SNACK !




julian_satran@il.ibm.com wrote:
>
> 2) SNACK mechanism cannot be relied upon for resource cleanup for the
> following reasons :
>
> a) SNACK support MUST be mandatory at the target and target can NEVER
> fail a Status SNACK.
> b) Initiators MUST always use a Status SNACK and this is not possible on
> a UP timeout. IOW, there exist I/O timeout and other circumstances when
> the initiator gives up and does not attempt SACK (suppose SACK itself
> got a digest error at the target and timed out at the initiator !).
>
> Since the current SNACK model is heavily dependent on the above
> assumptions [which canot be met], failure of SNACK blocks further
> forward progress with resource cleanup at the target since all further
> I/O completions beyond the hole StatSN cannot be acknowledged.
>
> In the worst case, any I/O timeout would imply session level error
> recovery since the target will no longer be able to relaim resources.
>
> +++ any UL timeout must include an abort for the task to clean up the
> target++

Julian,

The Abort Task sent by initiator on the ULP timeouts cleans up resources
for that specific task.

The issue under debate was that the spec does not have a mechanism by
which, once a hole is created, [which cannot be filled by the Status
SNACK,] the initiator can switch back to bulk acknowledgements. i.e.
while the timed out I/O resources may be released thru the Abort Task,
the remaining tasks completed thereafter are unable to be acknowledged
by the initiator.

>
> Proposal :
> ==========
> 1) Negotiate Status SACK support at login time.
> 2) Do not use StatSN when Status SACK is not supported.
> 3) Modify the current SNACK PDU to eliminate "Additional run Length"
> (which is of no practical use currently) and replace with an explicit
> positive ack run described by ack_begrun and ack_run_length.
>
> Comments ?
> +++ I am basically against options - If I can avoid them.
> I don't see how an optional SNACK and STatSN would simplify a
> target/initiator
> while still allowing command recovery without popping errors into SCSI+++

If a target does not support Status SNACK, then, such a target is
effectively releasing its I/O resources upon completion. This implies
that the target is neither capable of supporting SNACK nor the "retry"
(or replay) concept.

In such cases, command recovery may occur at the SCSI layer or iSCSI may
retry the task at its layer. For such simple implementations that don't
resort to complex status recovery techniques, StatSN has no value add
and only creates complexity by potential holes.

Of course, any such implementation may typically ignore ExpStatSN and
continue to release resources as the I/Os complete with a StatSN being
initialized only for compliance. Rather than have such a behaviour, the
spec should allow for these implementations by letting them use StatSN
of 0 as a don't care.

- Santosh
 - santoshr.vcf