Re: iSCSI: draft04 questions

[julian_satran@il.ibm.com]

Mallikarjun,

Answers in text ...

Thanks,
Julo

"Mallikarjun C." <cbm@rose.hp.com> on 01/03/2001 21:02:14

Please respond to cbm@rose.hp.com

To:   ips@ece.cmu.edu
cc:
Subject:  iSCSI: draft04 questions




Julian,

Thanks for incorporating a lot of the earlier reflector feedback
into the latest draft.

Some questions:

1. Section 1.2.5 states :
     "Unsolicited data MUST be sent on every connection in the
     same order in which commands were sent. If the amount of data
     exceeds the amount allowed for unsolicited write data, the
     specific connection MUST be stalled - i.e., no more unsolicited
     data will be sent on this connection until the specific command
     has finished sending all its data and has received a response."

Sorry if there was a discussion on this already.  Why not the iSCSI
response of "Unsolicited data rejected" usable for this case?  Initiator
appears to be behaving erratically, and I don't see how it is expected
to adhere to the stipulation that it shall not send anymore unsolicited
data till this command is completed.

++++ This is a leftover from an older scheme (very old) thanks +++

2. I didn't find a way for an iSCSI target to say that it does not support
any unsolicited data at all.  SPC-2 specifies that a zero FirstBurstSize
means unlimited.

+++ UseR2T=yes (default) and ImmediateData=no +++

3. Section 2.14 states:
     "If an initiator intends to start recovery for a failing connection it
     MUST use the either the Logout command to "clean-up" the target end
     of a failing connection and enable recovery to start, or use the
     restart option of the Login command to the same effect."
This seems to be contradicting section 2.10.1, where a prior logout of the
CID is stated as a requirement for using the restart bit of the Login PDU
(which I agree with).
+++ It is a colapse of a logout-login for those cases in which a new
connection is oppened _ and the target allows only one connection! It
allows the target to do the logout function then follow with the login +++

4. Somehow, "Asynchronous Message" seems at odds with the rest of the
usage in the draft in regards to PDUs (since a message is introduced as
PDU in section 1.2).  Should we may be just call it an AEN PDU?  Section
2.14.3 calls this so.  (I realize that it may not always result in a
SCSI-level AER.)

+++ Fixed 2.14.3 - vox populi in Orlando not to create confusion -:) +++

5. In the same section 2.18, I dont' quite see the operational difference
for an initiator, if any, between iSCSI event codes 2 & 3.  Could you
please
comment?
+++ 2 is for the purists - message,logout,login, 3 indicates that the
target will disconnectd the named connection +++
Also, isn't the time in seconds the maximum time than the minimum
time as currently stated?
+++ time is minimum - allows the target to do the cleanup before being hit
with a
login +++
6. In section 2.20.1, reject reason code 5 is stated as a "command
restart reject".  Seems like the usage of "restart" in the draft elsewhere
is for the connection/session login, and "retry" is for commands -
except this one.  Comment if I am reading too much into the usage.
+++ i'll make it retry +++
7. Section 6.2 on digest errors states:
     "If the error is a Data-Digest-Error in a Data-PDU, the target
     MUST either request retransmission with a R2T or answer with
     a Reject iSCSI PDU and abort the task."
Were you meaning the target's internal termination of the task? That
could cause problems on a subsequent Data PDU reception from the
initiator since there may be no state for the task in the target.
Suggest dropping "and abort the task".

+++For this reason 2.4.2 delays the bad status and I have already added a
similar statement in 6.2+++

8. Same section states the following:
     "When an initiator receives an iSCSI data PDU with a Data-Digest
     error, it must discard the PDU and it MUST either request the missing
     data PDUs through SACK or terminate the command with an error."
If you meant reporting a service failure to SCSI within the initiator,
seems like that could cause trouble to initiator iSCSI layer since it
is likely to receive the data/status PDUs for the command shortly
thereafter.
Suggest dropping "or terminate the command with an error", or replace
with "or abort the task".
+++ fixed +++
9. End of section 6.7.1 states:
     "An iSCSI target MAY reject a data-SACK and terminate the command with
     an iSCSI error response of SACK rejected."

The "SACK rejected" iSCSI response code needs to be added in section 2.4.2.

+++ will fix +++
Thanks.
--
Mallikarjun


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668   Hewlett-Packard, Roseville.
cbm@rose.hp.com