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

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

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