Subject: Re: StatSn Questions

From: "Mallikarjun C." <[email-masked]>
Date: Fri, 09 Mar 2001 11:02:50 PST

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.
[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: [email-masked]
Date: Sun, 11 Mar 2001 13:35:24 +0200

Matt,

There are different ways to implement and use iSCSI.  If the iSCSI target
is only a "front" for a collection of
boxes - it will be  good served if the data traffic can go almost unchanged
from the LU to the initiator (even

True we loose a chance to update the StatSN.

I am ambivalent also about R2T.

Basically the same argument can be made about it and we should remove all
the counters.

Nevertheless let's hear what others have to say on this too.

regards,
Julo

Matt Wakeley <[email-masked]> on 11/03/2001 10:44:21

Please respond to Matt Wakeley <[email-masked]>

To:   [email-masked]
cc:
Subject:  Re: StatSn Questions

[email-masked] wrote:

> >In Data
> >and R2T, it just transfers the previous value (except if Data is the
last
> Data
> +++ 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 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