Re: StatSn Questions

[Matt Wakeley <matt_wakeley@agilent.com>]

Hi Kevin,

The intent (I believe) is that all target-to-initiator messages will convey
the current StatSN.  That way, if the "status" message that contained the
StatSN was discarded due to header digest error, the initiator would know
about it when the next PDU was received, and could then perform error recovery
(if possible).

In the SCSI Task Response, Text Response and NOP-In PDUs,- StatSN has the same
meaning as SCSI Response (StatSN is incremented before PDU is sent).  In Data
and R2T, it just transfers the previous value (except if Data is the last Data
and conveys status).

-Matt



"LEMAY,KEVIN (A-Roseville,ex1)" wrote:
> 
> The iSCSI spec implies that the StatSn handshake is supposed to be for
> command responses, but all target PDUs except Login response, logout
> response and reject contain StatSn. The asynchronous message has a comment
> that it is a acknowledgeable event. For what purpose is StatSn on the other
> PDUs and how is it used?
> 
> Julian answered a question earlier about how to handle holes in the StatSn,
> but what about the case where the header is corrupted. It would be
> impossible to determine which command to retry.
> 
> Additionally, any responses that may be discarded while we attempt to resync
> the iSCSI headers via markers would require to be retied also. Will the spec
> be changed to address the appropriate way to handle these cases?
> 
> The cases shown in appendix B the command complete with the reception of the
> command response from the target. In reality, the command is not complete
> until the incremented ExpStatSn is received at the target.
> 
> Kevin Lemay
>