Re: iSCSI : More problems with Status SNACK !

[julian_satran@il.ibm.com]

Santosh,

Comments in text.

Thanks,
Julo

Santosh Rao <santoshr@cup.hp.com> on 13/04/2001 01:05:27

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

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




Julian & All,

Here are 2 more problems with the current model of Status SNACK. This
current model, IMO, is un-usable due to the reasons stated below, in
addition to reasons stated in earlier mails on this issue. iSCSI MUST
use a different Status SNACK model. See proposal below in that regard.

1)Section 2.16. S[N]ACK Request
-------------------------------
The rev 05 spec states that SACK also implicitly acknowledges data or
status PDUs.

Now, consider the following scenario :

ExpStatSN = 0
StatSNs 1 - 10 are sent from target to initiator.

-------> StatSN 1
-------> StatSN 2
-------> StatSN 4
-------> StatSN 5
-------> StatSn 6
-------> StatSN 8
-------> StatSN 9
-------> StatSN 10

If StatSn 3 & 7 are missing, the initiator would then issue status SACK
for 3 & 7. As per the above rule, SACK for 3 implicitly acknowledges 1 &
2. (ExpStatSN advances to 3). However, SACK for 7 will implicitly
acknowledge 3 - 7, whereas 3 is still a hole !

The current SNACK model MUST NOT be used as an implicit acknowledgement
since it can cause spurious free up of status resources at the target,
prior to initiator having gotten the status.

+++ Bad wording. Sorry - It reads now:

   SNACK request is used to request retransmission of status or data PDUs
   from the target.  The SNACK request indicates to the target the missed
   status or data runs, where a run is composed of an initial missed StatSN
   or DataSN and the number of additional missed Status or Data PDUs (0
   means only the initial). If a SNACK includes more than one run those
   have to be in increasing order and non-overlapping; the SNACK implicitly
   acknowledges data or status PDUs indicated by the intervals between
   runs.

   +++++


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

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

-----------------------------------------------------------------------------


Santosh Rao wrote:
>
> julian_satran@il.ibm.com wrote:
> >
> > Santosh,
> >
> > Case a is what we have today.
>
> Julian,
>
> I may be missing something, but case (a) is NOT what we have today.
> iSCSI rev 05 describes StatSN S[N]ACK support to be mandatory.
> (See http://ips.pdl.cs.cmu.edu/mail/msg04003.html for details).
>
> > Status numbering is not meant for ordering - it is only a helper for
ack
> > (bulk ack).
>
> Well understood.
>
> > All the resources required for status retransmission are the control
block
> > and the status,
> > If you give them up you give up all forms of recovery (as command retry
> > will not help either).
> >
> > The only recovery path remaining is a SCSI timeout and probably some
form
> > of task management clear (as SCSI does not know what went wrong).
>
> which is the standard SCSI recovery followed historically by most SCSI
> initiator and targets and given the TCP checksum escape rate, this is
> not an issue for disk I/O. For tape I/O, this is still under debate and
> timeout based recovery may not be optimal in some scenarios for tape.
> (not yet conclusive though).
>
> > That  is what I had in mind when I said that we can make it optional.
>
> Does "it" refer to StatSN optional or "StatSN SNACK support" ?
>
> >
> > However - a long time ago when we suggested making it optional for
targets
> > most of the list wanted it mandatory.
>
> Not sure what "it" is referring to.
>
> Are we in agreement on requirements (b) & (c) ? Can "StatSN S[N]ACK"
> support be negotiated at login time and StatSN numbering be only used if
> Status SNACK is supported by the target ?
>
> - Santosh
>
> >
> > Julo
> >
> > Santosh Rao <santoshr@cup.hp.com> on 10/04/2001 02:06:38
> >
> > Please respond to Santosh Rao <santoshr@cup.hp.com>
> >
> > To:   ips@ece.cmu.edu
> > cc:
> > Subject:  Re: iSCSI ERT: data SACK/replay buffer/"semi-transport"
> >
> > Julian & All,
> >
> > Do we agree on the following requirements for SNACK :
> >
> > a) iSCSI MUST NOT mandate either data or status S[N]ACK for intra-task
> > error recovery. Initiators MUST be allowed to perform command
> > granularity error recovery.
> >
> > b) iSCSI MUST provide a mechanism by which targets can continue with
I/O
> > resource release upon completion of an I/O. Such a mechanism may be
> > based on an explicit StatSN acknowledgement, (if the target supports
> > StatSN SNACK), or allow immiediate resource clean-up upon I/O
> > completion.
> >
> > c) Such a mechanism MUST NOT block forward progress when holes occur in
> > StatSN sequence, due to format or digest errors encountered at the
> > initiator.
> >
> > In order to meet the above requirements, "StatSN S[N]ACK" support can
be
> > negotiated at login time and if StatSN SNACK is not supported by the
> > target, it MUST NOT use StatSN sequence numbering. (i.e. StatSN = 0).
> >
> > By not using StatSN numbering, the "holes in StatSN" problem does not
> > occur, thereby, meeting requirements (a) ,(b) & (c) for targets that do
> > not retain I/O state information.
> >
> > For targets that do retain I/O state information, StatSn SNACK is
turned
> > on along with StatSN numbering.
> >
> > - Santosh
 - santoshr.vcf