Re: iSCSI: Question on StatRN usage

[julian_satran@il.ibm.com]

Mallikarjun and Prasanjit,

Sorry for the confusion.

The text is confusing and I have corrected it the new text. StatRN is
mandatory (it is the only way we have to ACK status and is not related to
ordering).

As for the data the intent was to use StatRN to just number data packets
for a given command (start with whatever you want) and have them acked with
a NOP with the same task tag (this is important for input data for which we
have no other way of acking them). Those numbers are not related to the
Status numbers. No ordering or recovery is required up to command restart.
I assume that numbers will not wrap unless a target sends more blocks than
bytes (and it can!) but even then
no harm is done.
At recovery the restarted command will be followed by a NOP with the same
initiator tag indicating what is the
the block expected. The initiator does not have to do any scoreboardong
only keep the counters.
The target can free early resources and iSCSI can recover eve long reads.
For writes evidently R2T does the job but it means that write data can be
recovered only with R2T.
Should we overload on CmdRN/ExpCmdRN to shorten recovery? I don't see a
need.

Julo

"Mallikarjun C." <cbm@rose.hp.com> on 18/10/2000 19:35:29

Please respond to cbm@rose.hp.com

To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI: Question on StatRN usage




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