Re: StatSn Questions

[julian_satran@il.ibm.com]

Mallikarjun,

Responses in text.

Julo

"Mallikarjun C." <cbm@rose.hp.com> on 09/03/2001 21:02:50

Please respond to cbm@rose.hp.com

To:   ips@ece.cmu.edu
cc:
Subject:  Re: StatSn Questions




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.

+++ You are right - the reason I left StatSN out is that the Data PDU may
originate close to the device where you don't know about StatRN +++

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!

+++ Matt is right - I've added a heading with the explanation on StatSN to
R2T +++
--
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
>>
>
>