Subject: Re: StatSn Questions

From: [email-masked]
Date: Sat, 10 Mar 2001 17:52:48 +0200

Mallikarjun,

Responses in text.

Julo

"Mallikarjun C." <[email-masked]> on 09/03/2001 21:02:50

Please respond to [email-masked]

To:   [email-masked]
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.
[email-masked]

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

---

From: Matt Wakeley <[email-masked]>
Date: Sun, 11 Mar 2001 00:44:21 -0800

> originate close to the device where you don't know about StatRN +++

I don't understand the above statement.  The device is supposed to communicate
through iSCSI, and iSCSI always knows what the StatSN is (not the device). 
Therefore, if the "S" bit is not set in a data PDU, then the StatSN conveys
the current value.  If "S" is set, then StatSN conveys the new value.

-Matt Wakeley
Agilent Technologies