iSCSI : More problems with Status SNACK !

[Santosh Rao <santoshr@cup.hp.com>]

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.

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.

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 ?

- 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
begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard