Re: iSCSI ERT: data SACK/replay buffer/"semi-transport"

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

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


julian_satran@il.ibm.com wrote:
> 
> Santosh,
> 
> I have to think about it a bit more.  The main ack mechanism is ExpStatSN
> (as I indicated in a previous note).  SNACk is meant to simplify recovering
> holes without having to reissue commands or wait for timeout. Rejecing
> SNACK with an "unsupported" indication but resending the status on command
> retry can hardly be considered a good alternative while rejecting SNACK
> with "no status to recover" has to be bubbled up to SCSI and that can be
> bad for tapes.
> I think that if you keep status until ack-ed SNACK makes only life easier
> as it makes the recovery request explicit an specific - unlike the command
> retry that is vague and unspecific.
> 
> Julo
> 
> Santosh Rao <santoshr@cup.hp.com> on 06/04/2001 20:26:47
> 
> Please respond to Santosh Rao <santoshr@cup.hp.com>
> 
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   santoshr@cup.hp.com, David Black <Black_David@emc.com>
> Subject:  Re: iSCSI ERT: data SACK/replay buffer/"semi-transport"
> 
> Julian,
> 
> I did not hear back on this and am re-sending in case you did not
> receive the same. Your comments would be appreciated.
> 
> (Can you clarify if you intend to make the current SNACK mechanism
> optional and if so, how it is expected to solve the "holes in StatSN"
> problem for targets that don't implement StatSN SNACK ?)
> 
> Regards,
> Santosh
> 
> -------------------------------------------------------------------------------------
> 
> Subject:  Re: iSCSI ERT: data SACK/replay buffer/"semi-transport"
> Date:     Thu, 05 Apr 2001 19:22:09 -0700
> From:     Santosh Rao <santoshr@cup.hp.com>
> Organization: Hewlett Packard, Cupertino.
> To:       julian_satran@il.ibm.com
> CC:       ips@ece.cmu.edu
> 
> julian_satran@il.ibm.com wrote:
> >
> > Santosh,
> >
> > SNACK and SACK are the same thing (I just renamed them to avoid confusion
> > with TCP SACK).
> > The status is acked by ExpStatSN (and only indirectly by SNACK). SNACK
> > enables fast recovery of
> > a hole (whithout having to resort to a timeout).
> 
> Julian,
> 
> The bottom line is that the current SNACK mechanism as defined in the
> spec will NOT work if it is made optional, and at the same time, it is
> too expensive to mandate the SNACK mechanism.
> 
> The current SNACK mechanism is really a negative ACK requesting the
> target to re-send the status PDU. This mechanism has 2 dis-advantages :
> 
> a) requires targets to retain I/O state information until StatSN is
> acknowledged.
> b) Does not allow forward progress with the release of I/O resources in
> the event that a target could not retain that state information or for
> some other reason could not service the SNACK.
> 
> I am suggesting that the alternate model of SACK be used, wherein, a
> SACK is an individual ACK of a received status PDU. This SACK only kicks
> in on detection of a hole. The hole is implicitly plugged by the
> initiator on eventual completion of the command
> [on timeout followed by abort or retry].
> 
> The advantage of this alternate model is :
> a) Does not require state information to be stored at targets beyond I/O
> completion.
> b) Allows a more reliable mechanism of resource release.
> 
> The dis-advantage of this mechanism is :
> a) It results in I/O timeout when Status PDU was dropped due to a digest
> error.
> 
> Once again, the question boils down to the rate of TCP checksum escapes
> and the probability of such escapes affecting status PDUs. If this is
> low enough, such a timeout on a digest error of a status PDU should be
> acceptable.
> 
> >  We decided long ago
> > against individual acks as bulk acking through a window is cheaper and
> > safer (repetition).
> 
> I am not suggesting removal of bulk ack scheme. My suggestion is that
> SACK kick in on a hole and the initiator revert to bulk ACK scheme once
> it considers the hole to be plugged (thru the eventual completion of the
> I/O on the timeout path followed by abort or retry).
> 
> - Santosh
>  - santoshr.vcf
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