Re: iSCSI: Question on StatRN usage

[julian_satran@il.ibm.com]

Mallikarjun,

Thanks for your comments.

Initiator scoreboarding is not considered. I will try to emphasize this
even more in the new draft.
The party responsible for reporting length is the target.  As overlapping
ranges are not explicitly
forbidden this would be a harder task than apparent. Reporting counts
becomes entirely a question of faith!

Regards,
Julo

"Mallikarjun C." <cbm@rose.hp.com> on 20/10/2000 05:40:16

Please respond to cbm@rose.hp.com

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




Julian,

Thanks for the clarifications, I am pleased to understand that
there's no overloading of any reference #s - the usage of new
term "DataRN" in your new draft makes it a lot clearer.

Some comments.

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

Eventhough StatRN itself may not be used by an initiator for ordering
(unless it
wants to order completions, for whatever reason), StatRNs are themseleves
are in a monotonically increasing order.  It is helpful to state this
explicitly.

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

This implies that in case an iSCSI implementation is counting the # of
bytes transferred in/out during a task, it shall not assume an error if
the count is the less than expected transfer size - if the retry bit
was set (This is especially true for writes, where the initiator doesn't
know from which point target starts issuing R2Ts).  I would suggest adding
this comment as well to enable better interoperability.

>Should we overload on CmdRN/ExpCmdRN to shorten recovery? I don't see a
>need.

NO, I don't see either.  My concern was that overloading these RNs for
data would become a scalability bottleneck, when a session spans mulitple
NICs.  I am glad that it's not what was intended.

Comments on your next email:
   >The NOP message PDUs are not associated with a task, are meant for
   >immediate delivery, and their only purpose is synchronizing the
ordering
   >registers of the target and initiator.

I would like to point out that NOP PDUs are indeed associated with a task!
They are associated with a task whose read data they are ack'ing (given
that the DataRN is only task-unique).  Also, I would like to point out
that the current definition of NOP payload does not have Initiator Task Tag
- it needs to be added.

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

phone: (916) 785-5621
fax:   (916) 785-2875