Subject: Re: iSCSI : Holes in StatSN

From: Santosh Rao <[email-masked]>
Date: Thu, 01 Feb 2001 10:51:35 -0800

[email-masked] wrote:

> The sack will specify a range to be filled. The initiator will revert to
> bulk as soon as it has no holes.

Julian,

Once a StatSN hole is created, it is never filled. [since subsequent "retry"
of the command results in a different StatSN being used.]. However, there is
currently no association available to determine when it is safe to
acknowledge that hole [which happens when the initiator switches back to bulk
ACK scheme.]

Given the above, the initiator needs to maintain a list of Initiator Task
Tags for which StatSN holes were encountered (i.e. Status PDU was not
received). It then needs to dequeue elements from this list when the "retry"
command completes or the command is aborted. Once all elements are off this
list, it can revert to the bulk StatSN ACK mechanism.

> A target can also resend after a timeout or when seen the same StatSN on a
> NOP.

Not sure what is implied here. Surely, we are not attempting a re-transmit
functionality akin to TCP re-transmit at the iSCSI layer for Status PDUs (?)

> The initiator will query after
> a long silence with a NOP (not longer than the SCSI timeout -:))

This is intriguing. Are you suggesting that on an I/O timeout, the initiator
send a NOP-OUT to request a re-transmit of the Status PDU ? How does the
initiator know one of the Data PDUs also did not time out ?

(An I/O timeout also implies that the O.S. expects a response back without
any further time being spent on the I/O. I/O timeouts cause the initiator to
abort the I/O and error the I/O up the stack. )

Regards,
Santosh

> Santosh Rao <[email-masked]> on 01/02/2001 02:57:25
>
> Please respond to Santosh Rao <[email-masked]>
>
> To:
> cc:   [email-masked]
> Subject:  Re: iSCSI : Holes in StatSN
>
> 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
>

---

From: [email-masked]
Date: Fri, 2 Feb 2001 13:16:01 +0200

comments in text - Julo

Santosh Rao <[email-masked]> on 01/02/2001 20:51:35

To:   IPS Reflector <[email-masked]>
cc:
Subject:  Re: iSCSI : Holes in StatSN

Julian,

Once a StatSN hole is created, it is never filled. [since subsequent
"retry"
of the command results in a different StatSN being used.]. However, there
is
currently no association available to determine when it is safe to
acknowledge that hole [which happens when the initiator switches back to
bulk
ACK scheme.]

received). It then needs to dequeue elements from this list when the
"retry"

Not sure what is implied here. Surely, we are not attempting a re-transmit
functionality akin to TCP re-transmit at the iSCSI layer for Status PDUs
(?)

> a long silence with a NOP (not longer than the SCSI timeout -:))

This is intriguing. Are you suggesting that on an I/O timeout, the
initiator
send a NOP-OUT to request a re-transmit of the Status PDU ? How does the
initiator know one of the Data PDUs also did not time out ?

+++ I the status PDU (alone or with a data block) there is a the last data
block sequence number
This is how holes in data will be detected (the same as with sum of
data-lengths versus expected-residual that you are advocating)

(An I/O timeout also implies that the O.S. expects a response back without
any further time being spent on the I/O. I/O timeouts cause the initiator
to
abort the I/O and error the I/O up the stack. )

Regards,
Santosh

> that the hole is filled (by sending a bulk StatSN ACK), since there is no

 - santoshr.vcf