Re: StatSn Questions

["Mallikarjun C." <cbm@rose.hp.com>]

Matt and Julian,

>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).  

OK.

>In Data
>and R2T, it just transfers the previous value (except if Data is the last Data
>and conveys status).

StatSN in a read data PDU is *not* the previous value.  Instead, it is a 
new (incremented) value and the field is valid only if the S-bit is set.

I hope Matt's interpretation of StatSN in R2T is correct - Julian, could
you please add text explaining it?  Also, please rename it as "Current 
StatSN"/"Running DataSN" (along those lines, since it is quoting a previous 
value) than a simple "StatSN" (which to me implies a unique StatSN assigned 
to this PDU).  From the current names, I was inclined to think that the 
R2T PDU has two sequence numbers!
--
Mallikarjun 


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
cbm@rose.hp.com


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