Re: iSCSI : Holes in StatSN

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

Julian,

Once the selective StatSN ACK mechanism kicks in, how is the initiator to
revert to the bulk StatSN ACK ? (i.e. when/how does an initiator realize that
the hole is filled ?) Or, does it only use selective StatSN ACK from there on
?

The difficulty lies in the fact that a hole created will never be filled
since "retry" will result in target sending back a subsequent Status PDU with
a different StatSN. However, the initiator does not know when to safely claim
that the hole is filled (by sending a bulk StatSN ACK), since there is no way
to detect this.

Regards,
Santosh

julian_satran@il.ibm.com wrote:

> I've also realized this and included a "sack" mechanism that kicks-in as
> soon as the initiator gets a hole in the status order.  ExpstatSN is still
> needed to do a low cost bulk acknowledgement.
>
> With a data sequence we may want to use a similar mechanism to ask for a
> missed data block as soon as we see one of its successors or the status.
>
> Julo
>
> Santosh Rao <santoshr@cup.hp.com> on 31/01/2001 10:30:59
>
> Please respond to Santosh Rao <santoshr@cup.hp.com>
>
> To:   ips@ece.cmu.edu (ips)
> cc:
> Subject:  iSCSI : Holes in StatSN
>
> Julian & All,
>
> The StatSN ACK is of the form "ExpStatSN acknowledges all Status
> upto the specified value", and hence, it cannot be sent until
> all prior command status' have been received.
>
> If StatSN 1 were yet to be received and StatSN 2 - 1000 were received
> thereafter, they cannot be acknowledged by the initiator since
> the current model does not allow an ExpStatSN ack of 2 - 1000,
> without also ACKing 1.
>
> Since StatSNs are assigned on a per-connection basis, this avoids
> holes in StatSN received at the initiator. [since TCP orders
> delivery to iSCSI within a connection]. However, this in itself
> is insufficient and holes can still occur in the StatSN
> sequence seen by the initiator, as explained below.
>
> Holes in StatSN sequence are seen by an initiator when
> it detects a digest error on the Status PDU
> [and discards that PDU] , thereby, dropping such
> Status'.
>
> In such cases, the ExpStatSN acknowledgement is not straight
> forward at the initiator and does involve some complexity to
> keep track of possible holes in StatSN. Further, such holes
> may never be filled, since the "retry" command only uses the
> same CmdSN while the target sends its response on a different
> StatSN.
>
> In the presence of StatSN holes, [and given the current model
> of ExpStatSN], initiators will need to score-board received
> StatSNs prior to sending ExpStatSN acknowledgements.
>
> A selective StatSN ack (i.e. ExpStatSN ACKs the specified StatSN)
> is simpler to implement on the initiator side and allows for
> quicker de-alloc of resources at the target end.
> This could be considered as either a replacement for the existing
> ExpStatSN model, or as a complement to it. (possibly indicated
> by a SACK bit in the outbound PDUs containing the ExpStatSN).
>
> Regards,
> Santosh
>
> ps :
> There is an earlier thread that dates 10/26/00
> and is titled "Re: iSCSI Error Recovery", which proposed StatSN per
> connection as a solution to this problem, but the problem does not
> go away with just setting StatSNs per connection, since holes still
> occur on digest errors.
>
> --
> #################################
> Santosh Rao
> Software Design Engineer,
> HP, Cupertino.
> email : santoshr@cup.hp.com
> Phone : 408-447-3751
> #################################
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