Re: iSCSI : Holes in StatSN

[julian_satran@il.ibm.com]

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