Re: iSCSI: Questions For You

[julian_satran@il.ibm.com]

Howard,

Here are some answers--

On unsolicited data:

     (a) Since the iSCSI specification states that the use of R2T is
     required by default, to clarify R2T message usage we'd like to see the
     wording in the last sentence for the description of the UseR2T key in
     Appendix C changed to specifically state the following:

     Before negotiating UseR2T:no, outgoing SCSI data (either immediate
     data or data in a SCSI Data PDU) MUST NOT be sent unless solicited by
     an R2T message. After negotiating UseR2T:no, the data starting at
     offset 0 continuing for the number of bytes specified by the initial
     burst size in Mode Page 2 MUST be sent, as either immediate data, data
     in a SCSI Data PDU, or some combination thereof, without waiting for
     an R2T.  All subsequent outgoing SCSI data for the same SCSI command
     MUST be solicited by an R2T message.

     It might further clarify things to define up front that ?SCSI data?
     means ?data for SCSI commands?, vs. login parameters and other iSCSI
     data.

<JS> Will try to make the text more clear. You are right in your
assumptions.</js>

     Assuming the above is correct, this is equivalent to an implicit R2T
     being sent and received at Offset 0 for ?first burst size? bytes;
     adding this analogy might clarify the text.  Taken with the text from
     Section 2.15 (2.16 in the 12/30 draft), this implies that ?a target
     SHOULD NOT issue an R2T which overlaps with (the implied R2T
     corresponding to) any negotiated unsolicited data.?  If the analogy is
     incorrect, are there any requirements around overlapping R2Ts with
     unsolicited data


     <JS> this is not correct - targets are allowed to send R2T for
     whenever and whatever they find appropriate and that includes
     re-requesting data for failed digests (data blocks).</js>

     To aid understanding, we think it would be useful to have a single
     place to go for a clearly worded description of SCSI data transfers.
     Rather than keeping the above text in Appendix C, we suggest combining
     it with the appropriate text from the descriptions of the ?Ready To
     Transfer? PDU and the ?iSCSI Full Feature Phase? into a new subsection
     under Section 1.2.

     <js> Will try - good idea </js>

     Since R2Ts are always used for SCSI data beyond the initial burst
     size, could we change ?R2T:no? to ?UnsolicitedData:yes??

(e) Typo in Section 1.2.5:  ?no more unsolicited data will not be on this
connection? should probably be ?no more unsolicited data will be sent on
this connection

<js> will fix. R2T will stay </js>

Section 2.2.7 Command data. Since it is being defined specifically for the
SCSI command opcode ( 0x01 ), shouldn?t the statement concerning immediate
data be qualified with respect to the setting of the ?UseR2T? key ?


<js> will fix </js>

Potential Login deadlock ?
The iSCSI spec 02b has an example of user-password authentication in
appendix A, 05, 1st example. It shows that following successful
authentication, when the iSCSI initiator receives the StartSecure: key,
there are a series of ... prior to login accept returned from the iSCSI
target.

Section 1.2.3 iSCSI Login, paragraph 7 states:

   It is expected that iSCSI parameters will be negotiated after the
   security association protocol is established if there is a security
   association.

The ... in the example represent the Text message negotiation of these
iSCSI parameters ( as defined by the receipt of the StartSecure: key ).
Questions:
     ( a )  If the iSCSI initiator doesn't have any parameters to send
     after authentication, how long will the target wait for them before
     giving up and retuning the "accept" Login Response ?
     ( b )  If the iSCSI target responds with an "accept" Login Response
     quickly after sending the StartSecure: key, ending the
     authentication/security exchange, a race condition may occur where the
     iSCSI initiator is sending Text message(s) that have the Initiator
     Task Tag = the Initiator Task Tag used during the Login message which
     indicates that these Text messages are considered part of the Login
     phase.
     What happens then, the target believes Login is done but it receives a
     Text message with the same Initiator Task Tag that was used during the
     Login message, would this cause an error ? How would the iSCSI target
     report the error, no iSCSI error bytes defined in the Text Response
     message.
     ( c )  The spec allows for iSCSI parameter keys to be sent in multiple
     Text messages. If these are sent within the Login phase, how does an
     iSCSI target know when the last Text message has been sent from the
     iSCSI initiator so that it can send the Login "accept" ?
     Its not a problem if they are sent outside of the Login phase since
     the target must wait for iSCSI commands anyway.

To prevent these issues, I think the "EndLogin:HERE" iSCSI key should be
created / defined. It is shown in the example in Apendix A ( iSCSI Security
). I think it should be specifically defined in Apendix C ( Login / Text
keys ).
It could be sent with the last authentication Text message if
authentication parameters are the only parameters the iSCSI initiator will
be sending which would allow an immediate Login Response by the target
after it returns the StartSecure: key.
or
If it is not included in the authentication text message, the target knows
that additional Text messages are coming so it will delay its Login
response until after the key is seen in a Text message payload.
If adopted, the specification should be clear that the EndLogin:HERE key
MUST be included in either the Login payload ( no authentication case ) or
in the last Text message sent by the iSCSI initiator to prevent a deadlock
that could occur should the iSCSI initiator not include this key in any of
its Text messages.


<js> The whole sections undergoes some cleaning including a "partial"
response and a behavior specification (command chaining)  </js>


( 5 ) When can an initiator task tag value repeat, after the task
completes, or after the entire session completes ?
Section 1.2.2.1 paragraph 2 Indicates that it is for the life of the task,
but section 2.1.5 paragraph 1 indicates it is for the life of the session.
I believe the intent is for the life of the task. If it was for the life of
the session, the iSCSI initiator would have to Logout and then Login to
create a new session every time its max initiator task tag threshold was
hit. With ItagLength negotiation set to 16 bits, this would be quite often.

<js>Task tags can be reused when (after) a task is completed and the status
is acked</js>

Section 2.13 Logout Command. Shouldn?t the Logout command include the ISID
and the TSID ? The same CID may exist in an iSCSI initiator capable of
creating multiple iSCSI sessions where the only unique session parameter
may be the TSID. Although the distinction can be made at the IP layer,
shouldn?t it be discernible at the iSCSI layer ?


<js> logout can arrive only within a session so why mention it? <js>


( 7 ) Section 2.2.2 AddCDB Additional CDB length is to be added in units of
4 bytes. Does this mean to add 4 CDB bytes that you set the AddCDB field =
1, or 4 ?

<js> 4</js>

Section 2.12 NOP-In. Should bit 6 of byte 1 = ?P? ( Ping bit ) so that
paragraph 2 will work ? The specification has it set = ?0?.

<js> fixed (typo) </js>

Regards,
Julo


"Hall, Howard" <howard@pirus.com> on 03/01/2001 22:27:09

Please respond to "Hall, Howard" <howard@pirus.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  iSCSI: Questions For You




Julian,

How are you doing?  I hope to see you in Orlando!  Here are a few question
we had for you.  They are based on version 02b, but I think most of them
are
still relevant.

Thanks!!

-Howard

Howard Hall
Pirus Networks
www.pirus.com
 <<Question_for_ietf_2.doc>>