Re: iSCSI: Question on StatRN usage

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

Julian,

I may be missing something here, but my question was in the context
of "overloading" of StatRN and CmdRN - ie., when they are used to 
number iSCSI data PDUs (in addition to status and command PDUs).
The draft allows it to implement effective command recovery (I should
state that I didn't really like it and questioned it in my earlier postings).
Here's the relevant excerpt from the draft:

3.10.5.  Packet numbering (CmdRN and StatRN)

     On both inbound and outbound data the source may decide to number
     (sequence) the data packets to enable shorter recovery on connec-
     tion failure.  In case the source numbers data packets the destina-
     tion is required to acknowledge them the same way it does with com-
     mand and status packets - i.e. specifying the next expected packet.


In my current posting, I am trying to point out (what I see as) a problem
in this area, and suggesting ways it can be worked around.  This is ofcourse
assuming that the future drafts would continue to allow numbering of 
iSCSI data PDUs.

Look forward to your comments.  Thanks.
--
Mallikarjun 
M/S 5601			
Networked Storage Architecture
HP Storage Organization
Hewlett-Packard, Roseville.
cbm@rose.hp.com


>Mallikarjun,
>
>StatRN implementation is MUST. Its role is to count statuses (responses)
>that where sent and allow
>bulk acknowledgement. As such I did not feel any need to place restrictions
>and 0 is a legal value.
>As the standard allows 2**32 Initiator Tags you could have 2**32 in flight
>status responses (! obviously I think it will never
>happen).  Obviously if you know that the target has N outstanding commands
>and finished commands and it gets
>from an initiator an ExpStatRN more the N distant from where it is
>something is wrong!
>
>Julo
>
>
>
>
>"Mallikarjun C." <cbm@rose.hp.com> on 18/10/2000 03:58:54
>
>Please respond to cbm@rose.hp.com
>
>To:   ips@ece.cmu.edu
>cc:
>Subject:  iSCSI: Question on StatRN usage
>
>
>
>
>Julian,
>
>Could you please comment on the following on StatRN usage?  Let me
>know if I am misinterpreting the draft.
>
>Current iSCSI draft seems to allow StatRN values from 0 through
>2**32-1.  It does not qualify the value of 0 as it does for CmdRNs.
>Assuming that 0 is legal, how would a receiving initiator distinguish
>between the target implementation that numbers (assigns StatRNs)
>read data PDUs and the one that doesn't?  A StatRN of 0 in a read data
>packet could be miscontrued and scoreboarded at the initiator, when
>all the target was saying is that it doesn't implement StatRN for
>data (assuming that 0 happens to be a legal StatRN at the moment).
>
>Options are:
>- explicitly state that StatRN value of 0 is not legal.  This is
>  simple, and my preference.  A statRN of 0 in data PDUs in this case
>  indicates non-implementation.
>- rely on a login dialogue to call out the capability.
>
>Even if we choose the first option, I propose introducing a login/text
>key request/response through which an initiator can ask a target not
>to number iSCSI data PDUs since he cannot scoreboard all the (potentially
>unlimited # per each read command) data PDUs.  Note that the converse
>case for target is not critical since target controls the write data
>transfers
>and can hope to have scoreboarding room always available.
>
>Thanks!
>--
>Mallikarjun
>M/S 5601
>Networked Storage Architecture
>HP Storage Organization
>Hewlett-Packard, Roseville.
>cbm@rose.hp.com
>
>
>
>
>