Re: iSCSI: Question on StatRN usage

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

Julian,

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

I didn't realize that (what FC calls as) data overlay is allowed, FCP 
requires this initiator capability to be explicitly stated in session 
establishment (process login).  Is there a particular reason why this 
is chosen to be allowed by default in iSCSI? 

Given that the physical number of bytes transferred could be more (data 
overlay case) or less (command retry case), may I suggest that the discussion
about Residual under/overflow (section 3.3.1) and Residual Count (section
3.3.2) make it explicitly clear that it's the status of "logical" # of 
bytes that is being reported?  That way, initiator implementations can
always rely on those fields regardless of the history of the task.

I assume you took note of my comments on the need to change wording and 
payload definition of NOP PDU.

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


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